3 Capítulo 3 Marco teórico Capítulo 3 Marco teórico

Transcription

cenidet
Centro Nacional de Investigación y Desarrollo Tecnológico
Departamento de Ciencias Computacionales
TESIS DE MAESTRÍA EN CIENCIAS EN CIENCIAS
DE LA COMPUTACIÓN
Servicios de localización conscientes del contexto aplicando
perfiles de movilidad y tecnologías de localización heterogéneas
presentada por
Israel Arjona Vizcaíno
Ing. en Sistemas Computacionales por el I. T. de Tepic
como requisito para la obtención del grado de:
Maestría en Ciencias en Ciencias de la Computación
Director de tesis:
Dr. Juan Gabriel González Serna
Co-Director de tesis:
Dr. Javier Ortiz Hernández
Jurado:
Dra. Azucena Montes Rendón – Presidente
Dr. José Antonio Zarate Marceleño – Secretario
M.C. Hugo Estrada Esquivel – Vocal
Dr. Juan Gabriel González Serna – Vocal Suplente
Cuernavaca, Morelos, México.
14 de Septiembre de 2009
“2009, Año de la Reforma Liberal”
SUBSECRETARÍA DE EDUCACIÓN SUPERIOR
DIRECCIÓN GENERAL DE EDUCACIÓN SUPERIOR
TECNOLÓGICA
CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO
TECNOLÓGICO
ANEXO No.11
M10
ACEPTACIÓN DEL DOCUMENTO DE TESIS
Cuernavaca, Morelos, 07/septiembre/2009
Dr. Hugo Estrada Esquivel
Jefe del departamento
de Ciencias Computacionales
Presente.
At´n: Dr. Raúl Pinto Elías.
Presidente del Consejo del Posgrado
de Ciencias Computacionales
Nos es grato comunicarle, que conforme a los lineamientos para la obtención del grado de Maestro en
Ciencias de este Centro, y después de haber sometido a revisión académica la tesis titulada “Servicios de
localización conscientes del contexto aplicando perfiles de movilidad y tecnologías de localización
heterogéneas” realizada por el alumno Israel Arjona Vizcaíno y dirigida por el Dr. Juan Gabriel González
Serna y Codirigida por el Dr. Javier Ortiz Hernández, habiendo realizado las correcciones que le fueron
indicadas, acordamos ACEPTAR el documento final de tesis, así mismo le solicitamos tenga a bien extender
el correspondiente oficio de autorización de impresión.
c.c.p.
Dr. Gerardo Reyes Salgado.- Subdirección Académica.
L.I. Guadalupe Garrido Rivera.- Jefe Departamento de Servicios Escolares.
Dr. Juan Gabriel González Serna.- Directores de tesis
Interesado
Interior Internado Palmira s/n Col. Palmira C. P. 62490 Cuernavaca, Morelos, México.
Tel. 777 362 77 70 con 10 líneas Fax : 362 77 95 (directo)
www.cenidet.edu.mx
“2009, Año de la Reforma Liberal”
SUBSECRETARÍA DE EDUCACIÓN SUPERIOR
DIRECCIÓN GENERAL DE EDUCACIÓN SUPERIOR
TECNOLÓGICA
CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO
TECNOLÓGICO
ANEXO No. 12
M11
AUTORIZACIÓN DE IMPRESIÓN DE TESIS
Cuernavaca, Morelos, 07/septiembre/2009
C. Israel Arjona Vizcaíno
Candidato al grado de Maestra en Ciencias
en Ciencias de la Computación
Presente.
Después de haber atendido las indicaciones sugeridas por la Comisión Revisora de la Academia de Ciencias
de la Computación en relación a su trabajo de tesis cuyo título es: “Servicios de localización conscientes
del contexto aplicando perfiles de movilidad y tecnologías de localización heterogéneas”, me es grato
comunicarle que conforme a los lineamientos establecidos para la obtención del grado de Maestro en Ciencias
en este centro se le concede la autorización para que proceda con la impresión de su tesis.
c.c.p.
Dr. Gerardo Reyes Salgado.- Subdirección Académica
Dr. Raúl Pinto Elías.- Presidente de la Academia de Ciencias Computacionales
L.I. Guadalupe Garrido Rivera.- Jefe del Departamento de Servicios Escolares
Expediente
Dedicatoria
A Dios:
Por hacerme un hombre afortunado, ya que nada me ha sido fácil.
A mis padres:
Ramón Arjona Flores y Ernestina Vizcaíno, sé que es poco,
comparado con todo lo que me han dado.
A mis hermanas:
Myriam y Denisse, el triunfo también es suyo, contribuyeron con su
apoyo incondicional.
A mi novia:
Gabriela Marisol, por soportar, mantener y respetar el amor a la
distancia.
Agradecimientos
Difícilmente podré, en tan limitado espacio, agradecer adecuadamente todo y a
todos los que algo debo en relación al trabajo que aquí presento. Si algo tiene de
meritorio, sin duda es fruto de muchos más de los que menciono en estas líneas.
Primero, y a gran distancia del resto, mis padres. Sin su sacrificio, la ayuda de los
que siguen habría sido estéril.
A mis hermanas Denisse y Myriam gracias por apoyarme en todo momento y en
todas mis decisiones, que aunque no siempre son las más acertadas las respetan.
A mis primos Celia Emma y José Luis, y sus hijos Alejandro y Andrea por
brindarme un techo y hacerme sentir como en mi hogar. Su contribución es
especial.
A toda mi familia: abuelos, tíos, sobrinos, primos, son tantos que se necesitaría de
otra tesis para describir el apoyo que he recibido de cada uno de ustedes. Gracias
muchas gracias.
Gracias, por supuesto, al Dr. Juan Gabriel, mi director de tesis. Sus consejos,
correcciones y confianza me señalaron el camino cuando lo necesité.
A los revisores de esta tesis: Dra. Azucena Montes Rendón, Dr. Hugo Estrada
Esquivel y al Dr. José Antonio Zarate Marceleño cuya incansable labor de
jardinería ha hecho posible que este trabajo pueda ser mostrado y no sólo leído.
A mis compañeros de sistemas distribuidos Rubí, Yanet, Omar, Christian y José
Luis por tenderme la mano y por su grata compañía.
A todos mis compañeros de generación, de ingeniería de software y de
inteligencia artificial por la ayuda recibida a lo largo de este tiempo, globalmente
muy positivo.
A todos mis amigos ¡gracias por los buenos momentos! Especialmente a los de
Santa María del Oro y Tepic, Nayarit.
Al Centro Nacional de Investigación y Desarrollo Tecnológico por haberme
permitido pertenecer a su comunidad estudiantil y realizar así mis estudios de
maestría.
Al Consejo Nacional de Ciencia y Tecnología por la beca para manutención
otorgada.
Termino por mi novia Gabriela, precisamente porque, al menos en mi mente y en
mi corazón, ella fue siempre la primera, la razón de mis esfuerzos. ¡Gracias, Gaby!
Resumen
Las tecnologías de información (TI) contextuales o dependientes de la localización
del usuario, están proyectándose como el nuevo paradigma de interacción entre el
usuario y su entorno. Sistemas en donde el usuario recibirá retroalimentación de
información contextual dependiendo del lugar donde se localice.
Estos servicios permitirán, entre otras cosas, realizar las actividades que tiene
programadas en su agenda, las cuales, están relacionadas con una ubicación
especifica, es decir, se define una relación espacio-tiempo, a diferencia de las
agendas tradicionales que únicamente administran actividades atemporales.
En este proyecto se presenta un sistema novedoso que utiliza tecnologías de
auto-identificación como RFID y QRCodes, y teléfonos celulares con sistema
operativo Android para la localización de usuarios dentro de edificios multinivel y
en áreas tipo campus, es decir con varios edificios. Además ofrece la asociación
de objetos del mundo real al sistema de información mediante la autoidentificación, utilizando RFID y QRCodes.
Abstract
Contextual or dependent information technologies are projected as the new
paradigm of interaction between the user and his or her environment. Systems
where the user will receive feedback from contextual information depending on
where it is located.
These services will, among other things, do the activities scheduled on his or her
agenda, which are related to a specific location, i.e. define a relationship between
space and time, unlike traditional agendas which only administer timeless
activities.
This project presents a novel system that uses self-identification technologies such
as RFID and QRCodes, and mobile phones with the Android operating system for
locating users inside multi-level buildings and in campus-type areas, i.e. with
several buildings. The association also offers real-world objects to the information
system by means of self-identification using RFID and QRCodes.
Tabla de contenido
Tabla de contenido __________________________________________________________ i
Listado de figuras __________________________________________________________ iv
Listado de tablas ___________________________________________________________ vi
Glosario de términos y siglas _________________________________________________ vii
1
Capítulo 1 Introducción___________________________________________________ 1
1.1
Introducción ____________________________________________________________ 3
1.2
Antecedentes del proyecto ________________________________________________ 4
1.2.1
API SMS para el Procesamiento de Consultas Georeferenciadas / No Georeferenciadas
[GUERRA 2007] ____________________________________________________________________ 4
1.2.2
Gateway SMS Pull para servicios basados en localización con una arquitectura de servicios
Web [QUIÑONEZ 2007] ______________________________________________________________ 4
2
1.3
Descripción del problema _________________________________________________ 5
1.4
Objetivos del proyecto ____________________________________________________ 6
1.5
Justificación y beneficios del proyecto _______________________________________ 7
1.6
Alcances y limitaciones del proyecto ________________________________________ 8
1.7
Organización del documento _______________________________________________ 8
Capítulo 2 Estado del arte _______________________________________________ 11
2.1
Simple Location-based Application Development for Mobile Phones [TITICA 2007] _ 13
2.2
RADAR: An In-Building RF-based User Location and Tracking System [RADAR 2000] 15
2.3
The Horus WLAN location determination system [HORUS 2004] _________________ 17
2.4
CAALIX Complete Ambient Assisted Living Experiment [CAALIX 2007] ____________ 18
2.5
Location Awareness in Community Wireless LANs [FERSCHA 2001] ______________ 20
2.6
UbiqMuseum: A Bluetooth and Java Based Context-Aware System for Ubiquitous
Computing [CANO 2006] ________________________________________________________ 22
2.7
A Location-aware System using RFID and Mobile Devices for Art Museums
[TESOREIRO 2008] _____________________________________________________________ 25
3
2.8
Comparativa del estado del arte con el proyecto _____________________________ 26
2.9
Servicio UBICACEL de iusacell [UBICACEL 2008]_______________________________ 27
2.10
Servicio Localízame de Movistar [LOCALIZAME 2008]__________________________ 27
2.11
AVL Reach U / Localización y Administración Vehicular Telcel [AVL REACH 2008] ___ 28
2.12
Tramigo [TRAMIGO 2008] ________________________________________________ 28
2.13
Skyhook WPS [SKYHOOK 2008] ____________________________________________ 28
Capítulo 3 Marco teórico ________________________________________________ 31
i
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
Plataformas de dispositivos móviles ________________________________________ 33
Windows Mobile ___________________________________________________________ 33
Symbian __________________________________________________________________ 33
J2ME ____________________________________________________________________ 33
iPhone OS ________________________________________________________________ 33
Android __________________________________________________________________ 33
3.2
REST (Representational StateTransfer) ______________________________________ 34
3.3
JSON__________________________________________________________________ 34
3.4
OSGi __________________________________________________________________ 35
3.5
Servicios basados en localización (LBS) ______________________________________ 35
3.6
Técnicas de posicionamiento______________________________________________ 37
3.6.1
Basadas en redes WAN ______________________________________________________ 37
3.6.1.1
GPS _________________________________________________________________ 37
3.6.1.2
Localización usando GSM ________________________________________________ 38
3.6.2
Basadas en redes LAN _______________________________________________________ 39
3.6.2.1
WiFi ________________________________________________________________ 39
3.6.2.2
RFID ________________________________________________________________ 39
3.6.2.3
Localización por Infrarrojos ______________________________________________ 40
3.6.2.4
Bluetooth ____________________________________________________________ 40
3.6.2.5
Wi-Max ______________________________________________________________ 41
4
Capítulo 4 Análisis y diseño ______________________________________________ 43
4.1
Análisis _______________________________________________________________ 45
4.2
Diseño ________________________________________________________________ 62
4.2.1
Cliente ___________________________________________________________________ 62
4.2.1.1
Paquete mx.edu.cenidet.clientetareasandroid.activities _______________________ 63
4.2.1.2
Paquete mx.edu.cenidet.clientetareasandroid.interfaz ________________________ 65
4.2.1.3
Paquete mx.edu.cenidet.clientetareasandroid.codigobarras ____________________ 67
4.2.1.4
Paquete mx.edu.cenidet.clientetareasandroid.conexionhttp ____________________ 68
4.2.1.5
Paquete mx.edu.cenidet.clientetareasandroid.objetos _________________________ 69
4.2.1.6
Paquete mx.edu.cenidet.clientetareasandroid.rfid ____________________________ 71
4.2.1.7
Paquete mx.edu.cenidet.clientetareasandroid.utilerias ________________________ 72
4.2.2
Servidor de tareas __________________________________________________________ 73
4.2.2.1
Paquete mx.edu.cenidet.servidortareasosgi.basedatos ________________________ 73
4.2.2.2
Paquete mx.edu.cenidet.servidortareasosgi.osgi _____________________________ 74
4.2.2.3
Paquete mx.edu.cenidet.servidortareasosgi.objetos __________________________ 74
4.2.2.4
Paquete mx.edu.cenidet.servidortareasosgi.utilerias __________________________ 76
4.2.2.5
Paquete mx.edu.cenidet.servidortareasosgi.recursosrestlet ____________________ 76
4.2.3
Interacción cliente-servidor___________________________________________________ 77
4.2.3.1
Autentificación del usuario ______________________________________________ 77
4.2.3.2
Consulta de tareas pendientes____________________________________________ 79
4.2.3.3
Consultar el detalle de una tarea pendiente _________________________________ 81
4.2.3.4
Completar/Cancelar una tarea pendiente ___________________________________ 83
4.2.3.5
Dar de alta una nueva tarea (establecer tarea como pendiente) _________________ 85
4.2.3.6
Tarea de guiado _______________________________________________________ 91
4.2.4
Diseño de las URL __________________________________________________________ 96
4.2.5
Diseño del modelo de la base de datos __________________________________________ 99
4.2.6
Diseño de la aplicación Web para la gestión de las tareas __________________________ 101
4.2.6.1
Paquete mx.edu.cenidet.basedatos_______________________________________ 102
ii
4.2.6.2
5
Capítulo 5 Implementación _____________________________________________ 105
5.1
5.1.1
5.1.2
5.1.3
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
5.3
5.3.1
5.3.2
5.3.3
5.3.4
5.3.5
6
7
Paquete mx.edu.cenidet.xmlread ________________________________________ 103
Detalles tecnológicos ___________________________________________________ 107
Cliente __________________________________________________________________ 107
Servidor _________________________________________________________________ 108
Aplicación Web de gestión de tareas __________________________________________ 108
Interacción del sistema cliente-servidor ____________________________________ 108
Autenticación del usuario ___________________________________________________ 108
Consulta de tareas pendientes _______________________________________________ 110
Completar/Cancelar una tarea _______________________________________________ 111
Nueva tarea (establecer una tarea como pendiente) ______________________________ 113
Tarea de guiado por RFID ___________________________________________________ 115
Tarea de guiado por QRCodes ________________________________________________ 117
Interacción de la aplicación Web__________________________________________ 119
Administración de usuarios __________________________________________________ 120
Administración de recursos __________________________________________________ 121
Administración de ubicaciones _______________________________________________ 122
Administración de tareas ____________________________________________________ 124
Administración de tareas de los usuarios _______________________________________ 125
Capítulo 6 Pruebas ____________________________________________________ 127
6.1
Pruebas de configuración y conexiones ____________________________________ 129
6.2
Pruebas de auto-identificación ___________________________________________ 132
6.3
Pruebas de localización y guiado del dispositivo móvil ________________________ 134
6.4
Pruebas de administración de tareas ______________________________________ 138
6.5
Pruebas de administración de la información de la base de datos ______________ 142
Capítulo 7 Conclusiones ________________________________________________ 157
7.1
Conclusiones __________________________________________________________ 159
7.2
Aportaciones __________________________________________________________ 159
7.3
Trabajos futuros _______________________________________________________ 160
7.4
Publicaciones _________________________________________________________ 161
Anexos___________________________________________________________________ 163
Anexo A Definición de la interfaz de usuario _______________________________________ 165
Anexo B Plan de pruebas T-Guide _______________________________________________ 171
Referencias _______________________________________________________________ 189
iii
List ado de figuras
Figura 1.1 Tecnologías inalámbricas _________________________________________________________ 4
Figura 2.1 Sistema de localización por ángulo de llegada ________________________________________ 14
Figura 2.2Plano utilizado sistema RADAR [RADAR 2000] ________________________________________ 16
Figura 2.3 Arquitectura proyecto CAALIX [CAALIX 2007]_________________________________________ 19
Figura 2.4 Proceso de localización CampusSpace ______________________________________________ 20
Figura 2.5 Arquitectura del sistema CampusSpace [FERSCHA 2001] _______________________________ 21
Figura 2.6 Descripción RDF de un miembro del staff [FERSCHA 2001] ______________________________ 21
Figura 2.7 Arquitectura del sistema UbiqMuseum [CANO 2006] __________________________________ 23
Figura 2.8 Información recibida en un cliente en UbiqMuseum [CANO 2006] ________________________ 24
Figura 2.9 Modelo conceptual [TESOREIRO 2008]______________________________________________ 26
Figura 3.1 LBS como intersección de tecnologías ______________________________________________ 36
Figura 3.2 Clasificación de las técnicas globales de posicionamiento _______________________________ 37
Figura 3.3 Esquema de la localización por GPS ________________________________________________ 38
Figura 4.1 Diagrama de bloques del proceso de comunicación entre el cliente y el servidor _____________ 45
Figura 4.2 Diagrama general de casos de uso _________________________________________________ 46
Figura 4.3 Diagrama del caso de uso CU-1 Consultar tareas pendientes ____________________________ 46
Figura 4.4 Diagrama de actividad del caso de uso CU-1 Consultar tareas pendientes __________________ 47
Figura 4.5 Diagrama de actividad del caso de uso CU-1.2 Listado de tareas pendientes ________________ 48
Figura 4.6 Diagrama del caso de uso CU-1.1 Verificar contexto ___________________________________ 49
Figura 4.7 Diagrama de actividad del caso de uso CU-1.1 Verificar contexto _________________________ 50
Figura 4.8 Diagrama de actividad del caso de uso CU-1.1.1 Consultar por RFID ______________________ 51
Figura 4.9 Diagrama de actividad del caso de uso CU-1.1.2 Consultar por barras _____________________ 52
Figura 4.10 Diagrama de actividad del caso de uso CU-1.1.3 Obtener ubicación ______________________ 54
Figura 4.11 Diagrama del caso de uso CU-2 Alta de tarea _______________________________________ 55
Figura 4.12 Diagrama de actividad del caso de uso CU-2 Alta de tarea _____________________________ 57
Figura 4.13 Diagrama del caso de uso CU-2.1 Seleccionar tarea de guiado __________________________ 57
Figura 4.14 Diagrama de actividad del caso de uso CU-2.1 Seleccionar tarea de guiado ________________ 59
Figura 4.15 Diagrama del caso de uso CU-3 Completar tarea_____________________________________ 59
Figura 4.16 Diagrama de actividad del caso de uso CU-3 Completar tarea __________________________ 60
Figura 4.17 Diagrama del caso de uso CU-4 Cancelar tarea ______________________________________ 61
Figura 4.18 Diagrama de actividad del caso de uso CU-4 Cancelar tarea ____________________________ 62
Figura 4.19 Diagrama de paquetes del cliente ________________________________________________ 63
Figura 4.20 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.activities ____________ 63
Figura 4.21 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.interfaz _____________ 65
Figura 4.22 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.codigobarras ________ 67
Figura 4.23 Diagrama de secuencias para la decodificación del código de barras _____________________ 68
Figura 4.24 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.conexionhttp _________ 69
Figura 4.25 Diagrama de secuencias comunicación cliente/servidor por HTTP _______________________ 69
Figura 4.26 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.objetos _____________ 70
Figura 4.27 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.rfid ________________ 71
Figura 4.28 Diagrama de secuencias para el proceso de lectura de tarjeta RFID ______________________ 71
Figura 4.29 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.utilerias _____________ 72
Figura 4.30 Diagrama de paquetes del servidor _______________________________________________ 73
Figura 4.31 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.basedatos ___________ 74
Figura 4.32 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.osgi ________________ 74
Figura 4.33 Diagrama de clases del paquete mx.edu.cenidet.servidortareasosgi.objetos _______________ 75
Figura 4.34 Diagrama de clases del paquete mx.edu.cenidet.servidortareasosgi.utilerias ______________ 76
Figura 4.35 Diagrama de clases del paquete mx.edu.cenidet.servidortareasosgi.recursosrestlet _________ 76
Figura 4.36 Diagrama de secuencias para la autenticación del usuario _____________________________ 78
Figura 4.37 Diagrama de secuencias para la consulta de tareas pendientes _________________________ 80
iv
Figura 4.38 Diagrama de secuencias para la consulta del detalle de una tarea _______________________ 82
Figura 4.39 Diagrama de secuencias para la operación de completar o cancelar una tarea _____________ 84
Figura 4.40 Diagrama de secuencias para la obtención de un listado de actividades disponibles para el
usuario _______________________________________________________________________________ 86
Figura 4.41 Diagrama de secuencias para la obtención de un listado de tareas disponibles para el usuario_ 88
Figura 4.42 Diagrama de secuencias para la operación establecer una tarea como pendiente (nueva tarea) 90
Figura 4.43 Diagrama de secuencias para la operación obtener la ubicación actual del dispositivo _______ 92
Figura 4.44 Diagrama de secuencias para la operación de obtener un listado de ubicaciones ___________ 94
Figura 4.45 Diagrama de secuencias de la tarea de guiado por RFID _______________________________ 95
Figura 4.46 Diagrama de secuencias de la tarea de guiado con QRCodes ___________________________ 96
Figura 4.47 Modelo físico de la base de datos________________________________________________ 100
Figura 4.48 Casos de uso de la aplicación Web _______________________________________________ 102
Figura 4.49 Diagrama de paquetes de la aplicación Web _______________________________________ 102
Figura 4.50 Diagrama de clases paquete mx.edu.cenidet.basedatos ______________________________ 103
Figura 4.51 Diagrama de clases paquete mx.edu.cenidet.xmlread ________________________________ 103
Figura 5.1 Detalles tecnológicos del proyecto ________________________________________________ 107
Figura 5.2 Pantalla inicial del sistema ______________________________________________________ 109
Figura 5.3 Pantalla de datos erróneos ______________________________________________________ 109
Figura 5.4 Diagrama de flujo del proceso de autenticación _____________________________________ 110
Figura 5.5 Pantalla de Tareas Pendientes ___________________________________________________ 110
Figura 5.6 Pantalla de detalles de tarea ____________________________________________________ 111
Figura 5.7 Diagrama de flujo del proceso de consulta de tareas pendientes ________________________ 111
Figura 5.8 Pantalla de detalles de tarea ____________________________________________________ 112
Figura 5.9 Pantalla de listado de tareas con mensaje de tarea completada_________________________ 112
Figura 5.10 Error en la operación _________________________________________________________ 112
Figura 5.11 Diagrama de flujo del proceso de completar/cancelar una tarea _______________________ 113
Figura 5.12 Pantallas involucradas en el proceso de alta de tarea ________________________________ 114
Figura 5.13 Diagrama de flujo de alta de nueva tarea _________________________________________ 115
Figura 5.14 Diagrama de flujo del proceso de guiado por RFID __________________________________ 116
Figura 5.15 Pantallas involucradas en el proceso de guiado por RFID _____________________________ 117
Figura 5.16 Diagrama de flujo del proceso de guiado por QRCodes _______________________________ 118
Figura 5.17 Pantallas involucradas en el proceso de guiado por QRCodes __________________________ 119
Figura 5.18 Pantalla principal de la aplicación Web ___________________________________________ 120
Figura 5.19 Pantallas del módulo de administración de usuarios _________________________________ 121
Figura 5.20 Pantallas del módulo de administración de recursos _________________________________ 122
Figura 5.21 Pantalla de alta de campus ____________________________________________________ 123
Figura 5.22 Pantalla de captura de ubicaciones ______________________________________________ 124
Figura 5.23 Pantalla de alta de tareas _____________________________________________________ 125
Figura 5.24 Pantalla de activación de tarea de usuarios ________________________________________ 125
v
List ado de tablas
Tabla 1 Comparativa de los trabajos relacionados con el proyecto de tesis __________________________ 27
Tabla 2 Comparativa de los servicios de localización ___________________________________________ 29
Tabla 3 Descripción del caso de uso CU-1 Consultar tareas pendientes _____________________________ 46
Tabla 4 Descripción del caso de uso CU-1.2 Listado de tareas pendientes ___________________________ 47
Tabla 5 Descripción del caso de uso CU-1.1 Verificar contexto ____________________________________ 49
Tabla 6 Descripción del caso de uso CU-1.1.1 Consultar por RFID __________________________________ 50
Tabla 7 Descripción del caso de uso CU-1.1.2 Consultar por Barras ________________________________ 51
Tabla 8 Descripción del caso de uso CU-1.1.3 Obtener ubicación __________________________________ 52
Tabla 9 Descripción del caso de uso CU-2 Alta de tarea _________________________________________ 55
Tabla 10 Descripción del caso de uso CU-2.1 Seleccionar tarea de guiado ___________________________ 58
Tabla 11 Descripción del caso de uso CU-3 Completar tarea _____________________________________ 59
Tabla 12 Descripción del caso de uso CU-4 Cancelar tarea _______________________________________ 61
Tabla 13 Caso de prueba T-Guide-001-001 __________________________________________________ 129
Tabla 29 Resumen de los casos de prueba de la plataforma propuesta ____________________________ 156
Tabla 30 Tareas a desarrollar para las pruebas ______________________________________________ 172
Tabla 31 Tecnología física utilizada ________________________________________________________ 173
Tabla 32 Tecnología de programación utilizada ______________________________________________ 173
Tabla 33 Características a probar de la aplicación ____________________________________________ 174
vi
Glosario de términos y siglas
GPRS
General Packet Radio Service. Servicio General de Paquetes por Radio.
Es una tecnología digital de telefonía móvil. Es considerada la
generación 2.5, entre la segunda generación (GSM) y la tercera
(UMTS). Proporciona altas velocidades de transferencia de datos
(especialmente útil para conectar a Internet) y se utiliza en las redes
GSM.
GPS
Global Positioning System. Sistema de Posicionamiento Global. Sistema
Global de Navegación por Satélite que permite determinar en todo el
mundo la posición de un objeto.
GSM
Global System for Mobile communications. Sistema Global para las
Comunicaciones Móviles. Formalmente conocida como “Group Special
Mobile” (GSM, Grupo Especial Móvil) es un estándar mundial para
teléfonos móviles digitales.
HTTP
HyperText Transfer Protocol. Protocolo de transferencia de hipertexto.
Protocolo desarrollado por la W3C para la transferencia de información
a través de la Web. Es un protocolo sin estado –no guarda información
sobre conexiones anteriores- y está basado en el modelo de clienteservidor.
IEEE
Institute of Electrical and Electronics Engineers. Instituto de Ingenieros
Eléctricos y Electrónicos, una asociación técnicoprofesional mundial
dedicada a la estandarización, entre otras cosas. Es la mayor
asociación internacional sin fines de lucro formada por profesionales de
las nuevas tecnologías, como ingenieros de telecomunicaciones,
ingenieros electrónicos, Ingenieros en informática e Ingenieros en
computación.
LBS
Location Based Services. Los Servicios Basados en Localización
buscan ofrecer un servicio personalizado a los usuarios basado en
información de ubicación geográfica de estos.
OSGI
Open Services Gateway Initiative. Fue creado en Marzo de 1999. Su
objetivo es definir las especificaciones abiertas de software que permita
diseñar plataformas compatibles que puedan proporcionar múltiples
servicios. Fue pensado principalmente para su aplicación en redes
domésticas y por ende en la llamada Domótica o informatización del
hogar.
PostgreSQL
Servidor de base de datos libre desarrollado en su primera versión con
el nombre de Ingres, proyecto desarrollado en la universidad de
Berkeley. Considerado como el referente a los sistemas manejadores
de base de datos libres.
QRCODES
QRCodes. Es un sistema para almacenar información en una matriz de
vii
puntos o un código de barras bidimensional creado por la compañía
japonesa Denso-Wave en 1994; se caracterizan por los tres cuadrados
que se encuentran en las esquinas y que permiten detectar la posición
del código al lector. La sigla "QR" se derivó de la frase inglesa "Quick
Response" pues el creador aspiraba a que el código permitiera que su
contenido se leyera a alta velocidad. Los códigos QR son muy comunes
en Japón y de hecho son el código bidimensional más popular en ese
país.
RFID
SMS
Radio Frequency Identification. Es un sistema de almacenamiento y
recuperación de datos remoto que usa dispositivos denominados
etiquetas, transpondedores o tags RFID. El propósito fundamental de la
tecnología RFID es transmitir la identidad de un objeto (similar a un
número de serie único) mediante ondas de radio. Las tecnologías RFID
se agrupan dentro de las denominadas Auto ID (automatic identification,
o identificación automática).
Short Message Service. Servicio de mensajería corto. Es un servicio
disponible en los teléfonos móviles que permite el envío de mensajes
cortos entre teléfonos móviles, teléfonos fijos y otros dispositivos de
mano.
TDMA
Time Division Multiple Access. Tecnología que distribuye las unidades
de información en alternantes slots de tiempo proveyendo acceso
múltiple a un reducido número de frecuencias. TDMA es una tecnología
inalámbrica de segunda generación que brinda servicios de alta calidad
de voz y datos. Divide un único canal de frecuencia de radio en seis
ranuras de tiempo. A cada persona que hace una llamada se le asigna
una ranura de tiempo específica para la transmisión, lo que hace posible
que varios usuarios utilicen un mismo canal simultáneamente sin
interferir entre sí.
WIFI
Wi-Fi es un sistema de envío de datos sobre redes computacionales
que utiliza ondas de radio en lugar de cables, además es una marca de
la Wi-Fi Alliance (anteriormente la WECA: Wireless Ethernet
Compatibility Alliance), la organización comercial que adopta, prueba y
certifica que los equipos cumplen los estándares 802.11.
WLAN
Wireless Local Area Network. Es un sistema de comunicación de datos
inalámbrico flexible, muy utilizado como alternativa a las redes LAN
cableadas o como extensión de éstas. Utiliza tecnología de
radiofrecuencia que permite mayor movilidad a los usuarios al minimizar
las conexiones cableadas. Las WLAN van adquiriendo importancia en
muchos campos, como almacenes o para manufactura, en los que se
transmite la información en tiempo real a una terminal central. También
son muy populares en los hogares para compartir el acceso a Internet
entre varias computadoras.
viii
1 Capítulo 1 Introducción
Capítulo 1 Introducción
En este capítulo se muestran los antecedentes que existen sobre el trabajo de
tesis desarrollado, el problema a abordar junto con la motivación y justificación del
desarrollo de esta tesis. Por último se muestra la manera en que se encuentra
estructurado el documento.
1.1 Introducción
La localización de usuarios en el interior de edificios multinivel es un área de
oportunidad en donde se puede potenciar la utilización de teléfonos celulares o
dispositivos móviles. Estos servicios de localización en interiores permiten
desarrollar innumerables aplicaciones gracias a la posibilidad de ubicar en tiempo
real a objetos o personas. Algunos de los principales servicios están relacionados
con el control de acceso a instalaciones, la seguridad en red basada en la
localización física de los usuarios, la gestión de las instalaciones que permite el
ahorro energético, el servicio de emergencia y estadísticas.
Sin embargo, las aplicaciones de mayor interés comercial provienen del
posicionamiento contextual (context-aware), las cuales requieren aplicaciones que
reaccionan ante los cambios de contexto de los usuarios, identificando su posición
y los recursos cercanos a él. Esto significa que el dispositivo del usuario estará
consiente de la proximidad de objetos, personas y obviamente de su ubicación en
el interior de un edificio que puede ser multinivel; esta capacidad de conciencia
contextual, abre la puerta para una gran cantidad de nuevos y novedosos
servicios. La información y servicios que necesita el usuario se le pueden ofrecer
en el momento y lugar que los requiere. De este modo el espacio de trabajo de los
usuarios puede ser adaptado, se permite el acceso a publicidad relevante y se
ofrece un guiado para que el usuario complete sus tareas del día a día, entre otras
muchas posibles aplicaciones.
Diversas circunstancias han impulsado el desarrollo de los sistemas de
posicionamiento. Ejemplo de ello, en la mayor economía del mundo (EEUU) estas
tecnologías cobraron especial interés a raíz de un mandato legislativo promulgado
por la Comisión Federal de Comunicaciones (Federal Communications
Commission, FCC). La FCC decidió hace seis años que en diciembre de 2005 las
operadoras de telefonía tendrían que ser capaces de localizar automáticamente a
cualquier persona que efectuara una llamada de emergencia con una precisión de
50 a 100 metros.
Con estas condiciones de contorno, se hace evidente ver escenarios en los que
los usuarios deambulan por las distintas redes, de forma que inician conexiones
en una tecnología concreta y, a lo largo de las mismas, se producen traspasos a
otras, en virtud de atributos relativos a la calidad de servicio, costo u otras
consideraciones que pueden emanar tanto desde la perspectiva de los usuarios
como del propio operador.
La figura 1.1 muestra un pequeño bosquejo de lo siguiente: los dispositivos
celulares actuales cuentan con un gran número de tecnologías de conectividad, a
las cuales pueden aplicarse técnicas para localizarlos y aprovechar todos estos
dispositivos que traen inmersos los celulares hoy en día.
3
Figura 1.1 Tecnologías inalámbricas
1.2 Antecedentes del proyecto
En el CENIDET, específicamente en el área de sistemas distribuidos, se han
realizado trabajos relacionados con el cómputo móvil. Los trabajos centran su
atención en diversas problemáticas que existen en esta área -problemas de
visualización en dispositivos móviles, interoperabilidad entre plataformas,
problemas de conexión- y principalmente en el desarrollo tecnológico que aportan
estas investigaciones. Los antecedentes inmediatos de este trabajo son los
siguientes.
1.2.1 API SMS para el Procesamiento de Consultas Georeferenciadas /
No Georeferenciadas [GUERRA 2007]
En esta tesis se desarrolló una API que permite el desarrollo de aplicaciones LBS
para dispositivos móviles utilizando el sistema GPS como técnica de
posicionamiento y el Servicio Mensajería Corta (SMS por sus siglas en inglés)
como medio de transporte.
En esta tesis se desarrollaron un conjunto de funciones que permiten implementar
aplicaciones en dispositivos móviles para procesar consultas georeferenciadas y
no georeferenciadas utilizando mensajería SMS.
1.2.2 Gateway SMS Pull para servicios basados en localización con
una arquitectura de servicios Web [QUIÑONEZ 2007]
En esta tesis se implementó la arquitectura de una plataforma para proporcionar
servicios basados en localización a través de mensajería SMS, utilizando la
ubicación del dispositivo, expresada en coordenadas geográficas para ubicar los
puntos de interés que se encuentran cerca, por medio de una base de datos
espacial y tecnologías de los servicios Web para resolver información externa
basada en localización.
Para ello se desarrolló un gateway –pasarela- que permite el procesamiento de los
mensajes SMS, los procesa y retorna información – contenida localmente en una
4
base de datos espacial o externa por tecnologías de servicios Web- acorde con la
ubicación del dispositivo móvil. Se proporcionan servicios basados en localización
sin la restricción de la red celular sobre la que opera el dispositivo y con las
ventajas que proporcionan las tecnologías de los servicios Web a través del
referente de la telefonía celular, la mensajería de SMS.
La particularidad de estas tesis es que únicamente enfocaban sus esfuerzos al
posicionamiento GPS.
1.3 Descripción del problema
El avance y la creciente difusión de las comunicaciones inalámbricas, la evolución
de las tecnologías de sensores y localización, y de las tecnologías de la
computación, permiten pensar en una nueva forma de interactuar con el medio
que nos rodea, que se ha venido a definir como la conformación de un espacio
―inteligente‖. En Europa existe el concepto de Inteligencia Ambiental (AmI),
promovido especialmente por la Comisión Europea. Según [CASAR 2007] plantea
un escenario a medio o largo plazo en el que los ciudadanos compran, trabajan o
descansan rodeados de interfaces inteligentes soportadas por tecnologías de
computación y de comunicación ubicuas y transparentes.
Los dispositivos modernos cuentan con una gran cantidad de interfaces
inalámbricas (IEEE 802.11 a/b/g, IEEE 802.15, GPS, GSM, WiMax, RFID) que
permiten aplicar técnicas de localización. La tendencia en tecnologías móviles es
la convergencia hacia varias tecnologías. Existen gran diversidad de técnicas de
localización que funcionan bien para ciertos escenarios, algunas son buenas para
interiores (indoor), como las utilizadas con redes IEEE 802.11b/g (WiFi), IEEE
802.15.1 (Bluetooth) y IEEE 802.15.4 (RFID), y otras en exteriores (outdoor), como
GPS y técnicas en GSM.
GPS es una tecnología de posicionamiento muy buena en exteriores, sin embargo
pierde su precisión debido a obstáculos como paredes y techos, y el error que
puede presentar es inadmisible. Es por ello que se necesita contar con técnicas de
localización heterogéneas que sean conscientes de su contexto y de este modo
aprovechen todas las opciones de conectividad inalámbrica presentes en el
dispositivo que se quiere localizar, para poder ubicar a un dispositivo de una
manera exacta en cualquier lugar y en cualquier momento (siempre y cuando haya
conectividad GSM).
La problemática de la localización en interiores ha sido objeto de un intenso
estudio e investigación durante los últimos años. Se han propuesto diversas
técnicas de localización en WiFi, Bluetooth, RFID e infrarrojos. Hasta ahora,
ninguna de las soluciones propuestas ha conseguido el éxito que han alcanzado
los sistemas de localización y navegación análogos empleados en exteriores,
sobre todo el GPS. Las razones de este fracaso han sido técnicas y sobre todo
económicas: técnicas porque la localización en interiores plantea retos
5
tecnológicos muy superiores a los de la localización en espacios abiertos y
económicas porque la mayor parte de los sistemas propuestos utilizan gran
cantidad de infraestructuras fijas (sensores, puntos de control, estaciones base,
etc.), lo que hace aumentar mucho el costo. Además el error en interiores tiene
que ser muy bajo ya que un error grande significaría un error inadmisible en la
ubicación del usuario. Cabe destacar que si no se utilizan técnicas de
optimización, la precisión es inversamente proporcional al alcance de la
tecnología, es decir, a mayor alcance menor precisión y viceversa.
Actualmente una de las tecnologías que está siendo muy utilizada (poco en el
ámbito de la localización) es RFID, sobre todo en la unión europea y puede
aplicarse en la automatización de las actividades del día a día, mediante la
asociación de objetos del mundo real a los sistemas de información. Con la
aplicación de estas tecnologías en el ámbito de los teléfonos móviles, los servicios
basados en localización (por sus siglas en inglés LBS-Location Based Services)
pueden verse enriquecidos con mayor información de contexto y con una mayor
precisión de localización.
La mayoría de los dispositivos actuales cuentan con una cámara fotográfica
integrada, la cual puede aprovecharse para decodificar QRCodes que estén
asociados a una ubicación y de este modo obtener la posición del usuario cuando
lo desee.
1.4 Objetivos del proyecto
El objetivo general del proyecto de tesis es el siguiente:
―Desarrollar servicios conscientes del contexto que permitan la localización de
dispositivos celulares a través tecnologías de posicionamiento heterogéneas
(GPS, identificación de células, WiFi, Bluetooth, RFID y QRCodes) mediante la
constante verificación del contexto del usuario‖.
Para el cumplimiento del objetivo general, se han desarrollado los objetivos
específicos que se describen a continuación:
i.
ii.
iii.
iv.
Realizar una prueba de concepto, implementación y modelo mediante un
sistema de localización consciente del contexto.
Identificación y análisis de limitaciones tecnológicas y de servicio para estas
familias de aplicaciones con tecnologías emergentes de localización,
gestión de comunicaciones y de intercambio de contenidos, que permitirán
subsanar progresivamente las deficiencias de servicio detectadas.
Contribuir al desarrollo de los servicios móviles y ubicuos, estudiando y
analizando las tecnologías de comunicaciones, su interoperabilidad,
aplicaciones y limitaciones.
Ampliar el uso de la inteligencia en el acceso a la información, mediante el
desarrollo de un software que seleccione la información relevante en el
6
v.
momento preciso (conciencia del contexto), teniendo en cuenta la ubicación
del usuario.
Hacer uso de la metodología orientada a componentes con el fin de hacer
reutilizable la aplicación.
1.5 Justificación y beneficios del proyecto
En los últimos años los servicios de localización en redes inalámbricas se están
convirtiendo en un servicio clave para todo operador. La razón del creciente
interés en este tipo de servicios reside en el hecho de que la información de
localización constituye un servicio en sí mismo (p. ej. un usuario desea conocer su
posición en un determinado instante), al tiempo que dicha información puede
emplearse para la construcción de servicios de valor añadido en los que el usuario
no solicite la posición de forma explícita, pero el servicio solicitado sí requiera de
ella para llevarse a cabo (p. ej. guiado, farmacia de guardia más cercana, etc.)
[DRANE 1998]. Además, las exigencias establecidas por parte de diversos
reguladores (p. ej. FCC, UE, etc.) hacen que los servicios de localización estén
cada vez más presentes en las redes celulares públicas actuales [ESCALONA
2007].
La disponibilidad de este tipo de servicios puede ser aprovechada por los
operadores de red más allá de la percepción económica que se espera de ellos.
De esta forma, la información de localización de los usuarios de la red puede
emplearse para optimizar el funcionamiento de la misma [LEE 2001], empleando
por ejemplo sistemas inteligentes de buscapersonas, modelos de traspaso
basados en la localización del usuario y la previsión de sus movimientos, la
reserva de recursos en función del patrón de movimiento de los distintos usuarios
de la celda, etc.
La problemática de la localización en interiores ha sido objeto de un intenso
estudio e investigación durante los últimos años. En varios proyectos se describe
como han ido evolucionando los sistemas basados en localización y pasaron de
ser reactivos, en donde el usuario solicitaba referencias según su ubicación a ser
proactivos en donde se verifica el contexto para ofrecer servicios al usuario.
Hasta ahora, ninguna de las soluciones propuestas ha conseguido el éxito que
han alcanzado los sistemas de localización y navegación análogos empleados con
mucho éxito en entornos urbanos, como lo es el sistema de posicionamiento
global (GPS por sus siglas en inglés) o los sistemas híbridos empleados por las
compañías de telefonía celular (AGPS), los cuales no son adecuados para
identificar la ubicación de un usuario que se encuentra dentro de un edificio.
En resumen, se pueden identificar dos factores que han determinado el fracaso de
estas técnicas de localización al interior de edificios, uno es técnico y otro
económico, es decir, el factor técnico se enfrenta a retos tecnológicos muy
superiores a los de la localización en espacios abiertos, las exigencias de
7
precisión en este tipo de sistemas incluyen un error medio menor a 2 metros; por
otro lado, el factor económico porque la mayor parte de los sistemas propuestos
en los trabajos relacionados utilizan gran cantidad de infraestructura fija (sensores,
puntos de control, estaciones base, etc.), lo que hace aumentar mucho el costo de
estos sistemas de localización.
Desarrollar una técnica que sea viable y factible tanto económica como
técnicamente, y además ofrezca una gran precisión de ubicación significa poder
ofrecer una gran cantidad de servicios a los usuarios dependiendo de su contexto
y de su ubicación.
1.6 Alcances y limitaciones del proyecto
El proyecto puede volverse muy amplio debido a la gran diversidad de tecnologías
y, para cada una de ellas una variedad de técnicas de localización, si a esto le
agregamos la convergencia de estas técnicas, resulta un problema sumamente
complejo, es por ello que hemos definido las siguientes consideraciones para el
proyecto:
Para el desarrollo del proyecto partiremos del hecho de que el entorno en el
que se quiere localizar al dispositivo tiene al menos cobertura GSM.
Se trabajará en técnicas de posicionamiento utilizando RFID y QRCodes.
Trabajará con tecnología GSM en los rangos de frecuencia 850/1900 y
900/1800.
El medio de transmisión será HTTP.
Los dispositivos celulares que se utilizarán son dispositivos que soporten el
sistema operativo Android y que tengan conectividad WiFi.
El proyecto no contemplará lo siguiente:
Redes WiFi para el estándar 802.11a\b\g,
Redes Bluetooth 802.15.
Se limitará a algunos dispositivos celulares, no para todas las marcas y
modelos.
No se trabajará con redes 802.16 (Wi-Max) debido a que no se tiene la
infraestructura para hacerlo.
1.7 Organización del documento
El documento se encuentra organizado en 6 capítulos, los cuales presentan la
siguiente información:
i.
Capítulo 2: Estado del arte. Se presentan trabajos relacionados con el
proyecto de tesis, desarrollados recientemente.
8
ii.
iii.
iv.
v.
vi.
vii.
viii.
Capítulo 3: Marco Teórico. Se presentan los fundamentos teóricos de las
diferentes tecnologías usadas y su forma de operación. Asimismo, se
describen los conceptos utilizados en el desarrollo del documento.
Capítulo 4: Análisis y Diseño. Se muestran los casos de uso, escenarios,
diagramas de actividad, clases y secuencia que representan el análisis y
diseño de las aplicaciones que resultan del proyecto.
Capítulo 5: Implementación. Se presenta la implementación de la
arquitectura y la forma en que colaboran los diferentes módulos que la
conforman. Se describen las interfaces de usuario desarrolladas para su
manejo y se menciona la relación entre cada uno de los módulos de las
aplicaciones.
Capítulo 6: Pruebas. Se presentan los resultados de las pruebas.
Capítulo 7: Conclusiones. Se presentan las aportaciones de la tesis, los
trabajos futuros y las publicaciones realizadas durante el desarrollo de la
tesis.
Anexo A: Definición de las interfaces de usuario. Se muestran las interfaces
de usuario desarrolladas para el dispositivo celular con el sistema operativo
Android.
Anexo B: Plan de pruebas. Describe el plan de pruebas basado en el IEEE
std 829.
9
2 Capítulo 2 Estado del arte
Capítulo 2 Estado del arte
En este capítulo se describen los trabajos relacionados y estado del arte que
influyen para el desarrollo del presente trabajo.
Capítulo 2 Estado del Arte
A continuación se describen y se evalúan algunos artículos, relacionados con el
tema de tesis, extraídos en su mayoría de memorias de congresos recientes
(2006-2008) de la IEEE.
2.1 Simple Location-based Application Development for Mobile
Phones [TITICA 2007]
Se da una descripción general acerca de algunas de los componentes más
importantes y servicios necesarios para construir aplicaciones basadas en
localización. Se enfatiza que una de las tareas más importantes para realizar un
sistema basado en localización, es la determinación de la posición de las
terminales móviles, es por esto que se centra en la descripción de técnicas de
posicionamiento GSM. Describe las siguientes:
Tiempo de llegada (Time of Arrival, TOA)
Esta técnica se basa en la medición del tiempo de llegada de una señal
transmitida por un terminal móvil a diferentes estaciones base. Para efectuar el
cálculo, una posibilidad es medir el tiempo de ida y vuelta de la señal. De esta
manera la distancia recorrida por la señal se calcula como producto del tiempo
empleado en llegar a la BTS (estación base) y la velocidad de la luz.
Mediante TOA es necesario efectuar medidas al menos respecto a tres estaciones
base para obtener una precisión aceptable en el cálculo de la posición de un
terminal. Las medidas permiten trazar circunferencias con centro en cada una de
las BTS, dando su intersección como resultado el punto donde se encuentra el
terminal que se desea localizar. Posteriormente se transmiten al servidor de
localización, que realiza los cálculos y corrige los errores utilizando métodos
matemáticos. Estos errores pueden deberse al tiempo de procesado en el
terminal, el cual depende del fabricante y también de la situación de carga del
dispositivo en un momento determinado. Otra desventaja que presenta esta
técnica es que la ausencia de visión directa entre el terminal y la estación base
puede causar un error que desemboque en una falsa estimación.
Cell ID
Esta técnica de localización (Cell Global Identity-CGI) está disponible sin realizar
ninguna inversión ni modificación en red o terminal, pues la posición se obtiene
mediante la identidad de la celda en la que se encuentra el terminal móvil. La
precisión de este método puede ir de algunos cientos de metros en áreas urbanas
hasta 32 kilómetros en áreas rurales.
Ángulo de llegada (Angle of Arrival, AOA o Direction of Arrival, DOA)
Este método utiliza antenas multi-arreglo situadas en la estación base para
determinar el ángulo de la señal incidente. Si un terminal que transmite una señal
13
está en la línea de vista directa (LOS, Line Of Sight), la antena multi-arreglo puede
determinar de qué dirección viene la señal. Para conocer la posición del terminal
es necesaria al menos una segunda estimación procedente de otra estación base
con la misma tecnología que la primera. La segunda estación base localizará al
terminal y comparará sus datos con los de la primera estación para después
calcular la posición del usuario mediante trigonometría. En principio sólo son
necesarias dos estaciones base para estimar la posición del terminal móvil, por
este motivo AOA resulta efectiva en entornos rurales, donde es complicado
disponer de visión de tres estaciones base al mismo tiempo. Pero en condiciones
adversas (entornos urbanos) suele ser imprescindible emplear más estaciones con
el fin de obtener mayor precisión.
Figura 2.1 Sistema de localización por ángulo de llegada
Los sistemas AOA deben diseñarse para tener en cuenta señales multitrayecto,
aquéllas que son consecuencia de una reflexión y que por tanto llegan a la antena
con un ángulo erróneo. Por otra parte, la instalación y alineación de las antenas
multi-arreglo en las estaciones base es un proceso complicado y caro. Además, si
las antenas sufren una leve modificación en su orientación debido al viento o las
tormentas se pueden producir errores considerables en la estimación, ya que ésta
se realiza en base a ángulos absolutos respecto de la antena.
Diferencia de tiempo de observado mejorado (Enhanced Observed Time
Difference, E-OTD)
La técnica E-OTD opera sobre redes GSM y GPRS e incluye nueva tecnología
tanto en el terminal móvil como en la red. Siendo la solución de red similar a l a
utilizada en TDOA, el sistema necesita que se instalen unidades de medida de
posición (Location Measurement Units - LMU) a modo de balizas de referencia en
puntos dispersos geográficamente. La densidad de LMUs determinará la precisión
del sistema, y por ello normalmente es necesario instalar en toda la red una LMU
por cada una o dos estaciones base. Estos receptores y los terminales móviles
habilitados con software E-OTD realizan medidas de las señales procedentes de
tres o más estaciones base periódicamente. Las diferencias temporales de llegada
de la señal a los dos puntos (LMU y terminal) se combinan para producir líneas
hiperbólicas que se intersecan en el lugar donde está el terminal móvil, ofreciendo
de esta manera localización en dos dimensiones.
14
En E-OTD el terminal móvil mide la diferencia de tiempo de llegada de las ráfagas
de pares cercanos de estaciones base. Si estas estaciones no están sincronizadas
(como es el caso de las redes GSM), la red debe evaluar el desfase entre ellas
para poder estimar las diferencias de tiempo relativas (Relative Time Difference RTD). Con el fin de obtener un resultado preciso, se necesitan medidas de la
diferencia de tiempo observado (Observed Time Difference) y RTD de tres pares
de estaciones base separadas en el espacio. Una vez obtenidas las medidas, el
cálculo de la posición puede estar asistido por red, si el terminal móvil mide la
señal de OTD y la red le proporciona la información de las coordenadas de las
BTS y valores RTD, o asistido por el terminal, en cuyo caso es el terminal el que
mide la OTD y envía la medida a la red que calcula la ubicación. En conclusión, la
posición del terminal móvil se obtiene mediante triangulación a partir de:
 Las coordenadas de las BTSs.
 El tiempo de llegada de las ráfagas de cada BTS.
 Las diferencias de tiempo entre las BTSs.
Desventajas
Únicamente se enfoca a la localización utilizando técnicas en GSM, por lo
que el error de posicionamiento es inadmisible para interiores (más de 50
metros).
No se maneja la consciencia de contexto.
No define otro tipo de tareas.
2.2 RADAR: An In-Building RF-based User Location and Tracking
System [RADAR 2000]
RADAR es un sistema de localización en WLAN, desarrollado por investigadores
de Microsoft, el cual opera mediante la grabación y procesamiento de información
de la potencia de señal recibida de múltiples AP (Utiliza potencia de señal
recibida). Este sistema combina mediciones empíricas con el modelado de
propagación de la señal para determinar la localización de un dispositivo.
Las fases de la metodología son las siguientes:
Fase de recolección de datos
Se registra información acerca de la señal de radio en función de la posición del
usuario, esto se realizó de la siguiente manera:
Se utiliza un software llamado WaveLAN para monitorear los paquetes beacom
enviados por los AP.
Se diseña un mapa del piso de un edificio (ver figura 2.2).
15
Figura 2.2Plano utilizado sistema RADAR [RADAR 2000]
Se realiza un recorrido utilizando un dispositivo inalámbrico y el software antes
mencionado, en los puntos negros de la figura 3 se tomaron varias medidas de
la potencia de la señal de los diversos AP provistas por el software WaveLAN,
cabe destacar que se toman medidas colocando al usuario con el dispositivo
inalámbrico volteando hacia los 4 puntos cardinales (debido a que el cuerpo
puede obstruir la señal de un AP, lo que ocasionaría recibir un dato de potencia
de señal más bajo).
Posteriormente un usuario manualmente define su posición dando clic sobre un
mapa.
Después los datos recolectados se almacenan en una base de datos como
tuplas formadas de la siguiente manera:
Posición x
Posición y
Dirección (norte, sur..)i
Potencia señali
Fase de localización
El dispositivo captura la potencia de la señal recibida en su posición
proveniente de los AP que tiene a la vista y utilizando la fórmula de la distancia
euclidiana:
D =
, donde si es la potencia de
señal detectada y s i’ es la potencia de señal obtenida por el usuario, dados
estos valores y por medio de la fórmula se obtiene la posición x y y que
minimice a D según las potencias recibidas.
Desventajas
No contempla otro tipo de posicionamiento.
No maneja consciencia de contexto ni auto-identificación.
El grado de precisión de la ubicación está en función de la cantidad de AP
que se tengan a la vista, a mayor número de AP mayor será la precisión,
por lo que se pueden tener errores inadmisibles cuando sólo se está en la
cobertura de un AP.
16
2.3 The Horus WL AN location determination system [HORUS
2004]
Investigadores de la Universidad de Maryland presentan Horus, el cual es un
sistema de determinación de la localización basado en RF (radio frecuencia). El
sistema utiliza la longitud de la señal observada por la transmisión de paquetes
transmitidos por los AP para inferir la localización del usuario. Utiliza una técnica
de mapeo de radio basado en la probabilidad, además utiliza clúster para reducir
los requerimientos computacionales y de procesamiento.
Las fases de la metodología son las siguientes:
Fase de entrenamiento fuera de línea
1. Se construye el mapa de radio, clúster de localizaciones del mapa de radio, el
cual almacena la distribución de la longitud de la señal recibida de cada AP
para cada ejemplo de localización.
2. Almacena los datos obtenidos del mapeo en forma de tuplas compuestas como
sigue:
x
y
ss
P(x)
Donde:
x y y representan las coordenadas dentro del plano del piso del edificio.
ss es la potencia de señal recibida y P(x) es la probabilidad de que un
dispositivo esté en las coordenadas (x, y) con potencia recibida ss.
Para obtener P(x) sacaron alrededor de 300 muestras en cada uno de los
puntos de ejemplo.
3. Posteriormente se crean clúster o agrupaciones según los puntos de
localización en el mapa del piso, con la finalidad de minimizar la carga
computacional al momento de la fase de determinación de la localización del
dispositivo.
Fase de determinación de localización en línea
1. Se obtiene un vector compuesto de las potencias de señal y las direcciones
MAC de los AP de los cuales se recibe señal.
2. Para el AP con mayor señal recibida se busca encontrar la localización (x, y)
que maximice la probabilidad P(x).
3. Si la diferencia entre la P(x) mayor y la segunda mayor es considerablemente
alta se toma ese punto como la localización del dispositivo, en caso contrario
se repite el paso 2 tomando en cuenta la potencia de señal del siguiente AP.
17
Desventajas
Al utilizar técnicas probabilísticas para la obtención del mapa de radio es
más preciso que los que utilizan técnicas determinísticas en WLAN.
No contempla otro tipo de posicionamiento.
No maneja la consciencia del contexto ni auto-identificación.
El grado de precisión de la ubicación está en función de la cantidad de AP
que se tengan a la vista, a mayor número de AP mayor será la precisión,
por lo que se pueden tener errores inadmisibles cuando sólo se está en la
cobertura de un AP.
2.4 CAALIX Complete Ambient Assisted Living Experiment
[CAALIX 2007]
Es un proyecto concluido en diciembre de 2008 en el cual se desarrolla un
dispositivo ligero capaz de medir los signos vitales específicos de los ancianos,
detectando fallas y comunicando automáticamente en tiempo real a sus
cuidadores en caso de emergencia, esto lo hace en interiores o en exteriores.
Los objetivos primordiales de este proyecto son los siguientes:
1. Identificar los signos vitales y patrones más importantes en la determinación de
probables estados críticos de la salud de un anciano.
2. Desarrollar un dispositivo electrónico habilitado para medir los signos vitales y
detectar recaídas en las personas ancianas en un ambiente domestico y en
exteriores. El aparato tiene un sistema de geolocalización, de modo que el
sistema de monitoreo esté habilitado para conocer la posición del anciano en
caso de emergencia.
3. Permitir el monitoreo seguro de los individuos organizados en grupos dirigidos
por un cuidador, quien decidirá si comunicar los eventos identificados mediante
el sistema a un servicio de emergencia.
4. Crear un servicio de tele-asistencia social que pueda ser operado fácilmente
por los usuarios.
Cuenta con tres áreas principales de desarrollo:
El sistema de monitoreo de roaming. Su intención es monitorear
discretamente a la persona mayor mientras lleva a cabo sus actividades
diarias en forma independiente, tanto en su casa como en el exterior. Se
medirán varios signos vitales o recaídas y automáticamente se enviarán
junto con su posición geográfica al servicio central de cuidado en caso de
emergencia, de este modo una unidad de rescate puede ser despachada a
tiempo.
18
El sistema de monitoreo del hogar. Su intención es extender el monitoreo
en el ambiente del hogar, integra otros dispositivos y sensores; el soporte
de video comunicación y VoIP.
El sistema central de monitoreo servicio de cuidado. Recibe las alertas
de las personas mayores suscritas. El cuidador evalúa la situación de una
persona de acuerdo a los resultados recibidos y en caso necesario se
comunica al servicio de emergencia.
Figura 2.3 Arquitectura proyecto CAALIX [CAALIX 2007]
Desventajas
Únicamente utiliza el GPS como técnica de localización, esto significa que
no se puede localizar a la persona en interiores que no sean su hogar, por
ejemplo un centro comercial o un campus donde hay muchos edificios y no
hay conectividad GPS.
En el interior de su hogar se tiene que desplegar un gran sistema de
monitoreo vía circuito cerrado para identificar la posición de la persona, esto
lo hace muy costoso.
La posición la envía únicamente con transmisión de datos GPRS, esta
cobertura es menor a la cobertura utilizada por el GSM, si no hay GPRS no
puede enviar su localización, aunque tenga cobertura GPS.
19
No maneja consciencia del contexto ni auto-identificación.
2.5 Location Awareness in Community Wireless LANs [FERSCHA
2001]
En este proyecto, llamado CampusSpace, se propone utilizar las capacidades de
posicionamiento de las técnicas en redes 802.11 (WiFi) mediante la integración de
las tecnologías RFID. Para lo anterior desarrollaron un Framework, el cual permite
de forma transparente recolectar e interpretar información de la posición de
móviles en coberturas de señales 802.11 y del mismo modo recolecta información
mapeada cartográficamente en etiquetas RFID.
Proceso de determinación de posición
El proceso que siguen consta de dos fases hasta antes de llegar a la
determinación de la posición, ver figura 2.4.
Recolección de
información
geográfica
Recolección de
proximidad espacial
Determinación de la
posición
Figura 2.4 Proceso de localización CampusSpace
Recolección de la información geográfica
En este punto se recolecta la potencia de señal recibida en la cobertura de los
dispositivos cliente registrados en los AP. Para la realización de las pruebas se
trabaja con el estándar 802.11b, además se considera la aparición de no más de
tres AP para evitar la colisión de paquetes.
Como técnica de posicionamiento WLAN se utiliza la potencia de la señal recibida
RSS, la cual se ve afectada por paredes de concreto, objetos de metal y personas,
entre otros.
Recolección de proximidad espacial
Para realizar este proceso se hace uso de la tecnología RFID, para ello se utilizan
tarjetas RFID pasivas. Los lectores RFID se integraron dentro de los dispositivos
como un hardware PCMCIA mismo que permite, por un lado la conexión mediante
WiFi y por otro está magnéticamente acoplado a un lector RFID.
20
Arquitectura del sistema
La arquitectura del sistema se presenta en la figura 2.5. Como puede observarse
está compuesta por un servidor central, el cual colecta información de localización
de las estaciones móviles y de los AP, así como sus propiedades, localización,
etc. Este servidor es llamado servidor de localización y actúa como un agente
entre diferentes clientes.
Figura 2.5 Arquitectura del sistema CampusSpace [FERSCHA 2001]
Los clientes almacenan información local, mientras el servidor de localización sólo
administra URIs y URLs enlazadas a la información. Para manejar esta
información de forma estructurada se utiliza RDF como un formato general de
descripción, el cual es un Framework para metadatos en la World Wide Web
(WWW), desarrollado por el World Wide Web Consortium (W3C). Un ejemplo de
este tipo de formato se muestra en la figura 2.6.
Figura 2.6 Descripción RDF de un miembro del staff [FERSCHA 2001]
21
El funcionamiento se describe como sigue:
1. Primeramente el dispositivo móvil detecta en que AP está conectado.
2. El dispositivo verifica la información de su posición en el servidor de
localización, obteniendo de ello una URL la cual contiene una página que
contiene una imagen o texto, la cual le indica el lugar en donde se encuentra.
3. Como el error que conlleva utilizar únicamente la potencia recibida del AP
puede ser grande, en el momento que el dispositivo tiene en su cercanía una
etiqueta RFID este la lee, cada etiqueta tiene su propio identificador de modo
que el servidor de localización tendrá almacenada alguna URL de posición de
dicha etiqueta.
4. Nuevamente el dispositivo vuelve a verificar su posición, ya más exacta debido
a la corta distancia que manejan estas etiquetas (las que utilizaron tienen un
máximo de 1 metro de cobertura), y actualiza la información en el servidor de
posición y obtiene la URL correspondiente a su posición, de este modo el
usuario puede verificar su posición entrando a la URL correspondiente.
Desventajas
Se deben tener tantas páginas como tarjetas se tengan o como puntos de
localización se quieran mostrar, debido a que cada punto de localización
tiene su propia URL que describe su posición mediante una imagen o texto.
No maneja consciencia del contexto ni auto-identificación.
Únicamente se centra en el posicionamiento y no extiende su funcionalidad
a algún servicio para el usuario, como lo es el manejo de tareas de acuerdo
al contexto.
2.6 UbiqMuseum: A Bluetooth and Java Based Context-Aware
System for Ubiquitous Computing [CANO 2006]
Este proyecto se desarrolla por investigadores de la Universidad Politécnica de
Valencia. El principal objetivo de este proyecto es evaluar el uso de Bluetooth y
tecnologías basadas en java en ambientes de computación ubicua.
UbiqMuseum es una aplicación experimental consciente del contexto que provee
información a visitantes de museos. El sistema da a los visitantes información
precisa acerca de lo que están viendo, de acuerdo a su nivel de conocimiento y en
su lenguaje natural. Del mismo modo provee de una interfaz grafica de usuario
que se adapta al tipo de dispositivo (háblese de teléfonos móviles, PDAs o
laptops).
Arquitectura del sistema
El sistema considera 3 tipos de entidades de software:
22
Aplicaciones cliente. Ejemplo de ello es un visitante con una PDA con
Bluetooth habilitado.
Puntos de información del museo (MIPs). Se asocian a una o más piezas
de arte u objetos dentro del museo.
Servidor central. El cual contiene información de los distintos objetos y
piezas de arte en el museo además de guardar una bitácora de las piezas
que son visitadas e información del usuario que la visita.
La figura 2.7 muestra una representación de la arquitectura de UbiqMuseum.
Figura 2.7 Arquitectura del sistema UbiqMuseum [CANO 2006]
Funcionamiento del sistema
Para la implementación se utilizan APIs de Java para la tecnología Bluetooth
(JABWT) contenida en el JSR-82.
La funcionalidad de cada uno de los elementos de la arquitectura es la siguiente:
 Los usuarios (visitantes del museo), que llevan consigo los clientes, configuran
sus preferencias mediante un conjunto de parámetros de entrada que son: 1) el
tipo de dispositivo (laptop, PDA o teléfono móvil), 2) el lenguaje de su
preferencia y c) el nivel de detalle de la información recibida (intermedio,
básico, experto).
 Una vez hecho esto, el cliente busca por algún MIP mediante Bluetooth.
 Cuando encuentra un dispositivo y si el usuario decide elegirlo el dispositivo
cliente envía el perfil del usuario previamente capturado al MIP elegido.
 Posteriormente el MIP combina el perfil del usuario con el identificador de la
pieza del museo que representa y envía esta información al servidor central.
23
 El siguiente paso es que el servidor central registra en la bitácora la petición y
envía la información correspondiente a la pieza de arte que el MIP representa
combinando está con las preferencias del usuario.
 El MIP recibe esta información y la retransmite al cliente.
La figura 2.8 muestra la información que un usuario recibe, cabe resaltar que el
usuario lleva consigo una PDA y ha elegido el nivel de detalle intermedio.
Figura 2.8 Información recibida en un cliente en UbiqMuseum [CANO 2006]
Desventajas
Únicamente maneja conectividad Bluetooth.
No maneja perfiles de movilidad.
La puesta en marcha puedo costar mucho debido a que se deben tener
tantos MIPs (dispositivos Bluetooth), en este caso se utilizan tantas laptops,
como piezas se tengan en el museo.
Es un sistema de corto alcance debido a que la comunicación entre los
MIPs y el servidor central se hace a través de sockets.
Limitado a pocos clientes por MIP (máximo 7) debido a las características
de las piconet formadas por los dispositivos Bluetooth.
No maneja otras tareas.
24
2.7 A Location-aware System using RFID and Mobile Devices for
Art Museums [TESOREIRO 2008]
Este proyecto dirigido por investigadores de la Universidad de Castilla-La Mancha,
España, presenta un sistema de localización consciente basado en RFIDs activos
y pasivos combinado con la tecnología IR (infrarrojos) los cuales soportan el
posicionamiento automático de dispositivos móviles. Este proyecto se aplica a
museos de arte.
Funcionamiento
 Para saber la ubicación del usuario se utilizan tarjetas RFID de tipo activas, las
cuales están transmitiendo ondas indicando su presencia y cuando el usuario
llega, dotado de un lector RFID y un equipo móvil (PDA o laptop), envían su
identificador.
 Cuando el equipo móvil lee el identificador lo envía a un servidor el cual tiene
una tabla de mapeo indicando su posición y la información relativa al objeto
que el usuario tiene en cercanía.
 Posteriormente el servidor envía la información perteneciente al identificador,
ya sea en forma de texto, audio, imagen o video mediante el protocolo HTTP.
 Por último el usuario recibe en su dispositivo la información que requiere. Cabe
resaltar que aunado al uso de tarjetas RFID activas, incluye el uso de tarjetas
RFID pasivas y de lectores de códigos de barras, para leer un objeto en
particular.
El modelo
Su mayor aportación es que presentan un modelo conceptual para soportar un
sistema de posicionamiento automático basado en la tecnología RFID. La figura
2.9 muestra el modelo que se presenta en este proyecto.
25
Figura 2.9 Modelo conceptual [TESOREIRO 2008]
Lo interesante de este modelo es la parte resaltada en gris claro, la cual hace
referencia a la forma en que se obtiene el identificador de cada objeto presente en
el museo, es independiente de tecnología y puede obtenerse mediante RFID
activos, RFID pasivos y códigos de barras. El modelo y el prototipo son flexibles a
cambios y fácilmente pueden añadirse otras tecnologías como (WiFi y Bluetooth)
para establecer la ubicación del usuario y mostrarle la información pertinente.
Desventajas
No define tareas, actividades y servicios, únicamente se centra en enviar la
información de los objetos que el usuario tiene en cercanía.
No es compatible con dispositivos celulares.
2.8 Comparativa del estado del arte con el proyecto
En la tabla 1 se comparan diversas características de los trabajos relacionados
con el proyecto de tesis. Puede observarse claramente las ventajas que ofrece
respecto de otros proyectos similares. Las ventajas más notables son el hecho de
que maneja perfiles de movilidad, ofrece un posicionamiento mediante RFID y
QRCodes, y no sólo eso sino que también será flexible a la introducción de otras
técnicas y tecnologías de posicionamiento. Aunado a esto el proyecto tiene la
ventaja de ofrecer múltiples tareas para la realización de las actividades de un
usuario dentro de un campus universitario y no sólo se limita al posicionamiento
26
del mismo. Asimismo, el proyecto manejará un proceso de guiado utilizando la
información de la ubicación del usuario, para posicionarlo dentro del campus.
Tabla 1 Comparativa de los trabajos relacionados con el proyecto de tesis
Envío de
datos
[Radar 2000]
WiFi
HTTP
WiFi, RFID
activo
HTTP,
GPRS
[Horus 2004]
WiFi
HTTP
[Cano 2006]
Bluetooth
Bluetooth

<5
[Titi 2007]
GSM
GPRS

<500
[Caalix 2007]
GPS
GPRS

[Teso 2008]
RFID activo
y pasivo
HTTP

RFID y
QRCodes
HTTP
Tesis
Guiado
Múltiples
tareas
Manejo
de
mapas
Método
Posición
[Fers 2001]
Consciencia
de contexto
Utilizado
en
celulares
Proyecto








<9.5
No
aplica
<1


La segunda parte que conforma el estado del arte la cubren desarrollos
tecnológicos que se encuentran operando en el sector privado, los principales
desarrollos son servicios que proporcionan las compañías telefónicas para sus
usuarios.
2.9 Servicio UBICACEL de iusacell [UBICACEL 2008]
Servicio de localización que permite conocer la ubicación geográfica de
dispositivos Iusacell. Sirve para localizar dispositivos con capacidad de GPS y
GPSOne cuando se encuentren dentro del alcance de la red celular y satelital.
Su funcionamiento es el siguiente: mediante una aplicación instalada en el
teléfono celular a través de técnicas de triangulación se obtiene la localización del
dispositivo y se puede generar la respuesta sobre la ubicación del teléfono.
2.10 Servicio Localízame de Movistar [LOCALIZAME 2008]
Servicio proporcionado por la compañía telefónica Movistar para localizar
dispositivos móviles por medio de mensajes SMS. Cuenta con la opción de
localización por medio de su página de Internet, la localización se hace por medio
de la infraestructura de red de la telefónica. Su precisión varía dependiendo de la
zona en que se encuentra el dispositivo móvil.
27
<15
<1.5


Error
(m)
<1
Cuenta con tres opciones del servicio: para localizar otros dispositivos móviles,
para que localicen mi dispositivo y para saber mi propia ubicación. Necesita
autorización para conocer la ubicación de otro dispositivo.
2.11 AVL Reach U / Localización y Administración Vehicular Telcel
[AVL REACH 2008]
Servicio que permite a empresas, desde sus propias instalaciones, localizar,
rastrear y monitorear vehículos particulares o utilitarios bajo un concepto avanzado
de interacción con el equipo instalado en el vehículo. Además permite la
obtención de reportes estadísticos y un nivel sofisticado de funcionalidades desde
la plataforma y/o a través del envío de mensajes escritos desde un celular Telcel
previamente definido.
2.12 Tramigo [TRAMIGO 2008]
Tramigo es una compañía establecida en Finlandia, sus productos permiten
rastrear la ubicación y controlar su automóvil a través de su teléfono celular o de
su computadora y ser notificado en caso de eventos inesperados tales como
accidentes, robos o secuestros.
Todos los productos Tramigo cuentan con las siguientes características: rastreo y
gestión vehicular, localización vía GPS, soporte SMS en cualquier red telefónica
GSM, datos geográficos, posibilidad de personalizar ubicaciones o puntos de
interés.
2.13 Skyhook WPS [SKYHOOK 2008]
El sistema de posicionamiento WiFi inalámbrico Skyhook, es una simple solución
de localización software que permite a cualquier dispositivo móvil con WiFi
habilitado determinar su posición con una precisión de 20 metros. A diferencia de
los receptores GPS, los cuales utilizan satélites para determinar su localización,
WPS utiliza puntos de acceso WiFi terrestres.
El cliente WPS localiza las señales WiFi existentes a su alrededor y calcula su
posición actual usando algoritmos de localización desarrollados por Skyhook
Wireless. WPS requiere el conocimiento de la localización geográfica de cada
punto de acceso. Esta información es obtenida mediante el despliegue de cientos
de especialistas de datos, quieres buscan y localizan puntos de acceso, los cuales
se almacenan en una base de datos, por medio de los puntos de acceso es como
el dispositivo móvil puede identificar su localización.
En la tabla 2 se muestra la comparativa de los servicios anteriores con la tesis
propuesta.
28
Tabla 2 Comparativa de los servicios de localización
Nombre
Posicionamiento
Envío
de
datos
Servicio UBICACEL
de Iusacell
Técnicas híbridas
GSM y GPS
SMS
Servicio localízame
de Movistar
Basada en red
SMS
Técnicas hibridas
GSM y GPS
SMS,
GPRS
Tramigo
GPS
SMS,
GPRS
Skyhook WPS
Wi Fi
GPRS
RFID, QRCodes
HTTP
AVL Reach U /
Localización y
administración
vehicular
Tesis
Indep.
de red
Consciencia
de contexto
Múltiples
tareas





La mayoría de los desarrollos presentados en la tabla anterior, utilizan técnicas
híbridas para obtener la localización de los dispositivos. La presentación de los
datos puede ser en una página Web o en formato de un SMS. La desventaja que
tiene cada uno de estos desarrollos es su dependencia con la red celular para
obtener la ubicación y proporcionar los servicios que se demandan. Con la
plataforma, producto de esta tesis, no se tiene ninguna limitante para obtener la
localización, la respuesta se envía con los servicios disponibles en la posición
actual, además el dispositivo tendrá consciencia del contexto y se administrarán
las tareas de los usuarios. Además ninguno de los proyectos anteriores maneja la
consciencia del contexto del dispositivo ni técnicas de auto-identificación.
29
3 Capítulo 3 Marco teórico
Capítulo 3 Marco teórico
En este capítulo se presenta la teoría relacionada con este trabajo de tesis. Se
inicia describiendo las plataformas más populares de dispositivos móviles y las
tecnologías empleadas en el proyecto de tesis, posteriormente se describen los
LBS y técnicas de localización en diversas tecnologías.
Capítulo 3 Marco Teórico
3.1 Plataformas de dispositivos móviles
3.1.1 Windows Mobile
Es un sistema operativo compacto, con una suite de aplicaciones básicas para
dispositivos móviles basados en la API Win32 de Microsoft. Los dispositivos que
llevan Windows Mobile son Pocket PC, Smartphones y Media Center portátil. Ha
sido diseñado para ser similar a las versiones de escritorio de Windows.
3.1.2 Symbian
Es un sistema operativo que fue producto de la alianza de varias empresas de
telefonía móvil, entre las que se encuentran Nokia, Sony Ericsson, PSION,
Samsung, Siemens, Arima, Benq, Fujitsu, Lenovo, LG, Motorola, Mitsubishi
Electric, Panasonic, Sharp, etc. Sus orígenes provienen de su antepasado
EPOC32, utilizado en PDA's y Handhelds de PSION.
3.1.3 J2ME
La plataforma Java Micro Edition, o anteriormente Java 2 Micro Edition(J2ME), es
una especificación de un subconjunto de la plataforma Java orientada a proveer
una colección certificada de APIs de desarrollo de software para dispositivos con
recursos restringidos. Está orientado a productos de consumo como PDAs,
teléfonos móviles o electrodomésticos.
3.1.4 iPhone OS
El iPhone OS es el sistema operativo que utiliza el iPod touch y el iPhone,
diseñado por 175 ingenieros de Apple. Está basado en una variante del Mach
kernel que se encuentra en Mac OS X.
3.1.5 Android
Android es un sistema operativo para dispositivos móviles basado en el núcleo
Linux. Inicialmente fue desarrollado por Google y luego por la Open Handset
Alliance (liderada por la propia Google). La presentación de la plataforma Android
se realizó el 5 de noviembre de 2007 junto con la fundación Open Handset
Alliance, un consorcio de 48 compañías de hardware, software y
telecomunicaciones comprometidas a la promoción de estándares abiertos para
dispositivos móviles.
Esta plataforma permite el desarrollo de aplicaciones por terceros (personas
ajenas a Google). Los desarrolladores deben escribir código gestionado en el
lenguaje de programación Java a través de la SDK que proporciona Google. La
mayoría del código fuente de Android ha sido publicado bajo la licencia de
software Apache, una licencia de software libre y código fuente abierto.
33
3.2 REST (Representational StateTransfer)
La Transferencia de Estado Representacional (Representational State Transfer) o
REST es una técnica de arquitectura software para sistemas hipermedia
distribuidos como la World Wide Web. El término se originó en el año 2000, en una
tesis doctoral sobre la Web escrita por Roy Fielding, uno de los principales autores
de la especificación del protocolo HTTP y ha pasado a ser ampliamente utilizado
por la comunidad de desarrollo.
Si bien el término REST se refería originalmente a un conjunto de principios de
arquitectura —descritos más abajo—, en la actualidad se usa en el sentido más
amplio para describir cualquier interfaz Web simple que utiliza XML y HTTP, sin
las abstracciones adicionales de los protocolos basados en patrones de
intercambio de mensajes como el protocolo de servicios Web SOAP. Con REST
es posible diseñar servicios Web de acuerdo con el estilo arquitectural REST de
Fielding y también es posible diseñar interfaces XML-HTTP de acuerdo con el
estilo de llamada a procedimiento remoto pero sin usar SOAP.
REST afirma que la Web ha disfrutado de escalabilidad como resultado de una
serie de diseños fundamentales clave, los cuales se describen a continuación:
 Un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene
toda la información necesaria para comprender la petición. Como resultado,
ni el cliente ni el servidor necesitan recordar ningún estado de las
comunicaciones entre mensajes. Sin embargo, en la práctica, muchas
aplicaciones basadas en HTTP utilizan cookies y otros mecanismos para
mantener el estado de la sesión (algunas de estas prácticas, como la
reescritura de URLs, no son permitidas por REST).
 Un conjunto de operaciones bien definidas que se aplican a todos los
recursos de información: HTTP 1.1, define un conjunto de operaciones,
las más importantes son POST, GET, PUT y DELETE.
 Una sintaxis universal para identificar los recursos. En un sistema
REST, cada recurso se referencia únicamente a través de su URI.
 El uso de hipermedios, tanto para la información de la aplicación como
para las transiciones de estado de la aplicación: la representación de este
estado en un sistema REST son típicamente HTML o XML, aunque también
soporta la representación en JSON. Como resultado de esto, es posible
navegar a los recursos REST a través de URIs dinámicas.
3.3 JSON
JSON (JavaScript Object Notation - Notación de Objetos de JavaScript) es un
formato para el intercambio de datos. Es un formato con una estructura simple y
se caracteriza por reducir significativamente el volumen de datos a transmitir. Está
basado en un subconjunto del Lenguaje de Programación JavaScript, Standard
ECMA-262 3rd Edition - Diciembre 1999. JSON es un formato de texto que es
34
completamente independiente del lenguaje pero utiliza convenciones que son
ampliamente conocidas por los programadores de la familia de lenguajes C,
incluyendo C, C++, C#, Java, JavaScript, Perl, Python, y muchos otros. Estas
propiedades hacen que JSON sea un lenguaje ideal para el intercambio de datos.
JSON está constituido por dos estructuras:
 Una colección de pares de nombre/valor. En varios lenguajes esto se
conoce como un objeto, registro, estructura, diccionario, tabla hash 1, lista
de claves o un arreglo asociativo.
 Una lista ordenada de valores. En la mayoría de los lenguajes, esto se
implementa como arreglos, vectores, listas o secuencias.
3.4 OSGi
OSGI son las siglas de Open Services Gateway Initiative y fue creado en Marzo de
1999.
Su objetivo es definir las especificaciones para software abierto que permitan
diseñar plataformas compatibles que puedan proporcionar múltiples servicios. Fue
pensado principalmente para su aplicación en redes domésticas y por ende en la
llamada domótica2 u hogar inteligente.
Aunque OSGi define su propia arquitectura, ha sido pensada para su
compatibilidad con Jini [JINI 2009] o UPnP [UPNP 2009].
La arquitectura de OSGi posee un elemento llamado Service Platform, el cual está
situado en la red local y a su vez conectado al proveedor de servicios a través de
una pasarela en la red del operador. Este elemento será el responsable de permitir
la interacción entre dispositivos o redes de dispositivos que podrían utilizar
distintas tecnologías para comunicarse.
La especificación de OSGi se ha definido con una serie de APIs básicas para el
desarrollo de servicios, como los de registro de bitácora, servidor HTTP y el la
especificación de acceso a dispositivos (por sus siglas en inglés DAS), que
permite el descubrir los dispositivos y servicios ofrecidos por éstos.
3.5 Servicios basados en localización (LBS)
Los LBS (Location Based Services) o LDIS (Location Dependent Information
Services) hacen referencia a Servicios Basados en Localización o para algunos
autores simplemente Servicios de Localización.
1
Una tabla hash o mapa hash es una estructura de datos que asocia llaves o claves con valores
Se entiende por domótica al conjunto de sistemas capaces de automatizar una vivienda,
aportando servicios de gestión energética, seguridad, bienestar y comunicación, y que pueden
estar integrados por medio de redes interiores y exteriores de comunicación, cableadas o
inalámbricas, y cuyo control goza de cierta ubicuidad, desde dentro y fuera del hogar
2
35
Los Servicios Basados en Localización buscan ofrecer un servicio personalizado a
los usuarios, en base a su ubicación geográfica. Para su operación utiliza
tecnología de sistemas de información geográfica, alguna tecnología de
posicionamiento bien sea de lado cliente (ej. GPS) o de lado servidor (ej. servicio
de posicionamiento suministrado por el operador de la red) y tecnología de
comunicación de redes para transmitir información hacia una aplicación LBS que
pueda procesar y responder la solicitud.
Las aplicaciones típicas LBS buscan proveer servicios geográficos en tiempo real.
Algunos ejemplos típicos de esto son servicios de mapas, enrutamiento y páginas
amarillas geográficas.
Las NICTs (New Information and Communication Technologies, Tecnologías
Nuevas de Información y Telecomunicación), describe a los LBS como una
intersección entre: sistemas y dispositivos móviles de comunicación, Internet y GIS
(Geographic Information Systems, Sistemas de información geográfica) con base
de datos espaciales. [STEINIGER 2006] Ver figura 3.1.
Figura 3.1 LBS como intersección de tecnologías
En la figura 3.1 se observa que existen algunas características en común entre los
LBS y los GIS, tales como el manejo de datos con referencia posicional y
funciones de análisis espacial, las cuales responden preguntas como: ¿Dónde
estoy…? ¿Qué está cerca de…? ¿Cómo puedo llegar a…? [GUERRA 2007].
Sin embargo los LBS y los GIS tienen diferentes orígenes y grupos de usuarios.
Los GIS han sido desarrollados durante varias décadas en base a aplicaciones de
datos geográficos profesionales, mientras que los LBS surgieron recientemente
por la evolución de servicios móviles públicos. En lo que se refiere a grupos de
usuarios, un GIS puede ser visto como un sistema profesional y tradicional,
destinado a usuarios con amplia experiencia en sistemas geográficos, además de
que consumen extensos recursos de cómputo.
En contraste, los LBS se desarrollan como servicios limitados para un gran
número de usuarios no profesionales. La aplicaciones LBS operan con las
restricciones del ambiente de cómputo móvil como baja potencia computacional,
pantallas pequeñas, o limitaciones debidas al alto consumo de batería.
36
3.6 Técnicas de posicionamiento
Existen diferentes técnicas para obtener la ubicación del dispositivo móvil. Las
cuales se clasifican como se muestra en la figura 3.2. [STEINIGER 2006],
[BERNARDOS 2003], [VENTURINO 2003], [MARTINEZ 2005].
Técnicas de
posicionamiento
Redes LAN
Redes WAN
Bluetooth
GSM
Wi Fi
GPS
Infrarrojos
RFID
Banda Ultraancha
Figura 3.2 Clasificación de las técnicas globales de posicionamiento
3.6.1 Basadas en redes WAN
3.6.1.1 GPS
Los localizadores por GPS (y de forma similar sus competidores el ruso Glonass,
el chino Beidou y el europeo Galileo) reciben el soporte de una constelación de
hasta 24 satélites, que orbitan por todo el globo terrestre enviando sus señales a
todo aquél que quiera oírlas. Un receptor de GPS que quiere localizarse dentro del
globo terrestre localiza al menos a cuatro satélites – cuanto mayor sea el número
de satélites encontrado mejorará su estimación de la posición – y de cada uno de
ellos obtiene la posición del satélite emisor y el tiempo de envío de cada muestra
recibida. Con estos datos, el receptor GPS calcula por triangulación su posición
absoluta dentro de la tierra (latitud, longitud, altitud) gracias a que los satélites
emiten en el mismo preciso momento su señal, pero ésta le llega retardada al
receptor por razones obvias de distancia.
37
Figura 3.3 Esquema de la localización por GPS
Un esquema básico del GPS se muestra en la figura 3.3; este sistema tiene una
precisión que puede llegar a ser menor a los 10 metros si se toman en
consideración más de cuatro satélites. El inconveniente de utilizar esta tecnología
es que al necesitar línea de visión directa (LOS Line of sight), hay veces que no se
encuentran suficientes satélites al alcance para permitir una localización correcta,
esto puede ocurrir en ciudades con rascacielos o calles demasiado estrechas y en
túneles. Además, normalmente se requiere que el dispositivo tenga grabado un
mapa porque, sin él, sólo se podrá mostrar al usuario su longitud, latitud y altitud, y
estos datos no suelen ser informativos para un usuario promedio.
Además, las señales del GPS viajan muchos kilómetros y son bastante tenues, por
lo que es muy difícil para un receptor GPS en el interior de un edificio encontrar
señales procedentes de los satélites y más aún, conseguir que estas señales le
sirvan para localizarse.
3.6.1.2 Localización usando GSM
Otra alternativa posible, que además no necesitaría ningún hardware adicional,
pasaría por el uso de un teléfono móvil [FISHER 1998], y de hecho ya hay
operadoras de telefonía móvil que ofrecen la opción de localización vía móvil a sus
clientes. Sin embargo, la falta de precisión sitúa a esta tecnología en clara
desventaja respecto de otras, ya que los sistemas de localización de este tipo no
pueden dar precisiones mayores de 50 metros. Esto es debido a que la
localización con el uso del teléfono móvil (localización por GSM) se basa en la
detección de la célula a la que está conectada el móvil, y en zonas urbanas la
precisión es de decenas de metros, sin embargo en las zonas rurales, donde se
necesitan menos células para dar servicio a menor población, esta precisión es
mucho menor.
38
3.6.2 Basadas en redes LAN
3.6.2.1 WiFi
La comunicación típica en el protocolo IEEE 802.11 sigue un modelo centralizado.
Por tanto, una red consta de uno o varios puntos de acceso (APs) y multitud de
clientes conectados a uno de los puntos de acceso. Cada punto de acceso emite
periódicamente una serie de paquetes llamados beacon frames para hacer notar
su presencia a los usuarios, los cuales de este modo pueden saber en todo
momento qué redes inalámbricas hay disponibles en su entorno. Así pues, se
puede realizar un mapeo de las coordenadas de los APs utilizando sus direcciones
MAC, un dispositivo que esté en la cobertura de un determinado AP puede saber
su ubicación mediante el envío de las direcciones MAC a un servidor que
contenga la ubicación de dicho AP.
El inconveniente de esta técnica en principio es el modo de recolección de las
coordenadas de los APs, ya que si no se establecen las correctas coordenadas de
un AP, la precisión en la localización posterior de un dispositivo se verá afectada.
3.6.2.2 RFID
RFID (siglas de Radio Frequency IDentification, en español Identificación por
radiofrecuencia) es un sistema remoto de almacenamiento y recuperación de
datos que usa dispositivos denominados etiquetas, transpondedores o tags RFID.
El propósito fundamental de la tecnología RFID es transmitir la identidad de un
objeto (similar a un número de serie único) mediante ondas de radio. Las
tecnologías RFID se agrupan dentro de las denominadas Auto ID (Automatic
Identification, o Identificación Automática), su especificación la define el estándar
IEEE 802.15.4.
Una etiqueta RFID es un dispositivo pequeño, que puede ser adherido o
incorporado a un producto, animal o persona. Contienen antenas para recibir y
responder a peticiones por radiofrecuencia desde un emisor-receptor RFID.
Existen dos tipos de etiquetas RFID: activas y pasivas. Las etiquetas pasivas no
necesitan alimentación eléctrica interna, mientras que las activas sí lo requieren.
Una de las ventajas del uso de radiofrecuencia (en lugar de infrarrojos) es que no
se requiere visión directa entre emisor y receptor.
Este sistema se basa en etiquetas de radiofrecuencia que contienen una antena
emisora/receptora, la etiqueta recibe dicha señal, y la utiliza como señal de
alimentación, la etiqueta utiliza el campo electromagnético alternativo creado por
la bobina de antena de lectura, originando un voltaje por inducción cuando el
campo electromagnético penetra la selección cruzada de la bobina de la antena
del transpondedor, el voltaje se rectifica y actúa como el suministro de poder para
dar energía al microchip y la memoria en la etiqueta, luego utilizando modulación
el transpondedor puede transferir datos codificados hacia la memoria de la
etiqueta desde el lector en onda modulada. Así, un usuario que se quisiera
39
localizar en un edificio tendría cerca de él un número de etiquetas de
radiofrecuencia. El propio usuario tendría un lector de etiquetas RFID y leyendo
las etiquetas cercanas puede llegar a localizarse.
Un ejemplo de un sistema de localización que usa RFID es Cricket [CRICKET
2001], un sistema ideado por ingenieros del MIT (Massachussets Institute of
Technology), cuya precisión es 2 centímetros y ha sido empleado en otros
proyectos como seguimiento de objetos, control de robots o en aplicaciones
conscientes del contexto (en las cuales la localización del usuario juega un papel
muy importante).
Revisando las características de esta tecnología es posible utilizarla para localizar
e identificar a un dispositivo dentro de un edificio, además es una tecnología que
en Europa está tomando auge y los dispositivos son cada vez más económicos,
tan es así que los celulares de nueva generación ya cuentan con un lector RFID
inmerso.
3.6.2.3 Localización por Infrarrojos
La localización por infrarrojos es de muy corto alcance (unos dos metros) y se
requieren enlaces de línea de visión directa. Por su corto alcance habría que
incluir una cantidad enorme de emisores de infrarrojos, y aún así serían imposibles
detectar ciertas localizaciones por el problema derivado de la necesidad de línea
de vista directa.
Existe un proyecto llamado WIPS (Wireless Indoor Positioning System) que se
basa en la existencia de beacons frames emitidos vía infrarrojos que llevan los
usuarios del sistema de posicionamiento para localizarse tanto de forma pública
como de forma anónima [WIPS 2000].
3.6.2.4 Bluetooth
En las técnicas basadas en Bluetooth el cliente monitorea los dispositivos que hay
al alcance y procedería por triangulación a ver su localización [HALLBERG 2003]
[WEISSMAN 2004]. La ventaja es que es una tecnología barata, pero el alcance
es demasiado corto en su versión 1.1, sin embargo en la versión 2.0 el alcance es
de cerca de 100 metros. El error cometido puede estar en torno a 1,5 metros, lo
cual no está mal para localización en interiores. El mayor inconveniente que tiene
Bluetooth es que el indicador de RSS (potencia de señal) no es preciso, por lo que
no se puede usar y por ello, si se encuentra un dispositivo cercano, hay que
asumir que se está en su entorno pero no se puede estimar el grado de cercanía o
lejanía.
Algunas técnicas de localización como la propuesta en [GONZALEZ 2003] han
sido desarrolladas con la finalidad de ubicar a un dispositivo Bluetooth dentro de
una red del mismo tipo, sin embargo no contempla que esta tecnología coexista
con otras más.
40
3.6.2.5 Wi-Max
La tecnología Wi-Max es aún bastante desconocida y sigue el estándar IEEE
802.16. Está pensada para la intercomunicación de áreas muy extensas, de hasta
48 kilómetros de radio, y puede llegar a transmitir a velocidades de hasta 70 Mbps.
La desventaja de la utilización de esta tecnología es que la mayoría de los
dispositivos actuales no cuenta con ella.
41
4 Capítulo 4 Análisis y diseño
Capítulo 4 Análisis y diseño
En este capítulo se presentan los diagramas de caso de uso, la definición de
escenarios y los diagramas de actividad que corresponden a la fase de análisis.
Asimismo se presentan los diagramas de clase y de secuencia correspondientes a
la etapa del diseño. Por último se detalla el diseño de las URLs válidas para el
sistema y el diagrama físico de la base de datos.
4.1 Análisis
El presente trabajo de tesis es un proyecto integral que incluye la implementación
tanto de la parte cliente como servidora.
En la figura 4.1 se muestra el diagrama de bloques que corresponde a la forma de
interacción entre el cliente y el servidor que formarán parte del proyecto.
Consulta de
tareas
pendientes
Nueva tarea
Recibir
petición
Enviar
petición
URI recurso
Completar tarea
Obtener
ubicación
Mostrar
resultado
s
Leer punto de
referencia
Interpretar
resultados
Realizar
consulta
Formatear
resultados
Recibir
resultado
s
Enviar
resultados
Figura 4.1 Diagrama de bloques del proceso de comunicación entre el cliente y el servidor
El análisis detallado del cliente y el servidor se llevo a cabo siguiendo un enfoque
UML, por medio de diagramas de casos de uso y diagramas de actividad. A
continuación se presentan los diagramas de caso de uso, la definición de
escenarios y los diagramas de actividad que corresponden a la fase de análisis del
proyecto.
En la figura 4.2 se muestra el diagrama general de casos de uso del proyecto, se
visualizan las funciones principales que ofrece, las cuales son:
Consultar tareas pendientes.
Alta de tarea.
Completar tarea.
Cancelar tarea.
45
CU-1 Consultar
tareas pendientes
CU-2 Alta de tarea
CU-3 Completar
tarea
Dispositivo cliente
Servidor
CU-4 Cancelar tarea
Figura 4.2 Diagrama general de casos de uso
La figura 4.3 muestra el diagrama de caso de uso CU-1 Consultar tareas
pendientes. La consulta de tareas pendientes puede ser general, o puede filtrarse
mediante la verificación de los objetos que se encuentran en el contexto del
dispositivo (la verificación puede realizarse mediante código de barras o RFID).
CU-1.1 Verificar
Contexto
«extends»
CU-1 Consultar
tareas pendientes
«uses»
CU-1.2 Listado de
tareas pendientes
Dispositivo cliente
Servidor
Figura 4.3 Diagrama del caso de uso CU-1 Consultar tareas pendientes
Tabla 3 Descripción del caso de uso CU-1 Consultar tareas pendientes
ID:
CU-1
El diagrama de actividades que incluye los escenarios de
éxito y los escenarios de fracaso se muestra en la figura 4.4.
Nombre del caso
Consultar tareas pendientes.
de uso:
Actores Dispositivo cliente, Servidor.
Permite consultar las tareas pendientes que tiene el usuario
Descripción:
mediante la conexión con el servidor y la verificación del contexto.
46
Precondiciones:
Postcondiciones:
Escenario de
éxito 1:
Escenario de
éxito 2:
Incluye:
Suposiciones:
1. El dispositivo cliente debe tener acceso al servidor por medio de
Internet.
2. El usuario debe haber accedido a la aplicación y haberse
autentificado.
1. Se obtendrá un listado de tareas pendientes que serán
mostradas en el dispositivo cliente.
1. Se inicia la conexión con el servidor.
2. El servidor consulta en la base de datos y devuelve mediante
HTTP un listado de tareas pendientes.
3. El dispositivo cliente visualiza el listado de tareas.
4. Terminar el proceso.
1. Se verifica el contexto.
2. Se inicia la conexión con el servidor enviándole datos del
contexto.
3. El servidor consulta en la base de datos las tareas pendientes
haciendo un filtrado según el contexto enviado y devuelve
mediante HTTP un listado de tareas pendientes.
CU-1.1 Verificar contexto, CU-1.2 Listado de tareas pendientes.
Se supone que el cliente tiene acceso a una conexión HTTP.
No
Conectar con el servidor
Verificar
contexto
Si
Buscar recursos en cercanía (RFID o barras)
Obtener un listado de tareas pendientes
Figura 4.4 Diagrama de actividad del caso de uso CU-1 Consultar tareas pendientes
Tabla 4 Descripción del caso de uso CU-1.2 Listado de tareas pendientes
ID:
CU-1.2
El diagrama de actividades que incluye el escenario de
éxito y los escenarios de fracaso se muestra en la figura
4.5.
Nombre del caso
Listado de tareas pendientes.
de uso:
47
Descripción: Despliega un listado tareas pendientes que tiene el usuario.
Internet.
Precondiciones:
autentificado.
1. Se obtendrá un listado de tareas pendientes que serán
Postcondiciones:
mostradas en el dispositivo cliente.
1. Se inicia la conexión con el servidor.
2. El servidor consulta en la base de datos y devuelve mediante
Escenario de
HTTP un listado de tareas pendientes.
éxito 1:
Incluye:
Suposiciones: Se supone que el cliente tiene acceso a una conexión HTTP.
Conectar con el servidor
No
Hay tareas
Informar que no existen tareas
Si
Obtener un listado de tareas pendientes
Figura 4.5 Diagrama de actividad del caso de uso CU-1.2 Listado de tareas pendientes
En la figura 4.6 se muestra el diagrama de caso de uso CU-1.1 Verificar contexto.
48
CU-1.1.1 Consultar
por RFID
«extends»
Dispositivo cliente
CU-1.1 Verificar
Contexto
CU-1.1.2 Consultar
por Barras
«extends»
«extends»
CU-1.1.3 Obtener
ubicación
Servidor
Figura 4.6 Diagrama del caso de uso CU-1.1 Verificar contexto
Tabla 5 Descripción del caso de uso CU-1.1 Verificar contexto
ID:
CU-1.1
El diagrama de actividades que incluye el escenario de éxito
y los escenarios de fracaso se muestra en la figura 4.7.
Nombre del
Verificar contexto.
caso de uso:
Permite que el dispositivo monitoreé su alrededor en busca de recursos
Descripción:
que estén asociados a una tarea.
1. El dispositivo cliente debe tener acceso a un lector de tarjetas RFID,
ó
Precondicione
2. El dispositivo cliente debe tener una cámara fotográfica incluida.
s:
autentificado.
Postcondicion 1. Se obtendrá un listado de recursos en cercanía, los cuales se
es:
relacionen con tareas pendientes almacenadas previamente.
1. Se inicia la conexión con el lector de tarjetas RFID.
2. Se obtienen los identificadores de los recursos en cercanía.
Escenario de
3. Se envían los identificadores de los recursos encontrados al
éxito 1:
servidor.
1. Se inicia la conexión con la cámara fotográfica.
2. Se captura la imagen correspondiente al código de barras del
recurso.
Escenario de
3. Se decodifica el código de barras obteniendo un identificador del
éxito 2:
recurso.
5. Se envía el identificador del recurso encontrado al servidor.
CU-1.1.1 Consultar por RFID, CU-1.1.2 Consultar por barras, CU-1.1.3
Incluye:
Obtener ubicación.
Se supone que el cliente tiene acceso a un lector RFID y a una cámara
Suposiciones: fotográfica y que la fotografía capturada corresponde a un código de
barras.
49
No
Código de
barras
Si
Conectar con el lector RFID
Conectar con cámara fotográfica
Obtener los identificadores en cercanía
Obtener fotografía de código de barras
Enviar información al servidor
Decodificar fotografía (código de barras)
Figura 4.7 Diagrama de actividad del caso de uso CU-1.1 Verificar contexto
Tabla 6 Descripción del caso de uso CU-1.1.1 Consultar por RFID
ID:
CU-1.1.1
4.8.
Nombre del caso
Consultar por RFID.
de uso:
Permite que el dispositivo monitoreé su alrededor en busca de
Descripción:
tarjetas RFID al alcance.
1. El dispositivo cliente debe tener acceso a un lector de tarjetas
RFID.
Precondiciones: 2. El dispositivo cliente tiene acceso mediante HTTP al servidor.
3. El usuario previamente ha ingresado a la aplicación y ha sido
autentificado.
1. Se obtendrán todos los recursos que se encuentren en cercanía
Postcondiciones:
al dispositivo cliente.
1. Se inicia la conexión con el lector de tarjetas RFID.
2. Se obtienen los identificadores de los recursos en cercanía.
Escenario de
3. Se envían los identificadores de los recursos encontrados al
éxito:
servidor.
1. Iniciar la conexión con el lector de tarjetas RFID.
Escenario de 2. Ocurre un error en la conexión.
fracaso 1: 3. Indicar que no se obtuvieron los datos.
4. Terminar proceso.
1. Iniciar la conexión con el lector de tarjetas RFID.
2. Extraer los identificadores de las tarjetas RFID en cercanía.
Escenario de
3. No hay tarjetas RFID en cercanía.
fracaso 2:
4. Indicar que no se obtuvieron los datos.
50
Incluye:
Suposiciones:
Se supone que el dispositivo cliente tiene acceso a un servidor por
medio de HTTP.
Conectar con el lector RFID
No
Conexión
establecida
Si
Extraer identificadores de tarjetas RFID
No
Extrajo
Si
Indicar que no se obtuvieron los datos
Figura 4.8 Diagrama de actividad del caso de uso CU-1.1.1 Consultar por RFID
Tabla 7 Descripción del caso de uso CU-1.1.2 Consultar por Barras
ID:
CU-1.1.2
4.9.
Nombre del caso
Consultar por barras.
de uso:
Permite que el dispositivo tome una fotografía y decodifique la
Descripción:
imagen si tiene un código de barras.
1. El dispositivo cliente debe tener acceso a una cámara fotográfica.
2. El dispositivo cliente tiene acceso mediante HTTP al servidor.
Precondiciones:
autentificado.
Postcondiciones: 1. Se decodificará la imagen que contiene un código de barras.
1. Se inicia la conexión con la cámara fotográfica.
2. Capturar imagen correspondiente al código de barras.
Escenario de 3. Convertir imagen capturada a monocromática.
éxito: 4. Decodificar imagen capturada (código de barras).
5. Enviar información al servidor.
Escenario de 1. Iniciar la conexión con la cámara fotográfica.
fracaso 1: 2. Ocurre un error en la conexión.
51
3.
4.
1.
2.
3.
Escenario de
4.
fracaso 2:
Indicar que no fue posible decodificar la imagen.
Terminar proceso.
Iniciar la conexión con la cámara fotográfica.
Capturar la imagen.
Convertir imagen a monocromática.
No se puede decodificar la imagen debido a que no es un código
de barras.
5. Indicar que no se pudo decodificar la imagen.
Incluye:
Suposiciones:
medio de HTTP.
Conectar con la cámara fotográfica
No
Conexión
establecida
Si
Capturar imagen
Convertir imagen a monocromática
Decodificar imagen
Decodificó
No
Si
No fue posible decodificar
Figura 4.9 Diagrama de actividad del caso de uso CU-1.1.2 Consultar por barras
Tabla 8 Descripción del caso de uso CU-1.1.3 Obtener ubicación
ID:
CU-1.1.3
4.10.
Nombre del
Obtener ubicación.
caso de uso:
52
Actores
Dispositivo cliente, Servidor.
Obtiene la ubicación actual del dispositivo utilizando RFID, Wi-Fi,
Descripción:
Bluetooth, GPS o alguna técnica en GSM.
1. El dispositivo cliente tiene acceso mediante HTTP al servidor.
Precondicione
s:
autentificado.
Postcondicion
1. Se obtendrá la localización del dispositivo.
es:
1. Iniciar la conexión con el dispositivo GPS.
Escenario de 2. Se obtiene la lectura de datos del GPS.
éxito 1: 3. Se obtiene la información de ubicación del dispositivo.
2. No se puede conectar con el dispositivo GPS.
3. Establecer conexión con el lector RFID.
Escenario de 4. Se leen las tarjetas RFID en cercanía.
éxito 2: 5. Se envía los identificadores de las tarjetas leídas al servidor.
6. El servidor mapea el identificador en la ubicación.
7. Se obtiene la información de ubicación del dispositivo.
2. No se puede obtener información de ubicación del GPS.
4. No se puede conectar con el lector o no existen tarjetas RFID en
cercanía.
Escenario de 5. Establecer conexión con Bluetooth.
éxito 3: 6. Obtener dispositivos cercanos.
7. Se envía las direcciones MAC de los dispositivos cercanos al
servidor.
8. El servidor mapea la dirección MAC en la ubicación.
cercanía.
5. Establecer conexión con Bluetooth.
6. No se puede establecer la conexión Bluetooth o no existen
Escenario de
dispositivos con Bluetooth en cercanía.
éxito 4:
7. Establecer conexión Wi-Fi.
8. Obtener dispositivos cercanos.
9. Se envía las direcciones MAC de los dispositivos cercanos al
servidor.
10. El servidor mapea la dirección MAC en la ubicación.
Escenario de
éxito 5:
53
cercanía.
5. Establecer conexión con Bluetooth.
6. No se puede establecer la conexión Bluetooth o no existen
dispositivos con Bluetooth en cercanía.
7. Establecer conexión Wi-Fi.
8. No se puede establecer la conexión Wi-Fi o no existen AP en
cercanía.
9. Obtener células GSM.
Incluye:
Suposiciones:
medio de HTTP. Se supone además que el dispositivo cuenta al menos
con conectividad GSM.
Verificar conectividad GPS
No
Existe
conexión
Si
Establecer conexión con lector RFID
Obtener lectura de GPS
No
Establecer conexión Bluetooth
Si
Conexión
establecida
No
Se obtuvo
lectura
Leer tarjetas en cercanía
Si
Obtener ubicación
A
No
Se obtuvo
lectura
C
Si
Enviar identificador al servidor
B
Figura 4.10 Diagrama de actividad del caso de uso CU-1.1.3 Obtener ubicación
54
A
No
Si
Conexión
establecida
Verificar dispositivos en cercanía
Establecer conexión Wi-Fi
No
No
Hay
dispositivos
Si
Conexión
establecida
Si
Verificar dispositivos cercanos
Obtener información GSM
B
C
No
Hay
dispositivos
Si
Figura 4.10 Diagrama de actividad del caso de uso CU-1.1.3 Obtener ubicación (Cont.)
En la figura 4.11 se muestra el diagrama de caso de uso CU-2 Alta de Tarea.
CU-2.1 Seleccionar
tarea de guiado
CU-1.1 Verificar
Contexto
«extends»
«extends»
CU-2 Alta de tarea
Servidor
Dispositivo cliente
Figura 4.11 Diagrama del caso de uso CU-2 Alta de tarea
Tabla 9 Descripción del caso de uso CU-2 Alta de tarea
ID:
CU-1.2
4.12.
55
Nombre del caso
Alta de tarea.
de uso:
Actores Dispositivo cliente, Servidor
Descripción: Permite al usuario registrar nuevas tareas.
internet.
Precondiciones:
2. El usuario debe haber ingresado y haber sido autentificado en la
aplicación.
1. Se creará una nueva tarea la cual se establecerá como
Postcondiciones:
pendiente.
1. Seleccionar actividad.
2. Seleccionar tipo de tarea.
3. Seleccionar tarea.
4. Elegir recurso asociado.
Escenario de
5. Verificar contexto.
éxito 1:
6. Establecer fecha de cumplimiento.
7. Almacenar tarea en servidor.
8. Establecer tarea como pendiente.
1. Seleccionar actividad.
2. Seleccionar tipo de tarea.
Escenario de 4. Elegir recurso asociado.
éxito 2: 5. Establecer fecha de cumplimiento.
6. Almacenar tarea en servidor.
7. Establecer tarea como pendiente.
Incluye: CU-1.1 Verificar contexto, CU-2.1 Seleccionar tarea de guiado.
56
Seleccionar Actividad
Seleccionar tipo de tarea
Seleccionar tarea
Elegir recurso asociado
No
Verificar
contexto
Si
Establecer fecha de cumplimiento
Almacenar tarea en servidor
Establecer tarea como pendiente
Figura 4.12 Diagrama de actividad del caso de uso CU-2 Alta de tarea
En la figura 4.13 se muestra el diagrama de casos de uso CU-2.1 Seleccionar
tarea de guiado.
CU-2.1 Seleccionar
tarea de guiado
«uses»
CU-1.1.3 Obtener
ubicación
«uses»
Dispositivo cliente
CU-2.1.1 Obtener
Ruta
Figura 4.13 Diagrama del caso de uso CU-2.1 Seleccionar tarea de guiado
57
Servidor
Tabla 10 Descripción del caso de uso CU-2.1 Seleccionar tarea de guiado
ID:
CU-2.1
4.14.
Nombre del caso
Seleccionar tarea de guiado.
de uso:
Descripción: Permite al usuario hacer una tarea de guiado.
internet.
Precondiciones:
2. El usuario debe haber accedido a la aplicación y haber sido
autentificado.
1. Se completará una tarea que se tenía establecida como
Postcondiciones:
pendiente.
1. El usuario selecciona la tarea de guiado.
2. Se obtiene la ubicación actual.
3. Se selecciona la ubicación destino.
Escenario de
4. Se envían la ubicación actual y la destino al servidor.
éxito 1:
5. El servidor crea la ruta y la devuelve mediante HTTP al cliente.
6. El dispositivo cliente debe seguir la ruta establecida.
1. El usuario selecciona la tarea de guiado.
2. No se puede obtener la ubicación actual.
Escenario de
3. Se envía un mensaje indicándole al cliente que el proceso no
fracaso 1:
puede llevarse a cabo.
Incluye: CU-1.1.3 Obtener ubicación, CU-2.1.1 Obtener ruta.
58
Seleccionar tarea de guiado
Obtener la ubicación actual
No
Se obtuvo
ubicación
Si
Seleccionar la ubicación destino
Informar que no se pudo realizar la operación
Obtener ruta del servidor
Figura 4.14 Diagrama de actividad del caso de uso CU-2.1 Seleccionar tarea de guiado
En la figura 4.15 se muestra el diagrama de caso de uso CU-3 Completar Tarea.
CU-1.1 Verificar
Contexto
«extends»
CU-3 Completar
tarea
Dispositivo cliente
Servidor
Figura 4.15 Diagrama del caso de uso CU-3 Completar tarea
Tabla 11 Descripción del caso de uso CU-3 Completar tarea
ID:
CU-1.3
4.16.
Nombre del caso
Completar tarea.
de uso:
Actores Dispositivo cliente, Servidor
Descripción: Permite al usuario completar una tarea pendiente.
Precondiciones: 1. El dispositivo cliente debe tener acceso al servidor por medio de
59
Postcondiciones:
Escenario de
éxito 1:
Escenario de
éxito 2:
Incluye:
Suposiciones:
internet.
autentificado.
3. El usuario deber haber consultado el listado de tareas
pendientes.
4. El usuario debe haber elegido el detalle de la tarea que quiere
completar.
1. Se completará una tarea que se tenía establecida como
pendiente.
2. Buscar recursos en cercanía.
4. Completar tarea.
5. Cambiar estado de tarea a completa.
2. Completar tarea.
3. Cambiar estado de tarea a completa.
CU-1.1 Verificar contexto.
Se supone que el cliente tiene acceso a una conexión HTTP.
No
Verificar
contexto
Seleccionar tarea
Si
Completar tarea
Cambiar estado de tarea a completa
Figura 4.16 Diagrama de actividad del caso de uso CU-3 Completar tarea
En la figura 4.17 se muestra el diagrama de caso de uso CU-4 Cancelar Tarea.
60
CU-1.1 Verificar
Contexto
«extends»
CU-3 Completar
tarea
Dispositivo cliente
Servidor
Figura 4.17 Diagrama del caso de uso CU-4 Cancelar tarea
Tabla 12 Descripción del caso de uso CU-4 Cancelar tarea
ID:
CU-1.3
4.18.
Nombre del caso
Cancelar tarea.
de uso:
Descripción: Permite al usuario cancelar una tarea pendiente.
internet.
autentificado.
Precondiciones:
3. El usuario deber haber consultado el listado de tareas
pendientes.
4. El usuario debe haber elegido el detalle de la tarea que quiere
cancelar.
Postcondiciones: 1. Se cancelará una tarea que se tenía establecida como pendiente.
2. Buscar recursos en cercanía.
Escenario de 3. Seleccionar tarea.
éxito 1: 4. Cancelar tarea.
5. Cambiar estado de tarea a cancelada.
Escenario de 2. Cancelar tarea.
éxito 2: 3. Cambiar estado de tarea a cancelada.
Incluye: CU-1.1 Verificar contexto.
61
No
Verificar
contexto
Seleccionar tarea
Si
Cancelar tarea
Cambiar estado de tarea a cancelada
Figura 4.18 Diagrama de actividad del caso de uso CU-4 Cancelar tarea
4.2 Diseño
El proyecto de tesis consiste en dos partes: la parte cliente y la parte servidora. El
diseño se explicará para cada una de las partes. En el punto 2.2.5 se detalla la
interacción entre las clases del cliente y el servidor en las operaciones que
realizará el sistema.
4.2.1 Cliente
La parte cliente consta de 7 paquetes que se listan a continuación:
mx.edu.cenidet.clientetareasandroid.activities define las activities propias de la
interfaz del cliente Android.
mx.edu.cenidet.clientetareasandroid.codigobarras implementa la lectura y
decodificación del código de barras.
mx.edu.cenidet.clientetareasandroid.conexionhttp contiene las clases para la
conexión con el servidor de tareas a través del protocolo HTTP.
mx.edu.cenidet.clientetareasandroid.interfaz define las interfaces gráficas del
cliente Android.
mx.edu.cenidet.clientetareasandroid.objetos define los objetos requeridos para
el establecimiento de tareas.
mx.edu.cenidet.clientetareasandroid.rfid define las clases para la conexión con
el lector de tarjetas RFID y para la lectura de las tarjetas.
mx.edu.cenidet.clientetareasandroid.utilerias
contiene
clases
para
el
procesamiento de imágenes, cadenas y la configuración propia del cliente
Android.
62
El nombre de los paquetes se asignó siguiendo las recomendaciones descritas en
el artículo Estructura de paquetes [Rames 2005].
La figura 4.19 muestra el diagrama de paquetes pertenecientes al cliente Android.
Figura 4.19 Diagrama de paquetes del cliente
4.2.1.1 Paquete mx.edu.cenidet.clientetareasandroid.activities
En la figura 4.20 se muestra el diagrama de clases del paquete
mx.edu.cenidet.clientetareasandroid.activities, el cual forma parte de la interfaz de
usuario.
Figura 4.20 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.activities
63
A continuación se describen de manera general las clases que componen a este
paquete. Cabe recalcar que este paquete define las interfaces gráficas con las que
trabaja Android, debido a esto no hay relación alguna entre las clases de este
paquete, no obstante si las hay de este paquete con los demás paquetes.
ActividadesListActivity. Contiene métodos para la obtención de la interfaz
gráfica en donde se visualiza un listado de actividades a las que puede tener
acceso un determinado usuario.
CapturaBarrasGuiadoActivity. Contiene la funcionalidad necesaria para
visualizar la interfaz gráfica para la captura de una imagen con código de
barras utilizado para realizar el proceso de guiado.
CapturaBarrasOrigenActivity. Contiene la funcionalidad necesaria para
visualizar la interfaz gráfica para la captura de una imagen con código de
barras utilizado para obtener la ubicación inicial del usuario dentro del proceso
de guiado.
DaemonTareas. Contiene los métodos y atributos necesarios para el
lanzamiento de un servicio que se ejecuta en segundo plano y está verificando
objetos cercanos que se asocien a tareas o tareas que se cumplan en los
próximos minutos.
GrupoListActivity. Proporciona la funcionalidad necesaria para visualizar una
lista de grupos de usuarios.
GuiadoActivity. Proporciona la interfaz gráfica necesaria para la realización de
la tarea de guiado en interiores utilizando RFID.
GuiadoQRCodesActivity. Proporciona la interfaz gráfica necesaria para la
realización de la tarea de guiado en interiores utilizando código de barras.
InstanciaTareaDetalleActivity. Contiene métodos y atributos necesarios para
la presentación al usuario de la información detallada de una tarea pendiente.
InstanciaTareaListActivity. Contiene métodos para la obtención de la interfaz
gráfica de un listado de tareas pendientes del usuario.
LoginActivity. Proporciona métodos para la presentación de la pantalla de
autenticación del usuario.
NuevaTareaActivity. Contiene métodos para visualizar la pantalla de alta de
una nueva tarea.
RecursoDetalleActivity. Proporciona métodos y atributos para la presentación
en pantalla de los detalles de un recurso.
RecursoListActivity. Contiene métodos para visualizar la pantalla de listado
de recursos, utilizando para mostrar los recursos cercanos al dispositivo.
TipoTareaListActivity. Proporciona métodos para la presentación en pantalla
de un listado de tareas disponibles para que un usuario pueda instanciarlas.
UbicacionDetalleActivity. Contiene métodos y atributos necesarios para
mostrar en pantalla el detalle de una ubicación.
UbicacionListQrcodesActivity. Proporciona métodos y atributos necesarios
para mostrar un listado con las ubicaciones. Utilizado para que el usuario
seleccione el destino en el proceso de guiado mediante QRCodes.
64
UbicacionListRFIDActivity. Contiene los métodos necesarios para mostrar en
pantalla un listado con las ubicaciones. Utilizado para que el usuario seleccione
el destino en el proceso de guiado mediante RFID.
UsuarioDetalleActivity. Proporciona métodos para la presentación en pantalla
de información detallada de un usuario.
UsuarioDetalleTareaActivity. Contiene los métodos que permiten mostrar en
pantalla la información detallada de un usuario.
UsuarioListActivity. Contiene métodos que permiten mostrar un listado de
usuarios pertenecientes. Utilizado para verificar los usuarios en cercanía.
4.2.1.2 Paquete mx.edu.cenidet.clientetareasandroid.interfaz
El paquete mx.edu.cenidet.clientetareasandroid.interfaz complementa al paquete
descrito anteriormente (4.2.1.1 mx.edu.cenidet.clientetareasandroid.activities) en
el despliegue y establecimiento de la interfaz de usuario.
La
figura
4.21
muestra
las
clases
pertenecientes
al
paquete
mx.edu.cenidet.clientetareasandroid.interfaz, el cual contiene clases para el
despliegue en pantalla de listas elegibles, ventanas de dialogo y todos los
elementos necesarios para la presentación visual de la interfaz al usuario.
Figura 4.21 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.interfaz
65
Las clases del este paquete se describen a continuación:
ActividadAdapter. Contiene las vistas y métodos necesarios para el
despliegue de las actividades en forma de una lista. Esta clase es usada por la
clase ActividadesListActivity para mostrar al usuario una lista de actividades
disponibles para elegir.
Dialogo. Esta clase permite mostrar en pantalla mensajes de alerta para
indicar al usuario, ya sea que una acción no se realizó, o que ha sido
completada exitosamente.
GrupoAdapter. Proporciona métodos necesarios para presentar los grupos de
usuarios en forma de una lista. Cabe destacar que esta clase es utilizada por la
clase GrupoListActivity para mostrar en pantalla un listado de grupos de
usuario almacenados en la base de datos.
InstanciaTareaAdapter. Contiene las vistas y métodos necesarios para el
despliegue de las tareas pendientes en forma de una lista. Esta clase es usada
por la clase InstanciaTareaListActivity para mostrar al usuario una lista de las
tareas pendientes que tiene almacenadas en la base de datos.
RecursoAdapter. Proporciona métodos necesarios para presentar los
recursos en forma de una lista elegible. Esta clase es usada por la clase
RecursoListActivity.
TipoTareaAdapter. Proporciona métodos necesarios para mostrar en un
listado los tipos de tarea. Cabe destacar que esta clase es utilizada por la clase
ipoTareaListActivity para mostrar en pantalla un listado de tipos de tarea a los
que un usuario puede tener acceso.
UbicacionAdapter. Contiene métodos para el despliegue de un listado de
ubicaciones. Esta clase es usada por la clase UbicacionListActivity para
mostrar al usuario una lista de las ubicaciones almacenadas en la base de
datos.
UsuarioAdapter. Proporciona los métodos necesarios para mostrar un listado
de usuarios. Cabe destacar que esta clase es utilizada por la clase
UsuarioGroupListActivity para mostrar en pantalla un listado de los usuarios
pertenecientes a un grupo de usuarios.
VistaGuiado. Proporciona los métodos y atributos necesarios para establecer
la interfaz de la actividad de guiado y refrescar la ubicación del usuario. Es
utilizada por las clases GuiadoActivity y GuiadoQRCodesActivity.
Complementado los paquetes pertenecientes a la interfaz de usuario y debido a la
forma de programación en Android, en donde se pueden definir las interfaces
mediante archivos XML, se establecieron 8 archivos para definir las interfaces, los
cuales son descritos a continuación:
 captura_barras.xml. Es utilizado para definir la interfaz que permite al
usuario capturar una fotografía con un código de barras y decodificarla.
 detalles_instancia_tarea.xml. Es utilizado para definir la interfaz que
permite al usuario capturar incidencias de alguna tarea pendiente, así como
66






completar o cancelar la tarea, también es utilizada para consultar los
detalles de una tarea.
detalles_ubicacion.xml. Define la interfaz para mostrar el detalle de una
ubicación.
detalles_usuario.xml. Define la interfaz para mostrar los detalles de un
usuario.
guiado.xml. Es utilizado para establecer la interfaz en el proceso de
guiado.
lista.xml. Define la interfaz para el despliegue de una vista en forma de
listado.
login.xml. Define la interfaz de la pantalla principal del sistema, en donde el
usuario se autentifica.
nueva_tarea_recurso.xml. Define la interfaz necesaria para que un
usuario establezca una nueva tarea como pendiente.
El contenido de estos archivos se detalla en el anexo A.
4.2.1.3 Paquete mx.edu.cenidet.clientetareasandroid.codigobarras
La
figura
4.22
muestra
las
clases
pertenecientes
al
paquete
mx.edu.cenidet.clientetareasandroid.codigobarras el cual hace uso de la API
ZXing [Zxing 2009], la cual es utilizada para la decodificación del código de barras.
Figura 4.22 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.codigobarras
En seguida se describen a grandes rasgos las clases pertenecientes a este
paquete.
CodigoBarras. Esta clase hace uso de la API ZXing para decodificar un
código de barras y contiene los métodos necesarios para la utilización de dicha
API y de la cámara fotográfica del dispositivo celular, quien se hará cargo de la
captura de la imagen.
RGBMonochromeBitmapSource. Proporciona los métodos necesarios para
el tratamiento de una imagen con la finalidad de convertirla en un formato que
sea más fácil de codificar por la API ZXing, para ello la imagen es convertida a
monocromática (blanco y negro).
En la figura 4.23 se muestra, mediante un diagrama de secuencias, el proceso
para decodificar una imagen que contiene un código de barras.
67
CodigoBarras
RGBMonochromeBitmapSource
Cliente
1. Selecciona por barras
2. Conecta
cámara
3. Muestra imagen
4. Captura imagen
5. Envía imagen
6. Convierte imagen
a monocromática
7. Envía imagen tratada
8. Decodifica imagen
9. Muestra identificador
Figura 4.23 Diagrama de secuencias para la decodificación del código de barras
El proceso de decodificación de código de barras es iniciado por el usuario cuando
quiere dar de alta una nueva tarea o quiere realizar el proceso de guiado mediante
QRCodes, el usuario elige identificar a un recurso por medio de un código de
barras. La clase CodigoBarras realiza la conexión con la cámara del dispositivo y
el cliente captura la imagen, hecho esto la clase CodigoBarras obtiene la imagen
capturada y la envía a la clase RGBMonochromeBitmapSource, la cual se encarga
de convertir la imagen a monocromática. Una vez que la imagen es tratada se
reenvía nuevamente a la clase CodigoBarras la cual utiliza la API ZXing para
decodificar el código de barras contenido en la imagen, finalmente se envía el
identificador perteneciente al código de barras capturado.
4.2.1.4 Paquete mx.edu.cenidet.clientetareasandroid.conexionhttp
En la figura 4.24 se muestran las clases pertenecientes al
mx.edu.cenidet.clientetareasandroid.conexionhttp.
Este
paquete
únicamente de dos clases, las cuales se describe a continuación:
paquete
consta
ConexionHTTP. Contiene los métodos necesarios para el establecimiento de
peticiones POST y GET mediante el protocolo HTTP, con la finalidad de
consumir los recursos ofrecidos por el servicio Web.
PeticionesHTTP. Proporciona métodos y atributos necesarios para obtener
objetos serializados de las peticiones mediante el protocolo HTTP.
68
Figura 4.24 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.conexionhttp
La descripción de la conexión HTTP entre cliente y servidor se detalla en el
diagrama de secuencias de la figura 4.25.
Cliente
Servidor
ConexionHTTP
WebServiceApplication
1. Envía petición GET/POST
2. Recibe petición y
redirecciona según URL
3. Envía respuesta en JSON
Figura 4.25 Diagrama de secuencias comunicación cliente/servidor por HTTP
La comunicación mediante el protocolo HTTP entre el cliente y el servidor es
iniciada por el cliente. La clase ConexionHTTP realiza una petición POST o GET,
después, del lado del servidor, la clase WebServiceApplication, la cual hace la
función de receptor de peticiones, recibe esta petición y según la URL solicitada, la
redirecciona otra clase. Cabe destacar que éste es el diagrama de secuencias
general de la comunicación HTTP entre el cliente y el servidor.
4.2.1.5 Paquete mx.edu.cenidet.clientetareasandroid.objetos
En la figura 4.26 se muestran las clases
mx.edu.cenidet.clientetareasandroid.objetos.
69
pertenecientes
al
paquete
Figura 4.26 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.objetos
A continuación se describen de manera general las clases que componen este
paquete. Cabe recalcar que este paquete define los objetos que se utilizan como
base para la realización de las operaciones del cliente, entre las que destacan la
recepción de objetos serializados enviados por el servidor mediante el protocolo
HTTP; debido a esto no hay relación alguna entre las clases de este paquete, no
obstante si las hay de este paquete con los demás paquetes.
Actividad. Contiene los métodos y atributos necesarios para la creación de
objetos del tipo Actividad, el cual representa una actividad para el sistema.
Grupo. Proporciona los métodos y atributos para la creación de objetos del tipo
Grupo, el cual representa a un grupo de usuarios.
InstanciaTarea. Contiene los métodos y atributos necesarios para la creación
y manipulación de objetos del tipo InstanciaTarea, el cual representa las tareas
pendientes de un determinado usuario.
Recurso. Proporciona los métodos y atributos para la creación de objetos del
tipo Recurso, el cual representa el recurso asociado a una tarea.
TipoTarea. Contiene los métodos y atributos necesarios para la creación y
manipulación de objetos del tipo TipoTarea, que representa las tareas que un
usuario o grupo de usuarios tiene disponibles para establecer como
pendientes.
Ubicacion. Proporciona los métodos y atributos para la creación de objetos del
tipo Ubicacion, el cual representa una ubicación almacenada en la base de
datos (en el servidor) y será utilizada en el proceso de guiado.
Usuario. Contiene los métodos y atributos necesarios para la creación y
manipulación de objetos del tipo Usuario, el cual representa un usuario
contenido en la base de datos (en el servidor de tareas).
70
4.2.1.6 Paquete mx.edu.cenidet.clientetareasandroid.rfid
En la figura 4.27 se muestra la clase perteneciente al paquete
mx.edu.cenidet.clientetareasandroid.rfid. Únicamente cuenta con una clase la cual
establece la conexión mediante un hilo con el lector de tarjetas RFID y rec ibe las
lecturas provenientes de él.
Figura 4.27 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.rfid
Cabe destacar que actualmente los dispositivos celulares no cuentan con lectores
de tarjetas RFID. La solución que se propone es realizar una aplicación en java
que establezca conexión con el lector de tarjetas RFID, el cual esté conectado a
una computadora mediante el puerto USB, de este modo el cliente Android se
conectará por medio de un socket a la computadora que tiene asociado el lector
de tarjetas RFID para obtener la lectura de las tarjetas RFID al alcance. La figura
4.28 muestra el diagrama de secuencias necesario para la obtención de una
lectura de tarjetas RFID.
ConexionRFID
IntermediarioRFID
1. Inicia hilo de conexión
LectorRFID
2. Recibe petición
3. Envía respuesta de conexión
4. Establece conexión
7. Recibe petición
Cliente
8. Envía respuesta de conexión
9. Establece conexión
10. Verifica conexión al
puerto
12. Envía identificador RFID
11. Obtiene lectura
RFID
...
15. Cierra hilo de conexión
17. Cierra hilo de conexión
Servidor de
conexión
RFID
14. Envía identificador RFID
Figura 4.28 Diagrama de secuencias para el proceso de lectura de tarjeta RFID
71
El proceso de obtención de tarjetas RFID en cercanía comienza del lado del
cliente (ConexionRFID), el cual inicia un hilo de conexión por medio de un socket
con el intermediario RFID, que hará el papel de intermediario entre el cliente y el
lector de tarjetas RFID. El intermediario RFID mediante la clase IntermediarioRFID
recibe la petición y se establece la conexión, IntermediarioRFID inicia otro hilo con
la clase LectorRFID la cual realiza la conexión con el lector RFID y obtiene la
lectura de la tarjeta RFID en cercanía, paso siguiente LectorRFID envía el
identificador RFID, el cual es interceptado por IntermediarioRFID y retransmitido a
ConexionRFID (ya del lado del cliente) el cual recibe el identificador de la tarjeta
RFID leída.
De esta forma se pueden realizar diversas operaciones dentro del sistema, como:
la identificación de recursos, la localización del dispositivo o el proceso de guiado.
Este proceso es iterativo y finaliza hasta que el cliente cierra socket de conexión;
mientras el hilo esté funcionando se estarán leyendo tarjetas en cercanía de la
forma antes descrita.
4.2.1.7 Paquete mx.edu.cenidet.clientetareasandroid.utilerias
Este paquete contiene métodos para el procesamiento de imágenes, cadenas y la
configuración propia del cliente Android.
La figura 4.29 muestra las clases pertenecientes a este paquete.
Figura 4.29 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.utilerias
Estas clases son utilizadas por clases de otros paquetes para el procesamiento de
imágenes y cadenas. Las clases de este paquete se describen a continuación:
Cadenas. Contiene los métodos para el procesamiento de cadenas.
Imagenes. Proporciona los métodos y atributos para el procesamiento de
imágenes.
ParsedDataSet. Contiene los métodos necesarios para almacenar la
información del archivo de configuración XML.
72
ParserXML. Contiene los métodos necesarios para recorrer el archivo de
configuración XML.
XMLRead. Contiene los métodos necesarios para interactuar con la clase
ParserXML y obtener los valores de las etiquetas del archivo de configuración
XML.
4.2.2 Servidor de tareas
El servidor está compuesto de los siguientes paquetes:
mx.edu.cenidet.servidortareasosgi.basedatos define la conexión y las consultas
a la base de datos.
mx.edu.cenidet.servidortareasosgi.objetos define los objetos requeridos para el
establecimiento de tareas y métodos para la serialización de los objetos
mediante JSON.
mx.edu.cenidet.servidortareasosgi.osgi pone en marcha el servidor OSGI y
publica el servicio Web, además contiene una clase que la hace de
orquestador de las peticiones al servicio Web.
mx.edu.cenidet.servidortareasosgi.recursosrestlet define las clases que
atenderán las peticiones de los clientes al servicio Web.
mx.edu.cenidet.servidortareasosgi.utilerias contiene las clases para el
procesamiento de imágenes y cadenas.
La figura 4.30 muestra el diagrama de paquetes pertenecientes a la parte
servidora.
Figura 4.30 Diagrama de paquetes del servidor
4.2.2.1 Paquete mx.edu.cenidet.servidortareasosgi.basedatos
En la figura 4.31 se muestra el diagrama de las clases pertenecientes a este
paquete, el cual permite realizar las consultas y operaciones sobre la base de
datos.
73
Figura 4.31 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.basedatos
paquete. Cabe recalcar que este paquete es utilizado por otros paquetes que
utilizan llamadas a la base de datos dentro del servidor.
Conexion. Contiene métodos y atributos que permiten la conexión con la base
de datos de tareas.
OperacionesBD. Proporciona la funcionalidad necesaria para actualizar,
insertar o seleccionar registros en la base de datos.
4.2.2.2 Paquete mx.edu.cenidet.servidortareasosgi.osgi
En la figura 4.32 se muestra el diagrama de las clases pertenecientes a este
paquete, el cual permite activar el servidor y publicar el servicio Web.
Figura 4.32 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.osgi
paquete:
Activator. Esta clase es necesaria debido a que se utilizará OSGI como
Framework para el servidor y es mediante ella que se inicia y se detiene el
servicio.
WebServiceApplication. Esta aplicación sirve de orquestador entre las
peticiones que realiza el cliente al servidor, es decir, es el que se encarga de
redirigir las peticiones a las clases correspondientes según la URL solicitada.
Previamente en el diagrama de secuencias de la figura 4.25 se ha detallado la
comunicación entre el servidor y el cliente mediante el protocolo HTTP.
4.2.2.3 Paquete mx.edu.cenidet.servidortareasosgi.objetos
En la figura 4.33 se visualizan las clases pertenecientes a este paquete, el cual
permite crear objetos que son necesarios para enviar de forma serializada, a
través del protocolo HTTP, en la comunicación entre el cliente y el servidor de
tareas, debido a esto no hay relación alguna entre las clases de este paquete, no
74
obstante si las hay de este paquete con otros paquetes dentro del servidor de
tareas.
Figura 4.33 Diagrama de clases del paquete mx.edu.cenidet.servidortareasosgi.objetos
A continuación se detallan las clases pertenecientes a este paquete:
Actividad. Contiene los métodos y atributos necesarios para la creación y
serialización de objetos del tipo Actividad, el cual representa una actividad para
el sistema.
Error. Maneja los mensajes de error enviados al cliente, los cuales se envían
serializados en formato JSON.
Grupo. Proporciona los métodos y atributos para la creación, manejo y
serialización de objetos del tipo Grupo, el cual representa a un grupo de
usuarios.
InstanciaTarea. Contiene los métodos y atributos necesarios para la creación,
manipulación y serialización de objetos del tipo InstanciaTarea, el cual
representa las tareas pendientes de un determinado usuario.
Recurso. Proporciona los métodos y atributos para la creación, manejo y
serialización de objetos del tipo Recurso, el cual representa el recurso
asociado a una tarea.
TipoTarea. Contiene los métodos y atributos necesarios para la creación,
manipulación y serialización de objetos del tipo TipoTarea, las tareas que un
usuario o grupo de usuarios tiene disponibles para establecer como
pendientes.
75
Ubicacion. Proporciona los métodos y atributos para la creación, manejo y
serialización de objetos del tipo Ubicacion, el cual representa una ubicación
almacenada en la base de datos.
Usuario. Contiene los métodos y atributos necesarios para la creación,
manipulación y serialización de objetos del tipo Usuario, el cual representa un
usuario contenido en la base de datos.
4.2.2.4 Paquete mx.edu.cenidet.servidortareasosgi.utilerias
Este paquete contiene métodos para el procesamiento de cadenas.
La figura 4.34 muestra las clases pertenecientes a este paquete. Consta
únicamente de una clase la cual es utilizada por clases de otros paquetes para el
procesamiento de cadenas.
Figura 4.34 Diagrama de clases del paquete mx.edu.cenidet.servidortareasosgi.utilerias
4.2.2.5 Paquete mx.edu.cenidet.servidortareasosgi.recursosrestlet
Este paquete contiene métodos que atenderán las peticiones al servicio Web por
parte de los clientes. La figura 4.35 detalla las clases que incluye este paquete.
Cabe mencionar que no existen relaciones entre clases de este paquete, sin
embargo si las hay entre clases de este paquete y otros paquetes dentro del
servidor de tareas.
Figura 4.35 Diagrama de clases del paquete mx.edu.cenidet.servidortareasosgi.recursosrestlet
Las clases de este paquete se describen a continuación, debido a la relevancia de
este paquete el diseño de las clases se hará con más detalle que los anteriores,
tomando en cuenta casos de diseño.
76
4.2.3 Interacción cliente-servidor
4.2.3.1 Autentificación del usuario
El proceso de autentificación se desarrolla de la siguiente forma:
El proceso comienza cuando el usuario inicia la aplicación.
La clase LoginActivity es la primera en cargarse y ésta se encarga de lanzar el
intent que contiene la interfaz gráfica, además de llamar al archivo login.xml
(ver anexo A, para mayor detalle), el cual contiene la descripción de la interfaz
a utilizar. De este modo se carga la pantalla de autenticación, pidiendo al
usuario su clave y su contraseña.
El usuario captura la clave y la contraseña.
LoginActivity forma la URL de petición con la clave y la contraseña y la envía a
ConexionHTTP.
ConexionHTTP recibe la URL y envía una petición GET al servicio Web, el cual
es proporcionado por el servidor de tareas mediante la clase
WebServiceApplication; dicha clase recibe la petición y dependiendo la URL
solicitada, redirecciona la petición a la clase correspondiente, en este caso
UsuarioResource.
UsuarioResource recibe la petición GET y la redirecciona al método que
corresponde con esta petición. Dentro de esta función se formula la cadena
con la consulta SQL.
UsuarioResource instancia la clase OperacionesBD enviándole la consulta
SQL. OperacionesBD realiza la conexión a la base de datos mediante la clase
Conexion, esta última devuelve el objeto de conexión con la base de datos.
OperacionesBD recibe la conexión y realiza la consulta del usuario por medio
de su clave y contraseña en la base de datos. Hecho esto, cierra la conexión
con la base de datos, para después crear un objeto de tipo Usuario con la
información recibida, lo cual se realiza mediante la clase Usuario.
Usuario se encarga de serializar el objeto de este mismo tipo, utilizando el
formato de representación JSON, y envía esta información a la clase
UsuarioResource.
UsuarioResource recibe el objeto Usuario serializado y lo reenvía por medio de
HTTP al cliente, el cual lo recibe mediante la clase ConexionHTTP.
ConexionHTTP recibe la información serializada y envía los resultados en
forma de un objeto de tipo Usuario a la clase LoginActivity.
LoginActivity verifica que ha recibido un objeto de tipo Usuario y permite al
usuario ingresar al sistema, mostrando la pantalla de detalles del usuario.
Cabe destacar que esto se realiza antes de cada uno de los procesos, es por ello
que se excluirá esta parte en la explicación individual de cada uno de ellos. En la
figura 4.36 se describe mediante un diagrama de secuencias, el proceso de
autenticación del usuario, tomando en cuenta la comunicación entre el cliente y el
servidor de tareas.
77
LoginActivity
ConexionHTTP
UsuarioResource
OperacionesBD
Conexion
Usuario
Usuario
1. Inicia aplicación
2. Carga Intent
3. Despliega interfaz
4. Captura usuario y
contraseña
5. URL de petición
6. Envía petición GET con
usuario y contraseña
Servidor de
tareas
7. Redirección a
clase
UsuarioResource
8. Envía URL con usuario
y contraseña
9. Redirección a
método GET
10. Forma consulta SQL
Cliente
11. Establece
conexión con BD
12. Conexión a BD
13.Consulta usuario
y contraseña
14. Cierra conexión
15. Cierra
conexión con BD
16. Envía información obtenida
19. Envía objeto de tipo Usuario serializado en JSON
18. Envía objeto de tipo Usuario serializado en JSON
20. Envía resultados
22. Despliega pantalla
de detalles de usuario
21. Valida
resultados
Figura 4.36 Diagrama de secuencias para la autenticación del usuario
78
17. Serializa
Objeto
4.2.3.2 Consulta de tareas pendientes
El proceso de consulta de tareas pendientes se describe detalladamente a
continuación:
Previamente a este proceso el usuario se debe haber autentificado.
El proceso inicia cuando el usuario selecciona la opción de tareas pendientes.
La clase InstanciaTareaListActivity se encarga de lanzar el intent que contiene
la interfaz gráfica, además de llamar al archivo lista.xml (ver anexo A, para
mayor detalle), el cual contiene la descripción de la interfaz a utilizar.
InstanciaTareaListActivity forma la URL de petición incluyendo en ella la clave
del usuario y la envía a ConexionHTTP.
es ofrecido por el servidor de tareas mediante la clase WebServiceApplication,
dicha clase recibe la petición y dependiendo la URL solicitada redirecciona la
petición a la clase correspondiente, en este caso InstanciaTareaResource.
InstanciaTareaResource recibe la petición GET y la redirecciona al método que
con la consulta SQL en donde se filtran las tareas pendientes del usuario.
InstanciaTareaResource instancia la clase OperacionesBD enviándole la
consulta SQL.
OperacionesBD realiza la conexión a la base de datos mediante la clase
OperacionesBD recibe la conexión y realiza la consulta de las tareas
pendientes del usuario en la base de datos. Hecho esto, cierra la conexión con
la base de datos, para después crear un arreglo de objetos de tipo
InstanciaTarea con la información recibida de la consulta a la base de datos, lo
cual se realiza mediante la clase InstanciaTarea.
InstanciaTarea se encarga de serializar los objetos de este mismo tipo,
utilizando el formato de representación JSON, y envía esta información a la
clase InstanciaTareaResource.
InstanciaTareaResource recibe el arreglo de objetos InstanciaTarea serializado
y lo reenvía al cliente, el cual lo recibe mediante la clase ConexionHTTP.
forma de un arreglo de objetos de tipo InstanciaTarea a la clase
InstanciaTareaListActivity.
InstanciaTareaListActivity verifica los objetos recibidos y los utiliza para formar
un listado elegible de tareas pendientes.
Cabe destacar que este proceso se realiza antes de completar y cancelar una
tarea, por lo que se omitirá en la explicación de estas operaciones.
En la figura 4.37 se describe mediante un diagrama de secuencias, el proceso que
se sigue para la realización de consulta de tareas pendientes.
79
InstanciaTareaListActivity
ConexionHTTP
InstanciaTareaResource
OperacionesBD
Conexion
InstanciaTarea
Usuario
2. Carga Intent
1. Selecciona
tareas pendientes
3. Envía URL de petición
con clave de usuario
4. Envía petición GET
5. Redirección a clase
6. Envía URL
7. Redirección a
método GET
Servidor de
tareas
9. Establece
conexión con BD
10. Conexión a BD
Cliente
11.Consulta tareas
pendientes del
usuario
13. Cierra
conexión con BD
17. Envía arreglo de objetos InstanciaTarea serializados en JSON
16. Envía arreglo de objetos de tipo InstanciaTarea serializados en JSON
20. Despliega listado
de tareas
19. Valida
resultados
Figura 4.37 Diagrama de secuencias para la consulta de tareas pendientes
80
15. Serializa
arreglo de
objetos
4.2.3.3 Consultar el detalle de una tarea pendiente
El proceso de consulta del detalle de una tarea se describe a continuación:
Previo a esto el usuario se debe haber autentificado y haber consultado el
listado de tareas pendientes.
El proceso inicia cuando el usuario selecciona del listado de tareas pendientes
una tarea específica.
La clase InstanciaTareaDetalleActivity se encarga de lanzar el intent que
contiene
la
interfaz
gráfica,
además
de
llamar
al
archivo
detalles_instancia_tarea.xml (ver anexo A, para mayor detalle), el cual contiene
la descripción de la interfaz a utilizar.
InstanciaTareaDetalleActivity forma la URL de petición e incluye en ella la clave
de usuario y el identificador de la tarea y la envía a ConexionHTTP.
petición a la clase correspondiente, en este caso InstanciaTareaResource.
InstanciaTareaResource recibe la petición GET y la redirecciona al método que
con la consulta SQL.
consulta SQL.
OperacionesBD recibe la conexión y realiza la consulta de la tarea pendiente
del usuario en la base de datos. Hecho esto, cierra la conexión con la base de
datos, para después crear un objeto de tipo InstanciaTarea con la información
recibida de la consulta a la base de datos, lo cual se realiza mediante la clase
InstanciaTarea.
InstanciaTarea se encarga de serializar el objeto del mismo tipo, utilizando el
InstanciaTareaResource.
InstanciaTareaResource recibe el objeto InstanciaTarea serializado y lo
reenvía al cliente, el cual lo recibe mediante la clase ConexionHTTP.
forma
de
un
objeto
de
tipo
InstanciaTarea
a
la
clase
InstanciaTareaDetalleActivity.
InstanciaTareaDetalleActivity verifica el objeto recibido y lo utiliza para formar
la interfaz del detalle de la tarea pendiente.
se sigue para consultar el detalle de una tarea pendiente.
81
InstanciaTareaDetalleActivity
ConexionHTTP
OperacionesBD
Conexion
InstanciaTarea
Usuario
2. Carga Intent
1. Elegir una tarea
pendiente
con clave de tarea
con clave de tarea
6. Envía URL
7. Redirección a
método GET
Servidor de
tareas
9. Establece
conexión con BD
10. Conexión a BD
Cliente
11.Consulta tarea
elegida
13. Cierra
conexión con BD
17. Envía objeto de tipo InstanciaTarea serializado en JSON
16. Envía objeto de tipo InstanciaTarea serializado en JSON
20. Despliega detalle
de tarea
19. Valida
resultados
Figura 4.38 Diagrama de secuencias para la consulta del detalle de una tarea
82
15. Serializa
objeto
4.2.3.4 Completar/Cancelar una tarea pendiente
El proceso de cancelar o completar una tarea se describe a continuación:
Previo a esto el usuario se debe haber autentificado y haber consultado el
listado de tareas pendientes, además de elegir el detalle de una tarea.
El proceso inicia cuando el usuario elige completar/cancelar una tarea.
InstanciaTareaDetalleActivity forma la URL de petición incluyendo el
identificador de la tarea y la envía a ConexionHTTP.
ConexionHTTP recibe la URL y envía una petición POST al servicio Web, el
cual es ofrecido por el servidor de tareas mediante la clase
WebServiceApplication, dicha clase recibe la petición y dependiendo la URL
solicitada redirecciona la petición a la clase correspondiente, en este caso
InstanciaTareaResource recibe la petición POST y la redirecciona al método
que corresponde con esta petición. Dentro de esta función se formula la
cadena con la instrucción en SQL indicando la actualización del estado de la
tarea.
instrucción SQL.
Conexion, esta última devuelve el resultado de la operación (éxito o fracaso).
OperacionesBD recibe la respuesta de la operación realizada en la base de
datos y reenvía la respuesta mediante un código HTTP al cliente, el cual recibe
esta respuesta por medio de la clase ConexionHTTP.
ConexionHTTP recibe la respuesta y lo traduce en un mensaje para el usuario,
en donde le indica que la tarea fue completada o cancelada exitosamente.
Cabe destacar que el proceso de completar una tarea difiere únicamente en lo
siguiente con el proceso de cancelarla: al completar una tarea, el estado de la
tarea se actualiza a ―C‖ y al cancelarla se actualiza a ―X‖.
se sigue para completar o cancelar una tarea pendiente.
83
InstanciaTareaDetalleActivity
ConexionHTTP
OperacionesBD
Conexion
Usuario
1. Elegir Completar/
Cancelar tarea
con clave de tarea
3. Envía petición POST
con clave de tarea
5. Envía URL
6. Redirección a
método POST
7. Forma sentencia de
actualización SQL
Servidor de
tareas
8. Establece
conexión con BD
9. Conexión a BD
10.Actualiza campo
estado de tarea elegida
(―C‖, ―X‖)
Cliente
14. Código 200 en HTTP
13. Actualización correcta
15. Mensaje de éxito
16. Mensaje de tarea
Completa/Cancelada
Figura 4.39 Diagrama de secuencias para la operación de completar o cancelar una tarea
84
12. Cierra
conexión con BD
4.2.3.5 Dar de alta una nueva tarea (establecer tarea como pendiente)
Este proceso es un tanto complejo y se divide en los siguientes subprocesos:
1. Obtener un listado de actividades disponibles para el usuario.
2. Obtener un listado de tareas disponibles para elegir según la actividad que se
haya escogido en el paso anterior.
3. Elegir un recurso por medio del código de barras o por RFID y establecer la
tarea como pendiente.
Obtener un listado de actividades disponibles para el usuario
El proceso inicia cuando el usuario selecciona la opción de crear una nueva
tarea.
La clase ActividadesListActivity se encarga de lanzar el intent que contiene la
interfaz gráfica, además de llamar al archivo lista.xml (ver anexo A, para mayor
detalle), el cual contiene la descripción de la interfaz a utilizar.
ActividadesListActivity forma la URL de petición incluyendo en ella la clave del
usuario y la envía a ConexionHTTP.
petición a la clase correspondiente, en este caso ActividadResource.
ActividadResource recibe la petición GET y la redirecciona al método que
con la consulta SQL en donde se filtran las actividades que tiene disponible el
usuario. ActividadResource instancia la clase OperacionesBD enviándole la
consulta SQL.
OperacionesBD recibe la conexión y realiza la consulta de las actividades
disponibles para el usuario, almacenadas en la base de datos. Hecho esto,
cierra la conexión con la base de datos, para después crear un arreglo de
objetos de tipo Actividad con la información recibida de la consulta a la base de
datos, lo cual se realiza mediante la clase Actividad.
Actividad se encarga de serializar los objetos de este mismo tipo, utilizando el
ActividadResource. Esta última recibe el arreglo de objetos Actividad
serializado y lo reenvía al cliente, el cual lo recibe mediante la clase
ConexionHTTP.
forma de un arreglo de objetos de tipo Actividad a la clase ActividadListActivity.
ActividadListActivity verifica los objetos recibidos y los utiliza para formar un
listado elegible de actividades disponibles para el usuario.
En la figura 4.40 se muestra el diagrama de secuencias perteneciente a la
obtención de un listado de actividades disponibles para el usuario.
85
ActividadesListActivity
ConexionHTTP
ActividadResource
OperacionesBD
Conexion
Actividad
Usuario
1. Selecciona
nueva tarea
2. Carga Intent
ActividadResource
6. Envía URL
7. Redirección a
método GET
Servidor de
tareas
9. Establece
conexión con BD
10. Conexión a BD
Cliente
11.Consulta actividades
disponibles para el
usuario
13. Cierra
conexión con BD
17. Envía arreglo de objetos Actividad serializados en JSON
16. Envía arreglo de objetos de tipo Actividad serializados en JSON
20. Despliega listado de
actividades disponibles
19. Valida
resultados
Figura 4.40 Diagrama de secuencias para la obtención de un listado de actividades disponibles para el usuario
86
15. Serializa
arreglo de
objetos
Obtener un listado de tareas disponibles para elegir según la actividad que
se haya escogido en el paso anterior
Una vez obtenido el listado de actividades, el siguiente paso es elegir una de ellas
y esto llevará a obtener un listado de tareas disponibles de acuerdo al usuario y a
la actividad elegida.
Previamente a este proceso el usuario se debe haber autentificado y haber
consultado el listado de actividades disponibles. El proceso inicia cuando el
usuario selecciona una actividad.
La clase TipoTareaListActivity se encarga de lanzar el intent que contiene la
TipoTareaListActivity forma la URL de petición incluyendo en ella la clave del
usuario y la clave de la actividad elegida previamente y la envía a
ConexionHTTP.
petición a la clase correspondiente, en este caso TipoTareaResource.
TipoTareaResource recibe la petición GET y la redirecciona al método que
con la consulta SQL en donde se filtran las tareas disponibles de acuerdo a la
actividad y al usuario. TipoTareaResource instancia la clase OperacionesBD
enviándole la consulta SQL. OperacionesBD realiza la conexión a la base de
datos mediante la clase Conexion, esta última devuelve el objeto de conexión
con la base de datos.OperacionesBD recibe la conexión y realiza la consulta
de las tareas disponibles para el usuario, almacenadas en la base de datos.
Hecho esto, cierra la conexión con la base de datos, para después crear un
arreglo de objetos de tipo TipoTarea con la información recibida de la consulta
a la base de datos, lo cual se realiza mediante la clase TipoTarea.
TipoTarea se encarga de serializar los objetos de este mismo tipo, utilizando el
TipoTareaResource.
TipoTareaResource recibe el arreglo de objetos TipoTarea serializado y lo
forma de un arreglo de objetos de tipo TipoTarea a la clase
TipoTareaListActivity. Esta última verifica los objetos recibidos y los utiliza para
formar un listado elegible de tareas disponibles para el usuario.
En la figura 4.41 se muestra el diagrama de secuencias perteneciente a la
obtención de un listado de tareas disponibles para el usuario.
87
TipoTareaListActivity
ConexionHTTP
TipoTareaResource
OperacionesBD
Conexion
TipoTarea
Usuario
1. Selecciona
actividad
2. Carga Intent
con clave de usuario y
clave de actividad
y clave de actividad
TipoTareaResource
6. Envía URL
7. Redirección a
método GET
Servidor de
tareas
9. Establece
conexión con BD
10. Conexión a BD
Cliente
11.Consulta tareas
disponibles para el
usuario
13. Cierra
conexión con BD
17. Envía arreglo de objetos TipoTarea serializados en JSON
16. Envía arreglo de objetos de tipo TipoTarea serializados en JSON
tareas disponibles
19. Valida
resultados
Figura 4.41 Diagrama de secuencias para la obtención de un listado de tareas disponibles para el usuario
88
15. Serializa
arreglo de
objetos
Elegir un recurso por medio del código de barras o por RFID y establecer la
tarea como pendiente
El siguiente paso para la creación de una nueva tarea pendiente consiste en elegir
un recurso, o bien por código de barras, o bien por una lectura RFID, estos
procesos fueron explicados en las figuras 4.23 y 4.28 respectivamente, por ello
sólo se abstraerá este proceso para la explicación del siguiente paso: el
establecimiento de la tarea como pendiente.
Previo a esto el usuario se debe haber autentificado, haber consultado el
listado de actividades disponibles y haber consultado los tipos de tareas
disponibles.
El proceso inicia cuando el usuario elige un tipo de tarea disponible. La clase
NuevaTareaActivity se encarga de lanzar el intent que contiene la interfaz
gráfica, además de llamar al archivo nueva_tarea_recurso.xml (ver anexo A,
para mayor detalle), el cual contiene la descripción de la interfaz a utilizar,
dicha interfaz es la que se muestra al usuario. El usuario elige la fecha en la
que desea completar la tarea y elige el recurso asociado a la tarea, o bien por
código de barras, o bien por RFID.
NuevaTareaActivity forma la URL de petición incluyendo el identificador del tipo
de tarea, el identificador del usuario, la clave del recurso y la fecha, y la envía a
ConexionHTTP.
ConexionHTTP recibe la URL y envía una petición POST al servicio Web, el
cual es ofrecido por el servidor de tareas mediante la clase
WebServiceApplication, dicha clase recibe la petición y dependiendo la URL
solicitada redirecciona la petición a la clase correspondiente, en este caso
InstanciaTareaResource, esta clase recibe la petición POST y la redirecciona
al método que corresponde con esta petición. Dentro de esta función se
formula la cadena con la instrucción de inserción SQL, en donde se especifica
la inserción de un nuevo registro como tarea pendiente del usuario.
instrucción SQL.
Conexion, esta última devuelve el resultado de la operación (éxito o fracaso).
OperacionesBD recibe la respuesta de la operación realizada en la base de
datos y reenvía la respuesta mediante un código HTTP al cliente, el cual recibe
esta respuesta por medio de la clase ConexionHTTP.
ConexionHTTP recibe la respuesta y lo traduce en un mensaje para el usuario,
en donde le indica que la tarea almacenada exitosamente.
En la figura 4.42 se describe el proceso que se sigue para establecer una tarea
como pendiente.
89
NuevaTareaActivity
ConexionHTTP
OperacionesBD
Conexion
Usuario
2. Carga intent
1. Elegir tipo de
tarea
3. Desplegar
interfaz
4. Selecciona fecha y
recurso
con clave de tipo de
tarea y clave de usuario
6. Envía petición POST
con clave del tipo de tarea
y clave de usuario
8. Envía URL
9. Redirección a
método POST
10. Forma sentencia de
inserción SQL
Servidor de
tareas
11. Establece
conexión con BD
12. Conexión a BD
Cliente
13. Inserta registro de
tarea pendiente en BD
17. Código 200 en HTTP
16. Actualización correcta
18. Mensaje de éxito
19. Mensaje de tarea
Almacenada
Figura 4.42 Diagrama de secuencias para la operación establecer una tarea como pendiente (nueva tarea)
90
15. Cierra
conexión con BD
4.2.3.6 Tarea de guiado
Este proceso se divide en varias actividades las cuales se listan a continuación: 1)
Obtener un listado de actividades disponibles para el usuario, 2) Obtener un
listado de tareas disponibles para elegir según la actividad que se haya escogido
en el paso anterior, 3) Obtener la ubicación actual del dispositivo, 4) Obtener un
listado de ubicaciones para elegir hacia donde se quiere realizar el guiado y 5)
Proceso de guiado. Las dos primeras actividades ya han sido descritas
anteriormente (ver figuras 4.40 y 4.41).
Obtener la ubicación actual del dispositivo
El proceso inicia cuando el usuario elije la actividad de guiado. La clase
GuiadoActivity se encarga de lanzar el intent que contiene la interfaz gráfica,
además de llamar al archivo guiado.xml (ver anexo A, para mayor detalle), el
cual contiene la descripción de la interfaz a utilizar, dicha interfaz es la que se
muestra al usuario.
GuiadoActivity instancia la clase ConexionRFID, la cual es la encargada de
verificar el entorno en busca de tarjetas RFID en cercanía. Una vez que
ConexionRFID ha leído alguna tarjeta, envía el identificador a GuiadoActivity,
esta clase por su parte forma la URL de petición incluyendo el identificador
RFID leído y la envía a ConexionHTTP.
dicha clase recibe la petición y dependiendo la URL solicitada la redirecciona a
la clase correspondiente, en este caso UbicacionResource.
UbicacionResource recibe la petición GET y la redirecciona al método que
con la consulta SQL en donde se consulta la ubicación que corresponde con el
identificador RFID en la base de datos.
UbicacionResource instancia la clase OperacionesBD enviándole la consulta
SQL. OperacionesBD realiza la conexión a la base de datos mediante la clase
OperacionesBD recibe la conexión y realiza la consulta de la ubicación por
medio del identificador RFID. Hecho esto, cierra la conexión con la base de
datos, para después crear un objeto de tipo Ubicacion con la información
recibida de la consulta a la base de datos, lo cual se realiza mediante la clase
Ubicacion. Este último se encarga de serializar el objeto de este mismo tipo,
utilizando el formato de representación JSON, y envía esta información a la
clase UbicacionResource.
UbicacionResource recibe el objeto Ubicacion serializado y lo reenvía al
cliente, el cual lo recibe mediante la clase ConexionHTTP.
forma de un objeto de tipo Ubicacion a la clase GuiadoActivity, la cual verifica
el objeto recibido y los utiliza para escribir en pantalla la ubicación actual del
usuario. En la figura 4.43 se muestra el proceso de obtención de la posición
actual del dispositivo.
91
GuiadoActivity
ConexionRFID
ConexionHTTP
UbicacionResource
OperacionesBD
Conexion
Ubicacion
Usuario
1. Selecciona
ubicación
2. Carga Intent
3. Obtiene tarjetas RFID
en cercanía
4. Lee tarjeta
RFID
5. Identificador de tarjeta
RFID
Servidor de
tareas
6. Forma URL con identificador RFID
con identificador RFID
UbicacionResource
9. Envía URL
10. Redirección
a método GET
Cliente
12. Establece
conexión con BD
13. Conexión a BD
14.Consulta Ubicación
con identificador RFID
16. Cierra
conexión con BD
20. Envía objeto Ubicacion serializado en JSON
19. Envía objeto de tipo Ubicacion serializado en JSON
23. Despliega ubicación
actual
22. Valida
resultados
Figura 4.43 Diagrama de secuencias para la operación obtener la ubicación actual del dispositivo
92
18. Serializa
el objeto
Obtener un listado de ubicaciones para elegir hacia donde se quiere realizar
el guiado
El siguiente paso para llevar a cabo el proceso de guiado es la obtención de un
listado de ubicaciones dentro del campus.
El proceso inicia cuando se obtiene la posición actual del usuario.
La clase UbicacionListActivity se encarga de lanzar el intent que contiene la
UbicacionListActivity forma la URL de petición de ubicaciones y la envía a
ConexionHTTP.
petición a la clase correspondiente, en este caso UbicacionResource.
UbicacionResource recibe la petición GET y la redirecciona al método que
con la consulta SQL en donde se consultan las ubicaciones almacenadas en la
base de datos.
UbicacionResource instancia la clase OperacionesBD enviándole la consulta
SQL.
OperacionesBD recibe la conexión y realiza la consulta de las ubicaciones
almacenadas en la base de datos. Hecho esto, cierra la conexión con la base
de datos, para después crear un arreglo de objetos de tipo Ubicacion con la
información recibida de la consulta a la base de datos, lo cual se realiza
mediante la clase Ubicacion.
Ubicacion se encarga de serializar los objetos de este mismo tipo, utilizando el
UbicacionResource.
UbicacionResource recibe el arreglo de objetos Ubicacion serializado y lo
forma de un arreglo de objetos de tipo Ubicacion a la clase
UbicacionListActivity.
UbicacionListActivity verifica los objetos recibidos y los utiliza para formar un
listado elegible de ubicaciones.
La figura 4.44 muestra el diagrama de secuencias para este proceso.
93
UbicacionListActivity
ConexionHTTP
UbicacionResource
OperacionesBD
Conexion
Ubicacion
Usuario
1. Selecciona
tarea de guiado
2. Carga Intent
de ubicaciones
de ubicaciones
UbicacionResource
6. Envía URL
7. Redirección a
método GET
Servidor de
tareas
9. Establece
conexión con BD
10. Conexión a BD
Cliente
11.Consulta ubicaciones
en la BD
13. Cierra
conexión con BD
17. Envía arreglo de objetos Ubicacion serializados en JSON
16. Envía arreglo de objetos de tipo Ubicacion serializados en JSON
ubicaciones
19. Valida
resultados
Figura 4.44 Diagrama de secuencias para la operación de obtener un listado de ubicaciones
94
15. Serializa
arreglo de
objetos
Proceso de guiado
El siguiente paso es el proceso de guiado, en el que se indicará al usuario en todo
momento su posición y la posición del destino elegido. La figura 4.45 muestra el
proceso de guiado con RFID mediante un diagrama de secuencias. Mucha de la
funcionalidad aquí mostrada se abstraerá de los procesos mostrados
anteriormente, lo cual se hizo con la finalidad de obtener diagramas más legibles y
entendibles. Cabe destacar que la parte resaltada en oscuro se repite tantas veces
como se actualice la posición actual del usuario sin llegar al destino elegido.
GuiadoActivity
ConexionRFID
Servidor
Usuario
2. Lee tarjeta
RFID
3. Identificador
4. Verifica si es
destino
7. Refresca el plano y
coordenadas de
posición actual y
destino
8. Camina a otra
posición
5. Consulta ubicación
6. Ubicación,
coordenadas y plano
10. Lee tarjeta
RFID
11. Identificador
12. Verifica si es
destino
...
13. Ha llegado al destino
Figura 4.45 Diagrama de secuencias de la tarea de guiado por RFID
El proceso mostrado en la figura 4.45 se describe de la siguiente manera:
1. GuiadoActivity inicia un hilo de conexión con ConexionRFID.
2. ConexionRFID lee las tarjetas que tiene en cercanía y se obtiene la
ubicación actual del usuario.
3. GuiadoActivity muestra al usuario el plano con su ubicación actual y la
ubicación destino elegida.
4. El Usuario entonces camina hacia otra ubicación. Una vez que el usuario
realiza esto, GuiadoActivity verifica la posición actual con ayuda de la clase
ConexionRFID. Los pasos 3 y 4 se repiten hasta que el usuario camina
hasta la posición destino.
5. Finalmente GuiadoActivity informa al usuario que ha llegado a su destino.
95
El proceso de guiado puede llevarse a cabo también mediante la lectura de
códigos de barras, la figura 4.46 muestra el proceso de guiado mediante códigos
de barras.
GuiadoQRcodesActivity
CodigoBarras
Usuario
1. Inicia cámara
2. Decodifica el
código de barras
Servidor
3. Identificador
4. Verifica si es
destino
7. Refresca el plano y
coordenadas de
posición actual y
destino
8. Captura fotografía
6. Ubicación,
coordenadas y plano
9. Envía fotografía
10. Decodifica el
código de barras
11. Identificador
12. Verifica si es
destino
...
13. Ha llegado al destino
Figura 4.46 Diagrama de secuencias de la tarea de guiado con QRCodes
El proceso mostrado en la figura 4.46 se describe de la siguiente manera:
1. GuiadoQRCodesActivity inicia la cámara y envía la fotografía con el código
de barras a CodigoBarras.
2. CodigoBarras decodifica el código de barras y envía el identificador a
GuiadoQRCodesActivity, este último obtiene la ubicación actual del usuario.
3. GuiadoQRCodesActivity muestra al usuario el plano con su ubicación actual
y la ubicación destino elegida.
4. El Usuario entonces captura otra fotografía. Los pasos 2, 3 y 4 se repiten
hasta que el usuario captura el código de barras correspondiente al destino
elegido.
5. Finalmente GuiadoQRCodesActivity informa al usuario que ha llegado a su
destino.
4.2.4 Diseño de las URL
Se establecieron las siguientes URL dinámicas válidas para la comunicación
mediante el protocolo HTTP entre el cliente y el servidor.
96
Las siguientes son URL manejadas por la clase UbicacionResource.
 http://<IP_o_dominio>/ubicaciones/campus/{idcampus}. Se utiliza en una
petición GET para obtener un listado de ubicaciones dentro del campus con
clave {idcampus}.
 http://<IP_o_dominio>/ubicaciones/campus/{idcampus}/rfid/{esrfid}.
Se
utiliza en una petición GET para obtener un listado de ubicaciones dentro
del campus con clave {idcampus}, las cuales tienen asociada una tarjeta
rfid.
 http://<IP_o_dominio>/ubicaciones/campus/{idcampus}/qrcodes/{esqrcode}.
Se utiliza en una petición GET para obtener un listado de ubicaciones
dentro del campus con clave {idcampus}, las cuales tienen asociado un
código de barras.
 http://<IP_o_dominio>/ubicaciones/{idubicacion}. Se utiliza con GET para
obtener la ubicación con clave {idubicacion}.
 http://<IP_o_dominio>/ubicaciones/{idubicacion}. Se utiliza con GET para
obtener la ubicación asociada al QRcode con identificador {qrcode}
 http://<IP_o_dominio>/ubicaciones/rfid/{rfid}. Se utiliza con GET para
obtener la ubicación asociada con la tarjeta RFID con identificador {rfid}.
 http://<IP_o_dominio>/ubicaciones/escaleras/plano/{idplano}. Se utiliza con
GET para obtener la ubicación definida como escaleras en el plano con
clave {idplano}.
 http://<IP_o_dominio>/ubicaciones/contexto/{etiquetas}. Se utiliza para
obtener un listado de ubicaciones que se asocien con las etiquetas con
identificadores {etiquetas}.
 http://<IP_o_dominio>/ubicaciones/edificio/{idedificio}. Se utiliza para
obtener la ubicación del edificio con identificador {idedificio}.
A continuación se listan
las
URL
administradas
por
la
clase
 http://<IP_o_dominio>/users/{idusuario}/tareas/. Permite, por medio de
GET, consultar todas las tareas pendientes del usuario con identificador
{idusuario}.
 http://<IP_o_dominio>/users/{idusuario}/tareas/contexto/{etiquetas}.
Permite, a través de una petición GET, consultar las tareas pendientes que
tengan objetos asociados a las tarjetas RFID con identificadores {etiquetas}.
 http://<IP_o_dominio>/users/{idusuario}/tareas/fecha/{porFecha}. Permite, a
través de una petición GET, consultar las tareas pendientes que tengan
como fecha {porFecha}.
 http://<IP_o_dominio>/users/{idusuario}/tareas/fecha/{porFecha}/hora/{porH
ora}. Permite, a través de una petición GET, consultar las tareas pendientes
que tengan como fecha {porFecha} y como hora {porHora}.
 http://<IP_o_dominio>/users/{idusuario}/tareas/{idinstanciatarea}. Permite, a
través de una petición GET, consultar la tarea pendiente con clave
{idinstanciatarea} del usuario con identificador {idusuario}.
97
 http://<IP_o_dominio>/users/{idusuario}/tareas/{idinstanciatarea}/incidencia/
{incidencia}. Una petición POST a esta URL nos permitirá actualizar las
incidencias a {incidencia} de la tarea con clave {idinstanciatarea} para el
usuario {idusuario}.
 http://<IP_o_dominio>/users/{idusuario}/tareas/{idinstanciatarea}/estado/{est
ado}/incidencia/{incidencia}. Una petición POST a esta URL nos permitirá
actualizar las incidencias a {incidencia} y cambiar de estado la tarea a
{estado} de la tarea con clave {idinstanciatarea} para el usuario {idusuario}.
 http://<IP_o_dominio>/users/{idusuario}/tareas/{idinstanciatarea}/modiFecha
/{modiFecha}/modiHora/{modiHora}. Una petición POST a esta URL nos
permitirá modificar la fecha y hora a {modiFecha}, {modiHora} de la tarea
con clave {idinstanciatarea} para el usuario {idusuario}.
 http://<IP_o_dominio>/users/{idusuario}/tareas/{idtipotarea}/guardarinstanci
a/asociado/{asociado}/idasociado/{idasociado}/tipoasociado/{tipoasociado}/r
fid_asociado/{rfid_asociado}/fecha/{fecha}/hora/{hora}. Una petición POST
en esta URL permite establecer una tarea como pendiente, la tarea se
establecerá del tipo {idtipotarea} para el usuario {idusuario}, se asignará el
objeto con identificador {idasociado}, descripción {asociado}, tipo
{tipoasociado} y RFID {rfid_asociado}. La fecha y hora para completarla se
serán {fecha}{hora}.
En seguida se describe la URL manejada por la clase ActividadResource.
 http://<IP_o_dominio>/users/{idusuario}/grupos/{idgrupo}/actividad/. Si se
usa con GET, permite obtener un listado de actividades disponibles para el
usuario {idusuario}, perteneciente al grupo {idgrupo}.
Las peticiones a la
TipoTareaResource.
siguiente
URL
son
administradas
por
la
clase
 http://<IP_o_dominio>/users/{idusuario}/grupos/{idgrupo}/actividad/{idactivid
ad}/tareas/. Al realizar una petición GET a esta URL se obtendrá un listado
de tipos de tareas dentro de la actividad {idactividad}, a las cuales el
usuario con clave {idusuario} y grupo {idgrupo} puede tener acceso.
A continuación se describen las URL que administra la clase RecursoResource.
 http://<IP_o_dominio>/users/{idusuario}/tareas/{idtipotarea}/recursos/{idrecu
rso}. Al realizar una petición GET a esta URL se obtendrá el recurso con
clave {idrecurso} asociado con el tipo de tarea {idtipotarea}, la cual está
asignada al usuario {idusuario}.
 http://<IP_o_dominio>/recursos/{idrecurso}. Al realizar una petición GET a
esta URL se obtendrá el recurso con clave {idrecurso}.
 http://<IP_o_dominio>/qrcode/{qrcode}. Al realizar una petición GET a esta
URL se obtendrá el recurso con asociado al QRcode con identificador
{qrcode}.
98
 http://<IP_o_dominio>/recursos/atributos/{idrecurso_atributos}.
Se
obtendrán los atributos del recurso con clave {idrecurso_atributos}.
 http://<IP_o_dominio>/recursos/contexto/{etiquetas}. Al realizar una petición
GET a esta URL se obtendrán los recursos asociados a las etiquetas
{etiquetas}.
Las siguientes URL son manejadas por la clase UsuarioResource.
 http://<IP_o_dominio>/users/. Con GET, obtiene todos los usuarios.
 http://<IP_o_dominio>/users/{idusuario}. Con GET, obtiene los detalles del
usuario con clave {idusuario}.
 http://<IP_o_dominio>/users/qrcode/{qrcode}. Con GET, obtiene los detalles
del usuario asociado al QRcode con identificador {qrcode}.
 http://<IP_o_dominio>/users/login/{login}/password/{password}.
Utilizado
con GET, obtiene los detalles del usuario con login {login} y contraseña
{password}.
 http://<IP_o_dominio>/users/contexto/{etiquetas}. Permite obtener mediante
una petición GET, un listado de los usuarios pertenecientes asociados a las
etiquetas {etiquetas}.
La URL que a continuación se muestra es administrada por la clase
GrupoResource.
 http://<IP_o_dominio>/grupos/. Con una petición GET, obtiene un listado de
los todos los grupos de usuario almacenados en la base de datos.
4.2.5 Diseño del modelo de la base de datos
La aplicación contará con una base de datos, la cual almacenará información de
los recursos, los usuarios, las tareas y las ubicaciones que servirán en los
procesos del sistema.
La figura 4.47 muestra el modelo de la base de datos.
99
Figura 4.47 Modelo físico de la base de datos
La definición de las relaciones se describe a continuación:
Gestión de tareas
 actividad. Almacenará las actividades, una actividad contiene 0 o más
tarea.
 tipoTarea. Contiene la descripción de los tipos de tareas, en esta relación
se establecerán las tareas que un usuario puede instanciar para ponerlas
como pendientes.
 requerimientos. Almacenará los requisitos que necesita una tarea para
llevarse a cabo (a quien está asociada, por quien es provista y el tipo que
requiere).
 operacion. Se utiliza para realizar las relaciones entre tareas, es decir las
operaciones que se realizan cuando una tarea se activa, se completa o se
cancela (p. ej. cuando se completa la tarea PRESTAR se activa la tarea
DEVOLUCION).
 instanciaTarea. Se almacenan las tareas pendientes de los usuarios y el
detalle del recurso asociado.
100
Gestión de grupos y usuarios
 grupo. Almacena los grupos de usuarios.
 usuario. Almacena la información de los usuarios que tendrán acceso a los
servicios de la aplicación.
Gestión de recursos
 tipoRecurso. Almacena los tipos de recursos asociados a las tareas, por
ejemplo LIBRO, COMPUTADORA, etc. Dependiendo el tipo de recurso
serán los atributos que se almacenen es por ello de la existencia de la
relación atributo.
 atributo. Almacena como los atributos referentes a un tipo de recurso (ej.
para un libro ISBN, TITULO, EDITORIAL), dentro de esta relación existe un
atributo llamado imprimible, el cual tendrá un valor 'S' refiriéndose a que el
atributo se imprimirá en el cliente.
 recurso. Hace referencia a un recurso en especifico (p. ej. Libro Don
Quijote), dependiendo del recurso que se tenga se tendrán los valores de
sus atributos.
 valor. Almacena los valores de los atributos para cada recurso (ej.
ISBN='SDGDGDGD', TITULO='DON QUIJITE'), etc.
Gestión de ubicaciones
 campus. Almacena la ruta del archivo del plano del campus y la
descripción del campus.
 edificio. Almacena la descripción del edificio, sus coordenadas dentro del
campus y el identificador asociado ya sea de RFID, MAC o Cell-ID.
 plano. Almacena la descripción del plano, la ruta del archivo del plano y el
edificio al cual pertenece.
 ubicacion. Como su nombre lo indica almacena las ubicaciones en las que
un usuario podrá localizarse dentro del campus, estará asociado a un
identificador, este identificador será el mismo que tenga una tarjeta RFID o
el dispositivo WiFi o Bluetooth para poder realizar la localización.
4.2.6 Diseño de la aplicación Web para la gestión de las tareas
La aplicación Web surge por la necesidad de alimentar y administrar el contenido
de la base de datos. Es un sistema de consulta, eliminación, modificación y alta de
tareas, recursos, ubicaciones y usuarios en la base de datos.
En la figura 4.48 Se muestra el diagrama de casos de uso de la aplicación Web.
101
CU-1 Login
CU-2 Administrar
grupos y usuarios
CU-8 Logout
Usuario
CU-7 Consultar
ayuda
CU-3 Administrar
recursos
CU-6 Administrar
tareas de los usuarios
Administrador
CU-4 Administrar
ubicaciones
CU-5 Administrar
tipos de tareas
Figura 4.48 Casos de uso de la aplicación Web
El sistema cuenta con 2 paquetes:
 mx.edu.cenidet.basedatos. Se encarga de la conexión y las operaciones
sobre la base de datos.
 mx.edu.cenidet.xmlread. Se encarga de leer los atributos del archivo de
configuración.
En la figura 4.49 se muestra el diagrama de paquetes de esta aplicación.
Figura 4.49 Diagrama de paquetes de la aplicación Web
4.2.6.1 Paquete mx.edu.cenidet.basedatos
Este paquete contiene dos clases, las cuales se describen a continuación:
 Conexion. Contiene los métodos y atributos necesarios para realizar la
conexión con la base de datos de tareas.
 OperacionesBD. Proporciona la funcionalidad para realizar operaciones de
consulta, inserción y modificación en la base de datos.
102
En la figura 4.50 se visualiza
mx.edu.cenidet.basedatos.
el
diagrama
de
clases
del
paquete
Figura 4.50 Diagrama de clases paquete mx.edu.cenidet.basedatos
4.2.6.2 Paquete mx.edu.cenidet.xmlread
Este paquete consta únicamente de una clase: XMLRead, la cual se encarga de
leer los atributos capturados en el archivo de configuración.
La figura 4.51 muestra el diagrama de clases de este paquete.
Figura 4.51 Diagrama de clases paquete mx.edu.cenidet.xmlread
En este capítulo se detallaron los diagramas UML correspondientes al análisis y
diseño de las aplicaciones que forman parte del sistema, el cual es resultado del
desarrollo de esta tesis.
A continuación se describirá la implementación de las aplicaciones del sistema.
103
5 Capítulo 5 Implementación
Capítulo 5 Implementación
En este capítulo se presentan los detalles tecnológicos de la propuesta. Se
describe la implementación de los módulos de las aplicaciones que son resultado
de la tesis, del servidor de tareas y de la aplicación Web que gestiona la
información de recursos, ubicaciones y tareas. Asimismo, se explica el
funcionamiento en conjunto de los componentes que integran la plataforma
propuesta.
5.1 Detalles tecnológicos
El proyecto consta de 3 aplicaciones: el cliente montado en el dispositivo celular,
el servidor que atiende las peticiones del cliente y la aplicación Web que gestiona
la información de tareas, ubicaciones, usuarios y recursos. La figura 5.1 muestra
los componentes que se utilizan en la implementación del proyecto.
Figura 5.1 Detalles tecnológicos del proyecto
Las tecnologías empleadas que muestra la figura 5.1 son descritas a continuación.
Android se utiliza como plataforma para la parte cliente.
La parte servidora se implementó utilizando OSGi, para ello se hace uso de
las funcionalidades que ofrece Apache Felix.
La identificación automática se hace mediante RFID y códigos de barras.
El intercambio de información se realiza a través del protocolo HTTP.
Se utiliza JSON para la serialización y deserialización de objetos.
Se utiliza un enfoque REST para ofrecer los servicios Web.
Para gestionar la información de recursos, ubicaciones, tareas y usuarios
se utiliza una aplicación Web desarrollada en JSP, montada sobre Apache
Tomcat.
5.1.1 Cliente
El cliente se implementó en la plataforma Android. Se definió una interfaz para
acceder a la lista de tareas pendientes. Esta lista puede filtrarse para mostrar las
tareas del usuario, las tareas en una fecha específica, las tareas asociadas a
objetos cercanos. Además se pueden establecer nuevas tareas como pendientes.
107
5.1.2 Servidor
Para obtener una arquitectura modular, la parte servidora se basó en OSGi. OSGi
es una tecnología Java que permite entre otras cosas definir las dependencias
entre distintos componentes (llamados bundles) de manera que se gestionen de
forma automática. La implementación a utilizar se basa en open source
específicamente Apache Felix.
Para ofrecer los servicios del sistema de manera que otras aplicaciones (p.ej. el
cliente Android) puedan acceder fácilmente a ellos, se ofrecen mediante un
servicio Web siguiendo una aproximación REST. Para ello se utiliza Restlet.
5.1.3 Aplicación Web de gestión de tareas
La aplicación Web de T-Guide surge por la necesidad de alimentar y gestionar la
información de la base de datos correspondiente a usuarios, recursos, tareas y
ubicaciones, necesarios para el correcto funcionamiento de la plataforma T-Guide.
Está desarrollada en JSP y montada sobre el servidor de aplicaciones Apache
Tomcat.
5.2 Interacción del sistema cliente-servidor
A continuación se describe la implementación del proyecto basándonos en las
interfaces de usuario, para ello se mostrará una figura con la interfaz y se
describirá el proceso realizado.
5.2.1 Autenticación del usuario
La autenticación se realiza de forma automática mediante la lectura de los
atributos del archivo de configuración que se encuentra en el dispositivo celular
llamado config.xml. A continuación se muestra el contenido del archivo de
configuración.
<?xml version="1.0" encoding="windows-1252"?>
<!-Document
: configuracion.xml
Created on : 18 de mayo de 2009, 09:22 AM
Author
: Israel Arjona Vizcaino
Description:
Purpose of the document follows.
-->
<root>
<servidor>192.168.200.21</servidor>
<puerto>8101</puerto>
<imagenes>/WebTareas/img/</imagenes>
<planos>/WebTareas/planos/</planos>
<barras>/WebTareas/barras/</barras>
<fotos>/WebTareas/fotos/</fotos>
<user_id>2</user_id>
<servidor_rfid>192.168.200.21</servidor_rfid>
<puerto_rfid>4444</puerto_rfid>
108
</root>
La autenticación se realiza mediante el atributo user_id. Si se autentifica
correctamente, se mostrará la pantalla inicial del sistema (ver figura 5.2).
Figura 5.2 Pantalla inicial del sistema
Si no se puede realizar correctamente la autenticación del usuario se muestra un
mensaje indicándole que el usuario es erróneo (ver figura 5.3).
Figura 5.3 Pantalla de datos erróneos
El proceso que se sigue para llevar a cabo la autenticación del usuario se muestra
en el diagrama de la figura 5.4.
109
BD tareas
Inicio
Hacer una petición GET
al servicio Web ofrecido
por Restlet enviando el
identificador del usuario
Obtener del
identificador
del usuario
Acceder al
sistema
Si
Se recibe objeto
El servidor valida el
consultando la BD
Se envía el objeto de tipo
usuario encontrado
No
Mostrar
pantalla de
datos erroneos
Fin
Figura 5.4 Diagrama de flujo del proceso de autenticación
5.2.2 Consulta de tareas pendientes
La figura 5.5 muestra la pantalla de ―Tareas Pendientes‖, en esta pantalla se
muestra una lista elegible de tareas pendientes para el usuario, las cuales pueden
ser filtradas por contexto o por fecha.
Figura 5.5 Pantalla de Tareas Pendientes
110
Cuando el usuario da clic sobre una tarea se mostrará la pantalla de detalles de
tarea, la cual se visualiza en la figura 5.6, en donde se podrán capturar las
incidencias de la tarea, modificar la fecha y hora de la tarea, ver los detalles del
objeto asociado a la tarea, cancelar y completar la tarea.
Figura 5.6 Pantalla de detalles de tarea
El proceso que se sigue para la consulta de tareas se muestra en el diagrama de
flujo de la figura 5.7.
BD tareas
Inicio
Hacer una petición GET
al servicio Web ofrecido
por Restlet enviando el
El servidor consulta las
tareas pendientes
pertenecientes al usuario
en la BD
Acceder al
sistema
Fin
El servidor envía el
listado en forma de
objetos serializados
Si
Mostrar listado
de tareas
pendientes
Se reciben objetos?
No
Figura 5.7 Diagrama de flujo del proceso de consulta de tareas pendientes
5.2.3 Completar/Cancelar una tarea
La figura 5.8 muestra la pantalla de ―Detalle de tareas‖, es en esta pantalla donde
el usuario realiza las operaciones de cancelar o completar una tarea.
111
Figura 5.8 Pantalla de detalles de tarea
Al dar clic en cualquier operación completar/cancelar el estado de la tarea pasar á
de activo a completado o cancelado según se haya elegido y se mostrará la
pantalla de tareas pendientes (ver figura 5.9).
Figura 5.9 Pantalla de listado de tareas con mensaje de tarea completada
Si la operación no se realiza correctamente se mostrará el mensaje que aparece
en la figura 5.10.
Figura 5.10 Error en la operación
112
El proceso que se sigue para completar o cancelar tareas se muestra en el
diagrama de flujo de la figura 5.11.
BD tareas
Elegir
completar o
cancelar
Inicio
Enviar petición POST al
servidor añadiendo el
identificador de la tarea y
del usuario
Mostrar pantalla
de tareas
pendientes
Fin
Actualizar el estado de la
tarea del usuario a
completo o cancelado en
la BD
Si
Se pudo actualizar?
Mostrar
mensaje de
alerta
No
Figura 5.11 Diagrama de flujo del proceso de completar/cancelar una tarea
5.2.4 Nueva tarea (establecer una tarea como pendiente)
Para dar de alta una nueva tarea se realiza lo siguiente:
Elegir ―Nueva tarea‖ dentro del menú de la pantalla de ―Tareas pendientes‖.
Elegir la actividad a la que pertenece la tarea.
Elegir el tipo de tarea que se dará de alta.
Seleccionar el objeto por código de barras, introducir el identificador
manualmente o verificar el contexto en busca de objetos cercanos.
5. Establecer la fecha y hora de la tarea.
6. Elegir del menú la opción ―Guardar‖.
1.
2.
3.
4.
La figura 5.12 muestra las pantallas para dar de alta una nueva tarea.
113
Figura 5.12 Pantallas involucradas en el proceso de alta de tarea
Si la operación no se realiza correctamente se mostrará el mensaje que aparece
en la figura 5.10. El proceso que se sigue para dar de alta una nueva tarea se
muestra en el diagrama de flujo de la figura 5.13.
A
Inicio
El servidor realiza un
filtrado de las los tipos de
tarea dentro de la
actividad elegido a los
que tiene acceso un
usuario en la BD
BD tareas
Enviar petición GET al
Elegir
nueva tarea
identificador del usuario y el
identificador de la actividad
B
114
Elegir
actividad
El servidor realiza un
filtrado de las actividades
a las que tiene acceso un
usuario en la BD
El cliente recibe la
información en forma de
objetos serializados y muestra
un listado de actividades
B
información en forma de
objetos serializados y muestra
un listado de tipos de tarea
Elegir tipo
de tarea
Elegir por
barras
información en forma de un
objetos serializado y muestra
la información del recurso
El servidor realiza
la consulta del
recurso en la BD
No
Leer
identificador
de recurso
A
Si
Por barras
identificador del recurso
Mostrar cámara
fotográfica
Capturar
imagen
Si
Pudo decodificar?
Decodificar
código de
barras
No
Enviar petición POST al
identificador del recurso, el
tipo de tarea, el identificador
del usuario y la fecha
Elegir
guardar
Se recibió exito
No
Mostrar mensaje de
error
Si
El servidor inserta un nuevo
registro de en la tabla
InstanciaTarea en la BD
El cliente recibe la respuesta
del servidor por medio de un
objeto serializado
Mostrar mensaje de
tarea almancenada
Fin
A
Figura 5.13 Diagrama de flujo de alta de nueva tarea
5.2.5 Tarea de guiado por RFID
Para dar de alta la tarea de guiado se realiza lo siguiente:
1.
2.
3.
4.
5.
6.
Elegir la actividad de guiado.
Elegir el tipo de tarea guiado por RFID.
Se obtiene automáticamente la posición del dispositivo.
Elegir el destino al que se desea el guiado.
Se inicia el proceso de guiado, que culmina una vez que se ha llegado al
destino solicitado.
El proceso de guiado se describe en el diagrama de flujo de la figura 5.14.
115
Obtener tarjetas
RFID en cercanía
Inicio
servidor el identificador
RFID obtenido
El servidor consulta las la
ubicación que tiene
asociado el RFID
BD tareas
El servidor envía la
ubicación encontrada
en forma serializada
No
Se reciben objetos?
Seleccionar
destino
El destino es igual
a la posición actual
Enviar mensaje
de error
Si
Terminar la
tarea de guiado
Fin
No
Mostrar al usuario
su posición actual y
la posición del
destino elegido
Obtener tarjetas
RFID en cercanía
servidor el identificador
RFID obtenido
asociado el RFID
Figura 5.14 Diagrama de flujo del proceso de guiado por RFID
La figura 5.15 muestra las pantallas que involucra el proceso de guiado mediante
RFID.
116
Figura 5.15 Pantallas involucradas en el proceso de guiado por RFID
5.2.6 Tarea de guiado por QRCodes
Para dar de alta la tarea de guiado se realiza lo siguiente:
1.
2.
3.
4.
5.
6.
7.
8.
Elegir la actividad de guiado.
Elegir el tipo de tarea guiado por QRCodes.
Se inicia la cámara y el usuario captura la fotografía del código de barras.
Se decodifica la fotografía.
Se obtiene la posición actual del dispositivo.
Elegir el destino al que se desea el guiado.
Se inicia el proceso de guiado, que culmina una vez que se ha llegado al
destino solicitado.
El proceso de guiado por QRCodes se describe en el diagrama de flujo de la figura
5.16.
117
Inicio
No
A
Iniciar la cámara
Capturar la fotografía con
el código de barras
Se decodificó?
Decodificar el código de
barras
Si
ubicación con el
identificador asociado
BD tareas
No
Si
Se reciben objetos?
Seleccionar
destino
El destino es igual
a la posición actual
A
Enviar mensaje
de error
Si
Terminar la
tarea de guiado
Fin
No
Mostrar al usuario
su posición actual y
la posición del
destino elegido
No
Capturar fotografía
con código de
barras
Decodificar código
de barras
Se decidificó?
Si
asociado el identificador
servidor con el
identificador
Figura 5.16 Diagrama de flujo del proceso de guiado por QRCodes
La figura 5.17 muestra las pantallas que involucra el proceso de guiado mediante
QRCodes.
118
Figura 5.17 Pantallas involucradas en el proceso de guiado por QRCodes
5.3 Interacción de la aplicación Web
La aplicación Web está desarrollada sobre JSP y montada en el servidor de
aplicaciones Apache Tomcat. Consta de los siguientes módulos:
Administración de usuarios.
Administración de recursos.
Administración de ubicaciones.
Administración de tareas.
Administración de tareas de los usuarios.
Esta aplicación puede ser iniciada únicamente por el administrador.
En la figura 5.18 se muestra la pantalla principal de la aplicación.
119
Figura 5.18 Pantalla principal de la aplicación Web
5.3.1 Administración de usuarios
Dentro de este módulo se pueden realizar consultas, modificaciones e inserciones
de grupos y usuarios. En la figura 5.19, se presentan algunas interfaces que
corresponden al módulo de administración de usuarios.
120
Figura 5.19 Pantallas del módulo de administración de usuarios
5.3.2 Administración de recursos
de recursos y tipos de recursos, un tipo de recurso hace referencia a una clase
que engloba ciertos objetos con ciertos atributos, por ejemplo el tipo de recurso
―Libro‖ tiene los atributos ―ISBN‖, ―titulo‖, entre otros. En la figura 5.20, se
presentan algunas interfaces que corresponden al módulo de administración de
recursos.
121
Figura 5.20 Pantallas del módulo de administración de recursos
5.3.3 Administración de ubicaciones
de campus, planos, edificios y ubicaciones. En la figura 5.21, se muestra la
pantalla de alta de campus. En esta pantalla se captura la descripción y la imagen
que corresponde al plano del campus.
122
Figura 5.21 Pantalla de alta de campus
La figura 5.22 muestra la pantalla de alta de ubicaciones. En esta pantalla se
captura el identificador de la ubicación, que puede ser RFID, o una dirección MAC
de un dispositivo WiFi o Bluetooth, se captura también la descripción y se da clic
sobre la imagen para almacenar la ubicación.
123
Figura 5.22 Pantalla de captura de ubicaciones
5.3.4 Administración de tareas
de tareas que estarán disponibles para los usuarios. En la figura 5.23, se muestra
la pantalla de alta de tarea. En esta pantalla se captura la descripción de la tarea,
se establecen los permisos y el tipo de objeto que se requiere (recurso, ubicación
o usuario), y las operaciones que se realizan al activar, completar o cancelar la
tarea.
124
Figura 5.23 Pantalla de alta de tareas
5.3.5 Administración de tareas de los usuarios
de tareas pendientes de los usuarios. En la figura 5.24, se muestra la pantalla de
activación de tarea del usuario. En esta pantalla se captura la actividad, el tipo de
tarea, la fecha y hora de la tarea, y el objeto que se asocia a la tarea.
Figura 5.24 Pantalla de activación de tarea de usuarios
En este capítulo se mostraron los detalles tecnológicos y las interfaces de usuario
de las aplicaciones desarrolladas (el cliente en el dispositivo móvil y la aplicación
Web para la administración de la información de la base de datos), las cuales
permiten el correcto funcionamiento del proyecto.
A continuación se detallan las pruebas realizadas para validar el buen
funcionamiento de las aplicaciones que son resultado del proyecto de tesis.
125
6 Capítulo 6 Pruebas
Capítulo 6 Pruebas
En este capítulo se muestran los resultados obtenidos en cada caso de prueba
realizado.
Capítulo 6 Pruebas
El plan de pruebas se titula T-GUIDE y se encuentra en el anexo B. Se realizó
siguiendo el estándar 829 de la IEEE [STD829].
La siguiente lista define las características a ser probadas:
 Configuración y conexiones. Se verificó la correcta configuración de los
dispositivos utilizados por el cliente: lector RFID; la conexión entre el cliente
y el servidor y la conexión de la base de datos con el servidor y la
aplicación Web.
 Auto-identificación. Define los casos de prueba para la identificación
automática de recursos físicos en cercanía del dispositivo móvil, utilizando
como tecnologías de Auto-ID el código de barras y tarjetas RFID.
 Localización y guiado del dispositivo móvil. Define los casos de prueba
para la localización por medio de RFID de un dispositivo móvil. Además se
definen los casos de prueba para la realización de la tarea de guiado, la
cual se refiere a guiar a un usuario de una localización origen obtenida
automáticamente a una destino elegida por el usuario.
 Administración de tareas. Define los casos de prueba para el manejo de
tareas, la correcta consulta y almacenamiento de la información de estas en
la base de datos y la obtención de resultados a través del protocolo HTTP.
 Administración de la información de la base de datos. Define los casos
de prueba para la gestión de la información de la base de datos, como es la
consulta, modificación, eliminación y actualización.
A continuación se describen los resultados de las pruebas.
6.1 Pruebas de configuración y conexiones
Tabla 13 Caso de prueba T-Guide-001-001
Caso de prueba: T-Guide-001-001 Configuración y conexión del cliente móvil con el
lector RFID
DESCRIPCIÓN: Permitir al dispositivo celular que pueda acceder a la conexión con el
lector de tarjetas RFID. La prueba se realizó utilizando el intermediario entre el lector
RFID y el dispositivo celular. Estando conectado el lector RFID, se inició el intermediario
y la aplicación en el dispositivo celular. En el listado de tareas se eligió la opción
contexto, para realizar una conexión con el lector RFID.
129
Capítulo 6 Pruebas
Resultado: OK.
Observaciones: La conexión entre el lector y el dispositivo celular se realizó exitosamente
haciendo uso del intermediario.
Responsable de la prueba: Israel Arjona Vizcaíno
Cargo: Autor
Caso de prueba: T-Guide-001-002 Configuración y conexión del servidor de tareas
con el dispositivo móvil
DESCRIPCIÓN: Permitir al dispositivo celular que pueda acceder al servicio Web
ofrecido por el servidor de tareas. La prueba se realizó teniendo iniciado Apache Felix y
el bundle del servidor de tareas activo, se realizó una petición GET para validar al usuario
y obtener sus datos.
130
Capítulo 6 Pruebas
Resultado: OK.
Observaciones: La conexión entre el dispositivo celular y el servidor se realizó
exitosamente, la configuración se hizo correctamente mediante el archivo de
configuración. La información tardó alrededor de un segundo en llegar al dispositivo
celular.
Cargo: Autor
Caso de prueba: T-Guide-001-003 Configuración y conexión del servidor de tareas
con la base de datos
DESCRIPCIÓN: Verificar que el archivo de configuración del servidor de tareas esté
correctamente formado y sea interpretado correctamente. Asimismo, verificar que el
servidor de tareas se conecte correctamente con la base de datos. La prueba se realizará
con el servidor de tareas en funcionamiento y se realizará una petición GET desde un
navegador Web, se solicitarán las tareas de un usuario.
131
Capítulo 6 Pruebas
Resultado: OK.
Observaciones: El servidor de tareas accedió exitosamente a la información de la base de
datos y se obtuvieron de forma correcta las tareas activas de un usuario.
Cargo: Autor
6.2 Pruebas de auto-identificación
Caso de prueba: T-Guide-002-001 Captura y decodificación del código de barras
DESCRIPCIÓN: Verificar que la imagen capturada, mediante la cámara inmersa en el
dispositivo móvil, que contenga un código de barras, se decodifique de una forma
correcta y se obtenga el identificador adecuado. La prueba se realizará con el dispositivo
celular, se capturará una imagen y se obtendrá su identificador.
132
Capítulo 6 Pruebas
Resultado: OK.
Observaciones: Se decodificó correctamente el código de barras en la imagen. Cabe
destacar que para que se lleve a cabo la decodificación debe haber bastante iluminación.
Cargo: Autor
Caso de prueba: T-Guide-002-002 Obtención de las tarjetas RFID en cercanía
DESCRIPCIÓN: Comprobar que se obtengan correctamente las tarjetas en cercanía
realizando la comunicación entre el dispositivo celular y el lector RFID. Para ello se
iniciará el intermediario que realiza la comunicación entre los dispositivos y se
comprobará mediante el listado de tareas relacionadas con objetos cercanos. El proceso
comenzará en el celular y se acercará una tarjeta RFID al lector. Se requiere que el
servidor esté activo.
133
Capítulo 6 Pruebas
Resultado: OK.
La tarjeta RFID obtenida
tiene como identificador
e070024a3848300
Observaciones: Se obtuvieron correctamente las tarjetas RFID en cercanía y el filtrado de
las tareas conforme al contexto se hizo de manera exitosa.
Cargo: Autor
6.3 Pruebas de localización y guiado del dispositivo móvil
Caso de prueba: T-Guide-003-001 Localización del dispositivo móvil por RFID
DESCRIPCIÓN: Verificar que se obtenga la ubicación del dispositivo móvil mediante la
lectura de tarjetas RFID en cercanía. Para ello se iniciará el intermediario que realiza la
comunicación entre los dispositivos. El proceso comenzará en el celular y se acercará una
tarjeta RFID al lector. El servidor deberá estar activo.
134
Capítulo 6 Pruebas
Resultado: OK.
El RFID obtenido
corresponde a la ubicación
―Sistemas Distribuidos‖
Observaciones: La posición se obtuvo exitosamente y con gran precisión.
Cargo: Autor
Caso de prueba: T-Guide-003-002 Localización del dispositivo móvil por QRCodes
DESCRIPCIÓN: Comprobar que se obtenga la ubicación del dispositivo móvil mediante
la captura y decodificación de una imagen con un código de barras. El servidor de tareas
deberá estar activo.
135
Capítulo 6 Pruebas
Resultado: OK.
El código de barras
decodificado corresponde a
la ubicación ―Mantenimiento‖
Observaciones: La posición se obtuvo exitosamente y con gran precisión.
Cargo: Autor
Caso de prueba: T-Guide-003-003 Guiado del dispositivo móvil
DESCRIPCIÓN: Verificar que el proceso de guiado, por RFID o por QRCodes desde su
posición actual al destino se lleve a cabo de una forma precisa y correcta, actualizando
constantemente la posición utilizando del dispositivo. El proceso iniciará desde el
dispositivo cliente y el servidor de tareas tendrá que estar activo.
136
Capítulo 6 Pruebas
Resultado: OK.
El origen ―Sistemas Distribuidos‖ y el
destino ―Documentación‖ están en planos
distintos
Se lee otra posición
que corresponde a
―Mantenimiento‖
Se indica al
usuario que vaya
a las escaleras
137
Capítulo 6 Pruebas
Se actualiza la posición
del usuario
Se lee otra posición y se
actualiza
Se llega al destino
solicitado (véase que el
plano es distinto)
Observaciones: El proceso de guiado se realiza de forma exitosa actualizando
constantemente la posición del usuario.
Cargo: Autor
6.4 Pruebas de administración de tareas
Caso de prueba: T-Guide-004-001 Invocación del servicio Web para la obtención de
un listado de tareas pendientes
DESCRIPCIÓN: Comprobar que se obtenga una lista de las tareas pendientes de un
usuario en especifico, a través de la conexión entre el dispositivo celular con el servidor
de tareas mediante una petición HTTP GET. Para llevar a cabo la prueba se iniciará el
Apache Felix con el servidor de tareas activo.
138
Capítulo 6 Pruebas
Resultado: OK.
El listado de tareas
corresponde con lo obtenido
mediante la consulta SQL
Observaciones: El listado de tareas obtenido del usuario es correcto, por lo tanto el
proceso es exitoso.
Cargo: Autor
Caso de prueba: T-Guide-004-002 Invocación del servicio Web para
completar/cancelar una tarea
DESCRIPCIÓN: Verificar que se desactive correctamente una tarea pendiente, ya sea
cancelándola o completándola, a través de la conexión entre el dispositivo celular
mediante una petición HTTP GET con el servidor de tareas, el cual ofrece el servicio
Web. Para llevar a cabo la prueba se iniciará el Apache Felix con el servidor de tareas
activo.
139
Capítulo 6 Pruebas
Resultado: OK.
La base de datos antes y después de
completar la tarea, se observa que la
tarea ―Devolver Libro‖ se activa después
de completar la tarea ―Prestar Libro‖.
La base de datos antes y después de
cancelar la tarea, se observa que ya no
aparecen tareas pendientes y el estado de
la tarea devolver libro se actualiza a ―X‖
Observaciones: El proceso de completar y cancelar una tarea se llevó a cabo de forma
exitosa, además se pudo comprobar que las dependencias establecidas entre tareas se
realizan correctamente.
Cargo: Autor
Caso de prueba: T-Guide-004-003 Invocación del servicio Web para el
almacenamiento de una nueva tarea del usuario
DESCRIPCIÓN: Comprobar que se establezca correctamente una nueva tarea como
pendiente para el usuario que la crea a través de una petición POST al servidor de
tareas, el cual ofrece el servicio Web. Para llevar a cabo la prueba se iniciará el Apache
Felix con el servidor de tareas activo.
140
Capítulo 6 Pruebas
Resultado: OK.
Se elige ―Nueva
Tarea‖
Se listan las
actividades
Se lee el objeto
―Mantenimiento‖
Se asocia el
objeto
Se listan las
tareas dentro
de la actividad
Se establecen la
fecha y la hora
Se buscarán
objetos
cercanos
Se almacena la
tarea
Observaciones: El proceso de establecer una tarea como pendiente se llevo a cabo de
forma exitosa.
141
Cargo: Autor
Capítulo 6 Pruebas
6.5 Pruebas de administración de la información de la base de
d a to s
Caso de prueba: T-Guide-005-001 Administración de la información de los usuarios
DESCRIPCIÓN: Comprobar que el módulo de administración de usuarios, en donde se
consulta, se modifican, se eliminan y se insertan grupos y usuarios se lleve a cabo de
forma exitosa. Para llevar a cabo la prueba se pondrá en marcha el servidor de
aplicaciones Apache Tomcat y se accederá a la aplicación Web de tareas mediante un
navegador Web.
Resultado: OK.
Se realiza una consulta
general
Se listan los grupos, los cuales
corresponden a los almacenados
en la base de datos
Se da de alta un nuevo
grupo
Se almacena el nuevo
registro en la base de
datos y se muestra el
listado
Se eliminará el grupo
142
Capítulo 6 Pruebas
El grupo se elimina de
la base de datos y
desaparece del listado
Se buscarán todos los
usuarios en la base de
datos
Se listan los usuarios,
los cuales corresponden
a los almacenados en la
base de datos
Se dará de alta un nuevo
usuario
listado
143
Capítulo 6 Pruebas
Se eliminará el usuario
El usuario se elimina de
la base de datos y
Observaciones: La administración de los grupos y usuarios hecha a través de la
aplicación Web, en donde se insertan, modifican y eliminan grupos y usuarios se llevó a
cabo de forma exitosa, manteniendo siempre la integridad de la información.
Cargo: Autor
Caso de prueba: T-Guide-005-002 Administración de la información de los recursos
DESCRIPCIÓN: Verificar que el módulo de administración de recursos, en donde se
consulta, se modifican, se eliminan y se insertan recursos y tipos de recursos se lleve a
cabo de forma exitosa. Para llevar a cabo la prueba se pondrá en marcha el servidor de
navegador Web.
144
Capítulo 6 Pruebas
Resultado: OK.
general
Se listan los tipos de recursos, los
cuales corresponden a los
almacenados en la base de datos
grupo
listado
Se agregarán atributos
al tipo de recurso
Se agregan los atributos
al tipo de recurso
Se listan los atributos
del tipo de recurso
general
Se listan los tipos de
recursos, los cuales
corresponden a los
almacenados en la
base de datos
145
Capítulo 6 Pruebas
Se dará de alta un
nuevo recurso
listado
Se eliminará el recurso
El recurso se elimina de
la base de datos y
Observaciones: La administración de los recursos hecha a través de la aplicación Web,
en donde se insertan, modifican y eliminan recursos y tipos de recursos se llevó a cabo
de forma exitosa, manteniendo siempre la integridad de la información.
146
Cargo: Autor
Capítulo 6 Pruebas
Caso de prueba: T-Guide-005-003 Administración de la información de las
ubicaciones
DESCRIPCIÓN: Comprobar que el módulo de administración de ubicaciones, en donde
se consulta, se modifican, se eliminan y se insertan campus, edificios, planos y
ubicaciones se realice de forma exitosa. Para llevar a cabo la prueba se pondrá en
marcha el servidor de aplicaciones Apache Tomcat y se accederá a la aplicación Web de
tareas mediante un navegador Web.
Resultado: OK.
general
Se listan los campus, los cuales
corresponden a los
almacenados en la base de
datos
campus
registro en la base de datos
y se muestra el listado
Se eliminará el campus
147
Capítulo 6 Pruebas
El campus se elimina de la base
de datos y desaparece del listado
Se realiza una consulta de
edificios con RFID en el
campus
Se listan los edificios, los cuales
corresponden a los almacenados
en la base de datos
Se capturará un nuevo edificio
148
Capítulo 6 Pruebas
Se eliminará el
edificio
El edificio
desaparece del
listado
general de planos
Se listan los planos, los
cuales corresponden a los
almacenados en la base de
datos
Se capturará un nuevo
plano
listado
149
Capítulo 6 Pruebas
Se eliminará el
plano
El plano
desaparece del
listado
Se realiza una de
ubicaciones con RFID en el
plano
Se listan las ubicaciones,
los cuales corresponden a
los almacenados en la base
de datos
150
Capítulo 6 Pruebas
Se capturará una nueva
ubicación
listado
Se eliminará la
ubicación
La ubicación
desaparece del
listado
Observaciones: La administración de las ubicaciones hecha a través de la aplicación
Web, en donde se insertan, modifican y eliminan campus, edificios, planos y ubicaciones
se llevó a cabo de forma exitosa, manteniendo siempre la integridad de la información.
151
Cargo: Autor
Capítulo 6 Pruebas
Caso de prueba: T-Guide-005-004 Administración de la información de las tareas
DESCRIPCIÓN: Verificar que el módulo de administración de tareas, en donde se
consulta, se modifica, se eliminan y se insertan actividades y tareas se realice de forma
exitosa. Para llevar a cabo la prueba se pondrá en marcha el servidor de aplicaciones
Apache Tomcat y se accederá a la aplicación Web de tareas mediante un navegador
Web.
Resultado: OK.
general
Se listan las actividades, las
cuales corresponden a las
almacenadas en la base de datos
Se da de alta una nueva
actividad
Se eliminará la actividad
La actividad se elimina de la
base de datos y desaparece del
listado
152
Capítulo 6 Pruebas
Se realiza una consulta de
edificios con RFID en el
campus
Se listan las tareas, las cuales
corresponden a las
almacenadas en la base de
datos
Se capturará una nueva tarea
listado
153
Capítulo 6 Pruebas
Se eliminará la
tarea
El edificio
desaparece del
listado
Observaciones: La administración de las tareas hecha a través de la aplicación Web, en
donde se insertan, modifican y eliminan actividades y tareas se llevó a cabo de forma
exitosa, manteniendo siempre la integridad de la información.
Cargo: Autor
Caso de prueba: T-Guide-005-005 Administración de la información de las tareas de
los usuarios
DESCRIPCIÓN: Verificar que el módulo de administración de tareas de tareas de los
usuarios, en donde se consulta, se modifican, se eliminan y se insertan tareas se realice
de forma exitosa. Para llevar a cabo la prueba se pondrá en marcha el servidor de
navegador Web.
154
Capítulo 6 Pruebas
Resultado: OK.
Se realiza una
consulta de tareas de
un usuario
Se listan las actividades, las
cuales corresponden a las
almacenadas en la base de
datos
Se da de alta una nueva
tarea para el usuario
listado
Se eliminará la tarea
La tarea se elimina de la
base de datos y
155
Capítulo 6 Pruebas
Observaciones: La administración de las tareas de los usuarios hecha a través de la
aplicación Web, en donde se insertan, modifican y eliminan tareas de los usuarios se
llevó a cabo de forma exitosa, manteniendo siempre la integridad de la información.
Cargo: Autor
Los casos de prueba presentados validaron la funcionalidad de los módulos que
conforman la arquitectura de T-Guide. En la Tabla 29 se muestra un resumen de
los grupos de casos de prueba con una conclusión sobre la operación y
comportamiento de la plataforma para cada grupo.
Tabla 29 Resumen de los casos de prueba de la plataforma propuesta
Grupo
Descripción
Resultado
T-Guide-001
Pruebas de configuración y
conexiones
Exitoso
T-Guide-002
Pruebas de autoidentificación
Exitoso
T-Guide-003
Pruebas de localización y
guiado del dispositivo móvil
Exitoso
T-Guide-004
Pruebas de administración de
tareas
Exitoso
T-Guide-005
Pruebas de administración de
la información de la base de
datos
Exitoso
156
Conclusión
La conexión entre dispositivo
móvil con el lector de
tarjetas, entre el servidor y la
base de datos y entre el
cliente y el servidor se
realizó de manera exitosa.
Se obtuvieron correctamente
las tarjetas RFID y se tomó y
decodificó la fotografía con
un código de barras. La
fotografía que se tome no
debe estar borrosa.
Se posicionó con precisión al
dispositivo
utilizando
QRCodes y RFID, y el
proceso de guiado se realiza
de
forma
exitosa
actualizando correctamente
la posición del usuario.
Se administran de manera
correcta las operaciones
sobre las tareas de los
usuarios desde el dispositivo
móvil.
La información de la base de
datos se administra de
manera exitosa desde la
aplicación
Web,
manteniendo siempre la
integridad de la información.
7 Capítulo 7 Conclusiones
Capítulo 7 Conclusiones
En este capítulo se muestran las conclusiones aportaciones, trabajos futuros,
publicaciones que se obtuvieron con el presente trabajo de tesis.
7.1 Conclusiones
El presente trabajo ha introducido una metodología para localizar dispositivos
celulares en interiores y se ha comprobado que es posible desarrollar un sistema
que asocie objetos del mundo real a actividades mediante la asociación de tarjetas
RFID a objetos, háblese de lugares, personas o recursos, que le servirán de
recordatorios para realizar sus tareas del día a día.
A través de la metodología propuesta es posible localizar un dispositivo celular
utilizando RFID y QRCodes en interiores con gran precisión.
El resultado de este proyecto son tres aplicaciones: el cliente sobre Android, el
servidor OSGi y una aplicación Web para la gestión de las tareas, de las
ubicaciones, las tarjetas RFID y las direcciones MAC de los dispositivos de
referencia. Hasta ahora, este proyecto ha sido probado únicamente para la
localización mediante RFID, sin embargo, la técnica utilizada para RFID es válida
para Bluetooth, WiFi y Cell-ID.
Se logró implementar y probar satisfactoriamente el proyecto en el dispositivo
celular HTC G2 con sistema operativo Android y se comprobó la exactitud de la
localización con RFID y QRCodes.
Debido a que el dispositivo celular no cuenta con lector RFID se realizó una
emulación de las lecturas RFID, pasando las lecturas a través de un socket entre
el lector RFID conectado mediante USB a una laptop y el dispositivo celular.
Se desarrolló un servidor que atiende las peticiones de los clientes a través de un
servicio Web, el cual es independiente del tipo de dispositivo celular y su sistema
operativo, lo que hace que el proyecto pueda crecer hacia otras plataformas
cliente.
A continuación se detallan las principales aportaciones del proyecto.
7.2 Aportaciones
Este proyecto tiene varias contribuciones, entre las que destacan:
i.
ii.
La vinculación de objetos del mundo real con las tareas mediante la autoidentificación, ya sea por código de barras (mediante QRCodes) o por
RFID, haciendo uso de las funcionalidades de un dispositivo celular.
La localización de un dispositivo utilizando varias técnicas de
posicionamiento, con tecnologías incluidas en la mayoría de los
dispositivos celulares nuevos, con esto se abre un gran abanico de
posibilidades de localizar a un dispositivo y cuando alguna de las
tecnologías no se encuentre disponible se puede verificar que alguna otra
159
iii.
iv.
esté disponible y con ello poder localizar al dispositivo en cualquier lugar y
en cualquier momento, en interiores y en exteriores.
La metodología utilizada para la localización ha sido probada únicamente
en RFID y QRCodes, sin embargo ésta técnica es válida y aceptable para
la localización en Bluetooth, WiFi y Cell-ID, la base de datos y la aplicación
Web están preparadas para aceptar estas modificaciones.
La precisión que se logra en el posicionamiento del dispositivo que es
menor a 2 metros en interiores.
7.3 Trabajos futuros
Algunos de los trabajos futuros que pueden depender del desarrollo de esta tesis
son los siguientes:
 Utilizando la metodología desarrollada se pueden ampliar las capacidades
de localización del dispositivo celular a otras tecnologías como Bluetooth,
WiFi y Cell-ID, cabe destacar que la aplicación Web que administra la
información de la base de datos no tiene que ser modificada, está
preparada para aceptar estos cambios.
 Se pueden desarrollar clientes en diversas plataformas como J2ME y no
sólo en Android, el servidor que atiende las peticiones no tendría que sufrir
modificación alguna.
 Se puede extender la auto-identificación a NFC 3, debido a que muchos
celulares actuales ya contarán con esta tecnología.
 Se puede incluir un guiado en exteriores, que haga uso del GPS y las APIs
de Google Maps.
 Se pueden investigar técnicas de posicionamiento como potencia de señal
recibida en WiFi e incluirlas al proyecto.
 Se puede desarrollar un módulo de diseño de planos para que se adapten
perfectamente a la pantalla de los dispositivos.
 Se puede hacer uso de las capacidades de los nuevos dispositivos
celulares los cuales cuentan con brújula para hacer un guiado indicándole
hacia dónde dirigirse.
3
Near Field Communication (NFC) es un protocolo basado en una interfaz inalámbrica. La
comunicación se realiza entre dos entidades (peer-to-peer). El protocolo establece conexión
wireless entre las aplicaciones de la red y los dispositivos electrónicos.
160
7.4 Publicaciones
Se logró la publicación de un artículo en el VII Congreso Internacional sobre
Innovación y Desarrollo Tecnológico con ISBN: ISBN978-607-95255-0-7.
 T-Guide: sistema contextual de guiado y administración de actividades
mediante teléfonos celulares con sistema operativo Android y tecnología
RFID.
Se obtuvo el 2º lugar en el XIV Concurso de creatividad de los Institutos
Tecnológicos en su fase local.
161
Anexos
Anexos
Anexo A Definición de la interfaz de usuario
1. captura_barras.xml
<?xml version="1.0" encoding="utf-8"?>
<TableLayout android:id="@+id/widget0" android:layout_width="fill_parent"
android:layout_height="wrap_content"
xmlns:android="http://schemas.android.com/apk/res/android">
<TableRow android:layout_width="fill_parent"
android:layout_height="wrap_content" android:gravity="center">
<TableLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:id="@+id/myTableLayout" android:layout_width="fill_parent"
android:animation="@anim/layout_animation_row_left_slide">
android:layout_height="wrap_content" android:layout_marginTop="15px"
android:gravity="center">
<EditText android:id="@+id/etCapturaBarras" android:text=""
android:textSize="18sp" android:typeface="sans" android:textStyle="bold"
android:layout_marginLeft="5px" android:maxWidth="100px"
android:width="100px" android:height="50px" android:maxHeight="50px">
</EditText>
<Button android:id="@+id/btCapturaBarras" android:width="130px"
android:layout_height="wrap_content" android:text="Por barras"
android:textSize="14sp">
</Button>
</TableRow>
</TableLayout>
</TableRow>
<ImageView android:id="@+id/imCapturaBarras" android:width="170px"
android:maxWidth="170px" android:height="170px" android:maxHeight="170px"
</ImageView>
</TableRow>
</TableLayout>
</TableRow>
</TableLayout>
2. detalles_instancia_tarea.xml
android:layout_height="wrap_content" android:layout_marginLeft="8px">
android:layout_height="wrap_content" android:layout_marginTop="10px">
<TextView android:text="Recurso Asociado" android:textSize="18sp"
android:typeface="sans" android:textStyle="bold">
</TextView>
165
</TableRow>
</TableLayout>
</TableRow>
android:layout_height="wrap_content" android:layout_gravity="center"
android:layout_marginLeft="8px">
android:layout_height="wrap_content" android:layout_marginLeft="3px"
android:layout_marginTop="5px">
<TextView android:id="@+id/recurso" android:width="300px"
android:maxWidth="300px"
android:text="Libro Don Quijote de la mancha\nclick for more..."
android:textSize="16sp" android:typeface="sans" android:gravity="center">
</TextView>
</TableRow>
</TableLayout>
</TableRow>
android:layout_height="fill_parent" android:layout_marginTop="10px"
android:layout_height="fill_parent"
android:layout_height="fill_parent" android:gravity="center_vertical">
<TextView android:layout_width="fill_parent"
android:layout_height="fill_parent" android:width="300px"
android:text="Incidencias" android:textSize="16sp"
</TextView>
</TableRow>
<EditText android:id="@+id/incidencias"
android:layout_width="wrap_content" android:layout_height="fill_parent"
android:maxWidth="300px" android:text="" android:textSize="18sp"
android:typeface="sans" android:lines="5">
</EditText>
</TableRow>
</TableLayout>
</TableRow>
android:layout_height="wrap_content" android:layout_gravity="center">
<TextView android:id="@+id/tareasRelacionadas"
android:width="300px" android:maxWidth="300px"
android:text="Ver tareas relacionadas\nclick for more..."
android:textSize="16sp" android:typeface="sans" android:gravity="center">
</TextView>
</TableRow>
</TableLayout>
</TableRow>
android:layout_gravity="center">
android:layout_height="fill_parent" android:layout_gravity="center"
166
<Button android:id="@+id/btGuardar" android:width="150px"
android:layout_height="wrap_content" android:text="Guardar"
android:layout_gravity="center_horizontal" android:textSize="14sp">
</Button>
</TableRow>
</TableLayout>
</TableRow>
</TableLayout>
3. detalles_ubicacion.xml
android:id="@+id/myTableLayout" android:layout_width="wrap_content"
android:gravity="center"
<TextView android:id="@+id/txUbicacion" android:layout_width="wrap_content"
android:autoLink="all" android:textSize="16sp" android:textStyle="bold">
</TextView>
</TableRow>
<TextView android:id="@+id/txEdificio" android:layout_width="wrap_content"
android:layout_height="wrap_content" android:text=""
android:layout_gravity="center" android:autoLink="all"
android:textSize="16sp" android:textStyle="bold">
</TextView>
</TableRow>
<Button android:id="@+id/btIniciaGuiado" android:width="130px"
android:layout_height="wrap_content" android:text="Iniciar Guiado"
android:layout_gravity="center" android:textSize="14sp">
</Button>
</TableRow>
</TableLayout>
4. detalles_usuario.xml
android:id="@+id/myTableLayout" android:layout_width="wrap_content"
android:layout_height="wrap_content" android:layout_gravity="center_horizontal"
<ImageView android:id="@+id/foto" android:layout_width="100px"
android:layout_height="100px">
</ImageView>
</TableRow>
<TextView android:id="@+id/name" android:layout_width="wrap_content"
android:layout_height="wrap_content" android:text="Israel Arjona Vizcaíno"
android:layout_gravity="center_horizontal" android:autoLink="all"
android:textSize="15sp" android:typeface="sans">
</TextView>
</TableRow>
167
<TextView android:id="@+id/email" android:layout_width="wrap_content"
android:layout_height="wrap_content" android:text="[email protected]"
</TextView>
</TableRow>
<TextView android:id="@+id/telefono" android:layout_width="wrap_content"
android:layout_height="wrap_content" android:text="3111111"
</TextView>
</TableRow>
</TableLayout>
5. guiado.xml
<TextView android:id="@+id/txGuiado"
android:text="
::Bitacora de eventos::
\n\n"
android:width="300px" android:maxWidth="300px" android:textSize="14sp"
android:typeface="sans" android:gravity="left" android:textStyle="bold">
</TextView>
</TableRow>
</TableLayout>
</TableRow>
<ImageView android:id="@+id/imFondoGuiado" android:width="170px"
</ImageView>
</TableRow>
</TableLayout>
</TableRow>
</TableLayout>
6. lista.xml
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical" android:layout_width="fill_parent"
android:layout_height="fill_parent">
<ListView android:id="@+id/android:list" android:layout_width="fill_parent"
android:layout_height="fill_parent" android:gravity="center" />
168
<TextView android:id="@+id/android:empty"
android:layout_width="fill_parent" android:layout_height="fill_parent"
android:text="@string/main_no_items" android:gravity="center" />
</LinearLayout>
7. login.xml
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent" android:layout_height="wrap_content"
android:padding="5dp">
<ImageView android:id="@+id/imgAtrexis" android:src="@drawable/candado"
android:layout_width="wrap_content" android:layout_height="wrap_content"
android:layout_alignParentTop="true" android:layout_centerHorizontal="true"
android:padding="10dp" />
<TextView android:id="@+id/lblUsername" android:layout_width="wrap_content"
android:layout_height="wrap_content" android:layout_below="@id/imgAtrexis"
android:text="Username:" />
<EditText android:id="@+id/txtUsernameLogin"
android:singleLine="true" android:layout_below="@id/lblUsername"
android:layout_marginBottom="5dp" />
<TextView android:id="@+id/lblPassword" android:layout_width="wrap_content"
android:layout_height="wrap_content" android:layout_below="@id/txtUsernameLogin"
android:text="Password:" />
<EditText android:id="@+id/txtPasswordLogin"
android:layout_below="@id/lblPassword" android:password="true"
android:singleLine="true" android:layout_marginBottom="10dp" />
<Button android:id="@+id/btnEntrarLogin" android:layout_width="80dp"
android:layout_height="wrap_content" android:layout_below="@id/txtPasswordLogin"
android:padding="10dp" android:layout_centerInParent="true"
android:text="Entrar" />
<TextView android:id="@+id/lblPowered" android:layout_width="wrap_content"
android:layout_height="wrap_content" android:layout_alignParentBottom="true"
android:layout_alignParentRight="true" android:textStyle="bold"
android:textColor="#FFFFFF" android:text="Powered By Israel" />
</RelativeLayout>
8. nueva_tarea_recurso.xml
<TextView android:id="@+id/descripcionTareaNuevaTarea"
android:text="" android:textSize="16sp" android:typeface="sans"
</TextView>
</TableRow>
</TableLayout>
</TableRow>
169
<TextView android:text="Recurso" android:textSize="18sp"
</TextView>
<EditText android:id="@+id/idrecurso" android:text=""
android:layout_marginLeft="5px" android:maxWidth="100px"
android:width="100px" android:height="50px" android:maxHeight="50px">
</EditText>
<Button android:id="@+id/btCargar" android:width="130px"
android:layout_height="wrap_content" android:text="Por barras"
android:layout_gravity="center" android:textSize="14sp">
</Button>
</TableRow>
</TableLayout>
</TableRow>
android:animation="@anim/layout_animation_row_left_slide"
<TextView android:id="@+id/fechaNuevaTarea" android:text="Fecha: "
</TextView>
</TableRow>
</TableLayout>
</TableRow>
<ImageView android:id="@+id/imBarras" android:width="170px"
</ImageView>
</TableRow>
</TableLayout>
</TableRow>
<TextView android:id="@+id/descripcionRecurso"
android:text="" android:textSize="16sp" android:typeface="sans"
</TextView>
</TableRow>
</TableLayout>
</TableRow>
</TableLayout>
170
Anexo B Plan de pruebas T-Guide
El plan de pruebas constará de los siguientes puntos:
1.
2.
3.
4.
5.
Introducción.
Descripción del plan.
Casos de prueba.
Procedimientos de prueba.
Resultados de pruebas
Introducción
Este documento define el plan de pruebas basado en el estándar IEEE 829
[STD829] para pruebas de software, que permitirá verificar la funcionalidad del
sistema T-Guide, que es una aplicación cliente-servidor que permite establecer
tareas asignadas a recursos físicos del mundo real, y sirve para recordar al
usuario que la tarea debe cumplimentarse, además incluye la funcionalidad para la
localización y guiado de dispositivos móviles a través de RFID.
La aplicación está compuesta de cuatro módulos principales:
1.
2.
3.
4.
Conexión y configuración.
Auto-identificación.
Localización y guiado.
Administración de tareas.
Descripció n del plan
Características a ser probadas
El plan de pruebas contiene la descripción de los casos de prueba definidos con el
fin de validar y verificar que la aplicación T-Guide cumple con los requisitos
requeridos para la correcta administración y recordatorio de tareas del usuario.
Características excluidas de las pruebas
No se dará prioridad al diseño de interfaz de las aplicaciones que se utilicen
para probar la aplicación.
Las aplicaciones no serán probadas en dispositivos móviles que no cuenten
con soporte para Android.
Habrá casos en los que la funcionalidad que se pruebe sea simulada.
171
Enfoque
Debido a que las mediciones que se utilizarán serán principalmente de
funcionalidad, por lo que no se tomará en cuenta el tiempo de respuesta, ni la
exactitud de la función.
Criterio pasa/ no pasa de casos de prueba
En la descripción de los casos de prueba, se detallarán los resultados esperados
para cada uno de ellos. Se considerará que una prueba ha pasado con éxito
cuando los resultados esperados coincidan con los descritos en el caso de prueba.
En caso de no coincidencia, se analizarán las causas y se harán las
modificaciones necesarias hasta que se cumplan con los resultados esperados.
Criterios de suspensión y requerimientos de reanudación
En ningún caso se suspenderán definitivamente las pruebas. Cada vez que se
presente que el caso no pasa una prueba, inmediatamente se procederá a evaluar
y corregir el error, permaneciendo en la prueba de este caso hasta que ya no se
presenten dificultades con él.
Tareas de pruebas
Las tareas a desarrollar para preparar y aplicar las pruebas son:
Tabla 30 Tareas a desarrollar para las pruebas
Tarea
Habilidades especiales
precedente
Tarea
Responsa
bilidades
1. Preparación del
plan de pruebas.
Terminación del
análisis y diseño
de la aplicación.
Conocimiento
sobre
servicios
basados
en
localización,
las
aplicaciones cliente servidor, los
servicios Web y del IEEE Std. 829.
Autor de la
tesis.
2. Preparación del
diseño
de
las
pruebas.
Tarea 1.
Conocimiento sobre la estructura de
la Aplicación T-Guide, sus clases y
métodos, y del IEEE Std. 829.
Autor de la
tesis.
3. Preparación de los
casos de prueba.
Tarea 2.
Conocimiento
sobre
servicios
basados
en
localización,
las
aplicaciones cliente servidor
Autor de la
tesis.
4.
Aplicación
pruebas.
Tarea 3.
Conocimiento
del
entorno
y
preparación del sistema desarrollado
para su ejecución.
Autor de la
tesis.
de
172
5.
Resolver
incidentes
pruebas.
los
de
6. Evaluación
resultados.
de
Tarea 4.
Conocimiento de programación en
JAVA, Android, Restlet, OSGi,
JSON, servicios Web, hilos, sockets,
protocolo
HTTP;
además
conocimiento en base de datos
PostgreSQL.
Autor de la
tesis.
Tarea 4.
Tarea 5.
Conocimiento de las preguntas de
investigación, la hipótesis de prueba,
y los objetivos de esta tesis.
Autor de la
tesis.
Liberación de las pruebas
La entrada especificada y la salida esperada en cada caso de prueba, serán
suficientes para la comprobación del objetivo alcanzado y por lo tanto para la
aceptación de las pruebas.
Requisitos ambientales
Las características y propiedades físicas y lógicas requeridas para el ambiente de
pruebas, son las siguientes:
Tabla 31 Tecnología física utilizada
Equipo
PC de
Laptop
escritorio
o
Dispositivo móvil
Procesador Intel P4 o superior.
512MB de memoria RAM o
superior.
80 GB en disco duro.
Windows XP o superior.
Android OS.
Wi-Fi.
Bluetooth.
Lector de tarjetas RFID
Conexión mediante USB.
Tarjetas RFID
Compatibles con el lector RFID.
Tabla 32 Tecnología de programación utilizada
Herramientas
Android SDK 1.2
Eclipse 3.4 Ganymede como entorno de programación
Celular HTC G2 con Android
Apache Tomcat 6.0
Apache Felix 1.4.1
API ZXing 2.0 para la decodificación del código de barras
PostgreSQL 8.3.
173
Responsabilidades
Toda la responsabilidad de las pruebas recae en el autor de la tesis.
Riesgos y contingencias
Falta de tiempo: El tiempo es un factor importante que genera incertidumbre
a la hora de aplicar las pruebas, por lo que se tomarán como mínimo 16
casos de prueba, si el tiempo lo permite se extenderán las pruebas a otros
casos.
Todas las fallas que se pudieran presentar en el transcurso del desarrollo
de las pruebas deberán ir resolviéndose de manera iterativa por el
responsable de esta tesis, hasta que la falla no produzca más.
Casos de pruebas
Características a probar
Los distintos casos de prueba definen las características a ser probadas que se
muestran en la tabla 33.
Tabla 33 Características a probar de la aplicación
Característica
Configuración y
conexiones
Auto-identificación
Localización y guiado del
dispositivo móvil
Administración de tareas
Descripción
Define los casos de prueba para verificar la correcta
configuración de los dispositivos utilizados por el cliente:
lector RFID; la conexión entre el cliente y el servidor y la
conexión de la base de datos en la aplicación T-Guide.
Define los casos de prueba para la identificación automática
de recursos físicos en cercanía del dispositivo móvil,
utilizando como tecnologías de Auto-ID el código de barras
y tarjetas RFID.
Define los casos de prueba para la localización por medio
de RFID de un dispositivo móvil. Además se definen los
casos de prueba para la realización de la tarea de guiado, la
cual se refiere a guiar a un usuario de una localización
origen obtenida automáticamente a una destino elegida por
el usuario.
Define los casos de prueba para el manejo de tareas, la
correcta consulta y almacenamiento de la información de
estas en la base de datos y la obtención de resultados a
través del protocolo HTTP.
Pruebas de
Define los casos de prueba para la gestión de la información
administración de la
de la base de datos, como es la consulta, modificación,
información de la base de
eliminación y actualización.
datos
174
Pruebas de configuración y conexiones
T-Guide-001 Pruebas de configuración y conexión.
T-Guide-001-001 Configuración y conexión del cliente móvil con el lector
RFID.
T-Guide-001-002 Configuración y conexión del servidor de tareas con el
dispositivo móvil.
T-Guide-001-003 Configuración y conexión del servidor de tareas con la
base de datos.
Pruebas de auto-identificación
T-Guide-002 Pruebas de auto-identificación.
T-Guide-002-001 Captura y decodificación del código de barras.
T-Guide-002-002 Obtención de las tarjetas RFID en cercanía.
Pruebas de localización y guiado del dispositivo móvil
T-Guide-003 Pruebas de localización y guiado del dispositivo móvil.
T-Guide-003-001 Localización del dispositivo móvil por RFID.
T-Guide-003-002 Localización del dispositivo móvil por QRCodes.
T-Guide-003-003 Guiado del dispositivo móvil.
Pruebas de administración de tareas
T-Guide-004 Pruebas de administración de tareas.
T-Guide-004-001 Invocación del servicio Web para la obtención de un
listado de tareas pendientes.
T-Guide-004-002 Invocación del servicio Web para completar/cancelar una
tarea.
T-Guide-004-003 Invocación del servicio Web para el almacenamiento de
una nueva tarea del usuario.
175
Pruebas de administración de la información de la base de datos
T-Guide-005 Pruebas de administración de la información de la base de datos.
T-Guide-005-001 Administración de la información de los usuarios.
T-Guide-005-002 Administración de la información de los recursos.
T-Guide-005-003 Administración de ubicaciones.
T-Guide-005-004 Administración de tareas.
T-Guide-005-005 Administración de tareas de los usuarios.
Procedim iento de pruebas
Este apartado contiene la descripción de los procedimientos correspondientes a
todos los casos de prueba que conforman el presente documento. La organización
de todos los casos de prueba se basa en cada uno de los grupos definidos. El
objetivo fundamental de cada uno de los casos es verificar y validar una
funcionalidad específica de la aplicación T-Guide acrónimo de plan de pruebas.
Dentro de cada uno de los grupos de pruebas se definen casos de prueba para
cierta funcionalidad específica a modo de comprobar que cumple con aspectos
funcionales que deben ser cubiertos por ese grupo de casos de prueba.
Cada uno de los casos de prueba se enfoca en la validación y verificación de una
funcionalidad concreta de la aplicación T-Guide. La descripción de cada uno de los
casos de prueba muestra el objetivo general del grupo, el entorno de prueba
necesario y todos los casos de prueba que lo conforman.
Para cada uno de los casos de prueba se define el propósito del caso, el entorno
necesario para su ejecución, el procedimiento y los resultados esperados de la
prueba.
Como recomendación para la revisión de los casos de prueba, se deben llevar a
cabo en orden de aparición.
T-Guide-001 Pruebas de conexión y configuración
Objetivo
Verificar que la conexión entre dispositivo móvil y el lector RFID se establezca
correctamente. Asimismo que la comunicación del servidor con la base de datos y
entre el cliente y el servidor se lleve a cabo de una forma correcta.
176
Entorno de prueba
Para los casos de prueba contenidos en este grupo se utilizan los siguientes
elementos:
PC o Laptop.
Lector de tarjetas RFID.
Teléfono móvil HCT G2 con sistema operativo Android.
Manejador de bases de datos PostgreSQL 8.3.
Apache Felix con bundle de servidor de tareas iniciado.
Tarjetas RFID.
T-Guide-001-001 Configuración y conexión del cliente móvil con el lector
RFID
Objetivo
Establecer la configuración en el archivo config.xml y verificar la conexión
del software T-Guide con el lector de tarjetas RFID.
Entorno de prueba
La prueba se llevará a cabo con un teléfono que contenga el sistema
operativo Android y un lector de tarjetas RFID con capacidad para
conectarse al puerto USB.
Proceso
1. Conectar el lector de tarjetas RFID al puerto USB de la computadora.
2. Establecer los parámetros de conexión al teléfono en el archivo
config.xml.
3. Ejecutar la aplicación e iniciar el hilo de conexión al lector de tarjetas
mediante el lanzamiento de la tarea de guiado, observar los
resultados.
Resultados
Lograr la conexión con el lector RFID para comenzar a obtener tarjetas
RFID en cercanía.
T-Guide-001-002 Configuración y conexión del servidor de tareas con el
dispositivo móvil
Objetivo
Establecer la configuración en el archivo config.xml y verificar la conexión
del software T-Guide con el servidor de tareas OSGI, instalado como un
bundle en el servidor Apache Felix.
177
Entorno de prueba
La prueba se llevará a cabo con un teléfono que contenga el sistema
operativo Android y una computadora (PC o Laptop) que tenga el servidor
de tareas OSGI instalado en forma de un bundle en Apache Felix.
Proceso
1. Iniciar el servidor Apache Felix.
2. Si el bundle Servidor_OSGI_Tareas_1.0.0.jar no está instalado,
proceder con su instalación.
3. Iniciar el bundle anteriormente mencionado.
4. Establecer los parámetros de conexión del teléfono móvil con el
servidor en el archivo config.xml.
5. Realizar una petición GET al servicio Web ofrecido por el servidor
de tareas.
6. Verificar que se reciban resultados.
Resultados
Lograr que se establezca la comunicación entre el cliente Android y el
servidor de tareas OSGI.
T-Guide-001-003 Configuración y conexión del servidor de tareas con la base
de datos
Objetivo
Establecer la configuración de la base de datos en el archivo
OSGITareas.conf y verificar la conexión del servidor de tareas OSGI y el
manejador de base de datos.
Entorno de prueba
La prueba se llevará a cabo utilizando una computadora (PC o Laptop) con
el manejador de bases de datos PostgreSql 8.3 en ejecución.
Proceso
1. En caso de que el servidor de base de datos no se encuentre en
ejecución, iniciarlo.
2. Establecer los parámetros de conexión a la base de datos en el archivo
OSGITareas.conf.
3. Ejecutar la aplicación y observar los resultados.
Resultados
Obtener y mantener una conexión a la base de datos y verificar que se
cuenta con el acceso a ella en la aplicación T-Guide.
178
T-Guide-002 Pruebas de auto-identificación
Objetivo
Verificar que la captura y decodificación de una imagen con un código de barras
se lleve a cabo exitosamente. Asimismo comprobar que la lectura de tarjetas RFID
en cercanía al lector RFID se realiza de una forma correcta.
Entorno de prueba
elementos:
Computadora.
Teléfono móvil con sistema operativo Android.
API ZXing 1.2.
Imagen con código de barras impreso y legible.
T-Guide-002-001 Captura y decodificación del código de barras
Objetivo
Capturar una imagen, mediante la cámara inmersa en el dispositivo móvil,
que contenga un código de barras, decodificar la imagen y obtener el
identificador asociado al código.
Entorno de prueba
La prueba se llevará a cabo utilizando el dispositivo móvil y la API ZXing
para la decodificación del código de barras, además de la cámara
fotográfica que incluida en el dispositivo.
Proceso
1. Iniciar la captura de la imagen mediante la cámara fotográfica del
dispositivo móvil.
2. Capturar la imagen con el código de barras impreso.
3. Observar los resultados.
Resultados
Obtener el identificador asociado a un código de barras mediante la captura
y decodificación utilizando el software T-Guide.
T-Guide-002-002 Obtención de las tarjetas RFID en cercanía
Objetivo
Obtener los identificadores de las tarjetas RFID en cercanía al dispositivo
móvil mediante la conexión a un lector de tarjetas RFID.
179
Entorno de prueba
La prueba se llevará a cabo utilizando el dispositivo móvil, una computadora
y un lector de tarjetas RFID con conexión al puerto USB.
Proceso
1. Iniciar alguna tarea que involucre la lectura mediante RFID.
2. Observar los resultados obtenidos.
Resultados
Obtener el identificador asociado a las tarjetas RFID en cercanía al lector
RFID mediante el software T-Guide.
T-Guide-003 Pruebas de localización y guiado del dispositivo móvil
Objetivo
Verificar que la localización del dispositivo móvil se realiza de una forma acertada.
Asimismo que en la tarea de guiado se lleve a cabo de una forma correcta
mostrando la posición del dispositivo en todo momento.
Entorno de prueba
elementos:
Computadora.
Manejador de bases de datos PostgreSQL iniciado.
T-Guide-003-001 Localización del dispositivo móvil por RFID
Objetivo
Obtener la ubicación del dispositivo móvil en una posición donde existen
tarjetas RFID en cercanía.
Entorno de prueba
La prueba se llevará a cabo utilizando el dispositivo móvil, una computadora
y un lector de tarjetas RFID con conexión al puerto USB. Asimismo, es
necesario que el servidor de tareas esté corriendo en forma de un bundle
en Apache Felix y que el manejador de bases de datos PostgreSQL esté en
ejecución con la base de datos de las ubicaciones activa. Previo a esto se
deben haber verificado las pruebas de configuración y conexión y de autoidentificación.
180
Proceso
1. Iniciar los servidores (PostgreSQL, Apache Felix y el servidor de tareas).
2. Iniciar la tarea de guiado en interiores por RFID.
3. Observar y verificar que el resultado de la posición actual sea el
correcto.
Resultados
Se espera que la ubicación actual del dispositivo se despliegue en pantalla
y sea la localización correcta.
T-Guide-003-002 Localización del dispositivo móvil por QRCodes
Objetivo
Obtener la ubicación del dispositivo móvil mediante la captura y
decodificación de un código de barras.
Entorno de prueba
La prueba se llevará a cabo utilizando el dispositivo móvil. Asimismo, es
necesario que el servidor de tareas esté corriendo en forma de un bundle
Proceso
2. Iniciar la tarea de guiado en interiores por QRCodes.
3. Observar y verificar que el resultado de la posición actual sea el
correcto.
Resultados
Se espera que la ubicación actual del dispositivo se despliegue en pantalla
y sea la localización correcta.
T-Guide-003-003 Guiado del dispositivo móvil
Objetivo
Guiar al dispositivo móvil desde su posición actual al destino, actualizando
constantemente su posición utilizando la tecnología RFID o QRCodes.
Entorno de prueba
La prueba se llevará a cabo utilizando una computadora, un dispositivo
móvil y un lector de tarjetas RFID con conexión al puerto USB. Asimismo,
es necesario que el servidor de tareas esté corriendo en forma de un bundle
181
Proceso
2. Iniciar la tarea de guiado en interiores (por RFID o por QRCodes).
3. Se obtiene la posición actual por RFID o QRCodes (ver T-Guide-003001 y T-Guide-009-002).
4. Seleccionar el destino hacia el que se guiará.
5. Ir hacia el destino mostrado en el dispositivo, verificar que se refresque
la posición del dispositivo.
6. Observar y verificar los resultados.
Resultados
Se espera que el dispositivo móvil sea guiado de forma correcta y que se
refresque en todo momento la posición del dispositivo T-Guide 003-002.
T-Guide-004 Pruebas de administración de tareas
Objetivo
Verificar que la administración de las tareas (consulta, completar/cancelar y nueva
tarea) se lleven a cabo de forma exitosa.
Entorno de prueba
elementos:
Computadora.
T-Guide-004-001 Invocación del servicio Web para la obtención de un listado
de tareas pendientes
Objetivo
Obtener una lista de las tareas pendientes que tiene un usuario en
especifico a través de la conexión entre el cliente con el software T-Guide
mediante HTTP con el servidor de tareas, el cual ofrece un servicio Web.
Entorno de prueba
La prueba se llevará a cabo utilizando una computadora y un dispositivo
móvil. Asimismo, es necesario que el servidor de tareas esté corriendo en
forma de un bundle en Apache Felix y que el manejador de bases de datos
182
PostgreSQL esté en ejecución con la base de datos de tareas activa. Previo
a esto se deben haber verificado las pruebas de configuración y conexión.
Proceso
2. Iniciar la aplicación T-Guide.
3. Elegir el listado de tareas pendientes.
4. Observar y verificar los resultados obtenidos.
Resultados
Se espera que el listado de tareas pendientes que se visualice en el
dispositivo cliente a través del software T-Guide sea el correcto, es decir,
que sean las tareas activas pertenecientes al usuario que realiza la
consulta.
T-Guide-004-002 Invocación del servicio Web para completar/cancelar una
tarea
Objetivo
Desactivar una tarea pendiente, ya sea cancelándola o completándola, a
través de la conexión entre el cliente con el software T-Guide mediante
HTTP con el servidor de tareas, el cual ofrece el servicio Web.
Entorno de prueba
a esto se deben haber verificado las pruebas de configuración y conexión.
Proceso
4. Elegir la tarea que se desea completar/cancelar.
5. Completar o cancelar la tarea.
Resultados
Se espera que la operación de cancelación o completitud se realice
exitosamente para la tarea elegida y que esto se refleje en el listado de
tareas pendientes, es decir, que esta tarea desaparezca de dicho listado.
183
T-Guide-004-003 Invocación del servicio Web para el almacenamiento de una
nueva tarea del usuario
Objetivo
Establecer una nueva tarea como pendiente para el usuario que la crea a
través de la conexión entre el cliente con el software T-Guide mediante
HTTP con el servidor de tareas, el cual ofrece el servicio Web.
Entorno de prueba
a esto se deben haber verificado las pruebas de configuración, conexión y
de auto-identificación.
Proceso
4. Elegir nueva tarea.
5. Elegir la actividad a la que pertenece.
6. Elegir el tipo de tarea.
7. Elegir el recurso al que se asociará la tarea (Por barras o introduciendo
el identificador).
8. Elegir guardar la tarea.
Resultados
Se espera que el almacenamiento de la nueva tarea se realice
exitosamente con el recurso asociado elegido y que esto se refleje en el
listado de tareas pendientes, es decir, que esta tarea aparezca en dicho
listado.
T-Guide-004 Pruebas de administración de la información de la base de
datos
Objetivo
Verificar que la información de la base de datos se almacena, se c onsulta, se
elimina y se modifica de forma correcta manteniendo la integridad de la
información y se obtiene lo que se pide en cada caso.
184
Entorno de prueba
elementos:
Computadora.
Apache Tomcat iniciado
Aplicación Web de tareas iniciada.
T-Guide-005-001 Administración de la información de los usuarios
Objetivo
Verificar que el módulo de administración de usuarios, en donde se
consulta, se modifica, se eliminan y se insertan grupos y usuarios se lleve a
cabo de forma exitosa.
Entorno de prueba
La prueba se llevará a cabo utilizando una computadora. Asimismo, es
necesario que el servidor de aplicaciones Apache Tomcat esté corriendo y
que el manejador de bases de datos PostgreSQL esté en ejecución con la
base de datos de tareas activa.
Proceso
1. Iniciar los servidores (PostgreSQL y Apache Tomcat).
2. Iniciar la aplicación Web de tareas.
3. Realizar operaciones de modificación, consulta, eliminación e inserción
de grupos y usuarios.
Resultados
Se espera que las operaciones realizadas de consulta, modificación,
eliminación e inserción se lleven a cabo de forma exitosa y que los datos
arrojados sean los correctos.
T-Guide-005-002 Administración de la información de los recursos
Objetivo
Verificar que el módulo de administración de recursos, en donde se
consulta, se modifica, se eliminan y se insertan recursos y tipos de recursos
se lleve a cabo de forma exitosa.
Entorno de prueba
185
Proceso
de recursos y tipos de recursos.
Resultados
T-Guide-005-003 Administración de la información de ubicaciones
Objetivo
Verificar que el módulo de administración de ubicaciones, en donde se
consulta, se modifica, se eliminan y se insertan campus, edificios, planos y
ubicaciones se lleve a cabo de forma exitosa.
Entorno de prueba
Proceso
de campus, edificios, planos y ubicaciones.
Resultados
T-Guide-005-004 Administración de la información de tareas
Objetivo
Verificar que el módulo de administración de tareas, en donde se consulta,
se modifica, se eliminan y se insertan actividades y tareas se lleve a cabo
de forma exitosa.
186
Entorno de prueba
Proceso
de actividades y tareas.
Resultados
T-Guide-005-005 Administración de la información de tareas de los usuarios
Objetivo
Verificar que el módulo de administración de tareas de los usuarios, en
donde se consulta, se modifica, se eliminan y se insertan actividades y
tareas se lleve a cabo de forma exitosa.
Entorno de prueba
Proceso
de tareas de los usuarios.
Resultados
187
Referencias
[STEINIGER 2006]
Steiniger Stefan Neun Moritz, Alistair Edwardes. ―Foundations of
Location Based Services‖. Zurich, Suiza : Departamento de Geografía,
Universidad de Zurich, Suiza, 2006.
[GUERRA 2007]
Ruiz Guerra Lirio. ―API SMS para el procesamiento de consultas
Georeferenciadas / No georeferenciadas‖. Cuernavaca, Morelos:
Cenidet, 2007.
[QUIÑONEZ 2007]
Quiñonez Bernardino, Pedro. ―Gateway SMS Pull para Servicios
Basados en Localización con una Arquitectura de Servicios Web‖.
Cuernavaca, Morelos: Cenidet, 2007.
[BERNARDOS 2003]
Bernardos Barbolla Ana M. ―Servicios Móviles de localización‖. España:
ceditec, 2003
[MARTINEZ 2005]
Martínez Gens Luis E. y Urios de las Heras Mercedes. ―Tecnologías de
Localización y Posicionamiento para Servicios Basados en Localización
(LBS)‖. España, 2005.
[DRANE 1998]
C. Drane M. Macnaughtan, and C. Scott. ―Positioning GSM‖. IEEE
Communications Magazine, 1998. - Vol. 36.
[ESCALONA 2007]
Escalona I. Martin y Arroyo F. Barcelo. ―Estudio de disponibilidad de
medidas de localización en redes celulares urbanas‖. Madrid, España:
IEEE LATIN AMERICA TRANSACTIONS, 2007. - 6 : Vol. 5.
[LEE 2001]
Lee D.J.Y y Lee W.C.Y. ―Optimize CDMA System Capacity with
Location‖. IEEE PIMRC, 2001.
[CASAR 2007]
Casar Corredera José Ramón y López Molina José Manuel.
―Integración de comunicaciones, localización y provisión inteligente de
contenido: arquitectura para servicios moviles móviles emergentes.
(COLOCAME)‖. Madrid, España : Jornada de Seguimiento de
Proyectos en Tecnologías de Servicios de la Sociedad de la
Información, 2007.
[BELLAVISTA 2006]
Bellavista Paolo y Cinque Marcelo. ―Integrated Support for Handoff
Management and Context Awareness in Heterogeneus Wireless
Networks‖. Grenoble, Francia, 2006.
[PANDEY 2006]
Pandey Santosh y Agrawal Prathima. ―A survey on localization
techniques for wireless networks‖. Auburn, AL : Electrical and Computer
Engineering Auburn University, 2006.
[KAVITHA 2006]
Muthukrishnan Kavitha. ―WLAN location sharing through a privacy
observant architecture‖. Holanda : University of Twente, Faculty of
Computer Science Computer Architecture Design and Test for
Embedded Systems group, 2006.
[FRIEDMAN 2006]
Friedman Roy y Kliot Gabriel. ―Location services in wireless Ad Hoc and
Hybrid networks: A survey‖. Haifa, Israel : Department of Computer
Science Technion, 2006.
189
[VARSHAVSKY 2007]
Varshavsky Alex. ―The SkyLoc Floor Localization System‖. Toronto,
US : University of Toronto, 2007.
[CHOI 2006]
Choi Youngkyu and Choi Sunghyun. ―Service Charge and EnergyAware Vertical Handoff in Integrated‖. IEEE [Journal] 2006.
[UBICACEL 2008]
Iusacell. Servicio Ubicacel de Iusacell. Cunsultado el 8 de abril de 2008
de http://www.iusacell.com.mx.
[LOCALIZAME 2008]
Telefónica Movistar. Servicio Localízame de Movistar. Consultado el 8
de
abril
de
2008
de
http://www.movistar.com.mx/servicios/serv_loca.html.
[AVL REACH 2008]
Telcel. AVL Reach / U Localización y Administración Vehicular Telcel.
Consultado el 8 de abril de 2008 de http://www.telcel.com/.
[SKYHOOK 2008]
Skyhook. Skyhook Wireless. Consultado el 23 de junio de 2008 de
http://www.skyhookwireless.com.
[TRAMIGO 2008]
Tramigo. Localizador GPS GSM más avanzado. Consultado el 23 de
junio de 2008 de http://www.tramigo.net/spa/default.asp.
[GONZALEZ 2003]
González Castaño F. J. y García Reinoso J. ―Survivable Bluetooth
Location Networks‖. Anchorage, EEUU : IEEE International Conference
of Communications, 2003. - 1 : Vol. 1.
[MOUSTAFA 2005]
Youssef Moustafa y Agrawala Ashok. ―Location-clustering techniques
for WLAN location determination systems‖. Maryland, Virginia :
University of Maryland at College Park, 2005. - 1 : Vol. I.
[FISHER 1998]
S. Fischer, H. Grubeck, A. Kangas, H. Koorapaty, E. Larsson, P.
Lundqvist, ―Time of Arrival Estimation of Narrowband TDMA Signals for
Mobile Positioning‖ Personal Indoor and Mobile Radio Communications,
1998.
[RADAR 2000]
Paramvir Bahl and Venkata N. Padmanabhan. (2000). ―RADAR: An InBuilding RF-based User Location and Tracking System‖. INFOCOM
2000. Nineteenth Annual Joint Conference of the IEEE Computer and
Communications Societies. Proceedings. IEEE.
[WIPS 2000]
―Wireless
Indoor
http://csd.ssvl.kth.se/2000/group12/
Positioning
System‖,
[FERSCHA 2001]
Ferscha Alois, Beer Wolfgang, Narzt Wolfgang. (2001). ―Location
Awareness in Community Wireless LANs‖.
[HIGHTOWER 2001]
Hightower, J. & Borriello, G. (2001), “Location Systems for Ubiquitous
Computing”, IEEE Computer 34(8), 57--66.
[HALLBERG 2003]
[LIONEL 2004]
J. Hallberg, M. Nilsson, K. Synnes, ―Bluetooth Positioning‖. (2003)
Lionel M. Ni, Yunhao Liu, Yiu Cho Lau and Abhishek P. Patil.
―LANDMARC: Indoor Location Sensing Using Active RFID‖. Department
of Computer Science, Hong Kong University of Science and
Technology, Clearwater Bay, Kowloon, Hong Kong, China. Ed. Springer
Netherlands 2004.
190
[HORUS 2004]
[WEISSMAN 2004]
Moustafa A. Youssef, Ashok Agrawala. (2004). ―The Horus WLAN
location determination system‖. Department of Computer Science,
University of Maryland, 2004.
Z. Weissman, ―Indoor Location‖. (2004)
[CANO 2006]
Juan-Carlos Cano, Pietro Manzoni and C.-K. Toh. ―UbiqMuseum: A
Bluetooth and Java Based Context-Aware System for Ubiquitous
Computing‖. Polytechnic University of Valencia, University of Hong
Kong, Hong Kong, China. Ed. Springer Netherlands 2006.
[MILLER 2006]
L. E. Miller, ―Indoor Navigation for First Responders: A Feasibility
Study‖. Feb. 2006
[GAYATHRI 2007]
Gayathri Chandrasekaran, Mesut Ali Ergin, Marco Gruteser, Richard P.
Martin. (2007). ―Bootstrapping a Location Service through Geocoded
Postal Addresses‖. Lecture Notes in Computer Science, 2007.
[GIUSTINIANO 2007]
Domenico Giustiniano, Francesca Lo Piccolo, Nicola Blefari Melazzi.
(2007). ―Relative Localizacion in 802.11/GPS systems‖. Satellite and
Space Communications, 2007. IWSSC '07. International Workshop on.
[CAALIX 2007]
Maged N Kamel Boulos, Artur Rocha, Angelo Martins, Manuel Escriche
Vicente, Armin Bolz, Robert Feld, Igor Tchoudovski, Martin Braecklein,
John Nelson, Gearóid Ó Laighin, Claudio Sdogati, Francesca Cesaroni,
Marco Antomarini, Angela Jobes and Mark Kinirons. (2007). ―CAALIX:
Complete Ambient Asisted Living Experiment‖. International Journal of
Health Geographics 2007.
[MOUSTAFA 2007]
Moustafa A. Youssef, Ashok Agrawala. (2007). ―Analysis of the optimal
strategy for WLAN location determination systems‖. International
Journal of Modeling And Simulation, 2007.
[TITICA 2007]
Titica, D. Fratu, O. Stanescu, E. Halunga-Fratu, S. (2007). ―Simple
Location-based Application Development for Mobile Phones‖.
Telecommunications in Modern Satellite, Cable and Broadcasting
Services, 2007. TELSIKS 2007. 8th International Conference on.
[TESORIERO 2008]
R. Tesoriero, J. A. Gallud, M. Lozano, V. M. R. Penichet. ―A Locationaware System using RFID and Mobile Devices for Art Museums‖.
Computer Systems Department Universidad de Castilla-La Mancha
[RAMES 2005]
Rodríguez Ramés ―Estructura de paquetes‖ Revista Software Guru.
Marzo - Abril 2005
[ZXING 2009]
Multi-format 1D/2D barcode image processing library with clients for
Android, Java, and iPhone. Consultado el 15 de noviembre de 2008 de
http://code.google.com/p/zxing/
[STD829]
Software Engineering Technical Committee of the IEEE Computer
Society.
IEEE Standard for Software Test Documentation. Disponible en:
http://www.ucsc.cl/~marciam/weblog/images/ieeestd8291998standardtest_documentation.pdf. Última consulta: Febrero 2009
[FELIX 2009]
Apache, Documentación de apache Felix. Consultado en enero de
191
2009 de http://felix.apache.org/site/index.html
[RESTLET 2009]
Noelios Technology, Documentación de Restlet. Consultado en enero
de 2009 de http://www.restlet.org/documentation/
[ANDROID 2008]
Android developers, Documentación de Android. Consultado en
diciembre de 2008 de http://developer.android.com/guide/index.html
[JSON 2009]
Android developers, Documentación de Android. Consultado en enero
de 2009 de http://developer.android.com/reference/org/json/packagesummary.html
[HTTP 2009]
Android developers, Documentación de Android. Consultado en enero
de
2009
de
http://developer.android.com/reference/org/apache/http/packagesummary.html
[ECLIPSE 2008]
Eclipse, Documentación de eclipse Ganymede. Consultado en
diciembre de 2008 de http://help.eclipse.org/ganymede/index.jsp
[BELLAVISTA 2008]
Bellavista, P.; Küpper, A. & Helal, S. (2008), ―Location-Based Services:
Back to the Future‖, IEEE Pervasive Computing 7(2), 85-89.
[OPEN 2009]
Open Handset Alliance, ―Android, Official Website‖. Última consulta 12
de mayo de 2009 de http://www.android.com/about/.
[OSGI 2009]
OSGi Alliance, “OSGi – The Dynamic Module System for Java”. Última
consulta 12 de mayo de 2009 de http://www.osgi.org/Main/HomePage
[COFETEL 2009]
COFETEL, ―Estadísticas de Portabilidad‖. Última consulta mayo de
2009
de
http://www.cft.gob.mx/wb/Cofetel_2008/estadisticas_de_portabilidad.
[JSON 2009]
JSON, ―Introducción a JSON‖. Última consulta 13 de mayo de 2009 de
http://www.json.org/json-es.html.
[EMCA 2009]
ECMA, ―Estándar ECMA-262‖. Última consulta 13 de mayo de 2009 de
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma262.pdf
[GINER 2009]
Giner, P.; Cetina, C.; Fons, J. & Pelechano, V. (2009), Presto: A
pluggable platform for supporting user participation in Smart Workflows,
in 'MobiQuitous'.
[NFC 2009]
Wikipedia la enciclopedia libre, ―NFC‖. Última consulta mayo de 2009
de http://es.wikipedia.org/wiki/Near_Field_Communication.
[JINI 2009]
Sun Microsystem, ―Jini‖. Última consulta febrero de 2009 de
http://www.jini.org/wiki/Main_Page.
[UPNP 2009]
[CRICKET 2001]
UPnP, ―UPnP Forum‖.
http://www.upnp.org/.
Última
consulta
febrero
de
2009
de
Nissanka B. Priyantha, ―The cricket location-support system‖.
International conference on mobile computing and networking, Boston,
Massachusetts, US. 2001.
192

3 Capítulo 3 Marco teórico Capítulo 3 Marco teórico

Transcription

Similar documents

EN1007M - Engeldroid

¿Cómo Puedo Ser Salvo?

Metodología

CATÁLOGO EN PDF Descarga nuestro

primavera p6 - Monografias.com

Diseño e implementación de una aplicación móvil para trabajo

Presentación de PowerPoint

Unidad 3

Soluciones de Movilidad

CONDOMS

Persianas automáticas - Domotique | Sistemas Inteligentes