Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android

UNIVERSIDAD DE TALCA
FACULTAD DE INGENIER´IA
ESCUELA DE INGENIER´ CIVIL EN COMPUTACION
IA ´

Desarrollo de un Sistema de Juego Ubicuo bajo
Plataforma Android

˜
JUAN SEGUNDO PIZARRO MUNOZ

Profesor Gu´ JORGE EDUARDO BUSTOS BUSTOS
ıa:

Memoria para optar al t´ ıtulo de
Ingeniero Civil en Computaci´n
o

Curic´ – Chile
o
27 de julio de 2012

UNIVERSIDAD DE TALCA
FACULTAD DE INGENIER´IA
ESCUELA DE INGENIER´ CIVIL EN COMPUTACION
IA ´

Desarrollo de un Sistema de Juego Ubicuo bajo
Plataforma Android

˜
JUAN SEGUNDO PIZARRO MUNOZ

Profesor Gu´ JORGE EDUARDO BUSTOS BUSTOS
ıa:

´
Profesor Informante: RODOLFO SEBASTIAN ALLENDES OSORIO

Profesor Informante: FELIPE ANDRES BESOA´ PINO
´ IN

Memoria para optar al t´ ıtulo de
Ingeniero Civil en Computaci´n
o

Curic´ – Chile
o
27 de julio de 2012

Dedicado a mi familia y cercanos.

i

TABLA DE CONTENIDOS

p´gina
a

Dedicatoria I

Tabla de Contenidos II

´
Indice de Figuras VI

´
Indice de Tablas X

Resumen XI

Abstract XII

Palabras claves XIII

1. Introducciń
o 14
1.1. Descripciń del problema . . . . . . . . . . . . . . . . . . . . . . . . .
o 15
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.2. Objetivos espec´ıficos . . . . . . . . . . . . . . . . . . . . . . . 16
1.3. Alcances y limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.1. Declaraciń del juego . . . . . . . . . . . . . . . . . . . . . . .
o 16
1.4. Organizaciń de la memoria . . . . . . . . . . . . . . . . . . . . . . .
o 17

2. Marco Te´rico
o 19
2.1. Computaciń ubicua . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
o
2.2. Terminales m´viles . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 20
2.2.1. Evoluciń en el mercado . . . . . . . . . . . . . . . . . . . . .
o 21
2.2.2. HTC G1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3. Plataforma Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.1. Open Handset Alliance . . . . . . . . . . . . . . . . . . . . . . 26
2.3.2. FLOSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.3. Caracter´
ısticas . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.4. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

ii

iii

2.3.5. Componentes de una aplicaciń en Android . . . . . . . . . .
o 30
2.3.6. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.7. Ciclo de vida . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.8. Archivos Layout . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.9. Archivos de recursos . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.10. Archivo AndroidManifest.xml . . . . . . . . . . . . . . . . . . 33
2.4. Servicios Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.1. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.2. REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.3. RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5. Realidad aumentada . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3. Metodolog´
ıa 37
3.1. Descripciń de Metodolog´ . . . . . . . . . . . . . . . . . . . . . . .
o ıa 37
3.1.1. Etapas del Proceso Unificado . . . . . . . . . . . . . . . . . . 38
3.1.2. Disciplinas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2. Patrones de dise˜ o . . . . . . . . . . . . . . . . . . . . . . . . . . . .
n 40
3.2.1. Patrones GRASP . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.2. Patrones GOF . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.3. Patrones arquitectńicos . . . . . . . . . . . . . . . . . . . . .
o 42
3.2.4. Otros patrones . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4. An´lisis
a 44
4.1. Resumen de las caracter´ısticas del sistema . . . . . . . . . . . . . . . 44
4.2. Especificaciń de requisitos . . . . . . . . . . . . . . . . . . . . . . . .
o 45
4.3. Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4. Especificaciń de Casos de Uso . . . . . . . . . . . . . . . . . . . . .
o 50
4.4.1. Casos de uso en formato resumido . . . . . . . . . . . . . . . . 50
4.4.2. Casos de uso en formato expandido . . . . . . . . . . . . . . . 52
4.4.3. Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . 60
4.4.4. Priorizaciń de Casos de Uso . . . . . . . . . . . . . . . . . .
o 61
4.5. Modelo conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.6. Diagrama de secuencia del sistema . . . . . . . . . . . . . . . . . . . 64
4.6.1. Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

iv

4.7. Contratos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.7.1. Contratos referentes a usuario . . . . . . . . . . . . . . . . . . 67

5. Dise˜ o
n 70
5.1. Diagrama de Interacciń . . . . . . . . . . . . . . . . . . . . . . . . . 70
o
5.1.1. Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2. Diagrama de Clases de dise˜ o . . . . . . . . . . . . . . . . . . . . . .
n 73
5.3. Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.4. Diagrama de dise˜ o de paquetes . . . . . . . . . . . . . . . . . . . . .
n 75
5.5. Arquitectura del software . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.6. Diagrama de clases de dise˜ o de capa de negocio o dominio . . . . . .
n 82
5.6.1. Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.6.2. Acciones o implementaciń de Casos de Uso . . . . . . . . . .
o 84
5.7. Persistencia de datos o capa de datos . . . . . . . . . . . . . . . . . . 86
5.7.1. Acceso a la base de datos . . . . . . . . . . . . . . . . . . . . 86
5.7.2. Estructura de la base de datos . . . . . . . . . . . . . . . . . . 86
5.7.3. Accessor o DAO(Data Access Object) . . . . . . . . . . . . . . 88
5.8. Diagrama de estados . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.8.1. Estados de un juego . . . . . . . . . . . . . . . . . . . . . . . 89
5.8.2. Estados de una pista . . . . . . . . . . . . . . . . . . . . . . . 90
5.8.3. Estados de las capas vista y controlador . . . . . . . . . . . . 91

6. Implementaciń
o 94
6.1. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.2. Diagrama de Clases de la capa de presentaciń . . . . . . . . . . . . .
o 98
6.3. Diagrama de Secuencia de implementaciń . . . . . . . . . . . . . . . 100
o
6.4. Persistencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.4.1. Base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.4.2. Clases persistentes . . . . . . . . . . . . . . . . . . . . . . . . 104
6.5. Comunicaciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
o
6.5.1. Intercambio de datos REST . . . . . . . . . . . . . . . . . . . 106
6.5.2. Servicios Web SOAP con Apache Axis2 . . . . . . . . . . . . . 107
6.5.3. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.6. Mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

v

6.7. Paginas Web en Wicket . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.8. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.9. Implementaciń iterativa . . . . . . . . . . . . . . . . . . . . . . . . . 115
o
6.10. Dependencias entre la capa de negocio y datos . . . . . . . . . . . . . 118
6.11. Arquitectura f´
ısica del software . . . . . . . . . . . . . . . . . . . . . 118
6.12. Diagrama de dise˜ o de paquetes . . . . . . . . . . . . . . . . . . . . . 120
n

7. Conclusiones y Trabajos Futuros 128

Bibliograf´
ıa 131

Glosario 134

Anexos

A. Especificaciń complementaria
o 141

B. Casos de Uso 144

C. Matriz de caracter´
ısticas de Casos de Uso 160

D. Diagrama de Secuencia del sistema 161

E. Contratos 169

F. Diagrama de Interacciń
o 175

G. Iteraciones 183

´
INDICE DE FIGURAS

p´gina
a

2.1. Entorno ubicuo. Fuente: http://www.tokyo-ubinavi.jp . . . . . . . . . 20
2.2. Estad´
ısticas de telefon´ m´vil en 2009. Fuente: INE . . . . . . . . . .
ıa o 21
2.3. Proyectos nuevos por sistema operativo Fuente: Flurry Analytics . . . 22
2.4. Request de dispositivos m´viles en Noviembre de 2008 a la izquierda.
o
Fuente: AdMob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5. Request de dispositivos m´viles en Junio de 2009 a la derecha. Fuente:
o
AdMob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6. Request de dispositivos m´viles en Abril de 2010. Fuente: AdMob . .
o 23
2.7. Ventas de terminales m´viles por sistema operativo en el segundo
o
cuarto de 2010. Fuente: Gartner . . . . . . . . . . . . . . . . . . . . . 23
2.8. Ventas de terminales m´viles por sistema operativo en 2010. Fuente:
o
Gartner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.9. HTC G1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.10. Arquitectura del sistema operativo Android. Fuente: Android Developers 28

4.1. Diagrama de casos de uso: Usuarios . . . . . . . . . . . . . . . . . . . 60
4.2. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3. Modelo Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.4. Diagrama de secuencias: Autenticarse CU 1.1 . . . . . . . . . . . . . 65
4.5. Diagrama de secuencias: Cambiar Contrase˜ a CU 1.3 . . . . . . . . .
n 66
4.6. Diagrama de secuencias: Registrar Competidor CU 1.4 . . . . . . . . 66
4.7. Diagrama de secuencias: Actualizar localizaciń CU 1.8 . . . . . . .
o 67

5.1. Diagrama de interacciń - Registrar Usuario, CU 1.4 . . . . . . . . .
o 71
5.2. Diagrama de interacciń - Autenticarse, CU 1.1 . . . . . . . . . . . .
o 72
5.3. Diagrama de interacciń - Cambiar contrase˜ a, CU 1.3 . . . . . . . .
o n 72
5.4. Diagrama de interacciń - Buscar usuarios, CU 1.6 . . . . . . . . . .
o 73
5.5. Diagrama de Clases de Dise˜ o . . . . . . . . . . . . . . . . . . . . . .
n 74
5.6. Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . . . . 75
5.7. Diagrama de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.8. Arquitectura del Software: modelo tres capas . . . . . . . . . . . . . . 78

vi

vii

5.9. Arquitectura del Software de cliente Android . . . . . . . . . . . . . . 79
5.10. Arquitectura del Software de servidor . . . . . . . . . . . . . . . . . . 81
5.11. Entidades del subsistema de usuario . . . . . . . . . . . . . . . . . . . 82
5.12. Entidades del subsistema de equipo . . . . . . . . . . . . . . . . . . . 83
5.13. Entidades del subsistema de mensajer´ . . . . . . . . . . . . . . . . .
ıa 83
5.14. Entidades del subsistema de lugar . . . . . . . . . . . . . . . . . . . . 84
5.15. Entidades del subsistema de juego . . . . . . . . . . . . . . . . . . . . 84
5.16. Managers del subsistema de usuario . . . . . . . . . . . . . . . . . . . 85
5.17. Managers del subsistema de juego . . . . . . . . . . . . . . . . . . . . 85
5.18. Diagrama Entidad Relaciń - componente de juegos . . . . . . . . . .
o 87
5.19. Accessor del subsistema de usuario . . . . . . . . . . . . . . . . . . . 88
5.20. Accessor del subsistema de juego . . . . . . . . . . . . . . . . . . . . 89
5.21. Diagrama de estados de un juego . . . . . . . . . . . . . . . . . . . . 90
5.22. Diagrama de estados de una pista . . . . . . . . . . . . . . . . . . . . 91
5.23. Diagrama de estados para las pantallas . . . . . . . . . . . . . . . . . 92
5.24. Diagrama de estados para las actividades del cliente Android . . . . . 92

6.1. Arquitectura SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.2. Arquitectura del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.3. Diagrama de Clases del Cliente Android . . . . . . . . . . . . . . . . 98
6.4. Diagrama de Clases del Servidor . . . . . . . . . . . . . . . . . . . . . 99
6.5. Diagrama de Secuencia del Cliente Android . . . . . . . . . . . . . . 101
6.6. Diagrama de Secuencia del servidor . . . . . . . . . . . . . . . . . . . 102
6.7. Dependencias Servicio, Accessor, Entidad . . . . . . . . . . . . . . . . 118
6.8. Arquitectura f´
ısica del software . . . . . . . . . . . . . . . . . . . . . 120
6.9. Diagrama de paquetes de la librer´ gen´rica . . . . . . . . . . . . . . 121
ıa e
6.10. Diagrama de paquetes de la librer´ gen´rica del servidor . . . . . . . 122
ıa e
6.11. Diagrama de paquetes de la librer´ del sub-sistema juego . . . . . . . 124
ıa
6.12. Diagrama de paquetes de la implementaciń del servidor del sub-
o
sistema juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.13. Diagrama de paquetes de la implementaciń REST del juego . . . . . 125
o
6.14. Diagrama de paquetes de la implementaciń Axis del juego . . . . . . 126
o
6.15. Diagrama de paquetes de la implementaciń Web del juego . . . . . . 126
o
6.16. Diagrama de paquetes del Cliente Android . . . . . . . . . . . . . . . 127

viii

B.1. Diagrama de casos de uso: Equipos . . . . . . . . . . . . . . . . . . . 146
B.2. Diagrama de casos de uso: Lugares y pistas . . . . . . . . . . . . . . . 149
B.3. Diagrama de casos de uso: Juego . . . . . . . . . . . . . . . . . . . . 155
B.4. Diagrama de casos de uso: Comunicaciń . . . . . . . . . . . . . . . . 156
o
B.5. Diagrama de casos de uso: Localizaciń y mapas . . . . . . . . . . . . 159
o

D.1. Diagrama de secuencias: Vincular Competidor a Equipo CU 2.2 . . . 161
D.2. Diagrama de secuencias: Crear Lugar(Pista) CU 3.1 . . . . . . . . . 162
D.3. Diagrama de secuencias: Alertar Cercan´ CU 3.3 . . . . . . . . . . . 162
ıa
D.4. Diagrama de secuencias: Comenzar Juego CU 4.1 . . . . . . . . . . . 163
D.5. Diagrama de secuencias: Buscar juegos por Ciudad CU 4.3 . . . . . . 163
D.6. Diagrama de secuencias: Buscar Juego CU 4.3 . . . . . . . . . . . . . 164
D.7. Diagrama de secuencias: Buscar equipos por juego CU 4.7 . . . . . . 164
D.8. Diagrama de secuencias: Ver Juego CU 4.8 . . . . . . . . . . . . . . 165
D.9. Diagrama de secuencias: Recoger Pista CU 4.5 . . . . . . . . . . . . 165
D.10.Diagrama de secuencias: Enviar Mensaje a Compa˜ eros CU 5.1 . . . 166
n
D.11.Diagrama de secuencias: Solicitar Ubicaciń CU 6.4 . . . . . . . . . . 167
o
D.12.Diagrama de secuencias: Mostrar mapa CU 6.1 . . . . . . . . . . . . 167
D.13.Diagrama de secuencias: Ver ubicaciń de compa˜ eros CU 6.2 . . . . 168
o n

F.1. Diagrama de interacciń - Vincularse a un equipo CU 2.2 . . . . . . 175
o
F.2. Diagrama de interacciń - Listar compa˜ eros CU 2.3 . . . . . . . . . 176
o n
F.3. Diagrama de interacciń - Ubicaciń de compa˜ eros CU 6.2 . . . . . 176
o o n
F.4. Diagrama de interacciń - Crear un lugar(pista), CU 3.1 . . . . . . . 177
o
F.5. Diagrama de interacciń - Asociar pista a juego, CU 4.9 . . . . . . . 177
o
F.6. Diagrama de interacciń - Buscar Pista CU 3.2 . . . . . . . . . . . . 178
o
F.7. Diagrama de interacciń - Buscar juegos CU 4.3 . . . . . . . . . . . 178
o
F.8. Diagrama de interacciń - Buscar equipos por juego CU 4.7 . . . . . 179
o
F.9. Diagrama de interacciń - Recoger Pista CU 4.5 . . . . . . . . . . . 179
o
F.10.Diagrama de interacciń - Enviar mensaje y almacenar informaciń,
o o
CU 5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
F.11.Diagrama de interacciń - Asociar mensaje al remitente y destinatario,
o
CU 5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
F.12.Solicitar localizaciń, CU 6.4
o . . . . . . . . . . . . . . . . . . . . . . 182

ix

G.1. Interfaz Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
G.2. Cliente Android para test de comunicaci´n con el servidor . . . . . . 190
o
G.3. Mapa en cliente Android . . . . . . . . . . . . . . . . . . . . . . . . . 191
G.4. Actividades del Cliente Android . . . . . . . . . . . . . . . . . . . . . 193

´
INDICE DE TABLAS

p´gina
a

2.1. Especificaciń de HTC G1 . . . . . . . . . . . . . . . . . . . . . . . .
o 25

4.1. Caracter´ısticas para determinar la prioridad de los casos de uso . . . 62
4.2. Priorizaciń de casos de uso . . . . . . . . . . . . . . . . . . . . . . .
o 62
4.3. Descripciń de conceptos del modelo conceptual . . . . . . . . . . . .
o 64

5.1. Descripciń de los paquetes de la librer´ gen´rica del servidor . . . .
o ıa e 77
5.2. Descripciń de estados de un juego . . . . . . . . . . . . . . . . . . .
o 90
5.3. Descripciń de estados de una pista . . . . . . . . . . . . . . . . . . .
o 91

6.1. Descripciń de la Arquitectura del Sistema . . . . . . . . . . . . . . . 97
o
6.2. Descripciń de los paquetes de la librer´ gen´rica . . . . . . . . . . . 121
o ıa e
6.3. Descripciń de los paquetes de la librer´ gen´rica del servidor . . . . 123
o ıa e
6.4. Descripciń de los paquetes de la librer´ del sub-sistema juego . . . . 124
o ıa
6.5. Descripciń de los paquetes de la implementaciń del servidor del sub-
o o
sistema juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.6. Descripciń de los paquetes de la implementaciń REST del juego . . 126
o o
6.7. Descripciń de los paquetes de la implementaciń Axis del juego . . . 126
o o
6.8. Descripciń de los paquetes de la implementaciń Web del juego . . . 126
o o
6.9. Descripciń de los paquetes de la implementaciń del cliente Android 127
o o

C.1. Tabla de caracter´
ısticas de priorizaciń de casos de uso . . . . . . . . 160
o

x

RESUMEN

El desarrollo de las telecomunicaciones e interfaces de usuarios, junto con la
disminuciń en el tama˜ o de dispositivos y piezas electrńicas nos permiten hoy
o n o
estar conectados en cualquier lugar y momento, facilitando las tareas que realizamos
cotidianamente sin estar obligados a permanecer en alg´ n lugar en especifico, es
u
as´ que el crecimiento explosivo que ha tenido Android desde su lanzamiento en
ı
2008 y la disminuciń en el costo de los smartphone’s nos permite tener hoy en d´
o ıa
dispositivos con variadas caracter´
ısticas, como lo son el GPS, pantalla tćtil, br´ jula,
a u
c´maras de alta resoluciń entre otros.
a o
Estas nuevas capacidades presentes hoy en nuestro bolsillo, nos perminten ex-
plorar y comunicarnos con el ambiente, sacńdonos de nuestras sillas y monitores,
a
mezclando la realidad con lo virtual, en una nueva forma de enriquecer la experiencia
con nuestro entorno y quienes nos rodean.
En esta memoria se muestra el dise˜ o e implementaciń de un juego ubicuo de
n o
realidad aumentada para entornos de exterior bajo plataforma Android con una
arquitectura basada en servicios Web.

xi

ABSTRACT

The development of telecommunications and user interfaces, the decrease in the
size of electronic devices and components, allow us today to be connected anywhere
and anytime, facilitating the tasks we perform daily, without being forced to stay
in a specific place. The explosive growth of Android since its launch in 2008 and a
decrease in the cost of smartphones allows us nowadays to have devices with different
characteristics, such as GPS, touch screen, compass, high resolution cameras, among
others.
These new capabilities we carry out in our pockets, allow us to explore and
communicate with the environment arround us, getting us off our chairs and screens,
mixing reality and virtuality, in a new way that enrich what actually sorrounds us.
This report shows us the design and implementation of an augmented reality game
for ubiquitous outdoor environments under Android platform with an architecture
based on Web services.

xii

PALABRAS CLAVES

Desarrollo de software, Android, Servicio Web, API, Dispositivos m´viles, SOAP
o

xiii

1. Introducciń
o

La tecnolog´ aparatos electrńicos, y redes comunicaciń, han pasado a ser parte
ıa, o o
de nuestra vida cotidiana, utilizamos estos en nuestros hogares, trabajos y lugares
de esparcimiento, en nuestro tiempo libre y para actividades laborales. Es as´ que
ı,
aparatos electrńicos como laptops, netbooks, smartphones, PDAs, entre muchos
o
otros nos ayudan a realizar una gran cantidad de las actividades que realizamos
diariamente, en cualquier lugar y en cualquier momento.
El tama˜ o de estos aparatos electrńicos se hace cada vez mas peque˜ o, aumen-
n o n
tando la portabilidad, adem´s estos se vuelven cada vez m´s intuitivos y baratos.
a a
Ejemplo de esto es el paso de celulares del tama˜ o de una maleta de los a˜ os 70, a los
n n
peque˜ os aparatos que poseemos casi todos hoy en d´ Estos aparatos electrńicos
n ıa. o
pueden ser embebidos en casi cualquier tipo de objeto de una forma amigable, en au-
tos, refrigeradores, sistemas de calefacciń, ropa, y electrodom´sticos, por no hablar
o e
de diversos bienes de consumo.
Tambiń las posibilidades de conectividad entre los distintos dispositivos que
e
usamos ha mostrado un incremento considerable en los ultimos a˜ os, destacando
´ n
en uso de tecnolog´ inal´mbricas como 3G, Bluetooth, 802.11 b/g/n, IR, Zigbee,
ıas a
entre otros, las que han disminuido sus costos y, aumentado sus alcances y expansiń
o
territorial, permitiendo estar comunicados con quienes nos rodean.
La manera en la cual se interact´ a con el entorno est´ en constante cambio
u a
debido a las tecnolog´ cada vez m´s adsequibles y presentes en los dispositivos
ıas a
utilizados, dan ejemplo de esto sensores de temperatura, luz, sonido, acelero-metros,
GPS, permitiendo conocer el contexto donde nos desenvolvemos.
Es as´ como la forma de relacionarse con otras personas por medio de los com-
ı
putadores e Internet ha estado en constante cambio, partiendo por ejemplo con el

14

CAP´ ´
ITULO 1. INTRODUCCION 15

correo electrńico, pasando por mensajes instantńeos, videoconferencia, juegos en
o a
l´
ınea, hasta la Internet 2.0 que permite ofrecer aplicaciones sociales como Facebook
[9] o Twitter [27].

1.1. Descripciń del problema
o

Las tecnolog´ detr´s de las consolas de videojuegos han permitido a los desar-
ıas a
rolladores crear juegos con narrativas visuales inmersivas e interactivas, desafortu-
nadamente, con ello los jugadores se han desconectado del medio ambiente y de la
gente que los rodea. Esta desconexiń se debe a la dependencia de los videojuegos
o
con las pantallas, teniendo estas como su principal interfaz. Al participar en el juego,
la unica conexiń que se hace es entre el jugador y la pantalla. Por otra parte, mien-
´ o
tras m´s atractivo e inmersivo es el juego, m´s fuerte ser´ el v´
a a a ınculo entre el jugador
y la pantalla.
Mientras que los dispositivos m´viles, tales como Nintendo DS [18] o PlayStation
o
Portable [23], son capaces de sacar a los jugadores de sus casas, sufren del mismo
problema que las consolas de hogar. El jugador est´ atado a la pantalla, no importa
a
dńde ellos estń jugando, una vez que se forma la conexiń con la pantalla, el mundo
o a o
que los rodea pasa a segundo plano.
La interacciń de las nuevas tecnolog´ y capacidades presentes en todo nuestro
o ıas
entorno, como por ejemplo, sensores de temperatura, proximidad, GPS, aceler´met-
o
ros, entre otros, nos permiten desarrollar juegos que vuelvan a conectar al jugador
con el ambiente y gente que lo rodea, adem´s de presentar una herramienta que
a
puede ser explotada para el uso empresarial, educacional, militar, salud, entre otros
[38].

1.2. Objetivos

En esta memoria se desarrollar´ un juego que haga uso de las nuevas tecnolog´
a ıas
y capacidades en dispositivos con Sistema Operativo Android, una plataforma de
software de c´digo abierto que incluye un sistema operativo para dispositivos m´viles
o o
basado en GNU/Linux, desarrollado por Google y por la Open Handset Alliance. Este´
permite el desarrollo de aplicaciones por terceros, controlando los dispositivos por
medio de bibliotecas desarrolladas o adaptadas por Google.

CAP´ ´

Se desarrollar´ un juego ubicuo de estrategia, cuyo tablero de juego ser´ un
a a
lugar f´
ısico, real, como lo puede ser un edificio, campus, ciudad, etc., permitiendo la
interacciń real entre el ambiente y los jugadores, los cuales pertenecerń a distintos
o a
equipos, teniendo una finalidad o meta unica.
´

1.2.1. Objetivo general

Dise˜ ar e implementar un juego ubicuo de realidad aumentada para entornos de
n
exterior bajo plataforma Android.

1.2.2. Objetivos espec´
ıficos

Los objetivos espec´
ıficos son:

Estudiar las nuevas tecnolog´ presentes en los dispositivos m´viles
ıas o

Dise˜ ar y desarrollar un Juego ubicuo para la plataforma Android
n

Dise˜ ar y desarrollar un software basado en la arquitectura orientada en ser-
n
vicios (SOA en ingl´s)
e

1.3. Alcances y limitaciones

El software estar´ compuesto por varios servicios Web, un cliente Web y un
a
cliente para m´viles con Android.
o

El servidor de juego estar´ dise˜ ado para integrarse con distintas plataformas
a n
clientes.

Solo se utilizarń herramientas y librer´ licenciadas como Software Libre.
a ıas

1.3.1. Declaraciń del juego
o

El juego a implementar es “En b´squeda del tesoro”, juego en equipo, donde el
u
objetivo es buscar y encontrar un tesoro, el cual es un lugar geogr´fico, primero que
a
los equipos contrincantes, es por ello que los participantes se dividen en grupos de
similar n´ mero.
u

CAP´ ´

Para poder encontrar el tesoro deben seguir una serie de pistas a lo largo del
juego, las cuales dan idea de a dńde dirigirse, dńde se encuentra la pr´xima pista,
o o o
y qu´ es y dńde se encuentra el tesoro o meta.
e o
Los integrantes de los equipos pueden colaborar con sus compa˜ eros para realizar
n
las tareas de b´ squeda y seguimiento de pistas con mayor agilidad, es por ello que
u
se posibilitar´ la comunicaciń entre estos, para as´ poder separarse y abarcar m´s
a o ı a
terreno.
Como apoyo al proceso de b´ squeda y exploraciń, se proveerń mapas del es-
u o a
pacio( ´rea de juego), e informaciń georeferenciada de las pistas, a medida que las
a o
descubran, y de la localizaciń de compa˜ eros de equipo.
o n
Cada equipo contar´ con una pista al comienzo del juego. El juego termina cuando
a
alg´ n participante alcanza el tesoro, y con esto el equipo al que pertenece ´ste, gana
u e
la partida en cuestiń.
o

1.4. Organizaciń de la memoria
o

La memoria ha sido divida en distintos cap´
ıtulos, los que se describen brevemente
a continuaciń:
o

Cap´
ıtulo 1 Es el cap´
ıtulo actual, en el se presenta la descripciń general de la
o
memoria.

Cap´
ıtulo 2 Este cap´
ıtulo contiene las bases que sustentan el desarrollo de esta
memoria.

Cap´
ıtulo 3 Este cap´
ıtulo explica la metodolog´ de desarrollo de software utilizada.
ıa

Cap´
ıtulo 4 Este cap´ ıtulo esta destinado al an´lisis de requisitos y especificaciń
a o
del sistema a desarrollar, aqu´ se muestra qu´ es lo que debe hacer el sistema,
ı e
utilizando como herramientas los casos de uso, el modelo conceptual, los dia-
gramas de secuencia y los contratos.

Cap´
ıtulo 5 Este cap´
ıtulo muestra el dise˜ o del sistema, se muestra c´mo debe fun-
n o
cionar ´ste.
e

CAP´ ´

Cap´
ıtulo 6 En este cap´ ıtulo se aplica el dise˜ o del cap´
n ıtulo anterior a una ar-
quitectura espec´
ıfica, SOA, se muestran los aspectos m´s importantes de la
a
implementaciń del sistema y las iteraciones de desarrollo realizadas.
o

Cap´
ıtulo 7 En este cap´ıtulo se muestran algunas conclusiones del trabajo. Tambiń
e
se presentan algunas propuestas de trabajo a futuro.

2. Marco Te´rico
o

En este cap´
ıtulo se explican los conceptos m´s importantes que sustentan el
a
desarrollo de esta memoria.

2.1. Computaciń ubicua
o

“Mark Weiser, en Septiembre de 1991 describi´ su visiń de lo que el llamaba
o o
computaciń ubicua. La esencia de su visiń era la creaciń de entornos repletos de
o o o
computaciń y de capacidad de comunicaciń, todo integrado de forma inapreciable
o o
junto a las personas” [37, 49].

La visiń de Weiser estaba bastante alejada de su ´poca, entre otras razones
o e
porque no exist´ la tecnolog´ necesaria para llevarla a cabo, pero despu´s de dos
ıa ıa e
dćadas de progreso en el campo de los dispositivos Hardware, las criticadas ideas
e
de Weiser en 1991, ahora son productos comercialmente viables, prueba de ello es
que hoy en d´ estamos rodeados de dispositivos tecnol´gicos, con los cuales interac-
ıa o
tuamos a menudo, pero sin darnos cuenta.
Por ejemplo, cuando una persona se sienta en su escritorio a escribir un informe,
usa el teclado, pantalla y recursos del computador, pero cuando est´ escribiendo,
a
impregnando cada pensamiento, en ese preciso momento, el actor no esta consciente
de que esta usando un computador y de que ´ste, tiene un sistema operativo. [31, 40]
e
La computaciń ubicua (Ubiquitous computing, tambiń conocida como pervasive
o e
computing, proactive computing, ambient computing, y en contextos relacionados,
ambient intelligence) conecta a las redes de todo el mundo sin fronteras y provee
acceso r´pido y seguro a una gran cantidad de informaciń y servicios, en cualquier
a o
momento y en cualquier lugar. [47]

19

CAP´ ´
ITULO 2. MARCO TEORICO 20

En otras palabras, un sistema ubicuo es un entorno o ambiente con elementos de
c´mputo interconectados, interoperables y que interaccionan con el mundo real de
o
forma imperceptible para los usuarios, apoyando al desempe˜ o de tareas cotidianas.
n
Algunas de las tecnolog´ que hacen posible la computaciń ubicua que podemos
ıas o
nombrar son computadores de bolsillo, redes inal´mbricas, sensores muy avanzados
a
y computaciń vestible.
o
La Figura 2.1 muestra la integraciń de los sistemas ubicuos en nuestro entorno,
o
facililando as´ actividades cotidianas como ir de visita a un zool´gico.
ı o

Figura 2.1: Entorno ubicuo. Fuente: http://www.tokyo-ubinavi.jp

2.2. Terminales m´viles
o

Los dispositivos m´viles poseen actualmente una gran capacidad de procesamien-
o
to, almacenamiento y conexiń a distintas redes en casi cualquier parte del mundo.
o
Adem´s presentan capacidades de geolocalizaciń por sat´lite, br´ julas electrńicas,
a o e u o
aceler´metros, c´mara, y la posibilidad de conectar distintos sensores. El hacer uso de
o a
estas nuevas capacidades nos permite desarrollar juegos que mantengan en contacto
a personas con el ambiente los rodea. [33]

CAP´ ´

2.2.1. Evoluciń en el mercado
o

Hoy en d´ es muy com´ n que una persona tenga un dispositivo m´vil, de entre
ıa u o
los cuales, el tel´fono es el m´s utilizado.
e a
Seg´ n el INE [15], como se aprecia en la Figura 2.2, hasta Diciembre de 2009
u
el n´ mero de tel´fonos m´viles en Chile super´ los 17 millones de unidades y si se
u e o o
considera el n´ mero de la poblaciń estimada a Junio de 2009 en Chile (16.928.873),
u o
se puede decir que existen un poco m´s de un celular por habitante a dicha fecha.
a

Figura 2.2: Estad´sticas de telefoná m´vil en 2009. Fuente: INE
ı ı o

Adem´s, durante los ultimos a˜ os, con el avance de estos peque˜ os dispositivos
a ´ n n
en procesamiento y conectividad, se ha incrementado a˜ o a a˜ o el acceso a Internet
n n
utilizando estos.
Luego, como se puede apreciar en la Figura 2.3, existe un incremento relativo
en el desarrollo de nuevos proyectos para el sistema operativo Android entre Enero

CAP´ ´

y Julio de 2009. Adem´s, se aprecia un decremento relativo en los proyectos para
a
iPhone en el mismo per´
ıodo.

Figura 2.3: Proyectos nuevos por sistema operativo Fuente: Flurry Analytics

Seg´ n Flurry[10] los nuevos proyectos de IPhone han aumentado en un 30 % de
u
mes a mes, la tasa de crecimiento de Android se est´ acelerando, aumentando en
a
m´s del 50 % desde el mes de Junio a Julio de 2009.
a
Seg´ n las estad´
u ısticas de admob[1], con respecto al tr´fico producido por los
a
Smartphone a nivel mundial, se aprecia un incremento relativo considerable en el
uso del sistema operativo Android. La Figura 2.4 muestra que el tr´fico de Android
a
en el mes de Noviembre de 2008 era del 1 %, mientras que el mes de Junio de 2009
era de un 5 %, mostrado en la Figura 2.5. Este incremento relativo en el tr´fico ha
a
seguido en aumento hasta llegar a un 25 % en el mes de Abril de 2010, como se
aprecia en la Figura 2.6.

CAP´ ´

Figura 2.4: Request de dispositivos m´viles en Noviembre de 2008 a la izquierda. Fuente:
o
AdMob

Figura 2.5: Request de dispositivos m´viles en Junio de 2009 a la derecha. Fuente: AdMob
o

Figura 2.6: Request de dispositivos m´viles en Abril de 2010. Fuente: AdMob
o

Adem´s, Gartner[11], como se aprecia en la Figura 2.7, inform´ que las ventas
a o
mundiales de smartphones con sistema operativo Android han superado las ven-
tas del iPhone durante el segundo cuarto de 2010, 10.6 millones de tel´fonos con
e
sistema operativo Android durante dicho periodo, lo que representa un 17,2 %, en
comparaci´n con 8.74 millones tel´fonos con iOS, que representa un 14,2 % de cuota
o e
de mercado del per´
ıodo en estudio. Los m´s vendidos son a´ n Symbian, con el 41,2 %
a u
del mercado y RIM con el 18,2 % del mercado, en dicho per´
ıodo.

CAP´ ´

Figura 2.7: Ventas de terminales m´viles por sistema operativo en el segundo cuarto de
o
2010. Fuente: Gartner

Luego, en febrero de 2011 Gartner[11] inform´, como se aprecia en la Figura 2.8,
o
que las ventas totales de smartphones con sistema operativo Android durante el a˜ o
n
2010 han sido de 67 millones aproximadamente, moviendolo al segundo puesto.

Figura 2.8: Ventas de terminales m´viles por sistema operativo en 2010. Fuente: Gartner
o

2.2.2. HTC G1

La aplicaciń m´vil desarrollada en la presente memoria est´ destinada a dis-
o o a
positivos que tengan el Sistema Operativo Android 1.6 o superior, es por ello que
se tendr´ como dispositivo de pruebas y desarrollo al terminal m´vil “HTC G1”,
a o
mostrado en la Figura 2.9, y que cuenta con las especificaciones tćnicas mostradas
e
en el Cuadro 2.1.

CAP´ ´

Figura 2.9: HTC G1

Procesador Qualcomm R MSM7201ATM , 528 MHz
Memoria ROM: 256 MB, RAM: 192 MB
Pantalla Pantalla plana tćtil TFT-LCD 3.2 pulgadas. HVGA
a
Redes HSPA/WCDMA:
* 2100 MHz
* 7.2 Mbps de bajada (HSDPA) y 2 Mbps de subida
(HSUPA)
Cuatribanda GSM/GPRS/EDGE:
* 850/900/1800/1900 MHz
Control del dis- Bola de navegaciń con tecla enter
o
positivo
Teclado Qwerty deslizante de 5 filas
Conectividad Bluetooth R 2.0 con ERD
Wi-Fi R : IEEE 802.11b/g
HTC ExtUSBTM
C´mara
a 3.2 megap´
ıxeles con auto focus
Caracter´
ısticas Br´ jula y sensor de movimiento
u
Especiales

Cuadro 2.1: Especificaciń de HTC G1
o

CAP´ ´

2.3. Plataforma Android

Android [2] es una plataforma de software de c´digo abierto para dispositivos
o
m´viles, desarrollado por Google y por la Open Handset Alliance[19].
o
Incluye un sistema operativo basado en GNU/Linux, middleware y aplicaciones
claves, adem´s de un entorno de desarrollo, Android SDK[3], que provee las her-
a
ramientas y APIs necesarias para comenzar el desarrollo de aplicaciones utilizando
el lenguaje de programaciń Java.
o

2.3.1. Open Handset Alliance

Creada y fundada por Google, la Open Handset Alliance naci´ para el desarrollo
o
e implementaciń de Android en terminales m´viles. Actualmente est´ formada por
o o a
m´s de 70 compa˜´ o empresas del sector m´vil. Sus objetivos son acelerar la in-
a nıas o
novaciń en las comunicaciones m´viles y ofrecer a los consumidores una experiencia
o o
m´s rica, menos cara y mejor.
a
Con estos prop´sitos, dentro de las empresas que la forman, hay fabricantes de
o
terminales m´viles (Samsung, LG, Htc y Motorola), componentes (Texas Instru-
o
ments, Intel, Nvidia etc.), software (PV, EBay, Esmertec etc.), operadores de todo el
mundo (T-Mobile, Italia Telecom, China Mobile etc.) y tambiń empresas de com-
e
ercializaciń. [44]
o
En Chile, Android es comercializado por las tres principales operadores de tele-
fon´ m´vil, Claro Chile [6], Entel [8] y Movistar [17].
ıa o
El hecho de que hayan importantes multinacionales dentro de la alianza nos hace
ver que hay un gran equipo detr´s de este proyecto, el que se ha hecho notar en estos
a
m´s de 18 meses desde el lanzamiento oficial.
a

2.3.2. FLOSS

Android ha nacido con una filosof´ de c´digo abierto, esperando que progra-
ıa o
madores de todo el mundo contribuyan de manera libre al constante desarrollo del
sistema operativo. Adem´s, Google tambiń deja libertad a los fabricantes para que
a e
desarrollen aplicaciones para sus tel´fonos y no descarta la opciń de que haya em-
e o
presas que cobren por los programas que desarrollen. De hecho, cualquier operadora
puede vender terminales con Android, siempre que se cumpla con lo siguiente:

CAP´ ´

Precio bajo

Acceso abierto a Internet

Libertad del usuario para descargar cualquier aplicaciń
o
Para que los programadores puedan desarrollar, Google dispone de una p´gina a
Web para que los usuarios puedan descargar el SDK, manuales, ver ejemplos y leer
instrucciones para familiarizarse con la plataforma. Algo realmente l´gico si quieren
o
programadores que se predispongan a programar de manera voluntaria. [44]

2.3.3. Caracter´
ısticas

Las caracter´
ısticas m´s importantes de la plataforma Android son:
a
Framework de aplicaciones: un framework que tiene como objetivo reusar y
reemplazar componentes de software

M´quina virtual Dalvik: una m´quina virtual optimizada para dispositivos
a a
m´viles
o

Navegador integrado: un Web-browser basado en el engine de c´digo abierto
o
WebKit

Gr´ficos optimizados: potenciado por una librer´ gr´fica 2D, y gr´ficos 3D
a ıa a a
basados en la especificaciń OpenGL ES 1.0 (aceleraciń en hardware opcional)
o o

SQLite: un sistema de base de datos para almacenar informaciń estructurada
o

Soporte Multimedia: una librer´ multimedia para reproducir audio, video e
ıa
im´genes (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF)
a

Telefon´ GSM
ıa

Bluetooth, EDGE, 3G, y WiFi

C´mara, GPS, br´ jula, y aceler´metro
a u o

Ambiente de desarrollo enriquecido: Android ofrece un entorno de desarrollo
que incluye un emulador, herramientas para la depuraciń y un plugin para
o
Eclipse IDE

Pantalla tćtil
a

CAP´ ´

2.3.4. Arquitectura

La arquitectura de Android est´ formada por capas de software, donde cada una
a
puede utilizar los servicios de la capa inferior.
La Figura 2.10 muestra los componentes m´s importantes de Android, los que se
a
detallan luego.

Figura 2.10: Arquitectura del sistema operativo Android. Fuente: Android Developers

Aplicaciones

Esta es la capa m´s alta en la arquitectura de Android, es la capa con la cual los
a
usuarios interact´ an.
u
En la secci´n “application” de la Figura 2.10 se muestran algunas de las apli-
o
caciones b´sicas que provee Android: un cliente de correo, SMS, calendario, mapas,
a
browser, contactos.
Las aplicaciones en esta capa son escritas usando Java como lenguaje de progra-
maci´n.
o

CAP´ ´

Framework de aplicaciones

Esta secciń contiene las APIs utilizadas por las aplicaciones, que son de completo
o
acceso para los desarrolladores.
La estructura de Android est´ dise˜ ada para la re-utilizaciń, donde cualquier
a n o
aplicaciń pueda publicar sus capacidades y cualquier otra aplicaciń tenga acceso
o o
y use esas capacidades (sujeto a reglas de seguridad del framework). Este mismo
mecanismo permite que los componentes sean reemplazados por el usuario.
El framework de aplicaciones incluye:

Telephony manager: gestor de hardware del tel´fono
e

View system: Conjunto de vistas para poder desarrollar una aplicaciń, bus-
o
cadores, cajas de texto, botones etc. Algunos ejemplos son la “vista de mapas”
y la “vista de navegadores”

Content providers: Encapsula datos que son compartidos entre varias aplica-
ciones, como por ejemplo la agenda de tel´fono
e

Resource Manager: Administrador de recursos que permite acceder a recursos
como Strings, gr´ficos y archivos de layout
a

Notification Manager: Administrador de notificaciones para mostrar alertas.
Las aplicaciones pueden a˜ adir eventos en una barra de notificaciones
n

Activity Manager: Administrador de actividades, que maneja el ciclo de vida
de las aplicaciones y la navegaciń entre ellas
o

Location Manager: Servicio de localizaciń. Permite desarrollar aplicaciones
o
con capacidades de localizaciń geogr´fica con lo cual es posible recibir avisos,
o a
notificaciones, eventos etc., de un lugar espec´
ıfico o por nuestra localizacińo
actual. Una posibilidad de las much´
ısimas que se podr´ dar con esta API
ıan
ser´ que cada vez que nos acerc´semos a un cine, recibamos las novedades de
ıa a
´ste en nuestro tel´fono
e e

Servicio XMPP: Env´ de mensajes para aplicaciones entre terminales Android.
ıo
Se podr´ utilizar en juegos multiusuario por ejemplo
ıa

El “application framework” esta escrito en Java.

CAP´ ´

Librer´
ıas

Android incluye un conjunto de librer´ escritas en C/C++ que son usadas por
ıas
los componentes del sistema de Android, y que son expuestas a los desarrolladores por
medio del “application framework”. Algunas son: System C library (implementaciń o
librer´ C standard), librer´ de medios, librer´ de gr´ficos, 3D, SQLite, FreeType,
ıa ıas ıas a
entre otras.

Android Runtime

Esta capa es un set de librer´ base que proveen la mayor parte de las funcional-
ıas
idades disponibles en las librer´ base del lenguaje de programaciń Java.
ıas o
Cada aplicaciń es ejecutada en su propio proceso, junto con su propia m´quina
o a
virtual Dalvik. Dalvik est´ dise˜ ada para que un dispositivo m´vil pueda ejecutar
a n o
m´ ltiples instancias de Dalvik eficientemente.
u
Dalvik depende de Linux Kernel para las funcionalidades como threading y la
gestiń de memoria de bajo nivel.
o

Linux Kernel

Android es basado en Linux versiń 2.6 para sus servicios b´sicos, como seguridad,
o a
gestiń de memoria, gestiń de procesos, stack de red y modelo de drivers.
o o
El kernel act´ a tambiń como una capa de abstracciń entre el hardware y el
u e o
resto del stack de software.

2.3.5. Componentes de una aplicaciń en Android
o

Las aplicaciones en Android estń construidas utilizando componentes b´sicos
a a
que provee el SDK de Android.
Existen cuatro tipos diferentes de componentes, donde cada uno tiene distinto
prop´sito y distinto ciclo de vida, y que definen c´mo el componente es creado y
o o
destruido.

Actividades, la clase “Activity”
´
Este es, sin duda, el bloque de construcciń m´s utilizado. Una definiciń simple
o a o
de ´sta, ser´ la de una tarea que se lleva a cabo en la aplicaciń, que tiene interacciń
e ıa o o

CAP´ ´

con el usuario, es decir, una interfaz de usuario visual enfocada en la tarea en cuestiń.
o
T´ıpicamente tendremos una Activity como punto de entrada a nuestra aplicaciń. o
La mayor´ de las aplicaciones tienen pantallas m´ ltiples y cada vez que se accede
ıa u
a una nueva, la anterior es retenida y guardada en una pila. Gracias a esta pila el
usuario puede navegar “hacia atr´s” por las actividades que ya ha tenido activas.
a
Si Android lo considera oportuno, puede priorizar y quitar actividades de la pila
por cuestiones de memoria.
Las clases m´s comunes que extienden la clase Activity son:
a

MapActivity: encapsula toda la funcionalidad para mostrar un mapa

ListActivity: ayuda a mostrar una lista de elementos, y soporta la selecciń de
o
los elementos de esta

TabActivity: permite mostrar m´ ltiples Activity o Vistas dentro de una pan-
u
talla utilizando tabs para cambiar entre ellas

Servicios

El equivalente a un Daemon o un Servicio de Windows, no tiene una interfaz
de usuario visual, sino que se ejecuta en segundo plano por un per´
ıodo indefinido
de tiempo. Por ejemplo, un servicio puede reproducir m´ sica de fondo mientras el
u
usuario se ocupa de otros asuntos, o puede obtener datos sobre la red o calcular algo
y proporcionar el resultado a las actividades que lo requieran.

Broadcast receivers

Un “broadcast receiver” es un componente que no hace m´s que recibir y respon-
a
der a los anuncios o eventos de broadcast. Muchos vienen en el sistema, por ejemplo,
anuncios de que el timezone ha cambiado, que la bater´ est´ baja, que una imagen
ıa a
ha sido tomada, o que el usuario ha cambiado el idioma de preferencia.
Las aplicaciones tambiń pueden iniciar las emisiones o hacer anuncios, por ejem-
e
plo, que las aplicaciones de otros sepan que algunos datos se han descargado en el
equipo y estń disponibles para ser utilizados.
a

CAP´ ´

Content providers

Un “content provider” se usa cuando los datos de una aplicaciń se compartirń
o a
con otras aplicaciones. Esta clase implementa un conjunto de m´todos estńdar que
e a
permiten a otras aplicaciones recuperar y almacenar los datos de una aplicaciń.
o

2.3.6. Intent

Tres de los componentes de una aplicaciń: actividades, servicios, and broad-
o
cast receivers, se comunican o activan a trav´s de mensajes llamados Intents. Estos
e
mensajes pueden ser predefinidos ya sea por Android como “quiero llamar”, “quiero
abrir el navegador”, “quiero enviar un mail” o se pueden definir nuevos en nuestras
aplicaciones. Un Intent ser´ como “hacer un intento de algo” o decir “quiero hacer
ıa
tal cosa”.

2.3.7. Ciclo de vida

En Android, el sistema operativo es quien determina el ciclo de vida de una
aplicaciń y no esta ultima. Es decir, ´ste determina su duraciń en base a las partes
o ´ e o
de la aplicaciń que se estń ejecutando en ese momento, la importancia de estas
o a
´
para el usuario y la memoria disponible. Esta es una caracter´
ıstica importante y
poco usual. [2, 44]

2.3.8. Archivos Layout

En Android, las interfaces de usuario pueden ser construidas de dos maneras,
directamente invocando operaciones a las API desde las clases del programa, o a
trav´s de relacionar ´stas con archivos XML.
e e
La definiciń de la interfaz gr´fica de usuario en XML es muy preferible, porque,
o a
como se sabe en base al principio Modelo-Vista-Controlador, la interfaz de usuario
siempre debe estar separada de la l´gica del programa. Adem´s, la adaptaciń de un
o a o
programa a otra resoluciń de pantalla es mucho m´s fćil.
o a a
La definiciń de una interfaz de usuario en XML es muy similar a la creaciń de
o o
un documento HTML, donde cada etiqueta del ´rbol es un elemento del tipo View,
a
representado dentro de la pantalla del programa, con sus atributos correspondientes

CAP´ ´

que lo personalizan. De esta manera resulta mucho m´s r´pido y sencillo crear una
a a
interfaz de usuario. [44]

2.3.9. Archivos de recursos

Los recursos son archivos externos (no son de c´digo) que son utilizados por el
o
c´digo, adjuntados en su aplicaciń en tiempo de compilaciń. Android soporta un
o o o
gran n´ mero de diferentes tipos de archivos de recursos, incluyendo XML, PNG y
u
JPEG. Los archivos XML tienen formatos muy diferentes dependiendo de lo que
ellos describen, ya sean strings, arrays, layouts, etc.
Cada aplicaciń contiene un archivo de recursos llamado R.java. Este archivo hace
o
disponible los recursos por medio de sus propiedades, siendo estas de la forma R.tipo-
recurso.nombre-de-recurso. Por ejemplo, si un layout es creado para definir un View
llamado “MainScreen”se puede acceder como: setContentView(R.layout.MainScreen);

2.3.10. Archivo AndroidManifest.xml

El AndroidManifest.xml es un archivo necesario para cada aplicaciń en Android.
o
Se encuentra en la carpeta ra´ de la aplicaciń, y en ´l se describen los valores
ız o e
globales para el paquete, incluidos los componentes de la aplicaciń (actividades,
o
servicios, etc.) que el paquete expone al mundo exterior, los tipos que puede manejar
cada una de nuestras actividades, y c´mo pueden iniciarse estas.
o
Una cosa importante a mencionar de este archivo es que aqu´ se definen los
ı
IntentFilters. Estos filtros describen cuńdo y dńde una actividad se puede iniciar.
a o
Adem´s, se declaran los permisos que la aplicaciń debe tener para poder acceder
a o
a partes protegidas de la API y para poder interactuar con otras aplicaciones.
En otras palabras, este archivo dice al sistema qu´ es lo que hay para hacer, con
e
qu´ capacidad y qu´ componentes utiliza.
e e

2.4. Servicios Web

El consorcio W3C[28] define los servicios Web como sistemas de software dise˜ ados
n
para soportar una interacciń entre m´quinas en una red, interacciń que implica un
o a o
grado de interoperabilidad.

CAP´ ´

Un servicio Web est´ formado por un conjunto de protocolos y estńdares abier-
a a
tos, que definen una interfaz, a trav´s de la cual se comunican dos o m´s m´quinas,
e a a
independiente del lenguaje de programaciń en que estń dise˜ adas, o el sistema
o e n
operativo sobre el que se ejecuten.
Existen distintos tipo de servicios Web, donde los m´s comunes son SOAP, REST
a
y RPC.

2.4.1. SOAP

SOAP es un protocolo que proporciona un mecanismo estńdar de empaque-
a
tamiento de mensajes. Este protocolo est´ pensado para el intercambio de informa-
a
ciń en entornos descentralizados y distribuidos, que ha sido desarrollado para ser
o
independiente de cualquier modelo de programaciń.[39, 25, 43]
o
La forma de describir la interfaz se realiza por medio de los llamados lenguajes de
descripciń de servicios Web, que deben ser sintćticamente manejables y permitir
o a
expresar la mayor informaciń semńtica posible. El lenguaje m´s usado es el Web
o a a
Service Description Language (WSDL).
A continuaciń se comentan las ventajas y desventajas de este protocolo:
o
Ventajas:

• Al ser usado sobre HTTP permite una comunicaciń sencilla a trav´s de
o e
proxies y firewalls
• Su versatilidad le permite funcionar sobre diferentes protocolos de trans-
porte adem´s de HTTP, como por ejemplo SMTP
a
• Es independiente de cualquier plataforma
• Es independiente de cualquier lenguaje de programaciń
o
• Es simple y extensible

Desventajas:

• Al utilizar XML, SOAP puede ser considerablemente m´s lento en relaciń
a o
a otros protocolos como CORBA. Esto no es un inconveniente para men-
sajes peque˜ os, pero s´ cuando crece el tama˜ o del mensaje
n ı n
• Cuando se utiliza sobre HTTP, los roles de los extremos son fijos, de forma
que solo el cliente puede acceder a los servicios del servidor y no viceversa

CAP´ ´

2.4.2. REST

“La Transferencia del Estado Representacional (Representational State Transfer
o REST) es una tćnica de arquitectura software para sistemas distribuidos basados
e
en hipermedia como es la Web. El t´rmino se utiliza para referirse al estilo arqui-
e
tectńico de la Web y se acu˜ ´ en el a˜ o 2000, en la tesis doctoral de Roy T. Fielding,
o no n
autor adem´s de la especificaciń del protocolo HTTP, de la especificaciń de URI y
a o o
del documento del W3C sobre Arquitectura de la Web, y ha pasado a ser ampliamente
utilizado por la comunidad de desarrollo SOA”. [39]

Un concepto importante en REST es la existencia de recursos, cada uno de los
cuales puede ser accedido usando un identificador global, un URI. Como resultado,
el servidor devolver´ una representaciń del recurso, no el recurso en s´ por ejemplo,
a o ı,
si el recurso es un c´
ırculo el servidor podr´ responder con un fichero vectorial en
ıa
formato SVG que representa el c´ ırculo indicando el punto central y un radio.

Ventajas de REST:

Mejores tiempos de respuesta y disminuciń de carga en el servidor
o

Mayor escalabilidad al no requerir mantenimiento de estado

Facilita el desarrollo de clientes

Mayor estabilidad frente a futuros cambios

Permite evoluciń independiente de los tipos de documentos
o

La creaciń de nuevos tipos de documentos no afecta a los anteriores
o

2.4.3. RPC

RPC, acrńimo de Remote Procedure Call (Llamada a Procedimientos Remotos
o
en espa˜ ol) es una tecnolog´ que permite ejecutar una subrutina o procedimiento en
n ıa
otra m´quina a trav´s de una red. Si el software en cuestiń est´ escrito utilizando
a e o a
el paradigma de la orientaciń a objetos, a esta operaciń se le llama invocaciń
o o o
remota.
RPC es el m´todo m´s antiguo de invocaciń de m´todos remotos, y sigue el
e a o e
modelo cliente-servidor, la comunicaciń es iniciada por el cliente, quien env´ un
o ıa

CAP´ ´

mensaje de peticiń a un servidor remoto, con el fin de ejecutar un procedimiento
o
espec´
ıfico, usando ciertos par´metros.
a

2.5. Realidad aumentada

La realidad aumentada o augmented reality en ingl´s, tiene como objeto combinar
e
el ambiente real con objetos sint´ticos, interactivos, generados por computador. De
e
esta manera, el ambiente real es enriquecido o guiado con objetos virtuales, que
resultan de mayor utilidad a los usuarios.
Este aumento consiste en objetos virtuales que se a˜ aden al entorno o en informa-
n
ciń no geom´trica sobre los objetos reales existentes. Idealmente, el usuario percibe
o e
que los objetos reales y virtuales coexisten en el mismo espacio. [36]
La realidad aumentada mantiene el mundo real del usuario enriquecińdolo con
e
la presencia de elementos virtuales la que se diferencia de la realidad virtual, ya que
esta ultima permite la inmersiń del usuario en un mundo artificial que sustituye
´ o
completamente al mundo real del usuario.
Seg´ n Azuma[30], existen tres requerimientos que un sistema debe cumplir para
u
ser considerado como de realidad aumentada:

Combinar lo real y virtual

Interacciń en tiempo real
o

Registrado en 3D

3. Metodolog´
ıa

En este cap´ıtulo se describe la metodolog´ de desarrollo utilizada, detallando la
ıa
ventajas de ´sta. Adem´s, se listan los documentos esperados en cada una de las
e a
etapas de desarrollo.

3.1. Descripciń de Metodolog´
o ıa

Un proceso de desarrollo de software es un m´todo de organizar las actividades
e
relacionadas con la creaciń, presentaciń y mantenimiento de los sistemas de soft-
o o
ware.
La metodolog´ de desarrollo a utilizar es llamada “ Proceso Unificado de Desar-
ıa
rollo”, apoyado por el libro “ UML y Patrones” [41] de Craig Larman.
El Proceso Unificado de Desarrollo es una metodolog´ agil, con ciclo de vida
ıa ´
iterativo e incremental para el proceso de desarrollo de software.
Un ciclo de vida iterativo se basa en el agrandamiento y perfeccionamiento se-
cuencial de un sistema a trav´s de m´ ltiples ciclos de desarrollo, an´lisis, dise˜ o,
e u a n
implementaciń y pruebas. El sistema crece al incorporar nuevas funciones en cada
o
iteraciń de ciclo de desarrollo.
o
En cada ciclo de desarrollo se implementa uno o m´s casos de uso o bien sus
a
versiones simplificadas (si el caso de uso es muy complejo como para ser abordado
en un s´lo ciclo). Los casos de uso deber´ clasificarse, y los que ocupen los niveles
o ıan
m´s altos han de abordarse en los ciclos iniciales de desarrollo.
a
Cada iteraciń es un ciclo de desarrollo que termina en la liberaciń de una versiń
o o o
parcial del producto final y cada iteraciń pasa a trav´s de todos los aspectos del
o e
desarrollo de software: an´lisis de requerimientos, dise˜ o, implementaciń, pruebas,
a n o
documentaciń y evaluaciń.
o o

37

CAP´
ITULO 3. METODOLOG´
IA 38

Los beneficios de la metodolog´ elegida son:
ıa

Mitigaciń temprana de riesgos altos
o

Progreso visible en las primeras etapas

Una temprana realimentaciń, favoreciendo la adaptaciń, que provoca un sis-
o o
tema m´s robusto que se ajusta m´s a las necesidades
a a

Facilita el reuso, porque es fćil identificar partes comunes dise˜ adas o imple-
a n
mentadas

Flexibilidad para el cambio

Los elementos son integrados progresivamente

3.1.1. Etapas del Proceso Unificado

Las etapas presentes en la metodolog´ de desarrollo de Proceso Unificado son
ıa
inicio, elaboraciń, construcciń y transiciń, las que se explican a continuaciń.
o o o o

Inicio

Durante esta fase se especifica una visiń general y b´sica del proyecto. Esencial-
o a
mente, en esta fase se responden las siguientes preguntas:

¿Qu´ es lo que el sistema har´ principalmente para cada uno de los usuarios
e a
potenciales?

¿Cu´l es la forma de la arquitectura central del sistema?
a

¿Cu´l es el plan y el costo de desarrollo del sistema?
a

Es recomendable el desarrollo en esta fase de los siguientes documentos (llamados
artefactos): visiń, descripciń complementaria y algunos casos de uso.
o o

CAP´
IA 39

Elaboraciń
o

En esta fase se refinan los documentos creados en la fase de inicio de ser necesario,
y se identifican la mayor´ de los requerimientos. Al final de esta fase, el desarrollador
ıa
est´ en posiciń de planear las actividades y estimar los recursos necesarios para
a o
completar el proyecto.
Los artefactos recomendados para esta fase son: modelo de dominio o conceptu-
al, arquitectura del sistema, arquitectura del software. Adem´s se implementan las
a
caracter´
ısticas m´s importantes y riesgosas.
a

Construcciń
o

Se empieza a construir cada parte del sistema, siguiendo la arquitectura central
antes dise˜ ada. En esta fase, el sistema debe crecer lo suficiente para ponerlo a
n
disposiciń de los usuarios para obtener opiniones y hacer los cambios pertinentes.
o
Se implementan de forma iterativa las funcionalidades que no se han abarcado
en la fase de elaboraciń, y se completan las ya comenzadas.
o
La pregunta es: ¿Cumple el sistema con la mayor´ de las necesidades de los
ıa
usuarios para liberar una primera versiń?.
o
El resultado de esta fase es el refinamiento de los diferentes documentos, y la
implementaciń completa del software.
o

Transiciń
o

Esta fase cubre el per´ıodo durante el cual el sistema se convierte en una versiń
o
beta. Durante esta fase, un cierto n´ mero de usuarios experimentados prueban el sis-
u
tema y reportan los defectos y deficiencias encontradas. Los desarrolladores corrigen
los problemas reportados e incorporan las mejoras sugeridas.
Se genera una serie de pruebas beta, para concluir con el despliegue final de la
aplicaciń. Una vez superadas las pruebas beta, se lanza la aplicaciń para su puesta
o o
en producciń.
o

3.1.2. Disciplinas

La metodolog´ se organiza en disciplinas o flujos de trabajo. Una disciplina es
ıa
un conjunto de actividades realizadas en un ´rea determinada.
a

CAP´
IA 40

A continuaciń se listan las disciplinas utilizadas en el proceso de desarrollo de
o
esta memoria.

Modelado del negocio: La creaciń del modelo de negocio
o

Requisitos: La clarificaciń de los requerimientos, manifestado en los siguientes
o
documentos: visiń, casos de uso, especificaciń complementaria y glosario
o o

Dise˜ o: La especificaciń del dise˜ o de software
n o n

Implementaciń: Realizaciń de la implementaciń de software
o o o

Pruebas: El testing del software desarrollado

3.2. Patrones de dise˜ o
n

Un patrń se puede describir como una descripciń de un problema en el dise˜ o
o o n
orientados a objetos y la soluciń de ´ste, a este par problema/soluciń se le da un
o e o
nombre, por ejemplo el patrń “Creador”. [41]
o

3.2.1. Patrones GRASP

En esta secciń se presentan algunos patrones GRASP.
o

Creador ¿Quiń deber´ ser responsable de crear una nueva instancia de alguna
e ıa
clase?

Bajo acoplamiento ¿C´mo dar soporte a una dependencia escasa y a un aumento
o
de la reutilizaciń?
o

Alta cohesiń ¿C´mo mantener la complejidad dentro de l´
o o ımites manejables?

Controlador ¿Quiń deber´ encargarse de atender un evento del sistema?
e ıa

Polimorfismo ¿C´mo manejar las alternativas basadas en el tipo? ¿De qu´ manera
o e
crear componentes de software conectables?

Fabricaciń pura ¿A quiń asignar la responsabilidad cuando uno est´ desespera-
o e a
do y no quiere violar los patrones Alta Cohesiń y Bajo Acoplamiento?
o

CAP´
IA 41

Indirecciń ¿A quiń se asignarń las responsabilidades a fin de evitar el acoplamien-
o e a
to directo?

No hables con extra˜ os ¿A quiń asignar las responsabilidades para evitar cono-
n e
cer la estructura de los objetos indirectos?

Para mayor detalle de los patrones GRASP ver libro “ UML y Patrones” [41] de
Craig Larman.

3.2.2. Patrones GOF

En 1994 se public´ el libro “Design Patterns: Elements of Reusable Object Orient-
o
ed Sofware” [35] escrito por los ahora famosos Gang of Four (GoF, que en espa˜ ol es
n
la pandilla de los cuatro) formada por Erich Gamma, Richard Helm, Ralph Johnson
y John Vlissides. Ellos recopilaron y documentaron 23 patrones de dise˜ o aplicados
n
usualmente por expertos dise˜ adores de software orientado a objetos.
n
En esta secciń presentan algunos de los m´s importantes patrones GOF.
o a

Factor´ Define una interfaz para crear un objeto, pero deja que sean las subclases
ıa
quienes decidan qu´ clase instanciar. Permite que una clase delegue en sus
e
subclases la creaciń de objetos.
o

Singleton Garantiza que una clase s´lo tenga una instancia, y proporciona un punto
o
de acceso global a ella.

Fachada Proporciona una interfaz unificada para un conjunto de interfaces de un
sistema. Define una interfaz de alto nivel que hace que el subsistema sea mas
fćil de usar.
a

Patron Chain of Responsability Evita acoplar el emisor de una peticiń a su
o
receptor, al dar a m´s de un objeto la posibilidad de responder a la peticiń.
a o
Crea una cadena con los objetos receptores y pasa la peticiń a trav´s de la
o e
cadena hasta que esta sea tratada por alg´ n objeto.
u

Para mayor detalle de los patrones GOF ver libro “ Design patterns: elements of
reusable object-oriented software” [35].

CAP´
IA 42

3.2.3. Patrones arquitectńicos
o

Los Patrones arquitectńicos especifican un conjunto predefinido de subsistemas
o
con sus responsabilidades y una serie de recomendaciones para organizar los distintos
componentes. [34]
En esta secciń se presentan algunos patrones arquitectńicos de software.
o o

Capas El software se estructura en capas, lo que permite ocultar las tecnolog´ que
ıas
usa nuestro software, adem´s de hacer ´ste m´s tolerante a los cambios.
a e a

Tres Capas Este patrń divide el software en tres capas, donde cada una se co-
o
munica con la capa inmediatamente inferior, encapsulando la funcionalidad de
cada una de estas.

Presentaciń: es la que ve el usuario, esta capa se comunica unicamente
o ´
con la capa de negocio.
Negocio: es donde reside la l´gica e inteligencia. Se denomina capa de
o
negocio porque es aqu´ donde se establecen todas las reglas que deben
ı
cumplirse. Esta capa se comunica con la capa de presentaciń, para recibir
o
las solicitudes y presentar los resultados, y con la capa de datos, para
solicitar al gestor de base de datos almacenar o recuperar datos de ´l.
e
Datos: es donde residen los datos. Est´ formada por uno o m´s gestores
a a
de bases de datos que realizan el almacenamiento, reciben solicitudes de
almacenamiento o recuperaciń de informaciń desde la capa de negocio.
o o

Modelo-Vista-Controlador (MVC) Separaciń clara entre el modelo (l´gica de
o o
negocio) y la vista (interfaz gr´fica), gracias a un controlador que los mantiene
a
desacoplados. Para el dise˜ o de aplicaciones con sofisticadas interfaces se utiliza
n
el patrń de dise˜ o Modelo-Vista-Controlador. La l´gica de una interfaz de
o n o
usuario cambia con m´s frecuencia que los almacenes de datos y la l´gica de
a o
negocio. Si realizamos un dise˜ o ofuscado, es decir, que mezcle los componentes
n
de interfaz y de negocio, entonces la consecuencia ser´ que, cuando necesitemos
a
cambiar la interfaz, tendremos que modificar trabajosamente los componentes
de negocio. Mayor trabajo y m´s riesgo de error. [45]
a

CAP´
IA 43

3.2.4. Otros patrones

Patrń Data Access Object o Data Access Component El problema que viene
o
a resolver este patrń es el de contar con diversas fuentes de datos. De tal forma
o
que se encapsula la forma de acceder a la fuente de datos. [7, 46]

Patrń Page-by-Page Iterator, Value List Handler Proporciona un modo de
o
acceder secuencialmente a los elementos de un objeto agregado sin exponer su
representaciń interna. [45]
o

4. An´lisis
a

Este cap´ıtulo comienza presentando los requisitos que el sistema debe cumplir, en
los que se detallan y clasifican las necesidades de los usuarios; despu´s se muestra una
e
descripciń del comportamiento del sistema bajo distintos escenarios utilizando los
o
casos de uso; luego se presenta el modelo conceptual, el que muestra los conceptos del
mundo real, y las relaciones entre estos, y para finalizar se muestran los diagramas
de secuencia y contratos del sistema.

4.1. Resumen de las caracter´
ısticas del sistema

Esta secciń resume los requisitos del juego:
o

El sistema debe permitir gestionar competidores y almacenar su informaciń
o

El sistema debe permitir gestionar administradores y almacenar su informaciń
o

El sistema debe permitir gestionar equipos de competidores y almacenar su
informaciń
o

El sistema debe permitir la utilizaciń del GPS para determinar la posiciń de
o o
un usuario, objeto o lugar para as´ poder georeferenciar ´ste
ı e

El sistema debe almacenar informaciń de pistas y metas
o

El sistema debe permitir georeferenciar pistas, metas, competidores y admin-
istradores

El sistema debe mostrar la localizaciń de los competidores en el mapa
o

El sistema debe permitir la comunicaciń entre competidores
o

44

Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android

Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android

Recommended

Recommended

More Related Content

What's hot

What's hot (11)

Viewers also liked

Viewers also liked (20)

Similar to Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android

Similar to Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android (20)

Recently uploaded

Recently uploaded (10)

Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android