Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android

2,006 views

Published on

A multiplayer collaborative GPS game(proof of concept) implementing a SOA architecture, developed as part of a Computer Science Thesis http://dspace.utalca.cl/handle/1950/8674

http://www.slideshare.net/jpizarrom/desarrollo-de-un-sistema-de-juego-ubicuo-bajo-plataforma-android
https://www.slideshare.net/jpizarrom/memoria-18433248
http://youtu.be/IsscoCBuBCI
https://github.com/jpizarrom/thserver-game

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,006
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android

  1. 1. 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 MUNOZProfesor Gu´ JORGE EDUARDO BUSTOS BUSTOS ıa:Memoria para optar al t´ ıtulo deIngeniero Civil en Computaci´n oCuric´ – Chile o27 de julio de 2012
  2. 2. 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 MUNOZProfesor Gu´ JORGE EDUARDO BUSTOS BUSTOS ıa: ´Profesor Informante: RODOLFO SEBASTIAN ALLENDES OSORIOProfesor Informante: FELIPE ANDRES BESOA´ PINO ´ INMemoria para optar al t´ ıtulo deIngeniero Civil en Computaci´n oCuric´ – Chile o27 de julio de 2012
  3. 3. Dedicado a mi familia y cercanos.i
  4. 4. TABLA DE CONTENIDOS p´gina aDedicatoria ITabla de Contenidos II´Indice de Figuras VI´Indice de Tablas XResumen XIAbstract XIIPalabras claves XIII1. Introducci´n o 14 1.1. Descripci´n 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´n del juego . . . . . . . . . . . . . . . . . . . . . . . o 16 1.4. Organizaci´n de la memoria . . . . . . . . . . . . . . . . . . . . . . . o 172. Marco Te´rico o 19 2.1. Computaci´n ubicua . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 o 2.2. Terminales m´viles . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 20 2.2.1. Evoluci´n 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
  5. 5. iii 2.3.5. Componentes de una aplicaci´n 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 363. Metodolog´ ıa 37 3.1. Descripci´n 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´nicos . . . . . . . . . . . . . . . . . . . . . o 42 3.2.4. Otros patrones . . . . . . . . . . . . . . . . . . . . . . . . . . 434. An´lisis a 44 4.1. Resumen de las caracter´ısticas del sistema . . . . . . . . . . . . . . . 44 4.2. Especificaci´n de requisitos . . . . . . . . . . . . . . . . . . . . . . . . o 45 4.3. Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.4. Especificaci´n 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´n de Casos de Uso . . . . . . . . . . . . . . . . . . o 61 4.5. Modelo conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.6. Diagrama de secuencia del sistema . . . . . . . . . . . . . . . . . . . 64 4.6.1. Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
  6. 6. iv 4.7. Contratos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.7.1. Contratos referentes a usuario . . . . . . . . . . . . . . . . . . 675. Dise˜ o n 70 5.1. Diagrama de Interacci´n . . . . . . . . . . . . . . . . . . . . . . . . . 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´n 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 . . . . . . . . . . . . 916. Implementaci´n o 94 6.1. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 94 6.2. Diagrama de Clases de la capa de presentaci´n . . . . . . . . . . . . . o 98 6.3. Diagrama de Secuencia de implementaci´n . . . . . . . . . . . . . . . 100 o 6.4. Persistencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 6.4.1. Base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 6.4.2. Clases persistentes . . . . . . . . . . . . . . . . . . . . . . . . 104 6.5. Comunicaci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
  7. 7. v 6.7. Paginas Web en Wicket . . . . . . . . . . . . . . . . . . . . . . . . . . 110 6.8. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 6.9. Implementaci´n 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 n7. Conclusiones y Trabajos Futuros 128Bibliograf´ ıa 131Glosario 134AnexosA. Especificaci´n complementaria o 141B. Casos de Uso 144C. Matriz de caracter´ ısticas de Casos de Uso 160D. Diagrama de Secuencia del sistema 161E. Contratos 169F. Diagrama de Interacci´n o 175G. Iteraciones 183
  8. 8. ´ INDICE DE FIGURAS p´gina a2.1. Entorno ubicuo. Fuente: http://www.tokyo-ubinavi.jp . . . . . . . . . 202.2. Estad´ ısticas de telefon´ m´vil en 2009. Fuente: INE . . . . . . . . . . ıa o 212.3. Proyectos nuevos por sistema operativo Fuente: Flurry Analytics . . . 222.4. Request de dispositivos m´viles en Noviembre de 2008 a la izquierda. o Fuente: AdMob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.5. Request de dispositivos m´viles en Junio de 2009 a la derecha. Fuente: o AdMob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.6. Request de dispositivos m´viles en Abril de 2010. Fuente: AdMob . . o 232.7. Ventas de terminales m´viles por sistema operativo en el segundo o cuarto de 2010. Fuente: Gartner . . . . . . . . . . . . . . . . . . . . . 232.8. Ventas de terminales m´viles por sistema operativo en 2010. Fuente: o Gartner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.9. HTC G1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.10. Arquitectura del sistema operativo Android. Fuente: Android Developers 284.1. Diagrama de casos de uso: Usuarios . . . . . . . . . . . . . . . . . . . 604.2. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . 614.3. Modelo Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.4. Diagrama de secuencias: Autenticarse CU 1.1 . . . . . . . . . . . . . 654.5. Diagrama de secuencias: Cambiar Contrase˜ a CU 1.3 . . . . . . . . . n 664.6. Diagrama de secuencias: Registrar Competidor CU 1.4 . . . . . . . . 664.7. Diagrama de secuencias: Actualizar localizaci´n CU 1.8 . . . . . . . o 675.1. Diagrama de interacci´n - Registrar Usuario, CU 1.4 . . . . . . . . . o 715.2. Diagrama de interacci´n - Autenticarse, CU 1.1 . . . . . . . . . . . . o 725.3. Diagrama de interacci´n - Cambiar contrase˜ a, CU 1.3 . . . . . . . . o n 725.4. Diagrama de interacci´n - Buscar usuarios, CU 1.6 . . . . . . . . . . o 735.5. Diagrama de Clases de Dise˜ o . . . . . . . . . . . . . . . . . . . . . . n 745.6. Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . . . . 755.7. Diagrama de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . 765.8. Arquitectura del Software: modelo tres capas . . . . . . . . . . . . . . 78 vi
  9. 9. vii5.9. Arquitectura del Software de cliente Android . . . . . . . . . . . . . . 795.10. Arquitectura del Software de servidor . . . . . . . . . . . . . . . . . . 815.11. Entidades del subsistema de usuario . . . . . . . . . . . . . . . . . . . 825.12. Entidades del subsistema de equipo . . . . . . . . . . . . . . . . . . . 835.13. Entidades del subsistema de mensajer´ . . . . . . . . . . . . . . . . . ıa 835.14. Entidades del subsistema de lugar . . . . . . . . . . . . . . . . . . . . 845.15. Entidades del subsistema de juego . . . . . . . . . . . . . . . . . . . . 845.16. Managers del subsistema de usuario . . . . . . . . . . . . . . . . . . . 855.17. Managers del subsistema de juego . . . . . . . . . . . . . . . . . . . . 855.18. Diagrama Entidad Relaci´n - componente de juegos . . . . . . . . . . o 875.19. Accessor del subsistema de usuario . . . . . . . . . . . . . . . . . . . 885.20. Accessor del subsistema de juego . . . . . . . . . . . . . . . . . . . . 895.21. Diagrama de estados de un juego . . . . . . . . . . . . . . . . . . . . 905.22. Diagrama de estados de una pista . . . . . . . . . . . . . . . . . . . . 915.23. Diagrama de estados para las pantallas . . . . . . . . . . . . . . . . . 925.24. Diagrama de estados para las actividades del cliente Android . . . . . 926.1. Arquitectura SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.2. Arquitectura del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . 976.3. Diagrama de Clases del Cliente Android . . . . . . . . . . . . . . . . 986.4. Diagrama de Clases del Servidor . . . . . . . . . . . . . . . . . . . . . 996.5. Diagrama de Secuencia del Cliente Android . . . . . . . . . . . . . . 1016.6. Diagrama de Secuencia del servidor . . . . . . . . . . . . . . . . . . . 1026.7. Dependencias Servicio, Accessor, Entidad . . . . . . . . . . . . . . . . 1186.8. Arquitectura f´ ısica del software . . . . . . . . . . . . . . . . . . . . . 1206.9. Diagrama de paquetes de la librer´ gen´rica . . . . . . . . . . . . . . 121 ıa e6.10. Diagrama de paquetes de la librer´ gen´rica del servidor . . . . . . . 122 ıa e6.11. Diagrama de paquetes de la librer´ del sub-sistema juego . . . . . . . 124 ıa6.12. Diagrama de paquetes de la implementaci´n del servidor del sub- o sistema juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256.13. Diagrama de paquetes de la implementaci´n REST del juego . . . . . 125 o6.14. Diagrama de paquetes de la implementaci´n Axis del juego . . . . . . 126 o6.15. Diagrama de paquetes de la implementaci´n Web del juego . . . . . . 126 o6.16. Diagrama de paquetes del Cliente Android . . . . . . . . . . . . . . . 127
  10. 10. viiiB.1. Diagrama de casos de uso: Equipos . . . . . . . . . . . . . . . . . . . 146B.2. Diagrama de casos de uso: Lugares y pistas . . . . . . . . . . . . . . . 149B.3. Diagrama de casos de uso: Juego . . . . . . . . . . . . . . . . . . . . 155B.4. Diagrama de casos de uso: Comunicaci´n . . . . . . . . . . . . . . . . 156 oB.5. Diagrama de casos de uso: Localizaci´n y mapas . . . . . . . . . . . . 159 oD.1. Diagrama de secuencias: Vincular Competidor a Equipo CU 2.2 . . . 161D.2. Diagrama de secuencias: Crear Lugar(Pista) CU 3.1 . . . . . . . . . 162D.3. Diagrama de secuencias: Alertar Cercan´ CU 3.3 . . . . . . . . . . . 162 ıaD.4. Diagrama de secuencias: Comenzar Juego CU 4.1 . . . . . . . . . . . 163D.5. Diagrama de secuencias: Buscar juegos por Ciudad CU 4.3 . . . . . . 163D.6. Diagrama de secuencias: Buscar Juego CU 4.3 . . . . . . . . . . . . . 164D.7. Diagrama de secuencias: Buscar equipos por juego CU 4.7 . . . . . . 164D.8. Diagrama de secuencias: Ver Juego CU 4.8 . . . . . . . . . . . . . . 165D.9. Diagrama de secuencias: Recoger Pista CU 4.5 . . . . . . . . . . . . 165D.10.Diagrama de secuencias: Enviar Mensaje a Compa˜ eros CU 5.1 . . . 166 nD.11.Diagrama de secuencias: Solicitar Ubicaci´n CU 6.4 . . . . . . . . . . 167 oD.12.Diagrama de secuencias: Mostrar mapa CU 6.1 . . . . . . . . . . . . 167D.13.Diagrama de secuencias: Ver ubicaci´n de compa˜ eros CU 6.2 . . . . 168 o nF.1. Diagrama de interacci´n - Vincularse a un equipo CU 2.2 . . . . . . 175 oF.2. Diagrama de interacci´n - Listar compa˜ eros CU 2.3 . . . . . . . . . 176 o nF.3. Diagrama de interacci´n - Ubicaci´n de compa˜ eros CU 6.2 . . . . . 176 o o nF.4. Diagrama de interacci´n - Crear un lugar(pista), CU 3.1 . . . . . . . 177 oF.5. Diagrama de interacci´n - Asociar pista a juego, CU 4.9 . . . . . . . 177 oF.6. Diagrama de interacci´n - Buscar Pista CU 3.2 . . . . . . . . . . . . 178 oF.7. Diagrama de interacci´n - Buscar juegos CU 4.3 . . . . . . . . . . . 178 oF.8. Diagrama de interacci´n - Buscar equipos por juego CU 4.7 . . . . . 179 oF.9. Diagrama de interacci´n - Recoger Pista CU 4.5 . . . . . . . . . . . 179 oF.10.Diagrama de interacci´n - Enviar mensaje y almacenar informaci´n, o o CU 5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180F.11.Diagrama de interacci´n - Asociar mensaje al remitente y destinatario, o CU 5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181F.12.Solicitar localizaci´n, CU 6.4 o . . . . . . . . . . . . . . . . . . . . . . 182
  11. 11. ixG.1. Interfaz Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189G.2. Cliente Android para test de comunicaci´n con el servidor . . . . . . 190 oG.3. Mapa en cliente Android . . . . . . . . . . . . . . . . . . . . . . . . . 191G.4. Actividades del Cliente Android . . . . . . . . . . . . . . . . . . . . . 193
  12. 12. ´ INDICE DE TABLAS p´gina a2.1. Especificaci´n de HTC G1 . . . . . . . . . . . . . . . . . . . . . . . . o 254.1. Caracter´ısticas para determinar la prioridad de los casos de uso . . . 624.2. Priorizaci´n de casos de uso . . . . . . . . . . . . . . . . . . . . . . . o 624.3. Descripci´n de conceptos del modelo conceptual . . . . . . . . . . . . o 645.1. Descripci´n de los paquetes de la librer´ gen´rica del servidor . . . . o ıa e 775.2. Descripci´n de estados de un juego . . . . . . . . . . . . . . . . . . . o 905.3. Descripci´n de estados de una pista . . . . . . . . . . . . . . . . . . . o 916.1. Descripci´n de la Arquitectura del Sistema . . . . . . . . . . . . . . . 97 o6.2. Descripci´n de los paquetes de la librer´ gen´rica . . . . . . . . . . . 121 o ıa e6.3. Descripci´n de los paquetes de la librer´ gen´rica del servidor . . . . 123 o ıa e6.4. Descripci´n de los paquetes de la librer´ del sub-sistema juego . . . . 124 o ıa6.5. Descripci´n de los paquetes de la implementaci´n del servidor del sub- o o sistema juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256.6. Descripci´n de los paquetes de la implementaci´n REST del juego . . 126 o o6.7. Descripci´n de los paquetes de la implementaci´n Axis del juego . . . 126 o o6.8. Descripci´n de los paquetes de la implementaci´n Web del juego . . . 126 o o6.9. Descripci´n de los paquetes de la implementaci´n del cliente Android 127 o oC.1. Tabla de caracter´ ısticas de priorizaci´n de casos de uso . . . . . . . . 160 o x
  13. 13. RESUMEN El desarrollo de las telecomunicaciones e interfaces de usuarios, junto con ladisminuci´n en el tama˜ o de dispositivos y piezas electr´nicas nos permiten hoy o n oestar conectados en cualquier lugar y momento, facilitando las tareas que realizamoscotidianamente sin estar obligados a permanecer en alg´ n lugar en especifico, es uas´ que el crecimiento explosivo que ha tenido Android desde su lanzamiento en ı2008 y la disminuci´n en el costo de los smartphone’s nos permite tener hoy en d´ o ıadispositivos con variadas caracter´ ısticas, como lo son el GPS, pantalla t´ctil, br´ jula, a uc´maras de alta resoluci´n entre otros. a o Estas nuevas capacidades presentes hoy en nuestro bolsillo, nos perminten ex-plorar y comunicarnos con el ambiente, sac´ndonos de nuestras sillas y monitores, amezclando la realidad con lo virtual, en una nueva forma de enriquecer la experienciacon nuestro entorno y quienes nos rodean. En esta memoria se muestra el dise˜ o e implementaci´n de un juego ubicuo de n orealidad aumentada para entornos de exterior bajo plataforma Android con unaarquitectura basada en servicios Web. xi
  14. 14. ABSTRACT The development of telecommunications and user interfaces, the decrease in thesize of electronic devices and components, allow us today to be connected anywhereand anytime, facilitating the tasks we perform daily, without being forced to stayin a specific place. The explosive growth of Android since its launch in 2008 and adecrease in the cost of smartphones allows us nowadays to have devices with differentcharacteristics, such as GPS, touch screen, compass, high resolution cameras, amongothers. These new capabilities we carry out in our pockets, allow us to explore andcommunicate 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 gamefor ubiquitous outdoor environments under Android platform with an architecturebased on Web services. xii
  15. 15. PALABRAS CLAVESDesarrollo de software, Android, Servicio Web, API, Dispositivos m´viles, SOAP o xiii
  16. 16. 1. Introducci´n o La tecnolog´ aparatos electr´nicos, y redes comunicaci´n, han pasado a ser parte ıa, o ode nuestra vida cotidiana, utilizamos estos en nuestros hogares, trabajos y lugaresde esparcimiento, en nuestro tiempo libre y para actividades laborales. Es as´ que ı,aparatos electr´nicos como laptops, netbooks, smartphones, PDAs, entre muchos ootros nos ayudan a realizar una gran cantidad de las actividades que realizamosdiariamente, en cualquier lugar y en cualquier momento. El tama˜ o de estos aparatos electr´nicos se hace cada vez mas peque˜ o, aumen- n o ntando la portabilidad, adem´s estos se vuelven cada vez m´s intuitivos y baratos. a aEjemplo de esto es el paso de celulares del tama˜ o de una maleta de los a˜ os 70, a los n npeque˜ os aparatos que poseemos casi todos hoy en d´ Estos aparatos electr´nicos n ıa. opueden ser embebidos en casi cualquier tipo de objeto de una forma amigable, en au-tos, refrigeradores, sistemas de calefacci´n, ropa, y electrodom´sticos, por no hablar o ede diversos bienes de consumo. Tambi´n las posibilidades de conectividad entre los distintos dispositivos que eusamos ha mostrado un incremento considerable en los ultimos a˜ os, destacando ´ nen uso de tecnolog´ inal´mbricas como 3G, Bluetooth, 802.11 b/g/n, IR, Zigbee, ıas aentre otros, las que han disminuido sus costos y, aumentado sus alcances y expansi´n oterritorial, permitiendo estar comunicados con quienes nos rodean. La manera en la cual se interact´ a con el entorno est´ en constante cambio u adebido a las tecnolog´ cada vez m´s adsequibles y presentes en los dispositivos ıas autilizados, 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
  17. 17. CAP´ ´ ITULO 1. INTRODUCCION 15correo electr´nico, pasando por mensajes instant´neos, videoconferencia, juegos en o al´ ınea, hasta la Internet 2.0 que permite ofrecer aplicaciones sociales como Facebook[9] o Twitter [27].1.1. Descripci´n del problema o Las tecnolog´ detr´s de las consolas de videojuegos han permitido a los desar- ıas arolladores crear juegos con narrativas visuales inmersivas e interactivas, desafortu-nadamente, con ello los jugadores se han desconectado del medio ambiente y de lagente que los rodea. Esta desconexi´n se debe a la dependencia de los videojuegos ocon las pantallas, teniendo estas como su principal interfaz. Al participar en el juego,la unica conexi´n que se hace es entre el jugador y la pantalla. Por otra parte, mien- ´ otras m´s atractivo e inmersivo es el juego, m´s fuerte ser´ el v´ a a a ınculo entre el jugadory la pantalla. Mientras que los dispositivos m´viles, tales como Nintendo DS [18] o PlayStation oPortable [23], son capaces de sacar a los jugadores de sus casas, sufren del mismoproblema que las consolas de hogar. El jugador est´ atado a la pantalla, no importa ad´nde ellos est´n jugando, una vez que se forma la conexi´n con la pantalla, el mundo o a oque los rodea pasa a segundo plano. La interacci´n de las nuevas tecnolog´ y capacidades presentes en todo nuestro o ıasentorno, como por ejemplo, sensores de temperatura, proximidad, GPS, aceler´met- oros, entre otros, nos permiten desarrollar juegos que vuelvan a conectar al jugadorcon el ambiente y gente que lo rodea, adem´s de presentar una herramienta que apuede 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 ıasy capacidades en dispositivos con Sistema Operativo Android, una plataforma desoftware de c´digo abierto que incluye un sistema operativo para dispositivos m´viles o obasado en GNU/Linux, desarrollado por Google y por la Open Handset Alliance. Este´permite el desarrollo de aplicaciones por terceros, controlando los dispositivos pormedio de bibliotecas desarrolladas o adaptadas por Google.
  18. 18. CAP´ ´ ITULO 1. INTRODUCCION 16 Se desarrollar´ un juego ubicuo de estrategia, cuyo tablero de juego ser´ un a alugar f´ ısico, real, como lo puede ser un edificio, campus, ciudad, etc., permitiendo lainteracci´n real entre el ambiente y los jugadores, los cuales pertenecer´n a distintos o aequipos, teniendo una finalidad o meta unica. ´1.2.1. Objetivo general Dise˜ ar e implementar un juego ubicuo de realidad aumentada para entornos de nexterior 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) e1.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´n herramientas y librer´ licenciadas como Software Libre. a ıas1.3.1. Declaraci´n del juego o El juego a implementar es “En b´squeda del tesoro”, juego en equipo, donde el uobjetivo es buscar y encontrar un tesoro, el cual es un lugar geogr´fico, primero que alos equipos contrincantes, es por ello que los participantes se dividen en grupos desimilar n´ mero. u
  19. 19. CAP´ ´ ITULO 1. INTRODUCCION 17 Para poder encontrar el tesoro deben seguir una serie de pistas a lo largo deljuego, las cuales dan idea de a d´nde dirigirse, d´nde se encuentra la pr´xima pista, o o oy qu´ es y d´nde se encuentra el tesoro o meta. e o Los integrantes de los equipos pueden colaborar con sus compa˜ eros para realizar nlas tareas de b´ squeda y seguimiento de pistas con mayor agilidad, es por ello que use posibilitar´ la comunicaci´n entre estos, para as´ poder separarse y abarcar m´s a o ı aterreno. Como apoyo al proceso de b´ squeda y exploraci´n, se proveer´n mapas del es- u o apacio( ´rea de juego), e informaci´n georeferenciada de las pistas, a medida que las a odescubran, y de la localizaci´n de compa˜ eros de equipo. o n Cada equipo contar´ con una pista al comienzo del juego. El juego termina cuando aalg´ n participante alcanza el tesoro, y con esto el equipo al que pertenece ´ste, gana u ela partida en cuesti´n. o1.4. Organizaci´n de la memoria o La memoria ha sido divida en distintos cap´ ıtulos, los que se describen brevementea continuaci´n: oCap´ ıtulo 1 Es el cap´ ıtulo actual, en el se presenta la descripci´n 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. ıaCap´ ıtulo 4 Este cap´ ıtulo esta destinado al an´lisis de requisitos y especificaci´n 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
  20. 20. CAP´ ´ ITULO 1. INTRODUCCION 18Cap´ ı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´n del sistema y las iteraciones de desarrollo realizadas. oCap´ ıtulo 7 En este cap´ıtulo se muestran algunas conclusiones del trabajo. Tambi´n e se presentan algunas propuestas de trabajo a futuro.
  21. 21. 2. Marco Te´rico o En este cap´ ıtulo se explican los conceptos m´s importantes que sustentan el adesarrollo de esta memoria.2.1. Computaci´n ubicua o “Mark Weiser, en Septiembre de 1991 describi´ su visi´n de lo que el llamaba o ocomputaci´n ubicua. La esencia de su visi´n era la creaci´n de entornos repletos de o o ocomputaci´n y de capacidad de comunicaci´n, todo integrado de forma inapreciable o ojunto a las personas” [37, 49]. La visi´n de Weiser estaba bastante alejada de su ´poca, entre otras razones o eporque no exist´ la tecnolog´ necesaria para llevarla a cabo, pero despu´s de dos ıa ıa ed´cadas de progreso en el campo de los dispositivos Hardware, las criticadas ideas ede Weiser en 1991, ahora son productos comercialmente viables, prueba de ello esque hoy en d´ estamos rodeados de dispositivos tecnol´gicos, con los cuales interac- ıa otuamos 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, aimpregnando cada pensamiento, en ese preciso momento, el actor no esta conscientede que esta usando un computador y de que ´ste, tiene un sistema operativo. [31, 40] e La computaci´n ubicua (Ubiquitous computing, tambi´n conocida como pervasive o ecomputing, proactive computing, ambient computing, y en contextos relacionados,ambient intelligence) conecta a las redes de todo el mundo sin fronteras y proveeacceso r´pido y seguro a una gran cantidad de informaci´n y servicios, en cualquier a omomento y en cualquier lugar. [47] 19
  22. 22. CAP´ ´ ITULO 2. MARCO TEORICO 20 En otras palabras, un sistema ubicuo es un entorno o ambiente con elementos dec´mputo interconectados, interoperables y que interaccionan con el mundo real de oforma imperceptible para los usuarios, apoyando al desempe˜ o de tareas cotidianas. n Algunas de las tecnolog´ que hacen posible la computaci´n ubicua que podemos ıas onombrar son computadores de bolsillo, redes inal´mbricas, sensores muy avanzados ay computaci´n vestible. o La Figura 2.1 muestra la integraci´n de los sistemas ubicuos en nuestro entorno, ofacililando as´ actividades cotidianas como ir de visita a un zool´gico. ı o Figura 2.1: Entorno ubicuo. Fuente: http://www.tokyo-ubinavi.jp2.2. Terminales m´viles o Los dispositivos m´viles poseen actualmente una gran capacidad de procesamien- oto, almacenamiento y conexi´n a distintas redes en casi cualquier parte del mundo. o Adem´s presentan capacidades de geolocalizaci´n por sat´lite, br´ julas electr´nicas, a o e u oaceler´metros, c´mara, y la posibilidad de conectar distintos sensores. El hacer uso de o aestas nuevas capacidades nos permite desarrollar juegos que mantengan en contactoa personas con el ambiente los rodea. [33]
  23. 23. CAP´ ´ ITULO 2. MARCO TEORICO 212.2.1. Evoluci´n en el mercado o Hoy en d´ es muy com´ n que una persona tenga un dispositivo m´vil, de entre ıa u olos 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 uel n´ mero de tel´fonos m´viles en Chile super´ los 17 millones de unidades y si se u e o oconsidera el n´ mero de la poblaci´n estimada a Junio de 2009 en Chile (16.928.873), u ose puede decir que existen un poco m´s de un celular por habitante a dicha fecha. a Figura 2.2: Estad´sticas de telefon´a m´vil en 2009. Fuente: INE ı ı o Adem´s, durante los ultimos a˜ os, con el avance de estos peque˜ os dispositivos a ´ n nen procesamiento y conectividad, se ha incrementado a˜ o a a˜ o el acceso a Internet n nutilizando estos. Luego, como se puede apreciar en la Figura 2.3, existe un incremento relativoen el desarrollo de nuevos proyectos para el sistema operativo Android entre Enero
  24. 24. CAP´ ´ ITULO 2. MARCO TEORICO 22y Julio de 2009. Adem´s, se aprecia un decremento relativo en los proyectos para aiPhone 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 umes a mes, la tasa de crecimiento de Android se est´ acelerando, aumentando en am´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 aSmartphone a nivel mundial, se aprecia un incremento relativo considerable en eluso del sistema operativo Android. La Figura 2.4 muestra que el tr´fico de Android aen el mes de Noviembre de 2008 era del 1 %, mientras que el mes de Junio de 2009era de un 5 %, mostrado en la Figura 2.5. Este incremento relativo en el tr´fico ha aseguido en aumento hasta llegar a un 25 % en el mes de Abril de 2010, como seaprecia en la Figura 2.6.
  25. 25. CAP´ ´ ITULO 2. MARCO TEORICO 23Figura 2.4: Request de dispositivos m´viles en Noviembre de 2008 a la izquierda. Fuente: oAdMobFigura 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 omundiales 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 esistema operativo Android durante dicho periodo, lo que representa un 17,2 %, encomparaci´n con 8.74 millones tel´fonos con iOS, que representa un 14,2 % de cuota o ede mercado del per´ ıodo en estudio. Los m´s vendidos son a´ n Symbian, con el 41,2 % a udel mercado y RIM con el 18,2 % del mercado, en dicho per´ ıodo.
  26. 26. CAP´ ´ ITULO 2. MARCO TEORICO 24Figura 2.7: Ventas de terminales m´viles por sistema operativo en el segundo cuarto de o2010. Fuente: Gartner Luego, en febrero de 2011 Gartner[11] inform´, como se aprecia en la Figura 2.8, oque las ventas totales de smartphones con sistema operativo Android durante el a˜ o n2010 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 o2.2.2. HTC G1 La aplicaci´n m´vil desarrollada en la presente memoria est´ destinada a dis- o o apositivos que tengan el Sistema Operativo Android 1.6 o superior, es por ello quese tendr´ como dispositivo de pruebas y desarrollo al terminal m´vil “HTC G1”, a omostrado en la Figura 2.9, y que cuenta con las especificaciones t´cnicas mostradas een el Cuadro 2.1.
  27. 27. CAP´ ´ ITULO 2. MARCO TEORICO 25 Figura 2.9: HTC G1 Procesador Qualcomm R MSM7201ATM , 528 MHz Memoria ROM: 256 MB, RAM: 192 MB Pantalla Pantalla plana t´ctil 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´n 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´n de HTC G1 o
  28. 28. CAP´ ´ ITULO 2. MARCO TEORICO 262.3. Plataforma Android Android [2] es una plataforma de software de c´digo abierto para dispositivos om´viles, desarrollado por Google y por la Open Handset Alliance[19]. o Incluye un sistema operativo basado en GNU/Linux, middleware y aplicacionesclaves, adem´s de un entorno de desarrollo, Android SDK[3], que provee las her- aramientas y APIs necesarias para comenzar el desarrollo de aplicaciones utilizandoel lenguaje de programaci´n Java. o2.3.1. Open Handset Alliance Creada y fundada por Google, la Open Handset Alliance naci´ para el desarrollo oe implementaci´n de Android en terminales m´viles. Actualmente est´ formada por o o am´s de 70 compa˜´ o empresas del sector m´vil. Sus objetivos son acelerar la in- a nıas onovaci´n en las comunicaciones m´viles y ofrecer a los consumidores una experiencia o om´s rica, menos cara y mejor. a Con estos prop´sitos, dentro de las empresas que la forman, hay fabricantes de oterminales m´viles (Samsung, LG, Htc y Motorola), componentes (Texas Instru- oments, Intel, Nvidia etc.), software (PV, EBay, Esmertec etc.), operadores de todo elmundo (T-Mobile, Italia Telecom, China Mobile etc.) y tambi´n empresas de com- eercializaci´n. [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 hacever que hay un gran equipo detr´s de este proyecto, el que se ha hecho notar en estos am´s de 18 meses desde el lanzamiento oficial. a2.3.2. FLOSS Android ha nacido con una filosof´ de c´digo abierto, esperando que progra- ıa omadores de todo el mundo contribuyan de manera libre al constante desarrollo delsistema operativo. Adem´s, Google tambi´n deja libertad a los fabricantes para que a edesarrollen aplicaciones para sus tel´fonos y no descarta la opci´n de que haya em- e opresas que cobren por los programas que desarrollen. De hecho, cualquier operadorapuede vender terminales con Android, siempre que se cumpla con lo siguiente:
  29. 29. CAP´ ´ ITULO 2. MARCO TEORICO 27 Precio bajo Acceso abierto a Internet Libertad del usuario para descargar cualquier aplicaci´n o Para que los programadores puedan desarrollar, Google dispone de una p´gina aWeb para que los usuarios puedan descargar el SDK, manuales, ver ejemplos y leerinstrucciones para familiarizarse con la plataforma. Algo realmente l´gico si quieren oprogramadores 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´n OpenGL ES 1.0 (aceleraci´n en hardware opcional) o o SQLite: un sistema de base de datos para almacenar informaci´n 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´n y un plugin para o Eclipse IDE Pantalla t´ctil a
  30. 30. CAP´ ´ ITULO 2. MARCO TEORICO 282.3.4. Arquitectura La arquitectura de Android est´ formada por capas de software, donde cada una apuede utilizar los servicios de la capa inferior. La Figura 2.10 muestra los componentes m´s importantes de Android, los que se adetallan luego. Figura 2.10: Arquitectura del sistema operativo Android. Fuente: Android DevelopersAplicaciones Esta es la capa m´s alta en la arquitectura de Android, es la capa con la cual los ausuarios interact´ an. u En la secci´n “application” de la Figura 2.10 se muestran algunas de las apli- ocaciones b´sicas que provee Android: un cliente de correo, SMS, calendario, mapas, abrowser, contactos. Las aplicaciones en esta capa son escritas usando Java como lenguaje de progra-maci´n. o
  31. 31. CAP´ ´ ITULO 2. MARCO TEORICO 29Framework de aplicaciones Esta secci´n contiene las APIs utilizadas por las aplicaciones, que son de completo oacceso para los desarrolladores. La estructura de Android est´ dise˜ ada para la re-utilizaci´n, donde cualquier a n oaplicaci´n pueda publicar sus capacidades y cualquier otra aplicaci´n tenga acceso o oy use esas capacidades (sujeto a reglas de seguridad del framework). Este mismomecanismo 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´n, 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´n entre ellas o Location Manager: Servicio de localizaci´n. Permite desarrollar aplicaciones o con capacidades de localizaci´n geogr´fica con lo cual es posible recibir avisos, o a notificaciones, eventos etc., de un lugar espec´ ıfico o por nuestra localizaci´no 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.
  32. 32. CAP´ ´ ITULO 2. MARCO TEORICO 30Librer´ ıas Android incluye un conjunto de librer´ escritas en C/C++ que son usadas por ıaslos componentes del sistema de Android, y que son expuestas a los desarrolladores pormedio del “application framework”. Algunas son: System C library (implementaci´n olibrer´ C standard), librer´ de medios, librer´ de gr´ficos, 3D, SQLite, FreeType, ıa ıas ıas aentre otras.Android Runtime Esta capa es un set de librer´ base que proveen la mayor parte de las funcional- ıasidades disponibles en las librer´ base del lenguaje de programaci´n Java. ıas o Cada aplicaci´n es ejecutada en su propio proceso, junto con su propia m´quina o avirtual Dalvik. Dalvik est´ dise˜ ada para que un dispositivo m´vil pueda ejecutar a n om´ ltiples instancias de Dalvik eficientemente. u Dalvik depende de Linux Kernel para las funcionalidades como threading y lagesti´n de memoria de bajo nivel. oLinux Kernel Android es basado en Linux versi´n 2.6 para sus servicios b´sicos, como seguridad, o agesti´n de memoria, gesti´n de procesos, stack de red y modelo de drivers. o o El kernel act´ a tambi´n como una capa de abstracci´n entre el hardware y el u e oresto del stack de software.2.3.5. Componentes de una aplicaci´n en Android o Las aplicaciones en Android est´n construidas utilizando componentes b´sicos a aque provee el SDK de Android. Existen cuatro tipos diferentes de componentes, donde cada uno tiene distintoprop´sito y distinto ciclo de vida, y que definen c´mo el componente es creado y o odestruido.Actividades, la clase “Activity” ´ Este es, sin duda, el bloque de construcci´n m´s utilizado. Una definici´n simple o a ode ´sta, ser´ la de una tarea que se lleva a cabo en la aplicaci´n, que tiene interacci´n e ıa o o
  33. 33. CAP´ ´ ITULO 2. MARCO TEORICO 31con el usuario, es decir, una interfaz de usuario visual enfocada en la tarea en cuesti´n. o T´ıpicamente tendremos una Activity como punto de entrada a nuestra aplicaci´n. o La mayor´ de las aplicaciones tienen pantallas m´ ltiples y cada vez que se accede ıa ua una nueva, la anterior es retenida y guardada en una pila. Gracias a esta pila elusuario 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 pilapor 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´n 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 ellasServicios El equivalente a un Daemon o un Servicio de Windows, no tiene una interfazde usuario visual, sino que se ejecuta en segundo plano por un per´ ıodo indefinidode tiempo. Por ejemplo, un servicio puede reproducir m´ sica de fondo mientras el uusuario se ocupa de otros asuntos, o puede obtener datos sobre la red o calcular algoy 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- ader 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 aha sido tomada, o que el usuario ha cambiado el idioma de preferencia. Las aplicaciones tambi´n pueden iniciar las emisiones o hacer anuncios, por ejem- eplo, que las aplicaciones de otros sepan que algunos datos se han descargado en elequipo y est´n disponibles para ser utilizados. a
  34. 34. CAP´ ´ ITULO 2. MARCO TEORICO 32Content providers Un “content provider” se usa cuando los datos de una aplicaci´n se compartir´n o acon otras aplicaciones. Esta clase implementa un conjunto de m´todos est´ndar que e apermiten a otras aplicaciones recuperar y almacenar los datos de una aplicaci´n. o2.3.6. Intent Tres de los componentes de una aplicaci´n: actividades, servicios, and broad- ocast receivers, se comunican o activan a trav´s de mensajes llamados Intents. Estos emensajes pueden ser predefinidos ya sea por Android como “quiero llamar”, “quieroabrir el navegador”, “quiero enviar un mail” o se pueden definir nuevos en nuestrasaplicaciones. Un Intent ser´ como “hacer un intento de algo” o decir “quiero hacer ıatal cosa”.2.3.7. Ciclo de vida En Android, el sistema operativo es quien determina el ciclo de vida de unaaplicaci´n y no esta ultima. Es decir, ´ste determina su duraci´n en base a las partes o ´ e ode la aplicaci´n que se est´n ejecutando en ese momento, la importancia de estas o a ´para el usuario y la memoria disponible. Esta es una caracter´ ıstica importante ypoco 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 atrav´s de relacionar ´stas con archivos XML. e e La definici´n de la interfaz gr´fica de usuario en XML es muy preferible, porque, o acomo se sabe en base al principio Modelo-Vista-Controlador, la interfaz de usuariosiempre debe estar separada de la l´gica del programa. Adem´s, la adaptaci´n de un o a oprograma a otra resoluci´n de pantalla es mucho m´s f´cil. o a a La definici´n de una interfaz de usuario en XML es muy similar a la creaci´n de o oun documento HTML, donde cada etiqueta del ´rbol es un elemento del tipo View, arepresentado dentro de la pantalla del programa, con sus atributos correspondientes
  35. 35. CAP´ ´ ITULO 2. MARCO TEORICO 33que lo personalizan. De esta manera resulta mucho m´s r´pido y sencillo crear una a ainterfaz de usuario. [44]2.3.9. Archivos de recursos Los recursos son archivos externos (no son de c´digo) que son utilizados por el oc´digo, adjuntados en su aplicaci´n en tiempo de compilaci´n. Android soporta un o o ogran n´ mero de diferentes tipos de archivos de recursos, incluyendo XML, PNG y uJPEG. Los archivos XML tienen formatos muy diferentes dependiendo de lo queellos describen, ya sean strings, arrays, layouts, etc. Cada aplicaci´n contiene un archivo de recursos llamado R.java. Este archivo hace odisponible 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 Viewllamado “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´n en Android. oSe encuentra en la carpeta ra´ de la aplicaci´n, y en ´l se describen los valores ız o eglobales para el paquete, incluidos los componentes de la aplicaci´n (actividades, oservicios, etc.) que el paquete expone al mundo exterior, los tipos que puede manejarcada 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´ndo y d´nde una actividad se puede iniciar. a o Adem´s, se declaran los permisos que la aplicaci´n debe tener para poder acceder a oa 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 equ´ capacidad y qu´ componentes utiliza. e e2.4. Servicios Web El consorcio W3C[28] define los servicios Web como sistemas de software dise˜ ados npara soportar una interacci´n entre m´quinas en una red, interacci´n que implica un o a ogrado de interoperabilidad.
  36. 36. CAP´ ´ ITULO 2. MARCO TEORICO 34 Un servicio Web est´ formado por un conjunto de protocolos y est´ndares abier- a atos, que definen una interfaz, a trav´s de la cual se comunican dos o m´s m´quinas, e a aindependiente del lenguaje de programaci´n en que est´n dise˜ adas, o el sistema o e noperativo sobre el que se ejecuten. Existen distintos tipo de servicios Web, donde los m´s comunes son SOAP, REST ay RPC.2.4.1. SOAP SOAP es un protocolo que proporciona un mecanismo est´ndar de empaque- atamiento de mensajes. Este protocolo est´ pensado para el intercambio de informa- aci´n en entornos descentralizados y distribuidos, que ha sido desarrollado para ser oindependiente de cualquier modelo de programaci´n.[39, 25, 43] o La forma de describir la interfaz se realiza por medio de los llamados lenguajes dedescripci´n de servicios Web, que deben ser sint´cticamente manejables y permitir o aexpresar la mayor informaci´n sem´ntica posible. El lenguaje m´s usado es el Web o a aService Description Language (WSDL). A continuaci´n se comentan las ventajas y desventajas de este protocolo: o Ventajas: • Al ser usado sobre HTTP permite una comunicaci´n 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´n o • Es simple y extensible Desventajas: • Al utilizar XML, SOAP puede ser considerablemente m´s lento en relaci´n 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
  37. 37. CAP´ ´ ITULO 2. MARCO TEORICO 352.4.2. REST “La Transferencia del Estado Representacional (Representational State Transfero REST) es una t´cnica de arquitectura software para sistemas distribuidos basados een hipermedia como es la Web. El t´rmino se utiliza para referirse al estilo arqui- etect´nico de la Web y se acu˜ ´ en el a˜ o 2000, en la tesis doctoral de Roy T. Fielding, o no nautor adem´s de la especificaci´n del protocolo HTTP, de la especificaci´n de URI y a o odel documento del W3C sobre Arquitectura de la Web, y ha pasado a ser ampliamenteutilizado por la comunidad de desarrollo SOA”. [39] Un concepto importante en REST es la existencia de recursos, cada uno de loscuales puede ser accedido usando un identificador global, un URI. Como resultado,el servidor devolver´ una representaci´n 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 ıaformato SVG que representa el c´ ırculo indicando el punto central y un radio. Ventajas de REST: Mejores tiempos de respuesta y disminuci´n 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´n independiente de los tipos de documentos o La creaci´n de nuevos tipos de documentos no afecta a los anteriores o2.4.3. RPC RPC, acr´nimo de Remote Procedure Call (Llamada a Procedimientos Remotos oen espa˜ ol) es una tecnolog´ que permite ejecutar una subrutina o procedimiento en n ıaotra m´quina a trav´s de una red. Si el software en cuesti´n est´ escrito utilizando a e o ael paradigma de la orientaci´n a objetos, a esta operaci´n se le llama invocaci´n o o oremota. RPC es el m´todo m´s antiguo de invocaci´n de m´todos remotos, y sigue el e a o emodelo cliente-servidor, la comunicaci´n es iniciada por el cliente, quien env´ un o ıa
  38. 38. CAP´ ´ ITULO 2. MARCO TEORICO 36mensaje de petici´n a un servidor remoto, con el fin de ejecutar un procedimiento oespec´ ıfico, usando ciertos par´metros. a2.5. Realidad aumentada La realidad aumentada o augmented reality en ingl´s, tiene como objeto combinar eel ambiente real con objetos sint´ticos, interactivos, generados por computador. De eesta manera, el ambiente real es enriquecido o guiado con objetos virtuales, queresultan de mayor utilidad a los usuarios. Este aumento consiste en objetos virtuales que se a˜ aden al entorno o en informa- nci´n no geom´trica sobre los objetos reales existentes. Idealmente, el usuario percibe o eque los objetos reales y virtuales coexisten en el mismo espacio. [36] La realidad aumentada mantiene el mundo real del usuario enriqueci´ndolo con ela presencia de elementos virtuales la que se diferencia de la realidad virtual, ya queesta ultima permite la inmersi´n del usuario en un mundo artificial que sustituye ´ ocompletamente al mundo real del usuario. Seg´ n Azuma[30], existen tres requerimientos que un sistema debe cumplir para user considerado como de realidad aumentada: Combinar lo real y virtual Interacci´n en tiempo real o Registrado en 3D
  39. 39. 3. Metodolog´ ıa En este cap´ıtulo se describe la metodolog´ de desarrollo utilizada, detallando la ıaventajas de ´sta. Adem´s, se listan los documentos esperados en cada una de las e aetapas de desarrollo.3.1. Descripci´n de Metodolog´ o ıa Un proceso de desarrollo de software es un m´todo de organizar las actividades erelacionadas con la creaci´n, presentaci´n y mantenimiento de los sistemas de soft- o oware. La metodolog´ de desarrollo a utilizar es llamada “ Proceso Unificado de Desar- ıarollo”, 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 nimplementaci´n y pruebas. El sistema crece al incorporar nuevas funciones en cada oiteraci´n de ciclo de desarrollo. o En cada ciclo de desarrollo se implementa uno o m´s casos de uso o bien sus aversiones simplificadas (si el caso de uso es muy complejo como para ser abordadoen un s´lo ciclo). Los casos de uso deber´ clasificarse, y los que ocupen los niveles o ıanm´s altos han de abordarse en los ciclos iniciales de desarrollo. a Cada iteraci´n es un ciclo de desarrollo que termina en la liberaci´n de una versi´n o o oparcial del producto final y cada iteraci´n pasa a trav´s de todos los aspectos del o edesarrollo de software: an´lisis de requerimientos, dise˜ o, implementaci´n, pruebas, a n odocumentaci´n y evaluaci´n. o o 37
  40. 40. CAP´ ITULO 3. METODOLOG´ IA 38 Los beneficios de la metodolog´ elegida son: ıa Mitigaci´n temprana de riesgos altos o Progreso visible en las primeras etapas Una temprana realimentaci´n, favoreciendo la adaptaci´n, 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´cil identificar partes comunes dise˜ adas o imple- a n mentadas Flexibilidad para el cambio Los elementos son integrados progresivamente3.1.1. Etapas del Proceso Unificado Las etapas presentes en la metodolog´ de desarrollo de Proceso Unificado son ıainicio, elaboraci´n, construcci´n y transici´n, las que se explican a continuaci´n. o o o oInicio Durante esta fase se especifica una visi´n general y b´sica del proyecto. Esencial- o amente, 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 (llamadosartefactos): visi´n, descripci´n complementaria y algunos casos de uso. o o
  41. 41. CAP´ ITULO 3. METODOLOG´ IA 39Elaboraci´n 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 ıaest´ en posici´n de planear las actividades y estimar los recursos necesarios para a ocompletar 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 acaracter´ ısticas m´s importantes y riesgosas. aConstrucci´n o Se empieza a construir cada parte del sistema, siguiendo la arquitectura centralantes dise˜ ada. En esta fase, el sistema debe crecer lo suficiente para ponerlo a ndisposici´n de los usuarios para obtener opiniones y hacer los cambios pertinentes. o Se implementan de forma iterativa las funcionalidades que no se han abarcadoen la fase de elaboraci´n, y se completan las ya comenzadas. o La pregunta es: ¿Cumple el sistema con la mayor´ de las necesidades de los ıausuarios para liberar una primera versi´n?. o El resultado de esta fase es el refinamiento de los diferentes documentos, y laimplementaci´n completa del software. oTransici´n o Esta fase cubre el per´ıodo durante el cual el sistema se convierte en una versi´n obeta. Durante esta fase, un cierto n´ mero de usuarios experimentados prueban el sis- utema y reportan los defectos y deficiencias encontradas. Los desarrolladores corrigenlos problemas reportados e incorporan las mejoras sugeridas. Se genera una serie de pruebas beta, para concluir con el despliegue final de laaplicaci´n. Una vez superadas las pruebas beta, se lanza la aplicaci´n para su puesta o oen producci´n. o3.1.2. Disciplinas La metodolog´ se organiza en disciplinas o flujos de trabajo. Una disciplina es ıaun conjunto de actividades realizadas en un ´rea determinada. a
  42. 42. CAP´ ITULO 3. METODOLOG´ IA 40 A continuaci´n se listan las disciplinas utilizadas en el proceso de desarrollo de oesta memoria. Modelado del negocio: La creaci´n del modelo de negocio o Requisitos: La clarificaci´n de los requerimientos, manifestado en los siguientes o documentos: visi´n, casos de uso, especificaci´n complementaria y glosario o o Dise˜ o: La especificaci´n del dise˜ o de software n o n Implementaci´n: Realizaci´n de la implementaci´n de software o o o Pruebas: El testing del software desarrollado3.2. Patrones de dise˜ o n Un patr´n se puede describir como una descripci´n de un problema en el dise˜ o o o norientados a objetos y la soluci´n de ´ste, a este par problema/soluci´n se le da un o e onombre, por ejemplo el patr´n “Creador”. [41] o3.2.1. Patrones GRASP En esta secci´n se presentan algunos patrones GRASP. oCreador ¿Qui´n 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´n? oAlta cohesi´n ¿C´mo mantener la complejidad dentro de l´ o o ımites manejables?Controlador ¿Qui´n deber´ encargarse de atender un evento del sistema? e ıaPolimorfismo ¿C´mo manejar las alternativas basadas en el tipo? ¿De qu´ manera o e crear componentes de software conectables?Fabricaci´n pura ¿A qui´n asignar la responsabilidad cuando uno est´ desespera- o e a do y no quiere violar los patrones Alta Cohesi´n y Bajo Acoplamiento? o
  43. 43. CAP´ ITULO 3. METODOLOG´ IA 41Indirecci´n ¿A qui´n se asignar´n las responsabilidades a fin de evitar el acoplamien- o e a to directo?No hables con extra˜ os ¿A qui´n 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] deCraig Larman.3.2.2. Patrones GOF En 1994 se public´ el libro “Design Patterns: Elements of Reusable Object Orient- oed Sofware” [35] escrito por los ahora famosos Gang of Four (GoF, que en espa˜ ol es nla pandilla de los cuatro) formada por Erich Gamma, Richard Helm, Ralph Johnsony John Vlissides. Ellos recopilaron y documentaron 23 patrones de dise˜ o aplicados nusualmente por expertos dise˜ adores de software orientado a objetos. n En esta secci´n presentan algunos de los m´s importantes patrones GOF. o aFactor´ 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´n de objetos. oSingleton 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´cil de usar. aPatron Chain of Responsability Evita acoplar el emisor de una petici´n a su o receptor, al dar a m´s de un objeto la posibilidad de responder a la petici´n. a o Crea una cadena con los objetos receptores y pasa la petici´n 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 ofreusable object-oriented software” [35].
  44. 44. CAP´ ITULO 3. METODOLOG´ IA 423.2.3. Patrones arquitect´nicos o Los Patrones arquitect´nicos especifican un conjunto predefinido de subsistemas ocon sus responsabilidades y una serie de recomendaciones para organizar los distintoscomponentes. [34] En esta secci´n se presentan algunos patrones arquitect´nicos de software. o oCapas 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 aTres Capas Este patr´n 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´n: 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´n, 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´n de informaci´n desde la capa de negocio. o oModelo-Vista-Controlador (MVC) Separaci´n 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´n 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
  45. 45. CAP´ ITULO 3. METODOLOG´ IA 433.2.4. Otros patronesPatr´n Data Access Object o Data Access Component El problema que viene o a resolver este patr´n 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´n 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´n interna. [45] o
  46. 46. 4. An´lisis a Este cap´ıtulo comienza presentando los requisitos que el sistema debe cumplir, enlos que se detallan y clasifican las necesidades de los usuarios; despu´s se muestra una edescripci´n del comportamiento del sistema bajo distintos escenarios utilizando los ocasos de uso; luego se presenta el modelo conceptual, el que muestra los conceptos delmundo real, y las relaciones entre estos, y para finalizar se muestran los diagramasde secuencia y contratos del sistema.4.1. Resumen de las caracter´ ısticas del sistema Esta secci´n resume los requisitos del juego: o El sistema debe permitir gestionar competidores y almacenar su informaci´n o El sistema debe permitir gestionar administradores y almacenar su informaci´n o El sistema debe permitir gestionar equipos de competidores y almacenar su informaci´n o El sistema debe permitir la utilizaci´n del GPS para determinar la posici´n de o o un usuario, objeto o lugar para as´ poder georeferenciar ´ste ı e El sistema debe almacenar informaci´n de pistas y metas o El sistema debe permitir georeferenciar pistas, metas, competidores y admin- istradores El sistema debe mostrar la localizaci´n de los competidores en el mapa o El sistema debe permitir la comunicaci´n entre competidores o 44

×