Servicios de localización conscientes del contexto aplicando perfiles de movilidad y tecnologías...

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”

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

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

“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

DDeeddiiccaattoorriiaa

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.

AAggrraaddeecciimmiieennttooss 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!

RReessuummeenn

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 auto-

identificación, utilizando RFID y QRCodes.

AAbbssttrraacctt

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.

i

TTaabbllaa ddee ccoonntteenniiddoo

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

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

2 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

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

3 Capítulo 3 Marco teórico ________________________________________________ 31

ii

3.1 Plataformas de dispositivos móviles ________________________________________ 33 3.1.1 Windows Mobile ___________________________________________________________ 33 3.1.2 Symbian __________________________________________________________________ 33 3.1.3 J2ME ____________________________________________________________________ 33 3.1.4 iPhone OS ________________________________________________________________ 33 3.1.5 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

iii

4.2.6.2 Paquete mx.edu.cenidet.xmlread ________________________________________ 103

5 Capítulo 5 Implementación _____________________________________________ 105

5.1 Detalles tecnológicos ___________________________________________________ 107 5.1.1 Cliente __________________________________________________________________ 107 5.1.2 Servidor _________________________________________________________________ 108 5.1.3 Aplicación Web de gestión de tareas __________________________________________ 108

5.2 Interacción del sistema cliente-servidor ____________________________________ 108 5.2.1 Autenticación del usuario ___________________________________________________ 108 5.2.2 Consulta de tareas pendientes _______________________________________________ 110 5.2.3 Completar/Cancelar una tarea _______________________________________________ 111 5.2.4 Nueva tarea (establecer una tarea como pendiente) ______________________________ 113 5.2.5 Tarea de guiado por RFID ___________________________________________________ 115 5.2.6 Tarea de guiado por QRCodes ________________________________________________ 117

5.3 Interacción de la aplicación Web__________________________________________ 119 5.3.1 Administración de usuarios __________________________________________________ 120 5.3.2 Administración de recursos __________________________________________________ 121 5.3.3 Administración de ubicaciones _______________________________________________ 122 5.3.4 Administración de tareas ____________________________________________________ 124 5.3.5 Administración de tareas de los usuarios _______________________________________ 125

6 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

7 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

iv

LLiissttaaddoo ddee ffiigguurraass 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

v

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

vi

LLiissttaaddoo ddee ttaabbllaass 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 14 Caso de prueba T-Guide-001-002 __________________________________________________ 130 Tabla 15 Caso de prueba T-Guide-001-003 __________________________________________________ 131 Tabla 16 Caso de prueba T-Guide-002-001 __________________________________________________ 132 Tabla 17 Caso de prueba T-Guide-002-002 __________________________________________________ 133 Tabla 18 Caso de prueba T-Guide-003-001 __________________________________________________ 134 Tabla 19 Caso de prueba T-Guide-003-002 __________________________________________________ 135 Tabla 20 Caso de prueba T-Guide-003-003 __________________________________________________ 136 Tabla 21 Caso de prueba T-Guide-004-001 __________________________________________________ 138 Tabla 22 Caso de prueba T-Guide-004-002 __________________________________________________ 139 Tabla 23 Caso de prueba T-Guide-004-003 __________________________________________________ 140 Tabla 24 Caso de prueba T-Guide-005-001 __________________________________________________ 142 Tabla 25 Caso de prueba T-Guide-005-002 __________________________________________________ 144 Tabla 26 Caso de prueba T-Guide-005-003 __________________________________________________ 147 Tabla 27 Caso de prueba T-Guide-005-004 __________________________________________________ 152 Tabla 28 Caso de prueba T-Guide-005-005 __________________________________________________ 154 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

vii

GGlloossaarriioo ddee ttéérrmmiinnooss yy ssiiggllaass 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 cliente-servidor.

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

viii

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 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).

SMS 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.

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.


3

11..11 IInnttrroodduucccciióónn 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.


4

Figura 1.1 Tecnologías inalámbricas

11..22 AAnntteecceeddeenntteess ddeell pprrooyyeeccttoo 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


5

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.

11..33 DDeessccrriippcciióónn ddeell pprroobblleemmaa

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


6

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.

11..44 OObbjjeettiivvooss ddeell pprrooyyeeccttoo 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. Realizar una prueba de concepto, implementación y modelo mediante un sistema de localización consciente del contexto.

ii. 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.

iii. Contribuir al desarrollo de los servicios móviles y ubicuos, estudiando y analizando las tecnologías de comunicaciones, su interoperabilidad, aplicaciones y limitaciones.

iv. 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


7

momento preciso (conciencia del contexto), teniendo en cuenta la ubicación del usuario.

v. Hacer uso de la metodología orientada a componentes con el fin de hacer

reutilizable la aplicación.

11..55 JJuussttiiffiiccaacciióónn yy bbeenneeffiicciiooss ddeell pprrooyyeeccttoo

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


8

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.

11..66 AAllccaanncceess yy lliimmiittaacciioonneess ddeell pprrooyyeeccttoo 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.

11..77 OOrrggaanniizzaacciióónn ddeell ddooccuummeennttoo

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.


9

ii. 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.

iii. 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.

iv. 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.

v. Capítulo 6: Pruebas. Se presentan los resultados de las pruebas.

vi. Capítulo 7: Conclusiones. Se presentan las aportaciones de la tesis, los trabajos futuros y las publicaciones realizadas durante el desarrollo de la tesis.

vii. 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.

viii. Anexo B: Plan de pruebas. Describe el plan de pruebas basado en el IEEE std 829.

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

13

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.

22..11 SSiimmppllee LLooccaattiioonn--bbaasseedd AApppplliiccaattiioonn DDeevveellooppmmeenntt ffoorr MMoobbiillee

PPhhoonneess [[TTIITTIICCAA 22000077]] 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


14

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 la 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.


15

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.

22..22 RRAADDAARR:: AAnn IInn--BBuuiillddiinngg RRFF--bbaasseedd UUsseerr LLooccaattiioonn aanndd TTrraacckkiinngg

SSyysstteemm [[RRAADDAARR 22000000]]

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).


16

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 si’ 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.


17

22..33 TThhee HHoorruuss WWLLAANN llooccaattiioonn ddeetteerrmmiinnaattiioonn ssyysstteemm [[HHOORRUUSS

22000044]]

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.


18

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.

22..44 CCAAAALLIIXX CCoommpplleettee AAmmbbiieenntt AAssssiisstteedd LLiivviinngg EExxppeerriimmeenntt

[[CCAAAALLIIXX 22000077]] 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.


19

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.


20

No maneja consciencia del contexto ni auto-identificación.

22..55 LLooccaattiioonn AAwwaarreenneessss iinn CCoommmmuunniittyy WWiirreelleessss LLAANNss [[FFEERRSSCCHHAA

22000011]] 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.

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.

Recolección de información geográfica

Recolección de proximidad espacial

Determinación de la posición


21

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]


22

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.

22..66 UUbbiiqqMMuusseeuumm:: AA BBlluueettooootthh aanndd JJaavvaa BBaasseedd CCoonntteexxtt--AAwwaarree

SSyysstteemm ffoorr UUbbiiqquuiittoouuss CCoommppuuttiinngg [[CCAANNOO 22000066]] 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:


23

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.


24

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.


25

22..77 AA LLooccaattiioonn--aawwaarree SSyysstteemm uussiinngg RRFFIIDD aanndd MMoobbiillee DDeevviicceess ffoorr

AArrtt MMuusseeuummss [[TTEESSOORREEIIRROO 22000088]]

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.


26

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.

22..88 CCoommppaarraattiivvaa ddeell eessttaaddoo ddeell aarrttee ccoonn eell pprrooyyeeccttoo 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


27

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

Proyecto Método

Posición Envío de

datos Consciencia de contexto

Guiado Múltiples

tareas

Utilizado en

celulares

Manejo de

mapas

Error (m)

[Radar 2000] WiFi HTTP <15

[Fers 2001] WiFi, RFID

activo HTTP, GPRS

<1.5

[Horus 2004] WiFi HTTP <9.5

[Cano 2006] Bluetooth Bluetooth <5

[Titi 2007] GSM GPRS <500

[Caalix 2007] GPS GPRS No

aplica

[Teso 2008] RFID activo

y pasivo HTTP <1

Tesis RFID y

QRCodes HTTP <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.

22..99 SSeerrvviicciioo UUBBIICCAACCEELL ddee iiuussaacceellll [[UUBBIICCAACCEELL 22000088]] 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.

22..1100 SSeerrvviicciioo LLooccaallíízzaammee ddee MMoovviissttaarr [[LLOOCCAALLIIZZAAMMEE 22000088]]

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.


28

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.

22..1111 AAVVLL RReeaacchh UU // LLooccaalliizzaacciióónn yy AAddmmiinniissttrraacciióónn VVeehhiiccuullaarr TTeellcceell

[[AAVVLL RREEAACCHH 22000088]] 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.

22..1122 TTrraammiiggoo [[TTRRAAMMIIGGOO 22000088]]

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.

22..1133 SSkkyyhhooookk WWPPSS [[SSKKYYHHOOOOKK 22000088]] 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.


29

Tabla 2 Comparativa de los servicios de localización

Nombre Posicionamiento Envío

de datos

Indep. de red

Consciencia de contexto

Múltiples tareas

Servicio UBICACEL de Iusacell

Técnicas híbridas GSM y GPS

SMS

Servicio localízame de Movistar

Basada en red SMS

AVL Reach U / Localización y administración vehicular

Técnicas hibridas GSM y GPS

SMS, GPRS

Tramigo GPS SMS, GPRS

Skyhook WPS Wi Fi GPRS

Tesis RFID, QRCodes HTTP 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.

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

33

33..11 PPllaattaaffoorrmmaass ddee ddiissppoossiittiivvooss mmóóvviilleess

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.


34

33..22 RREESSTT ((RReepprreesseennttaattiioonnaall SSttaatteeTTrraannssffeerr)) 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.

33..33 JJSSOONN 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


35

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 hash1, 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.

33..44 OOSSGGii 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.

33..55 SSeerrvviicciiooss bbaassaaddooss eenn llooccaalliizzaacciióónn ((LLBBSS)) 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

2 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


36

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.


37

33..66 TTééccnniiccaass ddee ppoossiicciioonnaammiieennttoo 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].

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.

Técnicas de posicionamiento

Redes WAN

GSM

GPS

Redes LAN

Bluetooth

Wi Fi

Infrarrojos

RFID

Banda Ultra-ancha


38

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.


39

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


40

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.


41

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.

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.


45

44..11 AAnnáálliissiiss 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.

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.

Consulta de tareas

pendientes

Nueva tarea

Completar tarea

URI recurso Enviar

petición

Recibir

petición

Realizar

consulta

Formatear

resultados

Enviar

resultados Recibir

resultados

Interpretar resultados

Mostrar resultado

s

Obtener ubicación

Leer punto de referencia


46

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).

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 de uso:

Consultar tareas pendientes.

Actores Dispositivo cliente, Servidor.

Descripción: Permite consultar las tareas pendientes que tiene el usuario mediante la conexión con el servidor y la verificación del contexto.

CU-1 Consultar

tareas pendientes

Dispositivo cliente

CU-1.1 Verificar

Contexto

«extends»

CU-1.2 Listado de

tareas pendientes

«uses»

Servidor

Dispositivo cliente

CU-1 Consultar

tareas pendientes

CU-2 Alta de tarea

CU-3 Completar

tarea

CU-4 Cancelar tarea

Servidor


47

Precondiciones:

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.

Postcondiciones: 1. Se obtendrá un listado de tareas pendientes que serán

mostradas en el dispositivo cliente.

Escenario de éxito 1:

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.

4. El dispositivo cliente visualiza el listado de tareas. 5. Terminar el proceso.

Incluye: CU-1.1 Verificar contexto, CU-1.2 Listado de tareas pendientes.

Suposiciones: Se supone que el cliente tiene acceso a una conexión HTTP.

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.


Listado de tareas pendientes.

Buscar recursos en cercanía (RFID o barras)

Verificar

contexto

Conectar con el servidor

Obtener un listado de tareas pendientes

SiNo


48


Descripción: Despliega un listado tareas pendientes que tiene el usuario.

Precondiciones:

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.

Postcondiciones: 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.

Incluye:


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.

Conectar con el servidor

Obtener un listado de tareas pendientes

Hay tareasSiNo

Informar que no existen tareas


49

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



Verificar contexto.


Descripción: Permite que el dispositivo monitoreé su alrededor en busca de recursos que estén asociados a una tarea.

Precondiciones:

1. El dispositivo cliente debe tener acceso a un lector de tarjetas RFID, ó

2. El dispositivo cliente debe tener una cámara fotográfica incluida. 3. El usuario debe haber accedido a la aplicación y haberse

autentificado. Postcondicion

es: 1. Se obtendrá un listado de recursos en cercanía, los cuales se

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. 3. Se envían los identificadores de los recursos encontrados al

servidor. 4. Terminar el proceso.


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. 3. Se decodifica el código de barras obteniendo un identificador del

recurso. 5. Se envía el identificador del recurso encontrado al servidor. 4. Terminar el proceso.

Incluye: CU-1.1.1 Consultar por RFID, CU-1.1.2 Consultar por barras, CU-1.1.3 Obtener ubicación.

Suposiciones: Se supone que el cliente tiene acceso a un lector RFID y a una cámara fotográfica y que la fotografía capturada corresponde a un código de barras.

CU-1.1 Verificar

Contexto

CU-1.1.1 Consultar

por RFIDCU-1.1.2 Consultar

por Barras

«extends»

«extends»CU-1.1.3 Obtener

ubicación

«extends»

Dispositivo clienteServidor


50

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 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la figura 4.8.


Consultar por RFID.


Descripción: Permite que el dispositivo monitoreé su alrededor en busca de tarjetas RFID al alcance.

Precondiciones:

1. El dispositivo cliente debe tener acceso a un lector de tarjetas RFID.

2. El dispositivo cliente tiene acceso mediante HTTP al servidor. 3. El usuario previamente ha ingresado a la aplicación y ha sido

autentificado.

Postcondiciones: 1. Se obtendrán todos los recursos que se encuentren en cercanía

al dispositivo cliente.

Escenario de éxito:

1. Se inicia la conexión con el lector de tarjetas RFID. 2. Se obtienen los identificadores de los recursos en cercanía. 3. Se envían los identificadores de los recursos encontrados al

servidor. 4. Terminar el proceso.

Escenario de fracaso 1:

1. Iniciar la conexión con el lector de tarjetas RFID. 2. Ocurre un error en la conexión. 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. 3. No hay tarjetas RFID en cercanía. 4. Indicar que no se obtuvieron los datos. 5. Terminar proceso.

Conectar con cámara fotográfica

Código de

barras

Conectar con el lector RFID

Obtener los identificadores en cercanía

SiNo

Obtener fotografía de código de barras

Decodificar fotografía (código de barras)Enviar información al servidor


51

Incluye:

Suposiciones: Se supone que el dispositivo cliente tiene acceso a un servidor por medio de HTTP.

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



Consultar por barras.


Descripción: Permite que el dispositivo tome una fotografía y decodifique la imagen si tiene un código de barras.

Precondiciones:

1. El dispositivo cliente debe tener acceso a una cámara fotográfica. 2. El dispositivo cliente tiene acceso mediante HTTP al servidor. 3. El usuario debe haber accedido a la aplicación y haberse

autentificado.

Postcondiciones: 1. Se decodificará la imagen que contiene un código de barras.

Escenario de éxito:

1. Se inicia la conexión con la cámara fotográfica. 2. Capturar imagen correspondiente al código de barras. 3. Convertir imagen capturada a monocromática. 4. Decodificar imagen capturada (código de barras). 5. Enviar información al servidor. 6. Terminar el proceso.


1. Iniciar la conexión con la cámara fotográfica. 2. Ocurre un error en la conexión.

Indicar que no se obtuvieron los datos

Conexión

establecida

Conectar con el lector RFID

Extraer identificadores de tarjetas RFID

Si

No

Enviar información al servidor

Extrajo

Si

No


52

3. Indicar que no fue posible decodificar la imagen. 4. Terminar proceso.


1. Iniciar la conexión con la cámara fotográfica. 2. Capturar la imagen. 3. Convertir imagen a monocromática. 4. 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. 6. Terminar proceso.

Incluye:

Suposiciones: Se supone que el dispositivo cliente tiene acceso a un servidor por medio de HTTP.

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



Obtener ubicación.

No fue posible decodificar

Conexión

establecida

Conectar con la cámara fotográfica

Convertir imagen a monocromática

Si

No

Enviar información al servidor

Decodificó

Si

No

Decodificar imagen

Capturar imagen


53


Descripción: Obtiene la ubicación actual del dispositivo utilizando RFID, Wi-Fi, Bluetooth, GPS o alguna técnica en GSM.

Precondiciones:

1. El dispositivo cliente tiene acceso mediante HTTP al servidor. 2. El usuario debe haber accedido a la aplicación y haberse

autentificado. Postcondicion

es: 1. Se obtendrá la localización del dispositivo.


1. Iniciar la conexión con el dispositivo GPS. 2. Se obtiene la lectura de datos del GPS. 3. Se obtiene la información de ubicación del dispositivo. 4. Terminar proceso.


1. Iniciar la conexión con el dispositivo GPS. 2. No se puede conectar con el dispositivo GPS. 3. Establecer conexión con el lector RFID. 4. Se leen las tarjetas RFID en cercanía. 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. 8. Terminar proceso.


1. Iniciar la conexión con el dispositivo GPS. 2. No se puede obtener información de ubicación del GPS. 3. Establecer conexión con el lector RFID. 4. No se puede conectar con el lector o no existen tarjetas RFID en

cercanía. 5. Establecer conexión con Bluetooth. 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. 9. Se obtiene la información de ubicación del dispositivo. 10. Terminar proceso.


1. Iniciar la conexión con el dispositivo GPS. 2. No se puede obtener información de ubicación del GPS. 3. Establecer conexión con el lector RFID. 4. No se puede conectar con el lector o no existen tarjetas RFID en

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. 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. 11. Se obtiene la información de ubicación del dispositivo. 12. Terminar proceso.


1. Iniciar la conexión con el dispositivo GPS. 2. No se puede obtener información de ubicación del GPS. 3. Establecer conexión con el lector RFID.


54

4. No se puede conectar con el lector o no existen tarjetas RFID en 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. 10. Se obtiene la información de ubicación del dispositivo. 11. Terminar proceso.

Incluye:

Suposiciones: Se supone que el dispositivo cliente tiene acceso a un servidor por medio de HTTP. Se supone además que el dispositivo cuenta al menos con conectividad GSM.

Figura 4.10 Diagrama de actividad del caso de uso CU-1.1.3 Obtener ubicación

Existe

conexión

Verificar conectividad GPS

Si

No

Si

No

Obtener ubicación

Conexión

establecida

Si

Establecer conexión con lector RFID

Leer tarjetas en cercanía

Se obtuvo

lectura

Enviar identificador al servidor

Establecer conexión Bluetooth

No

Obtener lectura de GPS

Se obtuvo

lectura

Si

No

B

A

C


55

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.

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


CU-2 Alta de tarea

Dispositivo cliente

CU-1.1 Verificar

Contexto

«extends»

Servidor

CU-2.1 Seleccionar

tarea de guiado

«extends»

Conexión

establecida

Verificar dispositivos en cercanía

Hay

dispositivos

Si

Si

Establecer conexión Wi-Fi

No

Conexión

establecida

Verificar dispositivos cercanos

Hay

dispositivosSi

Obtener información GSM

SiNo

No

B

C

A

No


56


Alta de tarea.

Actores Dispositivo cliente, Servidor Descripción: Permite al usuario registrar nuevas tareas.

Precondiciones:

1. El dispositivo cliente debe tener acceso al servidor por medio de internet.

2. El usuario debe haber ingresado y haber sido autentificado en la aplicación.

Postcondiciones: 1. Se creará una nueva tarea la cual se establecerá como

pendiente.


1. Seleccionar actividad. 2. Seleccionar tipo de tarea. 3. Seleccionar tarea. 4. Elegir recurso asociado. 5. Verificar contexto. 6. Establecer fecha de cumplimiento. 7. Almacenar tarea en servidor. 8. Establecer tarea como pendiente. 9. Terminar el proceso.


1. Seleccionar actividad. 2. Seleccionar tipo de tarea. 3. Seleccionar tarea. 4. Elegir recurso asociado. 5. Establecer fecha de cumplimiento. 6. Almacenar tarea en servidor. 7. Establecer tarea como pendiente. 6. Terminar el proceso.

Incluye: CU-1.1 Verificar contexto, CU-2.1 Seleccionar tarea de guiado.



57

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.

Figura 4.13 Diagrama del caso de uso CU-2.1 Seleccionar tarea de guiado

CU-2.1 Seleccionar

tarea de guiado

Dispositivo cliente

CU-1.1.3 Obtener

ubicación

«uses»

ServidorCU-2.1.1 Obtener

Ruta

«uses»


Verificar

contexto

Almacenar tarea en servidor

SiNo

Seleccionar Actividad

Seleccionar tipo de tarea

Seleccionar tarea

Elegir recurso asociado

Establecer tarea como pendiente

Establecer fecha de cumplimiento


58

Tabla 10 Descripción del caso de uso CU-2.1 Seleccionar tarea de guiado



Seleccionar tarea de guiado.


Descripción: Permite al usuario hacer una tarea de guiado.

Precondiciones:


2. El usuario debe haber accedido a la aplicación y haber sido autentificado.

Postcondiciones: 1. Se completará una tarea que se tenía establecida como

pendiente.


1. El usuario selecciona la tarea de guiado. 2. Se obtiene la ubicación actual. 3. Se selecciona la ubicación destino. 4. Se envían la ubicación actual y la destino al servidor. 5. El servidor crea la ruta y la devuelve mediante HTTP al cliente. 6. El dispositivo cliente debe seguir la ruta establecida. 7. Terminar el proceso.


1. El usuario selecciona la tarea de guiado. 2. No se puede obtener la ubicación actual. 3. Se envía un mensaje indicándole al cliente que el proceso no

puede llevarse a cabo. 4. Terminar el proceso.

Incluye: CU-1.1.3 Obtener ubicación, CU-2.1.1 Obtener ruta.



59

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.

Figura 4.15 Diagrama del caso de uso CU-3 Completar tarea

Tabla 11 Descripción del caso de uso CU-3 Completar tarea



Completar tarea.

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

CU-3 Completar

tarea

Dispositivo cliente

CU-1.1 Verificar

Contexto

«extends»

Servidor

Obtener ruta del servidor

Se obtuvo

ubicación

SiNo

Seleccionar tarea de guiado

Obtener la ubicación actual

Seleccionar la ubicación destino

Enviar información al servidorInformar que no se pudo realizar la operación


60

internet. 2. El usuario debe haber accedido a la aplicación y haber sido

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.

Postcondiciones: 1. Se completará una tarea que se tenía establecida como

pendiente.


1. Verificar contexto. 2. Buscar recursos en cercanía. 3. Seleccionar tarea. 4. Completar tarea. 5. Cambiar estado de tarea a completa. 6. Terminar el proceso.


1. Seleccionar tarea. 2. Completar tarea. 3. Cambiar estado de tarea a completa. 4. Terminar el proceso.

Incluye: CU-1.1 Verificar contexto.


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.


Verificar

contexto

Completar tarea

SiNo

Cambiar estado de tarea a completa

Seleccionar tarea


61

Figura 4.17 Diagrama del caso de uso CU-4 Cancelar tarea

Tabla 12 Descripción del caso de uso CU-4 Cancelar tarea



Cancelar tarea.


Descripción: Permite al usuario cancelar una tarea pendiente.

Precondiciones:


2. El usuario debe haber accedido a la aplicación y haber sido 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 cancelar.

Postcondiciones: 1. Se cancelará una tarea que se tenía establecida como pendiente.


1. Verificar contexto. 2. Buscar recursos en cercanía. 3. Seleccionar tarea. 4. Cancelar tarea. 5. Cambiar estado de tarea a cancelada. 6. Terminar el proceso.


1. Seleccionar tarea. 2. Cancelar tarea. 3. Cambiar estado de tarea a cancelada. 4. Terminar el proceso.

Incluye: CU-1.1 Verificar contexto.


CU-3 Completar

tarea

Dispositivo cliente

CU-1.1 Verificar

Contexto

«extends»

Servidor


62

Figura 4.18 Diagrama de actividad del caso de uso CU-4 Cancelar tarea

44..22 DDiisseeññoo 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.


Verificar

contexto

Cancelar tarea

SiNo

Cambiar estado de tarea a cancelada

Seleccionar tarea


63

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


64

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.


65

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


66

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


67

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.


68

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 paquete mx.edu.cenidet.clientetareasandroid.conexionhttp. Este paquete consta

únicamente de dos clases, las cuales se describe a continuación:

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.

RGBMonochromeBitmapSourceCodigoBarras

1. Selecciona por barras

3. Muestra imagen

4. Captura imagen

2. Conecta

cámara

5. Envía imagen

6. Convierte imagen

a monocromática

7. Envía imagen tratada

8. Decodifica imagen

9. Muestra identificador

Cliente


69

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.

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 pertenecientes al paquete mx.edu.cenidet.clientetareasandroid.objetos.

WebServiceApplicationConexionHTTP

1. Envía petición GET/POST2. Recibe petición y

redirecciona según URL

3. Envía respuesta en JSON

Cliente Servidor


70

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).


71

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.

Figura 4.28 Diagrama de secuencias para el proceso de lectura de tarjeta RFID

Cli

en

te

Serv

ido

r d

e

co

nexió

n

RF

ID

IntermediarioRFIDConexionRFID

1. Inicia hilo de conexión 2. Recibe petición

3. Envía respuesta de conexión

4. Establece conexión

10. Verifica conexión al

puerto

LectorRFID

6. Inicia hilo de conexión

8. Envía respuesta de conexión

7. Recibe petición

9. Establece conexión

11. Obtiene lectura

RFID

12. Envía identificador RFID

14. Envía identificador RFID

...

15. Cierra hilo de conexión

17. Cierra hilo de conexión


72

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.


73

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.


74

Figura 4.31 Diagrama de clases del paquete mx.edu.cenidet.clientetareasandroid.basedatos

A continuación se describen de manera general las clases que componen este

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

A continuación se describen de manera general las clases que componen este 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


75

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.


76

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.


77

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.


78

Figura 4.36 Diagrama de secuencias para la autenticación del usuario

Cliente

Servidor de tareas

ConexionHTTPLoginActivity

1. Inicia aplicación 2. Carga Intent

3. Despliega interfaz

WebServiceApplication

5. URL de petición

4. Captura usuario y

contraseña

12. Conexión a BD

UsuarioResource

10. Forma consulta SQL

11. Establece

conexión con BD

9. Redirección a

método GET

14. Cierra conexión

8. Envía URL con usuario

y contraseña

20. Envía resultados

Usuario

6. Envía petición GET con

usuario y contraseña

7. Redirección a

clase

UsuarioResource

OperacionesBD Conexion

13.Consulta usuario

y contraseña

Usuario

16. Envía información obtenida

18. Envía objeto de tipo Usuario serializado en JSON

17. Serializa

Objeto

19. Envía objeto de tipo Usuario serializado en JSON

21. Valida

resultados

22. Despliega pantalla

de detalles de usuario

15. Cierra

conexión con BD


79

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.

ConexionHTTP recibe la URL y envía una petición GET 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.

InstanciaTareaResource 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 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

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

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.


80

Figura 4.37 Diagrama de secuencias para la consulta de tareas pendientes

Cliente

Servidor de tareas

ConexionHTTPInstanciaTareaListActivity

1. Selecciona

tareas pendientes

2. Carga Intent


3. Envía URL de petición

con clave de usuario

10. Conexión a BD

InstanciaTareaResource


9. Establece

conexión con BD

7. Redirección a

método GET


6. Envía URL


Usuario

4. Envía petición GET


5. Redirección a clase



11.Consulta tareas

pendientes del

usuario

InstanciaTarea


16. Envía arreglo de objetos de tipo InstanciaTarea serializados en JSON

15. Serializa

arreglo de

objetos

19. Valida

resultados

20. Despliega listado

de tareas

13. Cierra

conexión con BD

17. Envía arreglo de objetos InstanciaTarea serializados en JSON


81

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.


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.


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 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

formato de representación JSON, y envía esta información a la clase InstanciaTareaResource.

InstanciaTareaResource recibe el objeto InstanciaTarea serializado y lo reenvía 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 InstanciaTarea a la clase

InstanciaTareaDetalleActivity.

InstanciaTareaDetalleActivity verifica el objeto recibido y lo utiliza para formar

la interfaz del detalle de la tarea pendiente. En la figura 4.38 se describe mediante un diagrama de secuencias, el proceso que

se sigue para consultar el detalle de una tarea pendiente.


82

Figura 4.38 Diagrama de secuencias para la consulta del detalle de una tarea

Cliente

Servidor de

tareas

ConexionHTTPInstanciaTareaDetalleActivity

1. Elegir una tarea

pendiente

2. Carga Intent



con clave de tarea

10. Conexión a BD



9. Establece

conexión con BD

7. Redirección a

método GET


6. Envía URL


Usuario


con clave de tarea




11.Consulta tarea

elegida

InstanciaTarea


16. Envía objeto de tipo InstanciaTarea serializado en JSON

15. Serializa

objeto

19. Valida

resultados

20. Despliega detalle

de tarea

13. Cierra

conexión con BD

17. Envía objeto de tipo InstanciaTarea serializado en JSON


83

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.

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.

OperacionesBD realiza la conexión a la base de datos mediante la clase 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‖.

En la figura 4.39 se describe mediante un diagrama de secuencias, el proceso que se sigue para completar o cancelar una tarea pendiente.


84

Figura 4.39 Diagrama de secuencias para la operación de completar o cancelar una tarea

Cliente

Servidor de tareas

ConexionHTTPInstanciaTareaDetalleActivity

1. Elegir Completar/

Cancelar tarea



con clave de tarea

9. Conexión a BD


7. Forma sentencia de

actualización SQL 8. Establece

conexión con BD

6. Redirección a

método POST


5. Envía URL

15. Mensaje de éxito

Usuario

3. Envía petición POST

con clave de tarea




10.Actualiza campo

estado de tarea elegida

(―C‖, ―X‖)

13. Actualización correcta

16. Mensaje de tarea

Completa/Cancelada

12. Cierra

conexión con BD

14. Código 200 en HTTP


85

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.



dicha clase recibe la petición y dependiendo la URL solicitada redirecciona la 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

formato de representación JSON, y envía esta información a la clase 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.


86

Figura 4.40 Diagrama de secuencias para la obtención de un listado de actividades disponibles para el usuario

Cliente

Servidor de tareas

ConexionHTTPActividadesListActivity

1. Selecciona

nueva tarea

2. Carga Intent




10. Conexión a BD

ActividadResource


9. Establece

conexión con BD

7. Redirección a

método GET


6. Envía URL


Usuario




ActividadResource


11.Consulta actividades

disponibles para el

usuario

Actividad


16. Envía arreglo de objetos de tipo Actividad serializados en JSON

15. Serializa

arreglo de

objetos

19. Valida

resultados

20. Despliega listado de

actividades disponibles

13. Cierra

conexión con BD

17. Envía arreglo de objetos Actividad serializados en JSON


87

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.


dicha clase recibe la petición y dependiendo la URL solicitada redirecciona la petición a la clase correspondiente, en este caso TipoTareaResource.

TipoTareaResource 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 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

formato de representación JSON, y envía esta información a la clase TipoTareaResource.

TipoTareaResource recibe el arreglo de objetos TipoTarea serializado y lo reenvía al cliente, el cual lo recibe mediante la clase ConexionHTTP.


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.


88

Figura 4.41 Diagrama de secuencias para la obtención de un listado de tareas disponibles para el usuario

Cliente

Servidor de tareas

ConexionHTTPTipoTareaListActivity

1. Selecciona

actividad

2. Carga Intent



con clave de usuario y

clave de actividad

10. Conexión a BD

TipoTareaResource


9. Establece

conexión con BD

7. Redirección a

método GET


6. Envía URL


Usuario



y clave de actividad


TipoTareaResource


11.Consulta tareas

disponibles para el

usuario

TipoTarea


16. Envía arreglo de objetos de tipo TipoTarea serializados en JSON

15. Serializa

arreglo de

objetos

19. Valida

resultados


tareas disponibles

13. Cierra

conexión con BD

17. Envía arreglo de objetos TipoTarea serializados en JSON


89

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.

OperacionesBD realiza la conexión a la base de datos mediante la clase 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.


90

Figura 4.42 Diagrama de secuencias para la operación establecer una tarea como pendiente (nueva tarea)

Cliente

Servidor de

tareas

ConexionHTTPNuevaTareaActivity

1. Elegir tipo de

tarea



con clave de tipo de

tarea y clave de usuario

12. Conexión a BD


10. Forma sentencia de

inserción SQL 11. Establece

conexión con BD

9. Redirección a

método POST


8. Envía URL

18. Mensaje de éxito

Usuario

6. Envía petición POST

con clave del tipo de tarea

y clave de usuario




13. Inserta registro de

tarea pendiente en BD

16. Actualización correcta

19. Mensaje de tarea

Almacenada

15. Cierra

conexión con BD

17. Código 200 en HTTP

2. Carga intent

3. Desplegar

interfaz

4. Selecciona fecha y

recurso


91

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 Conexion, esta última devuelve el objeto de conexión con la base de datos.

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.


92

Figura 4.43 Diagrama de secuencias para la operación obtener la ubicación actual del dispositivo

ConexionHTTPGuiadoActivity

1. Selecciona

ubicación

2. Carga Intent


4. Lee tarjeta

RFID

13. Conexión a BD

UbicacionResource

11. Forma consulta SQL 12. Establece

conexión con BD

10. Redirección

a método GET


9. Envía URL


Usuario


con identificador RFID8. Redirección a clase

UbicacionResource


14.Consulta Ubicación

con identificador RFID

Ubicacion


19. Envía objeto de tipo Ubicacion serializado en JSON

18. Serializa

el objeto

22. Valida

resultados

23. Despliega ubicación

actual

16. Cierra

conexión con BD

20. Envía objeto Ubicacion serializado en JSON

ConexionRFID

3. Obtiene tarjetas RFID

en cercanía

5. Identificador de tarjeta

RFID

6. Forma URL con identificador RFID

Cliente

Servidor de

tareas


93

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.


dicha clase recibe la petición y dependiendo la URL solicitada redirecciona la petición a la clase correspondiente, en este caso UbicacionResource.

UbicacionResource 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 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

formato de representación JSON, y envía esta información a la clase UbicacionResource.

UbicacionResource recibe el arreglo de objetos Ubicacion serializado y lo reenvía al cliente, el cual lo recibe mediante la clase ConexionHTTP.


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.


94

Figura 4.44 Diagrama de secuencias para la operación de obtener un listado de ubicaciones

Cliente

Servidor de

tareas

ConexionHTTPUbicacionListActivity

1. Selecciona

tarea de guiado

2. Carga Intent



de ubicaciones

10. Conexión a BD

UbicacionResource


9. Establece

conexión con BD

7. Redirección a

método GET


6. Envía URL


Usuario


de ubicaciones


UbicacionResource


11.Consulta ubicaciones

en la BD

Ubicacion


16. Envía arreglo de objetos de tipo Ubicacion serializados en JSON

15. Serializa

arreglo de

objetos

19. Valida

resultados


ubicaciones

13. Cierra

conexión con BD

17. Envía arreglo de objetos Ubicacion serializados en JSON


95

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.

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.

GuiadoActivity

1. Inicia hilo de conexión 2. Lee tarjeta

RFID

Usuario

ConexionRFID

3. Identificador

8. Camina a otra

posición

7. Refresca el plano y

coordenadas de

posición actual y

destino

5. Consulta ubicación

Servidor

6. Ubicación,

coordenadas y plano

9. Consulta ubicación10. Lee tarjeta

RFID

11. Identificador

...


13. Ha llegado al destino

4. Verifica si es

destino

12. Verifica si es

destino


96

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.

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.

GuiadoQRcodesActivity

1. Inicia cámara2. Decodifica el

código de barras

Usuario

CodigoBarras

3. Identificador

5. Consulta ubicación

Servidor

6. Ubicación,

coordenadas y plano

9. Envía fotografía10. Decodifica el

código de barras

11. Identificador

...

13. Ha llegado al destino

4. Verifica si es

destino

12. Verifica si es

destino

8. Captura fotografía

7. Refresca el plano y

coordenadas de

posición actual y

destino


97

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 InstanciaTareaResource.

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/{porHora}. 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}.


98

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/{estado}/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}/guardarinstancia/asociado/{asociado}/idasociado/{idasociado}/tipoasociado/{tipoasociado}/rfid_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 siguiente URL son administradas por la clase TipoTareaResource.

http://<IP_o_dominio>/users/{idusuario}/grupos/{idgrupo}/actividad/{idactividad}/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}.


99

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.


100

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.


101

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.


102

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.

Administrador

CU-1 Login

CU-2 Administrar

grupos y usuarios

CU-3 Administrar

recursos

CU-4 Administrar

ubicaciones

Usuario

CU-5 Administrar

tipos de tareas

CU-6 Administrar

tareas de los usuarios

CU-8 Logout

CU-7 Consultar

ayuda


103

En la figura 4.50 se visualiza el diagrama de clases del paquete mx.edu.cenidet.basedatos.

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.

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.


107

55..11 DDeettaalllleess tteeccnnoollóóggiiccooss 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.

108

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.

55..22 IInntteerraacccciióónn ddeell ssiisstteemmaa cclliieennttee--sseerrvviiddoorr 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"?>



<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>


109

</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.


110

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

Inicio

Obtener del

identificador

del usuario

Hacer una petición GET

al servicio Web ofrecido

por Restlet enviando el

identificador del usuario

El servidor valida el


consultando la BD

Se recibe objeto

BD tareas

Acceder al

sistema

Si

No

Mostrar

pantalla de

datos erroneos

Fin

Se envía el objeto de tipo

usuario encontrado


111

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.

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.

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

Se reciben objetos?

BD tareas

Acceder al

sistemaSi

NoMostrar listado

de tareas

pendientes

Fin

El servidor envía el

listado en forma de

objetos serializados


112

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


113

El proceso que se sigue para completar o cancelar tareas se muestra en el diagrama de flujo de la figura 5.11.

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:

1. Elegir ―Nueva tarea‖ dentro del menú de la pantalla de ―Tareas pendientes‖.

2. Elegir la actividad a la que pertenece la tarea. 3. Elegir el tipo de tarea que se dará de alta. 4. 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‖.

La figura 5.12 muestra las pantallas para dar de alta una nueva tarea.

Inicio

Enviar petición POST al

servidor añadiendo el

identificador de la tarea y

del usuario

Se pudo actualizar?

BD tareas

Mostrar pantalla

de tareas

pendientesSi

NoMostrar

mensaje de

alerta

Fin

Actualizar el estado de la

tarea del usuario a

completo o cancelado en

la BD

Elegir

completar o

cancelar


114

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.

Inicio

Enviar petición GET al



BD tareas

El servidor realiza un

filtrado de las actividades

a las que tiene acceso un

usuario en la BD

Elegir

nueva tarea

El cliente recibe la

información en forma de

objetos serializados y muestra

un listado de actividades

Elegir

actividad

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



identificador del usuario y el

identificador de la actividad

A

B


115

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. Elegir ―Nueva tarea‖ dentro del menú de la pantalla de ―Tareas pendientes‖.

2. Elegir la actividad de guiado. 3. Elegir el tipo de tarea guiado por RFID. 4. Se obtiene automáticamente la posición del dispositivo.

5. Elegir el destino al que se desea el guiado. 6. 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.

Si

No

Fin


información en forma de

objetos serializados y muestra

un listado de tipos de tarea

Elegir tipo

de tarea

Elegir por

barrasPor barras

Mostrar cámara

fotográfica

Capturar

imagen

Decodificar

código de

barras

Pudo decodificar?



identificador del recurso

Si

Elegir

guardar

Enviar petición POST al


identificador del recurso, el

tipo de tarea, el identificador

del usuario y la fecha


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

Leer

identificador

de recurso

No

El cliente recibe la respuesta

del servidor por medio de un

objeto serializado

Se recibió exito

Mostrar mensaje de

tarea almancenada

Mostrar mensaje de

error

El servidor inserta un nuevo

registro de en la tabla

InstanciaTarea en la BD

A

Si

No

A

B


116

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.

InicioObtener tarjetas

RFID en cercanía

El servidor consulta las la

ubicación que tiene

asociado el RFID

Se reciben objetos?

BD tareas

Si

Mostrar al usuario

su posición actual y

la posición del

destino elegido

Fin

El servidor envía la

ubicación encontrada

en forma serializada

Seleccionar

destino


servidor el identificador

RFID obtenido

Terminar la

tarea de guiado

No

Enviar mensaje

de error

El destino es igual

a la posición actual

No

Obtener tarjetas

RFID en cercanía



asociado el RFID





servidor el identificador

RFID obtenido


117

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. Elegir ―Nueva tarea‖ dentro del menú de la pantalla de ―Tareas pendientes‖. 2. Elegir la actividad de guiado. 3. Elegir el tipo de tarea guiado por QRCodes.

4. Se inicia la cámara y el usuario captura la fotografía del código de barras. 5. Se decodifica la fotografía. 6. Se obtiene la posición actual del dispositivo.

7. Elegir el destino al que se desea el guiado. 8. 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.


118

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.

Inicio Iniciar la cámara


ubicación con el

identificador asociado

Se reciben objetos?

BD tareas

Si

Mostrar al usuario

su posición actual y

la posición del

destino elegido

Fin




Seleccionar

destino

Capturar la fotografía con

el código de barras

Terminar la

tarea de guiado

No

Enviar mensaje

de error

El destino es igual

a la posición actual

No

Capturar fotografía

con código de

barras



asociado el identificador





servidor con el

identificador

Decodificar el código de

barrasSe decodificó?

Si

Si

NoA

A

Decodificar código

de barrasSe decidificó?

Si

No


119

Figura 5.17 Pantallas involucradas en el proceso de guiado por QRCodes

55..33 IInntteerraacccciióónn ddee llaa aapplliiccaacciióónn WWeebb

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.


120

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.


121

Figura 5.19 Pantallas del módulo de administración de usuarios

5.3.2 Administración de recursos

Dentro de este módulo se pueden realizar consultas, modificaciones e inserciones 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.


122

Figura 5.20 Pantallas del módulo de administración de recursos

5.3.3 Administración de ubicaciones

Dentro de este módulo se pueden realizar consultas, modificaciones e inserciones 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.


123

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.


124

Figura 5.22 Pantalla de captura de ubicaciones

5.3.4 Administración de tareas Dentro de este módulo se pueden realizar consultas, modificaciones e inserciones

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.


125

Figura 5.23 Pantalla de alta de tareas

5.3.5 Administración de tareas de los usuarios

Dentro de este módulo se pueden realizar consultas, modificaciones e inserciones 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.

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

129

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.

66..11 PPrruueebbaass ddee ccoonnffiigguurraacciióónn yy ccoonneexxiioonneess

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.

Capítulo 6 Pruebas

130

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.

Capítulo 6 Pruebas

131

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.



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.

Capítulo 6 Pruebas

132

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.


66..22 PPrruueebbaass ddee aauuttoo--iiddeennttiiffiiccaacciióónn


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.

Capítulo 6 Pruebas

133

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.



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.

Capítulo 6 Pruebas

134

Resultado: OK.

Observaciones: Se obtuvieron correctamente las tarjetas RFID en cercanía y el filtrado de las tareas conforme al contexto se hizo de manera exitosa.


66..33 PPrruueebbaass ddee llooccaalliizzaacciióónn yy gguuiiaaddoo ddeell ddiissppoossiittiivvoo mmóóvviill


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.

La tarjeta RFID obtenida tiene como identificador

e070024a3848300

Capítulo 6 Pruebas

135

Resultado: OK.

Observaciones: La posición se obtuvo exitosamente y con gran precisión.



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.

El RFID obtenido corresponde a la ubicación

―Sistemas Distribuidos‖

Capítulo 6 Pruebas

136

Resultado: OK.

Observaciones: La posición se obtuvo exitosamente y con gran precisión.



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.

El código de barras decodificado corresponde a

la ubicación ―Mantenimiento‖

Capítulo 6 Pruebas

137

Resultado: OK.

Se indica al usuario que vaya

a las escaleras

Se lee otra posición que corresponde a

―Mantenimiento‖

El origen ―Sistemas Distribuidos‖ y el destino ―Documentación‖ están en planos

distintos

Capítulo 6 Pruebas

138

Observaciones: El proceso de guiado se realiza de forma exitosa actualizando constantemente la posición del usuario.


66..44 PPrruueebbaass ddee aaddmmiinniissttrraacciióónn ddee ttaarreeaass


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.

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)

Capítulo 6 Pruebas

139

Resultado: OK.

Observaciones: El listado de tareas obtenido del usuario es correcto, por lo tanto el proceso es exitoso.



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.

El listado de tareas corresponde con lo obtenido

mediante la consulta SQL

Capítulo 6 Pruebas

140

Resultado: OK.

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.



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.

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‖

Capítulo 6 Pruebas

141

Resultado: OK.

Observaciones: El proceso de establecer una tarea como pendiente se llevo a cabo de forma exitosa.


Se elige ―Nueva

Tarea‖

Se listan las

actividades Se listan las tareas dentro

de la actividad

Se buscarán objetos

cercanos

Se lee el objeto

―Mantenimiento‖

Se asocia el

objeto Se establecen la

fecha y la hora

Se almacena la

tarea

Capítulo 6 Pruebas

142

66..55 PPrruueebbaass ddee aaddmmiinniissttrraacciióónn ddee llaa iinnffoorrmmaacciióónn ddee llaa bbaassee ddee

ddaattooss


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

Capítulo 6 Pruebas

143

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

Capítulo 6 Pruebas

144

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.



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 aplicaciones Apache Tomcat y se accederá a la aplicación Web de tareas mediante un navegador Web.

Se eliminará el usuario

El usuario se elimina de la base de datos y


Capítulo 6 Pruebas

145

Resultado: OK.


general

Se listan los tipos de recursos, los cuales corresponden a los

almacenados en la base de datos

Se da de alta un nuevo 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

Capítulo 6 Pruebas

146

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.



listado

Se dará de alta un

nuevo recurso

Se eliminará el recurso

El recurso se elimina de la base de datos y


Capítulo 6 Pruebas

147


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

Se da de alta un nuevo

campus

Se almacena el nuevo registro en la base de datos

y se muestra el listado

Se eliminará el campus

Capítulo 6 Pruebas

148

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



Capítulo 6 Pruebas

149

Se eliminará el

edificio

El edificio desaparece del

listado

Se capturará un nuevo

plano


listado


general de planos

Se listan los planos, los cuales corresponden a los

almacenados en la base de

datos

Capítulo 6 Pruebas

150

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

Capítulo 6 Pruebas

151

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.


Se capturará una nueva

ubicación


listado

Se eliminará la

ubicación

La ubicación desaparece del

listado

Capítulo 6 Pruebas

152


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

Capítulo 6 Pruebas

153

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

Capítulo 6 Pruebas

154

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.



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 aplicaciones Apache Tomcat y se accederá a la aplicación Web de tareas mediante un navegador Web.

Se eliminará la

tarea

El edificio desaparece del

listado

Capítulo 6 Pruebas

155

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


Capítulo 6 Pruebas

156

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.


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 Conclusión

T-Guide-001 Pruebas de configuración y

conexiones Exitoso

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.

T-Guide-002 Pruebas de auto-

identificación Exitoso

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.

T-Guide-003 Pruebas de localización y

guiado del dispositivo móvil Exitoso

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.

T-Guide-004 Pruebas de administración de

tareas Exitoso

Se administran de manera correcta las operaciones sobre las tareas de los usuarios desde el dispositivo móvil.

T-Guide-005 Pruebas de administración de la información de la base de

datos Exitoso

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.


159

77..11 CCoonncclluussiioonneess 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.

77..22 AAppoorrttaacciioonneess Este proyecto tiene varias contribuciones, entre las que destacan:

i. La vinculación de objetos del mundo real con las tareas mediante la auto-

identificación, ya sea por código de barras (mediante QRCodes) o por

RFID, haciendo uso de las funcionalidades de un dispositivo celular. ii. 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


160

esté disponible y con ello poder localizar al dispositivo en cualquier lugar y en cualquier momento, en interiores y en exteriores.

iii. 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.

iv. La precisión que se logra en el posicionamiento del dispositivo que es menor a 2 metros en interiores.

77..33 TTrraabbaajjooss ffuuttuurrooss 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 NFC3, 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.


161

77..44 PPuubblliiccaacciioonneess 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.

Anexos

Anexos

Anexo A Definición de la interfaz de usuario

165

AAnneexxoo AA DDeeffiinniicciióónn ddee llaa iinntteerrffaazz ddee uussuuaarriioo 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 <?xml version="1.0" encoding="utf-8"?>





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>


166

</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"




167


<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 <?xml version="1.0" encoding="utf-8"?>


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 <?xml version="1.0" encoding="utf-8"?>


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>



168



<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 <?xml version="1.0" encoding="utf-8"?>

<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" />


169

<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 <?xml version="1.0" encoding="utf-8"?>

<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>









170



<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>

Anexo B Plan de pruebas T-Guide

171

AAnneexxoo BB PPllaann ddee pprruueebbaass TT--GGuuiiddee El plan de pruebas constará de los siguientes puntos:

1. Introducción. 2. Descripción del plan. 3. Casos de prueba.

4. Procedimientos de prueba. 5. Resultados de pruebas

IInnttrroodduucccciióónn 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. Conexión y configuración.

2. Auto-identificación. 3. Localización y guiado. 4. Administración de tareas.

DDeessccrriippcciióónn ddeell ppllaann

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.


172

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 Tarea

precedente Habilidades especiales

Responsabilidades

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 de pruebas.

Tarea 3. Conocimiento del entorno y preparación del sistema desarrollado para su ejecución.

Autor de la tesis.


173

5. Resolver los incidentes de pruebas.

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.

6. Evaluación de resultados.

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 escritorio o Laptop

Procesador Intel P4 o superior.

512MB de memoria RAM o superior.

80 GB en disco duro.

Windows XP o superior.

Dispositivo móvil 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.


174

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.

CCaassooss ddee pprruueebbaass

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 Descripción

Configuración y conexiones

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.

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.

Pruebas de 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.


175

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.


176

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.

PPrroocceeddiimmiieennttoo ddee pprruueebbaass

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.


177

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.


178

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.


179

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.


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.


180

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.


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 auto-

identificación.


181

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 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 auto-identificación.


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

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


182

deben haber verificado las pruebas de configuración y conexión y de auto-identificación.

Proceso 1. Iniciar los servidores (PostgreSQL, Apache Felix y el servidor de tareas). 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-003-001 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

Para los casos de prueba contenidos en este grupo se utilizan los siguientes elementos:

Computadora.



Manejador de bases de datos PostgreSQL iniciado.

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


183

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 1. Iniciar los servidores (PostgreSQL, Apache Felix y el servidor de tareas). 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

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

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 1. Iniciar los servidores (PostgreSQL, Apache Felix y el servidor de tareas). 2. Iniciar la aplicación T-Guide.

3. Elegir el listado de tareas pendientes. 4. Elegir la tarea que se desea completar/cancelar. 5. Completar o cancelar la tarea.

6. Observar y verificar los resultados obtenidos. 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.


184

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

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

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, conexión y de auto-identificación.


2. Iniciar la aplicación T-Guide. 3. Elegir el listado de tareas pendientes. 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. 9. Observar y verificar los resultados obtenidos.

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 consulta, 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.


185


elementos:

Computadora.

Apache Tomcat iniciado

Manejador de bases de datos PostgreSQL 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. 4. Observar y verificar los resultados obtenidos.

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 La prueba se llevará a cabo utilizando una computadora. Asimismo, es necesario que el servidor de aplicaciones Apache Tomcat esté corriendo y


186

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 recursos y tipos de recursos.

4. Observar y verificar los resultados obtenidos.

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-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 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 campus, edificios, planos y ubicaciones.


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-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.


187

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 actividades y tareas.


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-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 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 tareas de los 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.

189

RReeffeerreenncciiaass

[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.

190

[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 Energy-Aware 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 In-Building 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 Positioning System‖, http://csd.ssvl.kth.se/2000/group12/

[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] J. Hallberg, M. Nilsson, K. Synnes, ―Bluetooth Positioning‖. (2003)

[LIONEL 2004] 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.

http://www.iusacell.com.mx/

http://www.movistar.com.mx/servicios/serv_loca.html

http://www.telcel.com/

http://www.skyhookwireless.com/

http://www.tramigo.net/spa/default.asp

http://csd.ssvl.kth.se/2000/group12/

191

[HORUS 2004] Moustafa A. Youssef, Ashok Agrawala. (2004). ―The Horus WLAN location determination system‖. Department of Computer Science, University of Maryland, 2004.

[WEISSMAN 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 Location-aware 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/ieeestd829-1998standardtest_documentation.pdf. Última consulta: Febrero 2009

[FELIX 2009] Apache, Documentación de apache Felix. Consultado en enero de

http://code.google.com/p/zxing/

http://www.ucsc.cl/~marciam/weblog/images/ieeestd829-1998standardtest_documentation.pdf

http://www.ucsc.cl/~marciam/weblog/images/ieeestd829-1998standardtest_documentation.pdf

192

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/package-summary.html

[HTTP 2009] Android developers, Documentación de Android. Consultado en enero de 2009 de http://developer.android.com/reference/org/apache/http/package-summary.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/Ecma-262.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] UPnP, ―UPnP Forum‖. Última consulta febrero de 2009 de http://www.upnp.org/.

[CRICKET 2001] Nissanka B. Priyantha, ―The cricket location-support system‖. International conference on mobile computing and networking, Boston, Massachusetts, US. 2001.

http://felix.apache.org/site/index.html

http://www.restlet.org/documentation/

http://developer.android.com/guide/index.html

http://developer.android.com/reference/org/json/package-summary.html

http://developer.android.com/reference/org/json/package-summary.html

http://developer.android.com/reference/org/apache/http/package-summary.html

http://developer.android.com/reference/org/apache/http/package-summary.html

http://help.eclipse.org/ganymede/index.jsp

http://www.android.com/about/

http://www.osgi.org/Main/HomePage

http://www.cft.gob.mx/wb/Cofetel_2008/estadisticas_de_portabilidad

http://www.json.org/json-es.html

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

http://es.wikipedia.org/wiki/Near_Field_Communication

http://www.jini.org/wiki/Main_Page

http://www.upnp.org/

Servicios de localización conscientes del contexto aplicando perfiles de movilidad y tecnologías...

Technology

Transcript of Servicios de localización conscientes del contexto aplicando perfiles de movilidad y tecnologías...