Your SlideShare is downloading. ×
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Desarrollo de un Sistema de Juego Ubicuo bajo Plataforma Android

1,537

Published on

A multiplayer collaborative GPS game(proof of concept) implementing a SOA architecture, developed as part of a Computer Science Thesis …

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
1,537
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. 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. Dedicado a mi familia y cercanos.i
  • 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. 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. 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. 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. ´ 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. 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. 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. 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. ´ 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. 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. 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. PALABRAS CLAVESDesarrollo de software, Android, Servicio Web, API, Dispositivos m´viles, SOAP o xiii
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  • 47. CAP´ ´ ITULO 4. ANALISIS 454.2. Especificaci´n de requisitos o En esta secci´n se detallan y clasifican los requisitos, adem´s, se definen limita- o aciones para estos.Requisitos referentes a usuario Req Funci´n o Categor´ Detalles y Limitaciones ıa RF1.1 Almacenar datos de Oculta El sistema deber´ permitir almace- a Competidores nar los datos de los Competidores RF1.2 Crear Competidores Evidente El sistema deber´ permitir la a creaci´n de Competidores ingresan- o do los datos de estos RF1.3 Actualizar Competi- Evidente El sistema deber´ permitir la actual- a dores izaci´n de los datos de los Competi- o dores RF1.4 Eliminar Competi- Evidente El sistema deber´ permitir al admin- a dores istrador la eliminaci´n de Competi- o dores y los datos de estos RF1.5 Almacenar datos de Oculta El sistema deber´ permitir almace- a Administradores nar los datos de los Administradores RF1.6 Crear Admin- Evidente El sistema deber´ permitir al ad- a istradores ministrador la creaci´n de Admin- o istradores ingresando los datos de es- tos RF1.7 Actualizar Admin- Evidente El sistema deber´ permitir al admin- a istradores istrador la actualizaci´n de los datos o de los Administradores RF1.8 Eliminar Admin- Evidente El sistema deber´ permitir al admin- a istradores istrador la eliminaci´n de Admin- o istradores y los datos de estos RF1.9 Autenticarse en el sis- Evidente El sistema deber´ permitir a un a tema usuario autenticarse
  • 48. CAP´ ´ ITULO 4. ANALISIS 46 RF1.10 Des-autenticarse en el Evidente El sistema deber´ permitir a un a sistema usuario des-autenticarse RF1.11 Recordar contrase˜ a n Evidente El sistema deber´ recordar con- a trase˜ a a un usuario n RF1.12 Cambiar contrase˜ a n Evidente El sistema deber´ permitir a un a usuario cambiar su contrase˜ a nRequisitos referentes a juego Req Funci´n o Categor´ Detalles y Limitaciones ıa RF2.1 Almacenar datos de Oculta El sistema deber´ permitir almace- a Pistas nar los datos de las Pistas RF2.2 Crear Pistas Evidente El sistema deber´ permitir la a creaci´n de Pistas en un Juego o ingresando los datos de estas RF2.3 Actualizar Pistas Evidente El sistema deber´ permitir la actu- a alizaci´n de los datos de las Pistas o RF2.4 Eliminar Pistas Evidente El sistema deber´ permitir la elimi- a naci´n de Pistas y los datos de estas o RF2.5 Almacenar datos de Oculta El sistema deber´ permitir almace- a Metas nar los datos de las Metas RF2.6 Crear Metas Evidente El sistema deber´ permitir la a creaci´n de Metas en un Juego o ingresando los datos de estas RF2.7 Actualizar Metas Evidente El sistema deber´ permitir la actu- a alizaci´n de los datos de las Metas o RF2.8 Eliminar Metas Evidente El sistema deber´ permitir la elimi- a naci´n de Metas y los datos de estas o RF2.9 Almacenar datos de Oculta El sistema deber´ permitir almace- a Equipos nar los datos de los Equipos
  • 49. CAP´ ´ ITULO 4. ANALISIS 47RF2.10 Crear Equipos Evidente El sistema deber´ permitir la a creaci´n de Equipos en un Juego o ingresando los datos de estosRF2.11 Actualizar Equipos Evidente El sistema deber´ permitir la actu- a alizaci´n de los datos de los Equipos oRF2.12 Eliminar Equipos Evidente El sistema deber´ permitir la elimi- a naci´n de Equipos y los datos de es- o tosRF2.13 Vincular competi- Evidente El sistema deber´ permitir la vincu- a dores a un equipo laci´n de competidores a un equipo oRF2.14 Desvincular competi- Evidente El sistema deber´ permitir la desvin- a dores de un equipo culaci´n de competidores a un o equipoRF2.15 Recoger una pista Evidente El sistema deber´ permitir a un a competidor recoger una Pista de la cual se encuentra lo suficientemente cerca como para alcanzarlaRF2.16 Recoger Meta Evidente El sistema deber´ permitir a un a competidor recoger la Meta cuando se encuentra lo suficientemente cerca como para alcanzarlaRF2.17 Almacenar datos de Oculta El sistema deber´ permitir almace- a un Juego nar los datos de un JuegoRF2.18 Crear Juego Evidente El sistema deber´ a permitir la creaci´n de un Juego ingresando los o datos de esteRF2.19 Actualizar Juego Evidente El sistema deber´ permitir la actu- a alizaci´n de los datos de un Juego oRF2.20 Eliminar Juego Evidente El sistema deber´ permitir la elim- a inaci´n de un Juego y los datos de o este
  • 50. CAP´ ´ ITULO 4. ANALISIS 48Requisitos referentes a Comunicaci´n o Req Funci´n o Categor´ Detalles y Limitaciones ıa RF3.1 Enviar mensaje a Evidente El sistema deber´ permitir a un a compa˜ ero(s) n competidor enviar mensajes a sus compa˜ eros n RF3.2 Enviar mensaje al Ad- Evidente El sistema deber´ permitir a un a ministrador competidor enviar mensajes al Ad- ministradorRequisitos referentes a Localizaci´n o Req Funci´n o Categor´ Detalles y Limitaciones ıa RF4.1 Conocer la ubicaci´n o Evidente El sistema deber´ permitir a un a propia competidor conocer la ubicaci´n o donde se encuentra RF4.2 Conocer la ubicaci´n o Evidente El sistema deber´ permitir a un a de todos sus com- competidor conocer la ubicaci´n o pa˜ eros n donde se encuentran sus compa˜ eros n RF4.3 Conocer la ubicaci´n o Evidente El sistema deber´ permitir a un a de todas las pistas de competidor conocer la ubicaci´n o su equipo donde se encuentran todas la pistas recogidas por sus compa˜ eros n RF4.4 Conocer la informa- Evidente El sistema deber´ permitir a un a ci´n de todas las pis- o competidor conocer la informaci´n o tas de su equipo de todas la pistas recogidas por sus compa˜ eros nRequisitos referentes a Informaci´n o Req Funci´n o Categor´ Detalles y Limitaciones ıa
  • 51. CAP´ ´ ITULO 4. ANALISIS 49RF5.1 Competidor Evidente Obligatoria: nombre de usuario, con- trase˜ a n Alternativa: juego actual, equipo ac- tual, nombre, direcci´n, tel´fono, o e fecha de nacimientoRF5.2 Administrador Evidente Obligatoria: nombre de usuario, con- trase˜ a n Alternativa: ´ Idem competidorRF5.3 Pista Evidente Obligatoria: nombre, descripci´n, o ubicaci´n o Alternativa:RF5.4 Meta Evidente Obligatoria: nombre, descripci´n, o ubicaci´n o Alternativa:RF5.5 Equipo Evidente Obligatoria: nombre, integrantes Alternativa: descripci´n oRF5.6 Juego Evidente Obligatoria: nombre, fecha de inicio, fecha de t´rmino, n´ mero m´ximo e u a de equipos, n´ mero m´ximo de u a competidores por equipo, pistas, metas Alternativa: descripci´n, o ciudad, ubicaci´n o4.3. Actores En esta secci´n se definen los actores que intervendr´n en el sistema. o a Usuario no autenticado: Carece de privilegios, no se ha autenticado en el sis- tema, solo se le permite registrarse o autenticarse en el sistema Usuario: Posee una cuenta en el sistema Informaci´n obligatoria: nombre de usuario, contrase˜ a o n
  • 52. CAP´ ´ ITULO 4. ANALISIS 50 Informaci´n alternativa: nombre, direcci´n, tel´fono, profesi´n, fecha de nacimien- o o e o to, msn, skype, jabber, GTalk Usuario autenticado: es un usuario que se ha autenticado en el sistema Competidor: Es un tipo de usuario autenticado, quien juega y pertence un equipo en un juego Administrador: Es un tipo de usuario, encargado de coordinar y gestionar la plataforma de juegos Servicio GPS: Provee informaci´n de localizaci´n geogr´fica o o a Servicio de Mapas: Provee informaci´n de mapas o4.4. Especificaci´n de Casos de Uso o En esta secci´n se muestran algunos de los casos de uso m´s importantes en o aformato resumido.4.4.1. Casos de uso en formato resumido En esta secci´n de presenta un resumen de los casos de uso m´s importantes. o aCrear competidor Un usuario no autenticado ingresa su informaci´n al sistema para ser registrado ocomo competidor. El sistema verifica si el competidor existe. El sistema env´ la ıaconfirmaci´n de la creaci´n. o oCrear administrador El administrador ingresa la informaci´n de un nuevo administrador al sistema. oEl sistema verifica si el administrador existe. El sistema env´ la confirmaci´n de la ıa ocreaci´n. o
  • 53. CAP´ ´ ITULO 4. ANALISIS 51Autentificarse El usuario ingresa su nombre de usuario y clave al sistema. Sistema verifica si lainformaci´n ingresada es v´lida. El usuario es autentificado por el sistema. o aCrear pista Un usuario autenticado ingresa la informaci´n de una nueva pista al sistema. El osistema verifica si la pista existe. El sistema env´ la confirmaci´n de la creaci´n. ıa o oMostrar pista El competidor selecciona una pista. El sistema muestra la informaci´n de esta. oCrear meta Un usuario autenticado ingresa la informaci´n de una nueva meta al sistema. El osistema verifica si la meta existe. El sistema env´ la confirmaci´n de la creaci´n. ıa o oCrear equipo Un usuario autenticado ingresa la informaci´n de un nuevo equipo al sistema oasoci´ndolo al juego donde participa. El sistema verifica si el equipo existe. El sistema aenv´ la confirmaci´n de la creaci´n. ıa o oVincular competidor a equipo Un competidor selecciona el equipo del cual desea ser parte. El sistema verifica siel equipo existe y lo agrega al equipo seleccionado. El sistema env´ la confirmaci´n ıa ode la agregaci´n. oEnviar mensaje a compa˜ eros n El competidor ingresa el mensaje al sistema. El sistema env´ el mensaje a los ıacompa˜ eros de equipo del competidor que env´ en mensaje. El sistema env´ la n ıa ıaconfirmaci´n del envi´ de mensaje. o o
  • 54. CAP´ ´ ITULO 4. ANALISIS 52Recoger pista El competidor, cuando esta lo suficientemente cerca de una pista, la seleccionapara recogerla. El sistema env´ la informaci´n de la pista recogida, y muestra esta ıa oen el mapa de todos sus compa˜ eros de equipo. nRecoger el tesoro o meta El competidor, cuando esta lo suficientemente cerca del tesoro, selecciona ´ste epara recogerlo. El sistema env´ la confirmaci´n. El sistema informa a todos los ıa ocompetidores que el juego ha terminado y el equipo ganador.Mostrar mapa El mapa ser´ mostrado centrado en la localizaci´n del competidor. En un radio a odefinido alrededor de la localizaci´n del competidor, el sistema mostrar´ las pistas o o ameta dentro de ´ste. eComenzar Juego El Administrador da comienzo al juego y la pista inicial es enviada a todos loscompetidores cuando estos se unen a ´ste. e4.4.2. Casos de uso en formato expandido En esta secci´n se presentan algunos casos de usos en formato detallado. Para omayor detalle dirigirse al Anexo B. Usuarios
  • 55. CAP´ ´ ITULO 4. ANALISIS 53Caso de Uso 1.1 AutenticarseActor: Usuario no autenticadoProp´sito: Autenticarse oTipo: Primario, EsencialReferencias: RF 1.9Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea Autenticarse en el sistema 2.- Proporciona un formulario para in- gresar la informaci´n para Autenticarse o 3.- Ingresa y env´ el nombre de usuario ıa y la clave al sistema 4.- Verifica si los datos son correctos 5.- El actor es autenticado por el sistema 6.- Env´ confirmaci´n de la operaci´n ıa o o al actorFlujo alternativo: 4a.- Verifica que los datos son incorrec- tos 5.- Paso 2
  • 56. CAP´ ´ ITULO 4. ANALISIS 54Caso de Uso 1.2 Des-autenticarseActor: Usuario autenticadoProp´sito: Des-autenticarse oTipo: Primario, EsencialReferencias: RF 1.10Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea des-autenticarse en el sis- tema 2.- Proporciona un formulario para con- firmar 3.- Confirma 4.- Verifica si los datos son correctos 5.- El actor es des-autenticado por el sis- tema 6.- Env´ confirmaci´n de la operaci´n ıa o o al actor
  • 57. CAP´ ´ ITULO 4. ANALISIS 55Caso de Uso 1.3 Cambiar contrase˜ a nActor: Usuario autenticadoProp´sito: Cambiar contrase˜ a o nTipo: Primario, EsencialReferencias: RF 1.12Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea cambiar su contrase˜ a n 2.- Proporciona un formulario 3.- Ingresa antigua y nueva contrase˜ a n 4.- Verifica si los datos son correctos, contrase˜ a antigua correcta n 5.- Almacena la informaci´n o 6.- Env´ confirmaci´n de la operaci´n ıa o o al actorFlujo alternativo: 4a.- Verifica que los datos son incorrec- tos 5.- Paso 2
  • 58. CAP´ ´ ITULO 4. ANALISIS 56Caso de Uso 1.4 RegistrarseActor: Usuario no autenticadoProp´sito: Crear y almacenar la informaci´n de un nuevo competidor o oTipo: Secundario, EsencialReferencias: RF 1.1 , RF 1.2 , RF 5.1Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea registrarse en el sistema 2.- Proporciona un formulario para in- gresar su informaci´n o 3.- Ingresa y env´ los datos al sistema ıa 4.- Verifica si el competidor no existe 5.- Almacena la informaci´n del com- o petidor 6.- Env´ confirmaci´n de la operaci´n ıa o o al actorFlujo alternativo: 4a.- Verifica que el competidor existe 5.- Pregunta al actor si desea ingresar otro competidor
  • 59. CAP´ ´ ITULO 4. ANALISIS 57Caso de Uso 1.5 Registrar nuevo AdministradorActor: AdministradorProp´sito: Crear y almacenar la informaci´n de un nuevo administrador o oTipo: Secundario, EsencialReferencias: RF 1.5 , RF 1.6 , RF 5.2Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea registrar un nuevo admin- istrador en el sistema 2.- Proporciona un formulario para in- gresar la informaci´n o 3.- Ingresa y env´ los datos al sistema ıa 4.- Verifica si el administrador no existe 5.- Almacena la informaci´n del admin- o istrador 6.- Env´ confirmaci´n de la operaci´n ıa o o al actorFlujo alternativo: 4a.- Verifica que el administrador existe 5.- Pregunta al actor si desea ingresar otro administrador
  • 60. CAP´ ´ ITULO 4. ANALISIS 58Caso de Uso 1.6 Buscar UsuarioActor: Usuario autenticadoProp´sito: Buscar Usuario oTipo: Secundario, EsencialFlujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea buscar a un usuario en el sistema 2.- Proporciona un formulario 3.- Ingresa la informaci´n del usuario a o buscar 4.- Verifica si el usuario existe 5.- Muestra la informaci´n de usuario oFlujo alternativo: 4a.- Verifica que el usuario no existe 5.- Pregunta al actor si desea buscar otro usuario
  • 61. CAP´ ´ ITULO 4. ANALISIS 59Caso de Uso 1.7 Actualizar Informaci´n oActor: Usuario autenticadoProp´sito: Actualizar la informaci´n o oTipo: Secundario, EsencialReferencias: RF 1.1 , RF 1.3 , RF 5.1Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea actualizar su informaci´n o 2.- Proporciona un formulario para ac- tualizar su informaci´n o 3.- Modifica y env´ los datos al sistema ıa 4.- Verifica los datos 5.- Almacena los cambios 6.- Env´ confirmaci´n de la operaci´n ıa o o al actorFlujo alternativo: 4a.- Verifica que alg´ n dato es incorrec- u to 5.- Pregunta al actor si desea actualizar
  • 62. CAP´ ´ ITULO 4. ANALISIS 60Caso de Uso 1.8 Actualizar Informaci´n de localizaci´n o oActor: Usuario autenticadoProp´sito: Actualizar la informaci´n de localizaci´n o o oTipo: Secundario, EsencialReferencias: RF 1.1 , RF 1.3 , RF 5.1Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea actualizar su informaci´n o de localizaci´n. Para ello env´ su local- o ıa izaci´n actual o 2.- Verifica los datos 3.- Almacena los cambios 4.- Env´ confirmaci´n de la operaci´n ıa o o al actor La Figura 4.1 muestra los casos de uso y las dependencias entre ellos. Autenticarse <<include>> Registrarse <<include>> Cambiar Contraseña <<include>> Usuario no autenticado <<include>> <<include>> Des-autenticarse Buscar Usuario Usuario autenticado Actualizar Información Actualizar Información de localización Figura 4.1: Diagrama de casos de uso: Usuarios4.4.3. Diagrama de Casos de Uso Los diagramas de casos de uso ilustran los nombres de los casos de uso, los actoresy las interacciones entre ellos.
  • 63. CAP´ ´ ITULO 4. ANALISIS 61 La Figura 4.2 muestra los casos de uso y las dependencias entre ellos. Registrarse Comenzar Juego Crear Juego Crear pista Autenticarse Crear equipo Des-autenticarse Usuario no autenticado Buscar Equuipo Buscar Juego Ver Ubicación de Compañeros de Equipo Buscar Usuario Usuario autenticado Alertar Posibilidad de Recoger Cambiar Contraseña Competidor Alertar cercanía Actualizar Información Enviar Mensaje a Compañeros Actualizar Información de localización Recoger Pista Vincular competidor Ver Mapa Ver Ubicación de Pistas de Equipo Listar compañeros Figura 4.2: Diagrama de casos de uso4.4.4. Priorizaci´n de Casos de Uso o La importancia que tienen los casos de uso influye en el orden que se tomar´n aestos en etapas posteriores, es para ello que se utiliza una matriz de caracter´ ısticasy as´ asignar la importancia o prioridad a cada caso de uso. ı Las caracter´ ısticas son evaluadas de 1 a 5, en que la suma de las evaluaciones delas distintas caracter´ ısticas de un caso de uso nos muestra la importancia de ´ste en eparticular, para luego clasificar estos en alto, bajo y medio. En el Cuadro 4.1 se muestran las caracter´ ısticas a evaluar por cada caso de usoy en el Cuadro 4.2 se muestra la clasificaci´n de los casos de uso. o
  • 64. CAP´ ´ ITULO 4. ANALISIS 62 Caracter´ ısticas a Tener una fuerte repercusi´n en el dise˜ o arquitect´nico; por ejemplo, incor- o n o porar muchas clases a la capa del dominio o requerir servicios de persistencia b Permitir obtener, con relativamente poco esfuerzo, informaci´n e ideas im- o portantes sobre el dise˜ o n c Incluir funciones riesgosas, urgentes o complejas d Requerir una investigaci´n a fondo o tecnolog´ nueva o riesgosa o ıa e Representar los procesos primarios de la l´ ınea de negocios f Apoyar directamente el aumento de ingresos o la reducci´n de costos o Cuadro 4.1: Caracter´sticas para determinar la prioridad de los casos de uso ı Clasificaci´n o Casos de uso Alta CU 4.1 CU 3.3 CU 4.4 CU 6.2 CU 6.3 CU 4.5 Media CU 5.1 CU 1.8 CU 6.1 CU 3.1 CU 2.1 CU 2.2 CU 1.1 Bala CU 1.4 CU 1.6 CU 1.3 CU 2.3 CU 1.7 CU 1.2 Cuadro 4.2: Priorizaci´n de casos de uso o En el Anexo C se muestra la matriz de caracter´ ısticas de Casos de uso.4.5. Modelo conceptual “El modelo del dominio o conceptual es una representaci´n de las clases concep- otuales del mundo real, no de componentes de software”. [42] Muestra diferentes conceptos (identificados como clases conceptuales) del dominioy muestra las relaciones entre estos. Las clases conceptuales m´s importantes se han extra´ a partir de los casos de a ıdouso. A continuaci´n se muestra el modelo conceptual en la Figura 4.3 y se explican olos conceptos en el Cuadro 4.3.
  • 65. CAP´ ITULO 4. ANALISIS Map ´ show take show Place * 1 in 1Figura 4.3: Modelo Conceptual +latitude Hint +longitude * +name 1 Message +description * +messageBody * +sender * has +receiver +readed has +type send * 1 1 in see Game has 1 1 +name recive 1 1 0,1 User +description PersonalInfo 1 1 +startDate Goal +username 1 +name +finishDate +password +name +surname 1 +finished has +description +direction +city +phone belongs +maxTeams 1 +maxPlayersByTeam 1 1 +profesion 1 1 +msn compete Team +skype Admin * +name +jabber 0,1 +description +country take +email 1 +showPersonalInfo reaches 63
  • 66. CAP´ ´ ITULO 4. ANALISIS 64 Conceptos Descripci´n o User Son los interesados en interactuar con el sistema, ellos, por ejemplo, env´ mensajes, recogen pistas ıan o metas, crean juegos. Team Es un conjunto de usuarios que act´ an c´mo com- u o pa˜ eros en un juego en particular y buscan ganar n ´ste. e Message Es alguna informaci´n que se desea enviar a otro o usuario en el sistema. Hint Objeto o lugar georeferenciado que entrega infor- maci´n de c´mo continuar el juego. o o Goal Objeto o lugar que debe ser alcanzado para ganar un juego en particular. Game Un juego es un conjunto de hints y goals que deben ser encontrados, y de teams que compiten y buscan estos. Cuadro 4.3: Descripci´n de conceptos del modelo conceptual o4.6. Diagrama de secuencia del sistema “Antes de comenzar el dise˜ o l´gico de como funcionar´ la aplicaci´n de software, n o a oes conveniente estudiar y definir su comportamiento como caja negra”. [42] Los diagramas de secuencia muestran gr´ficamente la forma en que los actores ainteract´ an con el sistema mediante eventos de entrada y de salida, que se representan ucomo un paso de mensajes, viendo ´ste como una caja negra. e Como se ha expresado con anterioridad, se desarrollar´ un cliente para Android, aes por ello que se presentan dos cajas negras, y la interacci´n entre estas, una cor- orespondiente al cliente en un dispositivo m´vil, y la otra al sistema propiamente otal. En esta secci´n se presentan algunos diagramas de secuencia de sistema, para omayor detalle dirigirse al Anexo D, donde se muestran el total de estos.
  • 67. CAP´ ´ ITULO 4. ANALISIS 654.6.1. Usuarios En esta secci´n se muestran algunos de los diagramas relacionados con usuarios. o La Figura 4.4 muestra la interacci´n del caso de uso CU 1.1 en el cual, el usuario odesea autenticarse en el Sistema. :Actor :Client :System login() form_data login(username,password) login(username,password) Checkusernameand notification password notification Figura 4.4: Diagrama de secuencias: Autenticarse CU 1.1 La Figura 4.5 muestra la interacci´n del caso de uso CU 1.3 en el cual, el usuario odesea cambiar su contrase˜ a. n
  • 68. CAP´ ´ ITULO 4. ANALISIS 66 :Actor :Client :System changePassword() form_data changePassword(oldPassword, newPassword) changePassword(oldPassword, newPassword) CheckoldPassword notification notification Figura 4.5: Diagrama de secuencias: Cambiar Contrase˜a CU 1.3 n La Figura 4.6 muestra la interacci´n del caso de uso CU 1.4 en el cual, el usuario ose registra en el sistema, es decir, el competidor es creado en el sistema y su infor-maci´n almacenada. o :Client :System :Actor register() form_data register(userinfo) register(userinfo) Checkifthe notification userexist notification Figura 4.6: Diagrama de secuencias: Registrar Competidor CU 1.4 La Figura 4.7 muestra la interacci´n del caso de uso CU 1.8 en el cual, el usuario odesea actualizar su informaci´n de localizaci´n, para lo cual env´ el par latitud, lon- o o ıa
  • 69. CAP´ ´ ITULO 4. ANALISIS 67gitud al sistema, dicha informaci´n fue obtenida con anterioridad desde el GPS. o :Client :System :Actor updateLocation() updateLocation(lat, lon) notification notification Figura 4.7: Diagrama de secuencias: Actualizar localizaci´n CU 1.8 o4.7. Contratos “Los contratos de las operaciones pueden ayudar a definir el comportamientodel sistema: describen el resultado de la ejecuci´n de las operaciones del sistema en ofunci´n de los cambios de estado de los objetos del dominio”.[42] o Las pre-condiciones, nos sit´ an e instan el entorno necesario para que la funci´n u ose lleve a cabo, generalmente se clarifican las instancias del domino, por otra partelas post-condiciones describen los cambios de estado del modelo de dominio.[32] En esta secci´n se presentan algunos contratos, para mayor detalle dirigirse al oAnexo E, donde se muestra el total de estos.4.7.1. Contratos referentes a usuario En esta secci´n se muestran algunos de los contratos relacionados con usuarios. o
  • 70. CAP´ ´ ITULO 4. ANALISIS 68Crear competidorContrato CO1Operaci´n o registerReferencias Cruzadas RF 1.1 , RF 1.2 , RF 5.1Caso de Uso CU 1.4NotasSalidaPrecondiciones El nombre de usuario del competidor no debe existirPoscondiciones El competidor es creado Se ha almacenado la informaci´n del competidor oCrear AdministradorContrato CO2Operaci´n o create adminReferencias Cruzadas RF 1.5 , RF 1.6 , RF 5.2Caso de Uso CU 1.5NotasSalidaPrecondiciones El actor debe estar autentificado con rol de admin- istrador El nombre de usuario del administrador no debe exi- stirPoscondiciones El administrador es creado Se ha almacenado la informaci´n del administrador o
  • 71. CAP´ ´ ITULO 4. ANALISIS 69AutenticarseContrato CO3Operaci´n o loginReferencias Cruzadas RF 1.9Caso de Uso CU 1.1NotasSalidaPrecondiciones El actor debe existir El actor no debe estar autenticadoPoscondiciones El actor est´ Autenticado aActualizar Ubicaci´n oContrato CO4Operaci´n o updateLocationReferencias Cruzadas RF 4.1Caso de Uso CU 1.8NotasSalidaPrecondiciones El actor debe estar autenticado La informaci´n de localizaci´n debe haber sido o o obtenida desde el GPS o en un mapaPoscondiciones El actor actualiz´ el lugar donde se encuentra o Se ha almacenado la nueva posici´n del competidor o
  • 72. 5. Dise˜o n El contenido del cap´ ıtulo de an´lisis se puede describir como “estar seguro de ahacer lo correcto”, mientras este cap´ ıtulo describe “c´mo hacerlo bien”. [48] o Este cap´ıtulo describe el camino para implementar los requerimientos, pensandoen una soluci´n tecnol´gicamente neutra al comienzo, es decir, el dise˜ o no est´ sujeto o o n aa una tecnolog´ en particular, para luego aplicar este dise˜ o a una arquitectura y ıa ntecnolog´ determinada, cliente Android, servidor de Java Servlet, servicios Web con ıaApache Axis, e interfaz REST.5.1. Diagrama de Interacci´n o “Los diagramas de interacci´n ilustran c´mo los objetos interaccionan por medio o ode mensajes, mostrando el flujo de mensajes entre estos y sus responsabilidades”.[42] La formaci´n de los presentes diagramas y an´lisis parten como producto de o alos diagramas de secuencia del sistema y contratos, ambos presentados en cap´ ıtulosanteriores. Las responsabilidades se relacionan con obligaciones de un objeto respecto a sucomportamiento, estas pertenecen esencialmente a 2 categor´ ıas: conocer y hacer.Booch y Rumbaugh definen la responsabilidad como un contrato u obligaci´n de un otipo o clase. Para delegar las responsabilidades a los objetos se han aplicado algunos patronesGRASP[42], los que nos gu´ en el modo en que se deben asignar las responsabili- ıandades a los objetos, mejorando la calidad del dise˜ o del software. n En esta secci´n se muestran algunos de los diagramas de interacci´n, para mayor o odetalle dirigirse al Anexo F, donde se muestra el total de estos. 70
  • 73. CAP´ ˜ ITULO 5. DISENO 715.1.1. Usuarios En esta secci´n se muestran algunos de los diagramas de interacci´n relacionados o ocon usuarios. En la Figura 5.1 se aprecia la interacci´n del usuario con el sistema al momento ode registrarse en ´ste. Adem´s, se puede ver el paso de mensajes entre los objetos e aimplicados en la acci´n y las responsabilidades asignadas a estos. o El patr´n creador es utilizado cuando un objeto agrega, contiene, registra o inicial- oiza datos de otro objeto, por ello que a la clase UserManager se dio la responsabilidadde crear instancias de User, ya que esta administra y gestiona usuarios. Client Server Actor :View Creator Control :UserManager u:User register() :UserService show :User register(name,password) register(name,password) register(name,password) <<create>> add(u) notification notification notification Figura 5.1: Diagrama de interacci´n - Registrar Usuario, CU 1.4 o En la Figura 5.2 se aprecia la interacci´n del usuario con el sistema al momento ode autenticarse. Ya que para la autenticaci´n es necesaria la validaci´n del nombre o ode usuario y contrase˜ a, por el patr´n Experto, la clase que debe ser responsable n oes la que posea la informaci´n necesaria, en este caso la clase UserManager, la cual opuede obtener la informaci´n desde la clase User. o
  • 74. CAP´ ˜ ITULO 5. DISENO 72 Client Actor :View Server login() :UserManager :UserService :User show login(username,password) login(username,password) checkLogin(username,password) findByUsaername(username) Ckeckusernamey password notification notification notification Figura 5.2: Diagrama de interacci´n - Autenticarse, CU 1.1 o En la Figura 5.3 se aprecia la interacci´n del usuario con el sistema al momento ode cambiar su contrase˜ a. n Client Server Actor :View Creator Control changePassword() :UserManager u:User :UserService show changePassword(oldPassword, newPassword) changePassword(oldPassword, newPassword) changePassword(oldPassword, newPassword) checkoldPassword setPassword(newPassword) notification notification notification Figura 5.3: Diagrama de interacci´n - Cambiar contrase˜a, CU 1.3 o n En la Figura 5.4 se aprecia la interacci´n del usuario con el sistema al momento ode buscar usuarios.
  • 75. CAP´ ˜ ITULO 5. DISENO 73 Server Client Control Actor :View :UserService :UserManager :User find(filter) find(filter) find(filter) find(filter) users:list users:list users:list show(users:list) Figura 5.4: Diagrama de interacci´n - Buscar usuarios, CU 1.6 o5.2. Diagrama de Clases de dise˜ o n Un diagrama de clases de dise˜ o (DCD) muestra gr´ficamente las especificaciones n ade las clases y de las interfaces de software en una aplicaci´n. o A diferencia de las clases conceptuales del modelo de dominio o conceptual, lasclases del dise˜ o del DCD muestra las definiciones de las clases de software, en lugar nde los conceptos del mundo real. [42] En los DCD se encuentra generalmente la siguiente informaci´n: o Clases, asociaciones y atributos Interfaces, con sus operaciones y constantes M´todos e Informaci´n sobre los tipos de los atributos o Navegabilidad Dependencias En la Figura 5.5 se muestra el diagrama de Clases de Dise˜ o. n
  • 76. CAP´ Team ITULO 5. DISENO 1 TeamHavePlaces * -teamId:long 1 TeamSeePlaces -name:String 1 -Description:String -game:Game Contain * * * <<interface>> Place TeamManager -placeId:long * -latitude:int +findTeamsByGame() 1 -longitude:int +getUsers() Contain <<interface>> -name:String +join() PlaceManager 1 -description:String <<interface>> +abandon()Figura 5.5: Diagrama de Clases de Dise˜o GenericManager +addHint() * ˜ +take() Message TeamHaveUsers +create() -messageId:long +find() * -body:String <<interface>> UserSeePlaces +exists() Contain MessageManager -date:DateTime +update() 1 -isReaded:bool +remove() findIn +findByReceiverAndGame() +readed() +sendMSG() * * * UserSendMSG 1 1 <<interface>> UserReceiveMSG 1 User GameManager -userId:long use +findCitiesWithGames() <<interface>> * -username:String -password:String +findActiveGames() UserManager Contain -role:String +findFinishedGames() InGameSendMSG -latitude:int +countActiveGames() +findByUsername() 1 use -longitude:int +countNotFinishedGames() +login() 1 +changePassword() +register() +addMSGAsSender() Contain +addMSGAsReceiver() +updateLocation() GameHaveTeams 1 * 1 Game -gameId:long -name:String n -description:String -startDate:DateTime -finishDate:DateTime -finished:bool * Hint -maxTeams:int GameHaveHints -maxUsersPerTeam:int 1 -latitude:int -longitude:int GameHaveGoal -city:String +addHint() +getTeams() 1 Goal +start() +joinTeam() +abandonTeam() +take() 74
  • 77. CAP´ ˜ ITULO 5. DISENO 755.3. Componentes Durante el proceso de an´lisis, especificaci´n y dise˜ o se han reconocido cinco a o ncomponentes con bajo acoplamiento y alta cohesi´n: usuarios, equipos, mensajer´ o ıa,lugares y juegos, por lo cual se implementar´n estos como servicios Web. a En la Figura 5.6 se puede apreciar los distintos servicios Web y su dependencial´gica. o Team User Client Place Game MSG Figura 5.6: Diagrama de Componentes5.4. Diagrama de dise˜ o de paquetes n Esta secci´n muestran los diagramas de paquetes para los distintos m´dulos del o osistema. En la Figura 5.7 se muestra los paquetes que forman parte de la aplicaci´n, de- otallados en el Cuadro 5.1.
  • 78. CAP´ ˜ ITULO 5. DISENO 76view web ws activityuser team messagemodel.entity service model.entity service model.entity servicemodel.manager model.manager model.manager model.persistence model.persistence model.persistenceplace gamemodel.entity service model.entity servicemodel.manager model.manager model.persistence model.persistence Figura 5.7: Diagrama de paquetes
  • 79. CAP´ ˜ ITULO 5. DISENO 77 Paquete Descripci´n o model.entity Contiene definiciones de clases e interfaces para almacenar la informaci´n o model.manager Contiene definiciones de clases e interfaces para la implementaci´n de la gesti´n de las o o operaciones model.persistence Contiene definiciones de clases e interfaces para la implementaci´n de la persistencia o view.ws Contiene definiciones de clases e interfaces para la implementaci´n de servicios Web o view.Web Contiene definiciones de clases e interfaces para la implementaci´n de la aplicaci´n Web o o view.activity Contiene la implementaci´n de las activi- o dades para el cliente Android service Contiene definiciones de clases e interfaces para la implementaci´n de la comunicacion o entre los componetes del sistema Cuadro 5.1: Descripci´n de los paquetes de la librer´a gen´rica del servidor o ı e5.5. Arquitectura del software La arquitectura del software presenta la forma que tendr´ el software o los difer- aentes software que existan en el sistema. La arquitectura interna del juego que se utilizar´ es el modelo de tres capas, el acual realiza una separaci´n en capa de presentaci´n, capa de negocio o dominio, y o ocapa de persistencia de la informaci´n. o La Figura 5.8 muestra la ubicaci´n de los paquetes descritos anteriormente en el omodelo de tres capas.
  • 80. CAP´ ITULO 5. DISENO GUIFigura 5.8: Arquitectura del Software: modelo tres capas Domain user message ˜ model.entity service model.entity service game model.entity service model.manager comunication comunication model.manager model.manager comunication team place model.entity service model.entity service model.manager comunication comunication model.manager Persistence place.model.persitence game.model.persitence team.model.persitence message.model.persitence user.model.persitence 78
  • 81. CAP´ ˜ ITULO 5. DISENO 79 La aplicaci´n esta compuesta por tres partes, la cuales se explican a continuaci´n. o oEl cliente de M´vil o Esta compuesto por tres capas: la vista, el dominio y la capa de informaci´n o Posee un cliente HTTP/S para poder comunicarse con los servicios ofrecidos por el servidor La capa de dominio es responsable de la inteligencia de la aplicaci´n, es la o encargada de administrar las acciones de los usuarios, la informaci´n obtenida o del servidor, la informaci´n de localizaci´n del GPS, la informaci´n de los o o o mapas y mostrar al usuario todo de forma coherente utilizando la capa de vista Las Figura 5.9 muestra c´mo el software est´ estructurado desde el punto de vista o al´gico para el cliente m´vil. o o GUI activityDomain user team game model.entity service service model.entity service model.entity message place service service comunication model.entity model.entity Persistence Figura 5.9: Arquitectura del Software de cliente Android
  • 82. CAP´ ˜ ITULO 5. DISENO 80El servidor Esta compuesto por tres capas: la vista, el dominio y la capa de informaci´n o Es responsable de administrar toda la informaci´n de los usuarios, de los o equipos, de los juegos, de las pistas, de las metas y de los mensajes La persistencia de los datos es almacenada en una base de datos El servidor implementa servicios Web con Apache Axis, y una API REST utilizando HTTP/XML, lo cual permite el desarrollo de clientes para distintos tipos de dispositivos y sistemas operativos La Figura 5.10 muestra como el sistema esta estructurado desde el punto de vistal´gico. o
  • 83. CAP´ ˜ ITULO 5. DISENO 81 Figura 5.10: Arquitectura del Software de servidor
  • 84. CAP´ ˜ ITULO 5. DISENO 82El Servicio de mapas El servicio de mapas o servidor de tiles es el proveedor de im´genes georeferen- aciadas que muestran informaci´n cartogr´fica, como calles, puentes, edificios entre o aotros. Los tiles en nuestro caso son im´genes de 256x256 pixeles. a El servicio de mapas a utilizar ser´ el que ofrece OpenStreetMap[21], debido a la alicencia con que se entrega la informaci´n, y adem´s, por que existen librer´ para o a ıasAndroid para hacer uso de la informaci´n entregada por sus servidores. o5.6. Diagrama de clases de dise˜ o de capa de negocio o do- n minio En esta secci´n se muestran los diagramas de clases m´s importantes de la capa o ade negocio.5.6.1. Entidades En esta secci´n se muestran las clases que encapsulan la informaci´n o estado en o oel sistema. Como se aprecia en el diagrama de componentes de la Figura 5.6, se han identi-ficado 5 entidades o componentes: usuarios, equipos, mensajes, lugares, y juego, porlo que se muestra un diagrama de clases de entidad por cada uno de ellos. Como se aprecia en la Figura 5.11, el componente de usuario contiene la clase Us-er y PersonalInformation, que administra solo la informaci´n referente a los usuarios. o user.model.entity User PersonalInformation +userId:long +name:String +username:String 1 +phone=String +password:String +surname:String +role:String +country:String +latitude:int +showPersonalInfo:bool +longitude:int +email:Strinh +bool 1 Figura 5.11: Entidades del subsistema de usuario
  • 85. CAP´ ˜ ITULO 5. DISENO 83 Como se aprecia en la Figura 5.12, el componente de equipos contiene las clasesTeam y UserTeam, en la que esta ultima hace referencia a los usuarios del m´dulo ´ ode usuarios. team.model.entity Team UserTeam * +teamId:long +userId:long +name:String +teams:Set<Team> +Description:String +users:set<User> +addUser(User) * Figura 5.12: Entidades del subsistema de equipo Como se aprecia en la Figura 5.13, con an´lisis similar al anterior se puede ten- aer un m´dulo independiente de comunicaci´n y mensajer´ donde se relacionan los o o ıa,mensajes con referencias al remitente y destinatario, los que son usuarios en el m´du- olo de usuarios. message.model.entity UserMessage Message +userId:long +messageId:long +messages:Set<Message> +body:String +date:DateTime * 1 +readed:bool send * +sender:User +receivers:Set<User> receive * +type:String +readed() Figura 5.13: Entidades del subsistema de mensajer´a ı Como se aprecia en la Figura 5.14, con an´lisis similar a los anteriores se puede atener un m´dulo independiente de lugares, que administre solo la informaci´n refer- o oentes a los lugares, como por ejemplo su posici´n y descripci´n. o o
  • 86. CAP´ ˜ ITULO 5. DISENO 84 place.model.entity Place +placeId:long +latitude:int +longitude:int +name:String +description:String +type:String Figura 5.14: Entidades del subsistema de lugar Como se aprecia en la Figura 5.15, con an´lisis similar a los anteriores, se puede adefinir un m´dulo independiente de juego, que administre solo la informaci´n refer- o oente a los juegos, y relaciones que hacen referencias a los usuarios, equipos, mensajesy lugares, de los otros componentes. game.model.entity Game PlaceGame +gameId:long UserGame +placeId:long +name:String +userId:long * +game:Game +description:String see +teamsCanSeeMe:set<Team> +placesICanSee:set<Place> +startDate:DateTime * +teamsHaveMe:set<Team> +addPlaceICanSee() +finishDate:DateTime +usersCanSeeMe:set<User> +finished:bool +type:String * has * +maxTeams:int +addTeamCanSeeMe() +maxUsersPerTeam:int +addTeamHaveMe() +latitude:int * +addUserCanSeeMe() +longitude:int +city:String TeamGame take +teams:set<Team> +teamId:long +places:set<Place> +game:Game * +addTeam() +placesICanSee:Place +addPlace() +placesIHave:Place * Goal Hint +addPlaceICanSee() contain 1 +addPlaceIHave() Figura 5.15: Entidades del subsistema de juego5.6.2. Acciones o implementaci´n de Casos de Uso o En esta secci´n se muestran las clases que implementan los casos de uso, creando oy modificando el estado o atributos de las entidades. En la Figura 5.16 se muestran las clases que llevan a cabo la implementaci´n de olos casos de uso o acciones del componente de usuarios.
  • 87. CAP´ ˜ ITULO 5. DISENO 85 generic.model.manager <<interface>> GenericManager +create() +find() +exists() +update() +remove() user.model.manager <<interface>> UserManager UserManagerImpl +updateLocation() +login() +UserAccessor +register() +changePassword() +updatePersonalInfo() +findByUserName() Figura 5.16: Managers del subsistema de usuario En la Figura 5.17 se muestran las clases que llevan a cabo la implementaci´n de olos casos de uso o acciones del componente de juegos. game.model.manager <<interface>> <<interface>> <<interface>> GameManager PlaceManager UserManager +joinGame():bool +takePlace():bool +abandonGame():bool +startOrContinueGame() +findCitiesWithGames():List<String> +findGamesByCity():List<Game> +findGamesByLocation():List<Game> <<interface>> +countActiveGames():int +countFinishedGames():int TeamManager +countNotFinishedGames():int +findActiveGames():List<Game> +findTeamsByGame():List<TeamTO> +findNotFinishedGames():List<Game> +findFinishedGames():List<Game> +observeGame() +createGame():Game +addHint():boolean Figura 5.17: Managers del subsistema de juego Con el dise˜ o y an´lisis aplicados se obtienen m´dulos o componentes inde- n a opendientes que pueden ser reutilizados por nuevas aplicaciones sin tener que re-implementar funcionalidad, sino solo consumir distintos componentes.
  • 88. CAP´ ˜ ITULO 5. DISENO 86 Por ejemplo, si se desease dise˜ ar una aplicaci´n en la cual el fin es que los n ousuarios sean due˜ os de algunos lugares, bastar´ con implementar un m´dulo que n ıa orelacione los componentes de usuarios y lugares con el concepto de “ser due˜ o de”. n5.7. Persistencia de datos o capa de datos Esta secci´n describe c´mo la persistencia de la informaci´n es llevada a cabo. o o o5.7.1. Acceso a la base de datos El acceso a la base de datos es implementada utilizando un framework ORM(Object Relational Mapping), que realiza una representaci´n directa de la base de odatos en Objetos Java y viceversa. Lo que permite tener un tiempo r´pido de desar- arollo, ya que se trabaja solo con el paradigma orientado a objetos, al no ser necesariocrear el modelo relacional, ya que no es necesario escribir el c´digo de persistencia, oni las sentencias SQL que copian los valores desde las propiedades de las clases, esel framework ORM quien se encarga de hacer la tarea de almacenar la informaci´n ocontenida en las clases a la base de datos.5.7.2. Estructura de la base de datos La Figura 5.18 muestra la base de datos que utiliza el framework ORM paraalmacenar la informaci´n de las clases del componente de juegos. o
  • 89. CAP´ ˜ ITULO 5. DISENO 87 Figura 5.18: Diagrama Entidad Relaci´n - componente de juegos o
  • 90. CAP´ ˜ ITULO 5. DISENO 885.7.3. Accessor o DAO(Data Access Object) En esta secci´n se muestran las clases que interact´ an para llevar a cabo la per- o usistencia de la informaci´n contenida en las entidades a una base de datos relacional. o Para no depender de un framework de persistencia, como por ejemplo Hibernate,se han definido interfaces seg´ n la entidad con la interact´ an, para poder utilizar u ucualquier framework de persistencia. En los siguientres diagramas se muestran lasclases que implementan la persistencia para el framework Hibernate de modo deejemplo. La Figura 5.19 muestra las clases que implementan la persistencia para el com-ponente de usuarios. generic.model.persistence.accessor <<interface>> GenericAccessor GenericAccessorHibernate +create() -sessionFactory +find() +exists() +update() +remove() user.model.persistence.accessor <<interface>> UserAccessor +findByUsername() UserAccessorHibernate Figura 5.19: Accessor del subsistema de usuario
  • 91. CAP´ ˜ ITULO 5. DISENO 89 La Figura 5.20 muestra las clases que implementan la persistencia para el com-ponente de juegos. generic.model.persistence.accessor <<interface>> GenericAccessor GenericAccessorHibernate +create() -sessionFactory +find() +exists() +update() +remove() game.model.persistence.accessor <<interface>> <<interface>> TeamAccessor GameAccessor +findCitiesWithGames():List<String> +findActiveGames():List<Game> <<interface>> +findFinishedGames():List<Game> PlaceAccessor +findNotFinishedGames():List<Game> +findNotFinishedByCity():List<Game> <<interface>> +findNotFinishedByLocation():List<Game> UserAccessor +countActiveGames():int +countFinishedGames():int +countNotFinishedGames():int GameAccessorHibernate Figura 5.20: Accessor del subsistema de juego5.8. Diagrama de estados Los diagramas de estados son artefactos UML que representan los estados yeventos de las cosas, transiciones, casos de uso, personas, etc. a lo largo de su ciclode vida. En los diagramas se indican los estados, una condici´n en un instante de tiempo, olos eventos, una ocurrencia significativa o relevante, que producen cambios o transi-ciones, una relaci´n entre dos estados indica cuando tiene lugar un evento y se pasa odel estado anterior al siguiente. [42]5.8.1. Estados de un juego La Figura 5.21 muestra los estados de un juego a lo largo de su ciclo de vida, losque describen en el Cuadro 5.2.
  • 92. CAP´ ˜ ITULO 5. DISENO 90 creategame on create game savegame start game not started continue delete game paused active pause delete finish deleted game finished game Figura 5.21: Diagrama de estados de un juego Estado Descripci´n o oncreate game Se definen las caracter´ ısticas del juego, cantidad de jugadores, pistas, metas, lugar donde se juega game not started El juego esta creado y listo para ser jugado active El juego esta siendo jugado game paused El juego se ha detenido, ´ste se continuar´ jugando e a cuando se desee finished game El juego ha terminado con ´xito a causa de que e alg´ n equipo ha alcanzado alguna de las metas u deleted game El juego ha sido eliminado Cuadro 5.2: Descripci´n de estados de un juego o5.8.2. Estados de una pista La Figura 5.22 muestra los estados de una pista a lo largo de su ciclo de vida, losque se describen en el Cuadro 5.3.
  • 93. CAP´ ˜ ITULO 5. DISENO 91 createhint on create hint savehint assigntogame unassigned hint available hint delete delete take deleted hint taked hint Figura 5.22: Diagrama de estados de una pista Estado Descripci´n o oncreate hint Se definen las caracter´ ısticas de la pista, posici´n o geogr´fica, nombre descripci´n a o game not started La pista est´ creada y lista para ser asignada a un a juego available hint La pista est´ asignada a un juego y est´ disponible a a para ser recogida taked hint La pista ha sido recogida por alg´ n competidor del u juego al que pertenece esta deleted hint La pista ha sido eliminada Cuadro 5.3: Descripci´n de estados de una pista o5.8.3. Estados de las capas vista y controlador Para modelar las capas vista y controlador se utilizan diagramas de estados, dondecada estado representa una pantalla que se presenta al usuario y las transiciones entreestados corresponden a las acciones del controlador. Las Figuras 5.23 y 5.24 muestran los diagramas de estados para el servidor de
  • 94. CAP´ ˜ ITULO 5. DISENO 92juego y el cliente m´vil respectivamente. o register Register Home login save Login doLogin loggedHome creategame changepassword ListUsers listgame changepersonalinfo Change Password Create Game List Games List users Change PersonalInfo show show join Show game info joined play Show user info play a game Figura 5.23: Diagrama de estados para las pantallas LoginActivity HomeActivity LogoutActivity FindGameActivity PersolInfo MapActivity ViewGamesActivity ViewMSGActivity SendMSGDialog ViewHintDialog TakePlaceDialog ViewUserInfoDialog ViewTeamsActivity Figura 5.24: Diagrama de estados para las actividades del cliente Android
  • 95. CAP´ ˜ ITULO 5. DISENO 93 En la Figura 5.24 se aprecia que la actividad inicial es LoginActivity, la cual estaencargada de autenticase con el servidor de juego, para posteriormente continuar conla Actividad HomeActivity. A partir de esta ultima se pueden realizar las distintas ´actividades para un usuario autenticado, como por ejemplo, buscar juegos y unirsea estos, enviar mensajes, entre otros.
  • 96. 6. Implementaci´n o Este cap´ ıtulo muestra y explica los aspectos m´s importantes de la implementaci´n, a oen la cual se ha reutilizado c´digo de otros proyectos con licencias de software libre ocomo lo son osmdroid, Android Runner[4] , entre otros.6.1. Arquitectura del sistema En esta secci´n se presenta la arquitectura del sistema, explicando las partes de o´ste, sus relaciones y las razones de ello, intentando elaborar un sistema que hagaeposible lo que se ha analizado y especificado en las fases anteriores. En la etapa de dise˜ o del software se defini´ ´ste como un conjunto de com- n o eponentes que est´n l´gicamente relacionados, por lo cual, aplicar una arquitectura a oorientada a servicios es una buena opci´n. o La arquitectura elegida para el sistema es orientada a servicios (SOA), las razonesde esta elecci´n se detallan a continuaci´n. o o Los terminales m´viles de los clientes se encargan de la visualizaci´n de los o o datos La capacidad de c´lculo restringida, ya que los terminales m´viles poseen proce- a o sadores poco potentes, adem´s de poseer poca memoria, por ello es mejor no a delegar a estos tareas de c´lculos en cuanto a l´gica de negocio se refiere a o El servidor, al poseer un hardware m´s avanzado puede realizar c´lculos com- a a plejos en poco tiempo Las capacidades de conexi´n a redes con tecnolog´ WIFI y 3G se pueden o ıas aprovechar para poder obtener datos a trav´s de internet, desde el servidor e 94
  • 97. CAP´ ´ ITULO 6. IMPLEMENTACION 95 La l´gica de negocio se encuentra en un solo lugar, el servidor de servicio Web. o No es necesaria la replicaci´n de esta en cada uno de los terminales o alguna o otra entidad que se relacione o consuma alg´ n servicio Web particular u La reutilizaci´n de componentes es un punto importante, ya que se pueden o desarrollar otras aplicaciones basadas en los servicios ya desarrollados La facilidad para la integraci´n de diferentes tecnolog´ o ıas La facilidad para desarrollar aplicaciones por terceros El cliente consume distintos servicios, al igual que los servidores pasan a ser tam-bi´n clientes, ya que consumen servicios de otros servidores. La Figura 6.1 muestra la earquitectura SOA y como interact´ an distintos servicios, para en conjunto cumplir ucon una tarea l´gicamente concreta. Supongamos que existen los servicios de usuario, ode equipo y de juego, y que el segundo consume del primero y el tercero consume elsegundo. Un cliente desea obtener la informaci´n de los usuarios de los equipos en un ojuego particular, es por ello, que consulta al servicio de juego, el que a su vez consultaal servicio de equipo, el que a su vez consulta al servicio de usuario por la informa-ci´n de cada usuario dentro de los equipos en el juego en cuesti´n. El servicio de o ousuario al tener la informaci´n solicitada la retorna al servicio de equipo, el que a su ovez lo hace con el servicio de juego, el que retorna al cliente la informaci´n solicitada. o
  • 98. CAP´ ´ ITULO 6. IMPLEMENTACION 96 Game Service 2-getUserInfoByTeam User Service MSG Service 5- userinfos Place Service 4- userInfo 6- list:userInfo 3- getUserInfo 1-getUsersInfoByGame Team Service Figura 6.1: Arquitectura SOA En concreto, el cliente es una aplicaci´n para dispositivos m´viles con sistema o ooperativo Android, y los servidores son contenedores de Java Servlet que implemen-tan servicios Web con Apache Axis, una interfaz REST y una p´gina Web para la aadministraci´n, que almacena la informaci´n en una base de datos, tal como se apre- o ocia en la Figura 6.2.
  • 99. CAP´ ´ ITULO 6. IMPLEMENTACION 97 Map Service GPS Service Limitofthesystem Server User Servlet Interface Container Competitor db WebClient Admin Interface Admin Figura 6.2: Arquitectura del Sistema El Cuadro 6.1 muestra una descripci´n de los distintos elementos que aparecen oen la Figura 6.2. Elemento Descripci´n o Map Service Provee los datos de los mapas (Tiles) GPS Service Provee la ubicaci´n actual del cliente o DB Almacena la informaci´n del sistema (usuarios, o hints, goals, teams, etc) Servidor Permite conectarse a los servicios del juego y maneja los request del cliente Android Client Un dispositivo m´vil con Android, con la apli- o caci´n instalada o Web Client Aplicaci´n Web que interact´ a con el servidor de o u juego, permite la administraci´n y muestra infor- o maci´n de juegos, usuarios, puntaje o User Interface Define c´mo interact´ an los clientes y el servidor o u de juego. Cuadro 6.1: Descripci´n de la Arquitectura del Sistema o
  • 100. CAP´ ´ ITULO 6. IMPLEMENTACION 986.2. Diagrama de Clases de la capa de presentaci´n o En esta secci´n se muestran los diagramas de clases para la implementaci´n del o ocliente en Android, y de la aplicaci´n Web utilizando Apache Wicket. o Los diagramas solo muestran las clases m´s importantes. a En la Figura 6.3 se muestran las clases que interact´ an en la implementaci´n del u ojuego en el cliente Android. android.app.Activity Activity service comuncationactivity UserService THHelper RestTHHelper Login +login(username,password) use Runnable <<use>> <<use>> HttpHelper <<showdatain>> LoginTask +client:HttpClient HttpUserServiceImpl +request:HttpUriRequest +run() +response:HttpResponse +login(username,password) AxisTHHelper +instance:HttpHelper +getInstance():HttpHelper <<use>> +login(username,password):User LoginHandler +handleMessage() Handler Figura 6.3: Diagrama de Clases del Cliente Android En la Figura 6.4 se muestran las clases que interact´ an en la implementaci´n del u ojuego en el servidor utilizando Apache Wicket, en el que se pueden apreciar las clasespara la implemenaci´n de la administraci´n Web. o o
  • 101. CAP´ ITULO 6. IMPLEMENTACION org.apache.wicket.authentication org.apache.wicket.markup.html AuthenticatedWebSession WebPage AuthenticatedWebApplication +signIn(username,password):boolean view.web.applicationFigura 6.4: Diagrama de Clases del Servidor view.web org.springframework.security.core.context BasePage SecurityContextHolder WicketApplication +userService:UserService +gameService:GameService +get():WicketApplication +getGameService():GameService ´ LoginPage view.web.session WicketSession GameDetailsPage -loginResultTO:LoginResultTO +authenticate(username,password) +get():WicketSession +getLoginResultTO():LoginResultTO UserServiceAuthenticationManager +authenticate(usernamePasswordAuthenticationToken):Authentication model.service GameService org.springframework.security.authentication <<instance>> +findGameById(gameId):GameTO AuthenticationManager UserService org.springframework.security.core +authenticate(usernamePasswordAuthenticationToken):Authentication Authentication 99
  • 102. CAP´ ´ ITULO 6. IMPLEMENTACION 1006.3. Diagrama de Secuencia de implementaci´n o En esta secci´n se muestran los diagramas de secuencia para la implementaci´n o odel cliente en Android, y de la aplicaci´n Web utilizando Apache Wicket. o Los diagramas solo muestran las clases m´s importantes. a En la Figura 6.5 se muestran las clases que interact´ an en la implementaci´n y u oel paso de mensajes en el cliente Android.
  • 103. CAP´ ITULO 6. IMPLEMENTACIONFigura 6.5: Diagrama de Secuencia del Cliente Android HttpHelper +client:HttpClient +request:HttpUriRequest +response:HttpResponse HttpClient HttpResponse XMLToBussinessConversor Login LoginTask LoginHandler HttpUserServiceImpl +instance:HttpHelper +getInstance():HttpHelper +toUser(entity:HttpEntity) +run() +handleMessage() +login(username,password) +login(username,password):User onClick(View v) LoginTask(username, password) run() login(username,password) ´ login(username, password) execute(request) response getEntity entity toUser(entity) User User User sendMessage 101
  • 104. el paso de mensajes en la aplicaci´n Web del componente de juego. CAP´ En la Figura 6.6 se muestran las clases que interact´ an en la implementaci´n y ITULO 6. IMPLEMENTACION WicketSessionFigura 6.6: Diagrama de Secuencia del servidor LoginPage -loginResultTO:LoginResultTO UserService +authenticate(username,password) +doExecute():boolean +get():WicketSession +authenticate():Authentication +getLoginResultTO():LoginResultTO UserServiceAuthenticationManager SecurityContext o get() ´ session signIn(username, password) authenticate(username, password) authenticate() authentication authentication setAuthentication(authentication) bool u o 102
  • 105. CAP´ ´ ITULO 6. IMPLEMENTACION 1036.4. Persistencia Para poder hacer el desarrollo de la persistencia m´s intuitivo y r´pido se utiliza a aSpring[26] con Hibernate[14]. Adem´s, se usan anotaciones, de la forma @anotaci´n, un m´todo para a˜ adir a o e nmeta-datos al c´digo fuente Java que est´n disponibles para la aplicaci´n en tiem- o a opo de ejecuci´n, para, por ejemplo, declarar la base de datos en el c´digo fuente, o odefiniendo la llave primaria con @Id, como se aprecia en el c´digo 6.1, o definir el oURI por el que responde un Servlet en el c´digo 6.2 con @MountPath. o C´digo 6.1: Anotaciones: DB o @Entity public class User { private long userId; ... @Id @GeneratedValue(strategy=GenerationType.AUTO, generator="UserIdGenerator") @SequenceGenerator( // It only takes effect for name="UserIdGenerator", // databases providing identifier sequenceName="UserSeq") // generators. public long getUserId() { return userId; } C´digo 6.2: Anotaciones: URI o @MountPath(path = "user/home") @AuthorizeInstantiation("ROLE_USER") public class UserHomePage extends HomePage {6.4.1. Base de datos El sistema, al utilizar Hibernate, soporta diferentes motores de base de datos,siendo de nuestro inter´s PostgreSQL y MySQL. e
  • 106. CAP´ ´ ITULO 6. IMPLEMENTACION 104 A continuaci´n se muestran las configuraciones para utilizar MySQL y Post- ogreSQL como motor de base de datos, en los c´digos 6.3 y 6.4 respectivamente. o C´digo 6.3: MySQL o datasource.driver=com.mysql.jdbc.Driver datasource.url=jdbc:mysql://localhost/memoria2-team datasource.username=thgame datasource.password=*** hibernate.dialect = org.hibernate.dialect.MySQLDialect C´digo 6.4: PostgreSQL o datasource.driver = org.postgresql.Driver datasource.url = jdbc:postgresql://localhost/memoria2 datasource.username=thgame datasource.password=*** #hibernate.dialect = org.hibernate.dialect.PostgreSQLDialect6.4.2. Clases persistentes Como se puede apreciar en el c´digo 6.5, las clases persistentes son clases POJO o(Plain Old Java Object), clases simples, sin nada especial y que no dependen de unframework en particular, es as´ dado que todo el modelo persistente es POJO, que ı,´ste es f´cilmente testeable y portable.e a C´digo 6.5: JPA o package com.jpizarro.th.server.user.model.entity; import java.util.HashSet; import java.util.Set; import javax.persistence.CascadeType; import javax.persistence.Entity; import javax.persistence.FetchType; import javax.persistence.GeneratedValue; import javax.persistence.GenerationType;
  • 107. CAP´ ´ ITULO 6. IMPLEMENTACION 105 import javax.persistence.Id; import javax.persistence.JoinColumn; import javax.persistence.JoinTable; import javax.persistence.ManyToMany; import javax.persistence.ManyToOne; import javax.persistence.SequenceGenerator; import org.hibernate.annotations.AccessType; import com.jpizarro.th.server.place.model.entity.Place; import com.jpizarro.th.server.team.model.entity.Team; @Entity public class User { ... @Id @GeneratedValue(strategy=GenerationType.AUTO, generator="UserIdGenerator") @SequenceGenerator( // It only takes effect for name="UserIdGenerator", // databases providing identifier sequenceName="UserSeq") // generators. public long getUserId() { return userId; } public void setUserId(long userId) { this.userId = userId; }6.5. Comunicaci´n o La comunicaci´n entre el servidor y los clientes es implementada por distintos om´todos ampliamente utilizados, para as´ facilitar el desarrollo de clientes por ter- e ıceros para distintos dispositivos y sistemas operativos.
  • 108. CAP´ ´ ITULO 6. IMPLEMENTACION 1066.5.1. Intercambio de datos REST La interfaz REST ha sido implementada con XML, ya que es una de las inter-pretaciones de datos m´s utilizadas. a Para la serializaci´n de los objetos a XML y viceversa, se utiliza la librer´ o ıaXStream como se aprecia en los c´digos 6.6 y 6.7, la configuraci´n y declaraci´n o o ode clases serializables utilizando anotaciones respectivamente. C´digo 6.6: XStream: configuraci´n o o <bean id="xstreamMarshaller" class="org.springframework.oxm. xstream.XStreamMarshaller"> <property name="autodetectAnnotations" value="true" /> <property name="annotatedClasses"> <list> <value>com.jpizarro.th.lib.team.entity.UserTO</value> <value>com.jpizarro.th.lib.team.entity.TeamTO</value> </list> </property> </bean> C´digo 6.7: XStream: anotaciones o import java.io.Serializable; import java.util.ArrayList; import java.util.List; import javax.xml.bind.annotation.XmlRootElement; import com.thoughtworks.xstream.annotations.XStreamAlias; import com.thoughtworks.xstream.annotations.XStreamImplicit; @XStreamAlias("team") public class TeamTO implements Serializable { En el c´digo 6.8 se aprecia como se implementa la interfaz REST del sub-sistema ode equipos, “/teams”. El m´todo getEntity es el responsable de responder consultas eGET, el cual recibe el Id del equipo. Con la anotaci´n @Controller se dice que la clase es un controllador que debe ser otomado en cuenta por Spring, y con @RequestMapping(/teams”) se declara la URI
  • 109. CAP´ ´ ITULO 6. IMPLEMENTACION 107por la que es responsable ´ste. e C´digo 6.8: Spring o @Controller @RequestMapping("/teams") public class TeamController implements GenericController<TeamTO, Long>{ @Autowired private TeamService teamService; private String XML_VIEW_NAME = "xmlView"; @RequestMapping(method=RequestMethod.GET, value="/{id}") @ResponseBody public TeamTO getEntity(@PathVariable Long id) {6.5.2. Servicios Web SOAP con Apache Axis2 Otro m´todo de comunicaci´n se implement´ con Apache Axis2, en el c´digo 6.9 e o o ose muestra el archivo de configuraci´n del servicio Web de usuario, con lo cual se oexponen los m´todos de clase para ser consumidos por otras aplicaciones. e C´digo 6.9: Servicio Axis: configuraci´n o o <serviceGroup> <service name="WSUserService"> <!-- Invoke SpringInit on server startup and shutdown --> <!-- <service name="SpringAwareService" class="com.jpizarro.th. server.view.axis.SpringInit"> --> <description> simple spring example - inside the AAR </description> <!-- need the TCCL param when using spring inside the AAR --> <parameter name="ServiceTCCL">composite</parameter> <parameter name="ServiceObjectSupplier">org.apache.axis2. extensions.spring.receivers. SpringAppContextAwareObjectSupplier </parameter> <parameter name="SpringBeanName">wSUserService</parameter> <messageReceivers>
  • 110. CAP´ ´ ITULO 6. IMPLEMENTACION 108 <messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-only" class="org.apache.axis2.rpc.receivers. RPCInOnlyMessageReceiver" /> <messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out" class="org.apache.axis2.rpc.receivers.RPCMessageReceiver" /> </messageReceivers> </service> </serviceGroup>6.5.3. Seguridad La seguridad de la informaci´n es un punto importante en el desarrollo de cualquier osoftware, es as´ que existen distintas posibilidades para proveer seguridad a un sis- ıtema. Algunos de los m´todos de seguridad implementados se presentan a contin- euaci´n. oSesi´n de usuario y Roles o Al ser distintos tipos de usuarios los que acceden al software, se hace necesariorestringir el acceso a las distintas partes de ´ste. Es por ello que se implement´ per- e omisos de acceso con Spring dependientes del rol que posee el usuario, admin o user. En el c´digo 6.10 se muestra c´mo se restringe el acceso a la p´gina de detalles de o o ajuego a los usuarios que tienen el rol de user con la anotaci´n AuthorizeInstantiation. o C´digo 6.10: Roles o import org.apache.wicket.authorization.strategies.role.annotations. AuthorizeInstantiation; ... @AuthorizeInstantiation("ROLE_USER") public class GameDetailsPage extends BasePage { ... En el c´digo 6.11 se muestra la configuraci´n que hace posible la utilizaci´n de o o oSpring para administrar la seguridad. C´digo 6.11: Configuraci´n de seguridad en Spring o o <filter>
  • 111. CAP´ ´ ITULO 6. IMPLEMENTACION 109 <filter-name>springSecurityFilterChain</filter-name> <filter-class>org.springframework.web.filter. DelegatingFilterProxy</filter-class> <!-- <init-param> <param-name>targetBeanName</param-name> <param -value>filterChainProxy</param-value> --> <!-- </init-param> --> </filter> <filter-mapping> <filter-name>springSecurityFilterChain</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <bean id="httpSessionContextIntegrationFilter" class="org.springframework.security.web.context. SecurityContextPersistenceFilter"> </bean>Encriptaci´n o La encriptaci´n puede ser aplicada en distintas capas del software, en nuestro caso ose implementa en algunos String, como por ejemplo, el almacenamiento encriptadode la contrase˜ a de usuario. n6.6. Mapas Como se coment´ anteriormente, el proveedor de mapas a utilizar es Open- oStreetMap [21], dada la licencia de la informaci´n que entrega, adem´s de la creciente o acomunidad que est´ mejorando los mapas d´ a d´ a ıa ıa. Para poder mostrar la informaci´n de mapas que provee OpenStreetMap en la oaplicaci´n Web se decidi´ utilizar OpenLayers [20], una librer´ de JavaScript para o o ıamostrar informaci´n de mapas en navegadores Web. o En el c´digo 6.12 se muestra la configuraci´n para utilizar los tiles de Open- o oStreetMap. C´digo 6.12: OpenLayers o <script type="text/javascript"> var map, layer;
  • 112. CAP´ ´ ITULO 6. IMPLEMENTACION 110 function init(){ map = new OpenLayers.Map( ’map’); layer = new OpenLayers.Layer.OSM( "Simple OSM Map"); map.addLayer(layer); map.setCenter( new OpenLayers.LonLat(-71.147, 42.472).transform( new OpenLayers.Projection("EPSG:4326"), map.getProjectionObject() ), 12 ); } </script> Para poder mostrar la informaci´n de mapas en Android se utiliz´ osmdroid [22], o ocomo se aprecia en el c´digo 6.13 la declaraci´n de la vista de mapa, definiendo como o ofuente de datos Mapnik, el render oficial de OpenStreetMap. C´digo 6.13: Android Map o public class MapActivity extends Activity implements OpenStreetMapConstants{ ... private OpenStreetMapView mOsmv; ... @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); ... this.mOsmv = new OpenStreetMapView(this, OpenStreetMapRendererFactory.MAPNIK); this.mOsmv.setResourceProxy(mResourceProxy); this.mOsmv.setBuiltInZoomControls(true); this.mOsmv.setMultiTouchControls(true);6.7. Paginas Web en Wicket Una p´gina Web en Wicket est´ compuesta por una clase JAVA y un archivo a aHTML. La clase JAVA normalmente extiende a WebPage, y es la encargada de procesar
  • 113. CAP´ ´ ITULO 6. IMPLEMENTACION 111la solicitud y los par´metros de esta, poniendo a disposici´n de la vista los objetos a oque esta necesite. El archivo HTML, contiene solo tags HTML, lo cual permite la separaci´n com- opleta entre la parte l´gica de la visual, con esto para el dise˜ o son necesarios solo o nconocimientos de HTML y CSS, sin ser necesarios conocimientos exhaustivos delmodelo de negocio o conocimientos de JAVA. En el c´digo 6.14 se puede apreciar la clase JAVA que interact´ a con la capa de o unegocio. En particular esta clase es la responsable de solicitar un juego y ponerlo adisposici´n de la vista HTML para que sea mostrado como p´gina Web. o a C´digo 6.14: GameDetailsPage.java o package com.jpizarro.th.server.game.view.web.pages.game.details; import org.apache.wicket.PageParameters; import org.apache.wicket.authorization.strategies.role.annotations. AuthorizeInstantiation; import org.wicketstuff.annotation.mount.MountPath; import org.wicketstuff.annotation.strategy.MountMixedParam; import com.jpizarro.th.entity.GameTO; import com.jpizarro.th.server.game.model.service.GameService; import com.jpizarro.th.server.game.view.web.components.game.details. GameDetailsPanel; import com.jpizarro.th.server.game.view.web.pages.BasePage; import com.jpizarro.th.server.generic.model.persistence.util. exceptions.InstanceNotFoundException; import com.jpizarro.th.server.view.web.application.WicketApplication ; @AuthorizeInstantiation("ROLE_USER") @MountPath(path = "gameDetails") @MountMixedParam(parameterNames={"gameId"}) public class GameDetailsPage extends BasePage { public GameDetailsPage(PageParameters parameters) { super(parameters);
  • 114. CAP´ ´ ITULO 6. IMPLEMENTACION 112 long gameId = parameters.getLong("gameId"); GameService gameService = WicketApplication.get().getGameService (); try { GameTO gameTO = gameService.findGameById(gameId); add(new GameDetailsPanel("gameDetails", gameTO)); } catch (InstanceNotFoundException e) { // TODO Auto-generated catch block e.printStackTrace(); } } @Override protected String getTitle() { return getLocalizer().getString("gameDetails.title", GameDetailsPage.this); } } En el c´digo 6.15 se puede apreciar el archivo HTML encargado de mostrar el odetalle de un juego. Adem´s, se aprecia que solo contiene tags HTML como lo expre- asamos con anterioridad, lo cual es un beneficio de utilizar Wicket como frameworkpara el desarrollo Web. C´digo 6.15: GameDetailsPage.html o <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http ://www.w3.org/TR/html4/loose.dtd"> <html xmlns:wicket="http://wicket.apache.org/"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF -8"> <title>Insert title here</title> </head> <body> <wicket:extend> <div class="column-center" wicket:id="gameDetails"/> </wicket:extend> </body>
  • 115. CAP´ ´ ITULO 6. IMPLEMENTACION 113 </html>6.8. Pruebas La mitigaci´n de errores y el aseguramiento de la calidad del software es una odisciplina muy importante en el desarrollo de software, el cual debe estar presenteen todos los procesos que forman parte de un desarrollo de software, con el fin deevaluar la calidad, usabilidad, validaciones y tolerancia a fallos. En la presente memoria se realizaron pruebas de unidad, un proceso de desarrollode software en el cual se identifican las partes que pueden ser testeadas. En cadauna de las iteraciones, se identifican los m´todos m´s importantes de cada clase e aimplementada, luego, se definen casos de prueba para dichos m´todos. e Adem´s, conforme se van a˜ adiendo nuevas funcionalidades, se crean nuevas prue- a nbas, con las que podemos medir nuestro progreso y comprobar que lo que antes fun-cionaba, sigue funcionando tras haber realizado cambios en el c´digo, este proceso es ollamando test de regresi´n (para mayor detalle de las pruebas realizadas ver Anexo oG). Tambi´n se realizan pruebas de integraci´n entre los distintos componentes o e om´dulos del sistema, para ello, en cada una de las iteraciones, se identifican las ointeracciones entre componentes, luego se definen casos de prueba para dichas inter-acciones (para mayor detalle de las pruebas realizadas ver Anexo G). Para facilitar el proceso de pruebas, y adem´s con la intenci´n de que estas est´n a o epresentes en la mayor´ de las etapas o iteraciones de desarrollo, se utiliza JUnit ıa[16], un framework para escribir pruebas de unidad o de integraci´n automatizadas oen Java. En el c´digo 6.16, se puede apreciar la implementaci´n de las pruebas de unidad o opara la persistencia en el sub-sistema de usuarios. C´digo 6.16: Pruebas de unidad de persistencia de usuario con JUnit o package com.jpizarro.th.server.user.model.test; ... @RunWith(SpringJUnit4ClassRunner.class)
  • 116. CAP´ ´ ITULO 6. IMPLEMENTACION 114 @ContextConfiguration("file:src/main/webapp/WEB-INF/spring/app- config.xml") @TransactionConfiguration(transactionManager="transactionManager", defaultRollback=false) @Transactional //@TestExecutionListeners( { TransactionalTestExecutionListener. class }) public class UserTest { @Autowired UserAccessor userAccesor; @Test public void testCreateAndRemove() throws DuplicateInstanceException, InstanceNotFoundException{ User u = new User("Juan", "123", "ss@es.cl", "ROLE_USER"); userAccesor.create(u); userAccesor.remove(u.getUserId()); } @Test public void testFindByUsername() throws InstanceNotFoundException, DuplicateInstanceException{ User u = new User("Juan", "123", "ss@es.cl", "ROLE_USER"); userAccesor.create(u); userAccesor.findByUsername(u.getUsername()); } @Test(expected = InstanceNotFoundException.class) public void testInstanceNotFound() throws InstanceNotFoundException { User u = new User("Juans", "123", "ss@es.cl", "ROLE_USER"); userAccesor.findByUsername(u.getUsername()); } @Test(expected = DuplicateInstanceException.class) public void testDuplicateInstance() throws DuplicateInstanceException { User u1 = new User("Juan", "123", "ss@es.cl", "ROLE_USER"); userAccesor.create(u1);
  • 117. CAP´ ´ ITULO 6. IMPLEMENTACION 115 User u2 = new User("Juan", "123", "ss@es.cl", "ROLE_USER"); userAccesor.create(u2); } } 6.9. Implementaci´n iterativa o Durante el desarrollo del proyecto existen diferentes entregables de software, dado el comportamiento incremental y evolutivo de la metodolog´ aplicada. ıa Se establece un cronograma de entregas, tambi´n conocido como plan de entregas, e donde estas son compuestas por un conjunto de iteraciones. A continuaci´n se muestran las entregas y un resumen de las principales activi- o dades realizadas en cada iteraci´n (para mayor detalle, ver Anexo G). o Core El conjunto de iteraciones que componen esta entrega buscan la implementaci´n o del core, o n´ cleo del software y la persistencia de la informaci´n u oIter. 1. Se implementan las entidades y la persistencia de estasIter. 2. Se implementan los servicios de usuarios y equiposIter. 3. Se implementa el servicio de lugaresIter. 4. Se implementa el servicio de juegosIter. 5. Se implementa el servicio de mensajer´ y se integran las servicios implemen- ıa, tados en las iteraciones anteriores. Apache Axis El conjunto de iteraciones que componen esta entrega buscan la implementaci´n o del servicio Web con AxisIter. 6. Se implementan los servicios Web con Apache Axis
  • 118. CAP´ ´ ITULO 6. IMPLEMENTACION 116 REST El conjunto de iteraciones que componen esta entrega buscan la implementaci´n o del servicio Web REST Iter. 7. Se implementan servicios Web REST Web El conjunto de iteraciones que componen esta entrega buscan la implementaci´n o de la aplicacion Web Iter. 8. Se implementa la aplicaci´n Web o Cliente m´vil: Core y mapas o El conjunto de iteraciones que componen esta entrega buscan la implementaci´n o del core o n´ cleo del cliente m´vil, comunicaci´n con el servidor de juego y la inter- u o o acci´n con mapas o Iter. 9. Se implementa la comunicaci´n entre el cliente Android y el servidor de juego oIter. 10. Se implementa la Interfaz de mapa del cliente Android Cliente m´vil o El conjunto de iteraciones que componen esta entrega buscan la implementaci´n o de la interfaz de juego en el cliente m´vil oIter. 11. Se implementa la Interfaz de usuario del cliente Android. En las siguientes iteraciones se procede a la re-implementacion del software basa- do en una arquitectura SOA, con m´ ltiples sub-sistemas, seg´ n el dise˜ o mostrado u u n en el cap´ ıtulo de dise˜ o. n
  • 119. CAP´ ´ ITULO 6. IMPLEMENTACION 117 Core El conjunto de iteraciones que componen esta entrega buscan la implementaci´n o del core, o n´ cleo del software y la persistencia de la informaci´n u oIter. 12. Se implementa la persistencia y acciones o casos de uso del sub-sistema de usuariosIter. 13. Se implementa la persistencia y acciones o casos de uso del sub-sistema de equiposIter. 14. Se implementa la persistencia y acciones o casos de uso del sub-sistema de lugaresIter. 15. Se implementa la persistencia y acciones o casos de uso del sub-sistema de mensajesIter. 16. Se implementa la persistencia y acciones o casos de uso del sub-sistema de juego REST El conjunto de iteraciones que componen esta entrega buscan la implementaci´n o del servicio Web con RESTIter. 17. Se implementan servicios Web REST de los distintos sub-sistemas Axis El conjunto de iteraciones que componen esta entrega buscan la implementaci´n o del servicio Web con AxisIter. 18. Se implementan los servicios Web con Apache Axis de los distintos sub-sistemas Web El conjunto de iteraciones que componen esta entrega buscan la implementaci´n o de la aplicacion WebIter. 19. Se implementa la aplicaci´n Web del sub-sistema de juego o
  • 120. CAP´ ´ ITULO 6. IMPLEMENTACION 118 Cliente m´vil o El conjunto de iteraciones que componen esta entrega buscan la implementaci´n o de la interfaz de juego en el cliente m´vil y la comunicaci´n con el servidor de juego o oIter. 20. Se implementa el cliente Android 6.10. Dependencias entre la capa de negocio y datos La Figura 6.7 muestra las relaciones y/o dependencias entre las clases entidades, servicios y persistencia del componente de juegos. persistence.accessor service GenericAccessor userAccessor UserService +create() +find() +authenticate(usernamePasswordAuthenticationToken):Authentication +exists() +update() +remove() GameService GenericAccessorHibernate +findGameById(gameId):GameTO UserAccessorHibernate UserServiceImpl +userAccessor:UserAccessor GameServiceImpl +UserAccessor +GameAccessor GameAccessorHibernate +TeamAccessor GameAccessor +PlaceAccessor service.to +MessageAccessor GameTO entity Game Figura 6.7: Dependencias Servicio, Accessor, Entidad 6.11. Arquitectura f´ ısica del software Para mejor modularidad y reutilizaci´n del c´digo se ha separado en m´dulos, en o o o que XXX se refiere a los distintos subsistemas, usuario, equipo, mensajes, lugares y juego: TH Android Client: Es un cliente para la plataforma Android, que contiene la l´gica para mostrar mapas y otros componentes gr´ficos al usuario o a
  • 121. CAP´ ´ ITULO 6. IMPLEMENTACION 119 TH Library: Es una librer´ utilizada por el cliente y el servidor para compartir ıa definiciones de clases TH Server Library: Es una librer´ que contiene las clases e interfaces usadas ıa por la aplicaci´n Web, servicios Web con Apapche Axis, interfaz REST y otros o m´dulos del servidor o TH Library XXX: Es una librer´ que contiene las clases e interfaces del sub- ıa sistema XXX usadas por la aplicaci´n Web, servicios Web con Apapche Axis, o interfaz REST, otros m´dulos del servidor y el cliente o TH Server XXX: Es la implementaci´n de la l´gica para el sub-sistema XXX o o TH Web XXX: Esta un interfaz Web para administradores y usuarios para el sub-sistema XXX TH Axis XXX: Es la implementaci´n de servicio Web con Apache Axis para o el sub-sistema XXX TH REST XXX: Es la implementaci´n de REST para el sub-sistema XXX o
  • 122. CAP´ ´ ITULO 6. IMPLEMENTACION 120 En la Figura 6.8 se muestran las dependencias de los distintos m´dulos ya expli- ocados. THAndroidClient com.thoughtworks.xstream THClientREST THClientAxis org.apache.axis2 THLibrary THAxisXXX THLibraryXXX org.springframework THRESTXXX THServerLibrary THServerXXX THWebXXX org.wicketstuff org.apache.wicket org.hibernate javax.persistence Figura 6.8: Arquitectura f´sica del software ı6.12. Diagrama de dise˜ o de paquetes n Esta secci´n muestra los diagramas de paquetes para los distintos m´dulos del o osistema, ya que el dise˜ o de los sub-sistemas es similar, solo se muestra para el nsus-sistema de juego y librer´ gen´ricas. ıas eTH Library En la Figura 6.9 se muestran los paquetes que forman parte del m´dulo TH Li- obrary, los que se explican en el Cuadro 6.2.
  • 123. CAP´ ´ ITULO 6. IMPLEMENTACION 121 com.jpizarro.th.lib.generic util.exception util.xml.xstream Figura 6.9: Diagrama de paquetes de la librer´a gen´rica ı e Paquete Descripci´n o util.exception Contiene definiciones de clases e interfaces para manejar mejor las excepciones util.xml.xstream Contiene definiciones de clases e interfaces para convertir desde XML a objetos JAVA Cuadro 6.2: Descripci´n de los paquetes de la librer´a gen´rica o ı eTH Server Library En la Figura 6.10 se muestran los paquetes que forman parte del m´dulo TH oServer Library, los que se explican en el Cuadro 6.3.
  • 124. CAP´ ´ ITULO 6. IMPLEMENTACION 122 com.jpizarro.th.server.generic model.entity model.persistence model.service view.axis view.rest view.web view.web.ws util.exceptions Figura 6.10: Diagrama de paquetes de la librer´a gen´rica del servidor ı e
  • 125. CAP´ ´ ITULO 6. IMPLEMENTACION 123 Paquete Descripci´n o model.entity Contiene definiciones de clases e interfaces gen´ricas para las entidades e model.persistence Contiene definiciones de clases e interfaces gen´ricas para la implementaci´n de la per- e o sistencia model.service Contiene definiciones de clases e interfaces gen´ricas para la implementaci´n de los ser- e o vicios o casos de uso view.axis Contiene definiciones de clases e interfaces gen´ricas para la implementaci´n servicios e o Web con Apache Axis view.rest Contiene definiciones de clases e interfaces gen´ricas para la implementaci´n de la inter- e o faz REST view.Web Contiene definiciones de clases e interfaces gen´ricas para la implementaci´n de la apli- e o caci´n Web o util.exception Contiene definiciones de clases e interfaces para manejar mejor las excepciones en el servidor Cuadro 6.3: Descripci´n de los paquetes de la librer´a gen´rica del servidor o ı eTH Library Game En la Figura 6.11 se muestran los paquetes que forman parte del m´dulo TH oLibrary Game, los que se explican en el Cuadro 6.4.
  • 126. CAP´ ´ ITULO 6. IMPLEMENTACION 124 com.jpizarro.th.lib.game entity entity.list entity.response util.xml.xstream Figura 6.11: Diagrama de paquetes de la librer´a del sub-sistema juego ı Paquete Descripci´n o entity Contiene definiciones de clases e interfaces para las entidades del sub-sistema de juego entity.list Contiene definiciones de clases e interfaces para colecciones de entidades del sub-sistema de juego entity.response Contiene definiciones de clases e interfaces para mejorar la comunicaci´n con los clientes o del sub-sistema de juego util.xml.xstream Contiene definiciones de clases e interfaces para convertir desde XML a objetos JAVA del sub-sistema de juego Cuadro 6.4: Descripci´n de los paquetes de la librer´a del sub-sistema juego o ıTH Server Game En la Figura 6.12 se muestran los paquetes que forman parte del m´dulo TH oServer Game, los que se explican en el Cuadro 6.5.
  • 127. CAP´ ´ ITULO 6. IMPLEMENTACION 125 com.jpizarro.th.server.game model.entity model.persistence model.service utilFigura 6.12: Diagrama de paquetes de la implementaci´n del servidor del sub-sistema ojuego Paquete Descripci´n o model.entity Contiene la definiciones de clases e interfaces para las entidades del sub-sistema de juego model.persistence Contiene la implementaci´n de la persisten- o cia del sub-sistema de juego model.service Contiene la implementaci´n de los servicios o o casos de uso del sub-sistema de juego util Contiene definiciones de clases e interfaces de apoyo para la implementaci´n del sub- o sistema de juegoCuadro 6.5: Descripci´n de los paquetes de la implementaci´n del servidor del sub-sistema o ojuegoTH REST Game En la Figura 6.13 se muestran los paquetes que forman parte del m´dulo TH oREST Game, los que se explican en el Cuadro 6.6. com.jpizarro.th.server.game.view.rest Figura 6.13: Diagrama de paquetes de la implementaci´n REST del juego o
  • 128. CAP´ ´ ITULO 6. IMPLEMENTACION 126 Paquete Descripci´n o view.rest Contiene la implementaci´n REST del sub- o sistema de juego Cuadro 6.6: Descripci´n de los paquetes de la implementaci´n REST del juego o oTH Axis Game En la Figura 6.14 se muestran los paquetes que forman parte del m´dulo TH Axis oGame, los que se explican en el Cuadro 6.7. com.jpizarro.th.server.game.view.axis Figura 6.14: Diagrama de paquetes de la implementaci´n Axis del juego o Paquete Descripci´n o view.axis Contiene la implementaci´n AXIS del sub- o sistema de juego Cuadro 6.7: Descripci´n de los paquetes de la implementaci´n Axis del juego o oTH Web Game En la Figura 6.15 se muestran los paquetes que forman parte del m´dulo TH Web oGame, los que se explican en la tabla 6.8. com.jpizarro.th.server.game.view.web Figura 6.15: Diagrama de paquetes de la implementaci´n Web del juego o Paquete Descripci´n o view.Web Contiene la implementaci´n Web del sub- o sistema de juego Cuadro 6.8: Descripci´n de los paquetes de la implementaci´n Web del juego o o
  • 129. CAP´ ´ ITULO 6. IMPLEMENTACION 127TH Android Client En la Figura 6.16 se muestran los paquetes que forman parte del m´dulo TH oAndroid Client, los que se explican en el Cuadro 6.9. com.jpizarro.th.androidclient model service util util activity common Figura 6.16: Diagrama de paquetes del Cliente Android Paquete Descripci´n o activity Contiene la implementaci´n de las activi- o dades common Contiene la implementaci´n de acciones y o ventanas de di´logo comunes a varias activi- a dades model.service Contiene la implementaci´n de las intefaces o de comunicaci´n con el servidor de juego o model.util Contiene definiciones de clases e interfaces de apoyo osm Contiene definiciones de clases e interfaces de apoyo para la interacci´n con los mapas o Cuadro 6.9: Descripci´n de los paquetes de la implementaci´n del cliente Android o o
  • 130. 7. Conclusiones y Trabajos Fu- turos En este cap´ ıtulo se presentan conclusiones sobre el trabajo realizado, y posibleslineamientos de trabajo futuro o mejoras del proyecto en cuesti´n. oConclusiones En la presente memoria se estudi´ y aprendi´ de las tendencias y nuevas tec- o onolog´ utilizando tecnolog´ c´mo GPS y mapas georeferenciados en aplicaciones ıas, ıas om´viles. Tambi´n se ha entendido y aplicado el concepto de sistemas ubicuos, sis- o etemas de software que pueden ser usados en cualquier momento y en cualquier lugarpasando desapercibido al usuario, obteniendo una aplicaci´n no invasiva que puede oser usada en entornos de exterior donde el usuario lo desee. Con relaci´n al apren- odizaje y desarrollo en la plataforma Android, se desarroll´ un cliente de juego para odispositivos m´viles con este sistema operativo. o La plataforma desarrollada se compone de dos partes, la parte del servidor dejuego, donde esta la l´gica, y donde se almacena la informaci´n, y el cliente de juego o om´vil. o El servidor se ha implementado con una arquitectura basada en servicios, en lacual existen distintos servicios Web que interact´ an entre ellos, y con los clientes de ujuego. Estos servicios Web pueden estar ejecutandose en distintos servidores, dondecada uno puede tomar responsabilidades particulares, responsabilidad del servicioWeb de usuario, equipos, lugares, mensajes, o juego. Esto nos permite tener unamejor escalabilidad al poder tratar cada parte de manera independiente, y as´ de- ıcidir, de ser necesario, la ampliaci´n f´ o ısica del equipo computacional que ejecuta un 128
  • 131. CAP´ ITULO 7. CONCLUSIONES Y TRABAJOS FUTUROS 129servicio Web en particular. Con esto se optimizan los recursos econ´micos, ya que olas necesidades de equipamiento pueden ser diferentes seg´ n el servicio Web y la udemanda de uso de ´ste. e Adem´s la arquitectura promueve el desarrollo de aplicaciones por terceros, en aque estos pueden crear aplicaciones que consuman los servicios Web desarrollados enesta memoria, y as´ no duplicar el esfuerzo en el desarrollo de funcionalidades que ya ıest´n presentes en los distintos servicios Web, y as´ enfocarse en su idea o concepto. e ı Gracias al proceso de desarrollo se obtuvo un dise˜ o de la plataforma que no esta nsujeta a alguna tecnolog´ en particular, por ejemplo, se desarrollar´n distintas inter- ıa ofaces para la comunicaci´n, utilizando Apache Axis para imlementar servicios Web ocon SOAP y un API REST/XML, esto facilita la integraci´n con otras aplicaciones oy los cambios en tecnolog´ıas. La utilizaci´n de distintos framework y tecnolog´ de desarrollo ampliamente o ıasusadas en la industria, c´mo Spring, Wicket e Hibernate, permiten utilizar entornos ode producci´n propios o basados en la nube, ya que hay muchos proveedores de osoluciones de infraestructura o plataforma que se enfocan en productos de software,que son desarrollados con estos frameworks. Para la ejecuci´n de los distintos servicios oWeb, se utiliz´ el servicio de plataforma como servicio, que ofrece CloudFoundry, en onuestro caso el que esta orientado a desarrollos en Java con Spring. Es as´ que gracias al dise˜ o, el proceso de desarrollo y las tecnolog´ de la parte ı, n ıasdel servidor, nos permite elejir entre distintas opciones donde alojar y ejecutar laplataforma, seg´ n las necesidades. u GIT y Gitorious como control de versiones, y Redmine para el control de tareasdel proyecto, los que son altamente utilizados en la industria, entregan una visi´n m´s o aamplia de las herramientas y de buenas pr´cticas en el desarrollo de aplicaciones. Lo aque nos permite mejorar la comunicaci´n y organizaci´n de proyectos de desarrollo o ode software. El dise˜ o de la aplicaci´n es uno de los productos obtenidos, que puede ser imple- n omentado con la tecnolog´ que se desee, ya que se ha planteado, estudiado y dise˜ ado, ıa nuna soluci´n tecnol´gicamente neutra. o o El software obtenido, servidor de juego y cliente m´vil, pueden ser utilizados en odistintas ´reas, como lo pueden ser actividades de esparcimiento, jugando y com- apitiendo con amigos u otros usuarios de la plataforma, o como apoyo al desarrollodel turismo local y nacional, al utilizar esta herramienta en la difusi´n de lugares de o
  • 132. CAP´ ITULO 7. CONCLUSIONES Y TRABAJOS FUTUROS 130inter´s, presentando estos como lugares a visitar o descubrir en rutas tem´ticas a los e aturistas.Trabajos Futuros Algunos trabajos futuros que se desprenden del trabajo realizado de este memoriason: El desarrollo de clientes para los dispositivos m´viles m´s utilizados, como o a por ejemplo iPhone y Blackbery, abarcando as´ casi el total del mercado de ı dispositivos m´viles o Agregar soporte de multimedia, el har´ hace m´s atrayente el uso del juego al a a enriquecer la experiencia del usuario. Por ejemplo el relacionar audio, video o im´genes a lugares, permite utilizar la aplicaci´n como gu´ tur´ a o ıa ıstico, donde el usuario debe ir descubriendo la ciudad de una forma entretenida Integraci´n con las distintas redes sociales, la votaci´n de lugares y el poder o o comentar estos, integrando el entorno social virtual que posee el competidor, como el de facebook o foursquare, y f´ ısico al juego Utilizaci´n de c´digos QR y sensores de proximidad pueden enriquecer la ex- o o periencia ubicua, ampliando as´ las posibilidades de juego e interacci´n con ı o el entorno, ya que adem´s de estar f´ a ısicamente en alg´ n lugar geogr´fico, se u a podr´ solicitar la interacci´n con objetos espec´ ıa o ıficos
  • 133. Bibliograf´ ıa ´ [1] Admob. http://www.admob.com. Ultimo acceso el 12 de Abril del 2011. ´ [2] Android developers. http://developer.android.com. Ultimo acceso el 12 de Abril del 2011. ´ [3] Android download page. http://developer.android.com/sdk/index.html. Ultimo ac- ceso el 12 de Abril del 2011. ´ [4] Android runner. http://code.google.com/p/androidrunner/. Ultimo acceso el 12 de Abril del 2011. ´ [5] Apache axis2. http://axis.apache.org/axis2/java/core/. Ultimo acceso el 12 de Abril del 2011. ´ [6] Claro chile. http://www.clarochile.cl/. Ultimo acceso el 12 de Abril del 2011. [7] Core j2ee pattern catalog. http://java.sun.com/blueprints/corej2eepatterns/Patterns/. ´ Ultimo acceso el 12 de Abril del 2011. ´ [8] Entel. http://www.entel.cl/. Ultimo acceso el 12 de Abril del 2011. ´ [9] Facebook. http://www.facebook.com/. Ultimo acceso el 12 de Abril del 2011. ´[10] Flurry. http://www.flurry.com/. Ultimo acceso el 12 de Abril del 2011. ´[11] Gartner. http://www.gartner.com. Ultimo acceso el 12 de Abril del 2011. ´[12] Git. http://git-scm.com/. Ultimo acceso el 12 de Abril del 2011. ´[13] Gitorious. http://gitorious.org/. Ultimo acceso el 12 de Abril del 2011. 131
  • 134. BIBLIOGRAF´ IA 132 ´[14] Hibernate. http://www.hibernate.org/. Ultimo acceso el 12 de Abril del 2011. ´[15] Ine. http://www.ine.cl. Ultimo acceso el 12 de Abril del 2011. ´[16] Junit. http://www.junit.org/. Ultimo acceso el 12 de Abril del 2011. ´[17] Movistar. http://www.movistar.cl. Ultimo acceso el 12 de Abril del 2011. ´[18] Nintendo ds. http://www.nintendo.com/ds. Ultimo acceso el 12 de Abril del 2011. ´[19] Open handset alliance. http://www.openhandsetalliance.com. Ultimo acceso el 12 de Abril del 2011. ´[20] Openlayers. http://openlayers.org/. Ultimo acceso el 12 de Abril del 2011. ´[21] Openstreetmap. http://www.openstreetmap.org. Ultimo acceso el 12 de Abril del 2011. ´[22] osmdroid. http://code.google.com/p/osmdroid/. Ultimo acceso el 12 de Abril del 2011. ´[23] Playstation portable. http://www.playstationportable.com/. Ultimo acceso el 12 de Abril del 2011. ´[24] Redmine. http://www.redmine.org/. Ultimo acceso el 12 de Abril del 2011. ´[25] Soap. http://www.w3.org/TR/soap/. Ultimo acceso el 12 de Abril del 2011. ´[26] Spring. http://www.springsource.org/. Ultimo acceso el 12 de Abril del 2011. ´[27] twitter. http://twitter.com/. Ultimo acceso el 12 de Abril del 2011. ´[28] W3c. http://www.w3.org/. Ultimo acceso el 12 de Abril del 2011. ´[29] Wicket. http://wicket.apache.org/. Ultimo acceso el 12 de Abril del 2011.[30] R. T. Azuma et al. A survey of augmented reality. Presence-Teleoperators and Virtual Environments, 6(4):355–385, 1997.[31] G. Bell and P. Dourish. Yesterday’s tomorrows: notes on ubiquitous computing’s dominant vision. Personal and Ubiquitous Computing, 11(2):133–143, 2007.
  • 135. BIBLIOGRAF´ IA 133[32] Felipe Besoa´ Aplicaci´n para monitorizaci´n de caidas no intencionales en per- ın. o o sonas que sufren de s´ ındrome vertiginoso: Implementaci´n en la plataforma android. o 2010.[33] Ed Burnette. Hello, Android: Introducing Google’s Mobile Development Platform. Pragmatic Bookshelf, 2008.[34] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-oriented software architecture: a system of patterns. John Wiley & Sons, Inc. New York, NY, USA, 1996.[35] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design patterns: elements of reusable object-oriented software. Addison-Wesley Professional, 1995.[36] R. Garrido and A. Garc´ ıa-Alonso. T´cnicas de interacci´n para sistemas de realidad e o aumentada.[37] Diego Chaparro Gonz´lez. Computaci´n ubicua. Master’s thesis, 2003. a o[38] A. H¨hfeld. In and out of reality: Janus-faced location awareness in ubiquitous o games. JOURNAL OF SOFTWARE, 2(6), 2007.[39] Juan Jos´ Moreno Navarro (coordinador) Con la colaboraci´n de: Iv´n e o a Mart´ ınez Salles Juan Garbajosa Sope˜ a, Francisco Javier Soriano Camino. Informe n de Vigilancia Tecnol´gica madri+d. o[40] T. Kindberg and A. Fox. System software for ubiquitous computing. IEEE pervasive computing, 1(1):70–81, 2002.[41] C. Larman. Applying UML and patterns: an introduction to object-oriented analysis and design and iterative development. Prentice Hall PTR Upper Saddle River, NJ, USA, 2004.[42] C. Larman. UML y Patrones. 2004.[43] L. Montes and F. Manuel. Muusic: mashup de servicios web musicales. 2009.[44] Judit Balaguero Pe˜ a. Estudio de la plataforma android. Master’s thesis, 2008. n
  • 136. BIBLIOGRAF´ IA 134[45] Fernando Bellas Permuy. Integraci´n de sistemas. o http://www.tic.udc.es/is- ´ java/index.html. Ultimo acceso el 12 de Abril del 2011.[46] A. C. Spain. Accediendo a base de datos desde aplicaciones web desarrolladas con j2ee: patrones de dise˜ o. n[47] N. Streitz and P. Nixon. The disappearing computer. Communications of the ACM, 48(3), 2005.[48] Mauro Carabotti Thomas Hofstetter and Tobias Soder. Diploma thesis 2008 tomato - android city shopping guide. Master’s thesis, 2008.[49] M. Weiser. The computer for the 21 st century. ACM SIGMOBILE Mobile Com- puting and Communications Review, 3(3):3–11, 1999.
  • 137. GlossaryAndroidSDK es un kit de desarrollo de software que permite a los desarrolladores crear aplicaciones para Android [3].Apache Axis2 [5] es un framework de c´digo abierto para servicios Web basados o en XML/SOAP/WSDL, desarrollado bajo el auspicio de la Fundaci´n de Soft- o ware Apache. Esta compuesto por dos implementaciones, Apache Axis2/Java y Apache Ax- is2/C y varias herramientas que hacen posible, por ejemplo, generar autom´tica- a mente el archivo WSDL (Web Service Description Language) el cual contiene la definici´n de la interfaz de los servicios Web. o Utilizando Apache Axis2, los desarrolladores pueden crear aplicaciones inter- operables y distribuidas.Git [12] es un software de control de versiones dise˜ ado por Linus Torvalds, pen- n sando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando estas tienen un gran n´ mero archivos de c´digo fuente. Al u o principio, Git se pens´ como un motor de bajo nivel sobre el que otros pudier- o an escribir el interfaz de usuario o front end como Cogito (software) o StGIT. Sin embargo, Git se ha convertido desde entonces en un sistema de control de versiones con funcionalidad plena. Hay algunos proyectos de mucha relevancia que ya usan Git, en particular, el grupo de programaci´n del n´ cleo Linux. o uGitorious [13] proporciona una infraestructura de c´digo abierto para acoger proyec- o tos de fuente abierta que usan Git. La entidad central en Gitorious es el proyec- to, que contiene uno o m´s repositorios, estos repositorios son gestionados por a los colaboradores del proyecto. 135
  • 138. Glossary 136GPS , Sistema de Posicionamiento Global, es un sistema de navegaci´n por sat´lite o e formado por una red de 24 sat´lites colocados en ´rbita por el Departamento e o de Defensa de E.E.U.U.. El GPS fue pensado originalmente para aplicaciones militares, pero en la d´cada de 1980, el gobierno puso el sistema disponible para e uso civil. GPS funciona en cualquier condici´n clim´tica, en cualquier parte del o a mundo, las 24 horas del d´ No hay cuotas de suscripci´n ni de configuraci´n ıa. o o para utilizar el GPS.GRASP son patrones generales de software para asignar responsabilidades, es el acr´nimo de General Responsibility-Assigment Software Patterns. oHibernate [14] es una herramienta de Mapeo objeto-relacional para la plataforma Java (y disponible tambi´n para .Net con el nombre de NHibernate) que fa- e cilita el mapeo de atributos entre una base de datos relacional tradicional y el modelo de objetos de una aplicaci´n, mediante archivos declarativos (XML) o o anotaciones en los beans de las entidades que permiten establecer estas rela- ciones. Mapeador objeto/relacional Open Source Permite mapear objetos JavaBean a una BD relacional (internamente utilizael API de JDBC) Soporta relaciones entre objetos y herencia No oculta el tipo de BD (relacional), pero s´ la BD concreta (Oracle, ı MySQL, PostgreSQL, etc.) Proporciona API + lenguaje de consultas de b´ squeda y borrados/actu- u alizaciones en masa .INE Instituto Nacional de Estad´ ısticas de Chile.IR Infrarrojo.JSON acr´nimo de JavaScript Object Notation, es un formato ligero para el inter- o cambio de datos. JSON es un subconjunto de la notaci´n literal de objetos de o JavaScript que no requiere el uso de XML.
  • 139. Glossary 137 La simplicidad de JSON ha dado lugar a la generalizaci´n de su uso, espe- o cialmente como alternativa a XML en AJAX. Una de las supuestas ventajas de JSON sobre XML como formato de intercambio de datos en este contex- to es que es mucho m´s sencillo escribir un analizador sem´ntico de JSON. a a En JavaScript, un texto JSON se puede analizar f´cilmente usando el proced- a imiento eval(), lo cual ha sido fundamental para que JSON haya sido aceptado por parte de la comunidad de desarrolladores AJAX, debido a la ubicuidad de JavaScript en casi cualquier navegador Web.Mapnik es una librer´ que permite generar y manipular mapas obteniendo los ıa datos de diferentes fuentes (archivos .shp, PostGIS, .tif).MapService provee acceso a mapas cartogr´ficos georeferenciados, en particular, a a tiles renderizados a distintas escalas.OpenLayers [20] es una librer´ de JavaScript de c´digo abierto bajo una derivaci´n ıa o o de la licencia BSD para mostrar mapas interactivos en los navegadores Web. OpenLayers ofrece un API para acceder a diferentes fuentes de informaci´n o cartogr´fica en la red: Web Map Services, Mapas comerciales (tipo Google a Maps, Bing, Yahoo), Web Features Services, distintos formatos vectoriales, mapas de OpenStreetMap.OpenStreetMap [21] (tambi´n conocido como OSM) es un proyecto colaborativo e para crear mapas libres y editables. Los mapas se crean utilizando informaci´n geogr´fica capturada con disposi- o a tivos GPS m´viles, ortofotograf´ y otras fuentes libres. Esta cartograf´ tan- o ıas ıa, to las im´genes creadas como los datos vectoriales almacenados en su base de a datos, se distribuye bajo licencia Creative Commons Attribution-ShareAlike.osmdroid provee herramientas y vistas para interactuar con los datos entregados por OpenStreetMap en Android.PostgreSQL es un sistema de gesti´n de base de datos relacional orientada a ob- o jetos y libre, publicado bajo la licencia BSD. Como muchos otros proyectos de c´digo abierto, el desarrollo de PostgreSQL no o
  • 140. Glossary 138 es manejado por una empresa y/o persona, sino que es dirigido por una comu- nidad de desarrolladores que trabajan de forma desinteresada, altruista, libre y/o apoyados por organizaciones comerciales. Dicha comunidad es denominada el PGDG (PostgreSQL Global Development Group).Redmine [24] es una herramienta para la gesti´n de proyectos y el seguimiento de o errores escrita usando el framework Ruby on Rails. Incluye un calendario y diagramas de Gantt para la representaci´n visual de la l´ o ınea del tiempo de los proyectos. Es software libre y de c´digo abierto, disponible bajo la Licencia o P´ blica General de GNU v2. u El dise˜ o de Redmine est´ significativamente influenciado por Trac, otra her- n a ramienta con caracter´ ısticas similares.Smartphone es un t´rmino comercial para denominar a un tel´fono m´vil que e e o ofrece m´s funciones que un tel´fono celular com´ n. a e uSOA arquitectura orientada a servicios.Spring [26] es un framework de c´digo abierto de desarrollo de aplicaciones para la o plataforma Java.SVG , Gr´ficos Vectoriales Escalables (del ingl´s Scalable Vector Graphics), es una a e especificaci´n para describir gr´ficos vectoriales bidimensionales. o aTile es una imagen georeferenciada con informaci´n cartogr´fica, que representa un o a sector de un mapa a una escala dada.URI Universal Resource Identifier.Wicket [29] es framework que facilita la creaci´n de complicados IU (interfaces de o usuario) sobre XHTML facilitando su edici´n con herramientas como DreamWeaver o o Go Live en p´ginas din´micas asociadas a componentes Java. a a Los componentes Wicket son extensibles a componentes Java, como Swing y pueden ser devueltos POJO (Plain Old Java Object) usando una herramienta ORM, como Hibernate o JDO. Wicket, un recurso de desarrollo eficaz para la creaci´n y usabilidad de paquetes de componentes Web. o
  • 141. Glossary 139WIFI es una marca de certificaci´n desarrollada por la Alianza Wi-Fi para indicar o que la red de ´rea local inal´mbrica (WLAN) los productos se basan en el a a Instituto de Ingenieros El´ctricos y Electr´nicos (IEEE) 802.11. e oXML [20], siglas en ingl´s de eXtensible Markup Language (lenguaje de marcas am- e pliable), es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). Es una simplificaci´n y adaptaci´n del SGML o o y permite definir la gram´tica de lenguajes espec´ a ıficos (de la misma manera que HTML es a su vez un lenguaje defi nido por SGML). Por lo tanto, XML no es realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades. Algunos de estos lenguajes que usan XML para su definici´n son XHTML, SVG, MathML. XML 1.0 se convirti´ en una recomen- o o daci´n del W3C el 10 de febrero de 1998. oZigbee es un conjunto de especificaciones t´cnicas en torno a la norma IEEE 802.15.4 e protocolo inal´mbrico. a
  • 142. ANEXOS
  • 143. A. Especificaci´n complementaria oAtributos generales Este documento es el repositorio de todos los requisitos que no se capturan enlos casos de uso.Funcionalidad Esta secci´n describe funcionalidades comunes a muchos casos de uso. oRegistro y gesti´n de errores o Los errores se mostrar´n de forma amigable e informativa. aSeguridad El software debe restringir el ingreso al sistema a personas que no est´n registra- ados en ´l o tienen privilegios para algunas funcionalidades. eFacilidad de usoUsabilidad El sistema debe presentar un lenguaje tal que el usuario no tenga problema deentendimiento, la comunicaci´n entre sistema y usuario debe ser tan simple como osea posible. 141
  • 144. CAP´ ´ ITULO A. ESPECIFICACION COMPLEMENTARIA 142Documentaci´n o Se crear´ una gu´ de ayuda que orientar´ al usuario al momento de tener conflic- a ıa atos con el sistema, la que consistir´ en un manual de usuario en donde se mostrar´n a aejemplos claros de c´mo utilizar el juego. oNavegaci´n o Las interfaces de usuario del servidor Web y el cliente m´vil debe ser de f´cil uso o ay simples, as´ como tambi´n la transacci´n entre las distintas pantallas deben ser lo ı e om´s intuitivo posible. aFactores humanos La aplicaci´n cliente es implementada para terminales m´viles, las que tienen un o otama˜ o de pantalla limitada, por ello la interfaz debe ser f´cilmente legible. n a Adem´s, debe ser f´cil la interacci´n mediante teclas de tel´fono, touchpad, o a a o etouchscreens. La velocidad, comodidad y el procesamiento libre de errores es muy importantepara el correcto proceso de jugar, mejorando la experiencia sin complicar a los usuar-ios.FiabilidadNetworking La aplicaci´n, al ser utilizada en distintos lugares y ambientes, la tolerancia a ofallos de conexi´n a las distintas redes, es un punto importante para segurar un ocorrecto funcionamiento y consistencia de la informaci´n. oCapacidad de recuperaci´n o Es posible que la terminal falle o se quede sin bater´ lo cual no debe afectar la ıa,consistencia de los datos en tales casos.
  • 145. CAP´ ´ ITULO A. ESPECIFICACION COMPLEMENTARIA 143RendimientoTiempo de respuesta La informaci´n de los objetos y las ubicaciones de estos ser´n entregados tan o apronto como sea posible. Como la informaci´n es obtenida desde un servidor, la red es un cuello de botella, oes por ello que esta ser´ optimizada a nivel de API. aConsumo de recursos El consumo de bater´ es muy importante en los dispositivos m´viles, es por ello ıa oque se optimizar´ el uso de la misma. aSoportePortabilidad Como el n´ mero y caracter´ u ısticas es diferentes en los terminales con Android, elcliente m´vil debe ser f´cilmente portable en cualquier tel´fono corriendo Android o a econ un m´ınimo de esfuerzo. Al utilizar Web Service, y java como lenguaje de programaci´n del cliente es oposible implementar clientes basados el distintos dispositivos, por ejemplo iPhone,j2me, Desktop, etc.Adaptabilidad El proceso de cambiar la apariencia de la aplicaci´n Web o cliente Android, o oagregar funcionalidades debe ser f´cil y r´pido. a a
  • 146. B. Casos de Uso Gesti´n de Equipos oCaso de Uso 2.1 Crear EquipoActor: Usuario autenticadoProp´sito: Crear y almacenar la informaci´n de un Equipo o oTipo: Secundario, EsencialReferencias: RF 2.9 , RF 2.10 , RF 5.5Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea Crear un nuevo Equipo. Para esto selecciona Crear Equipo 2.- Proporciona un formulario para in- gresar la informaci´n del nuevo Equipo o 3.- Ingresa y env´ los datos al sistema ıa 4.- Verifica si el Equipo existe 5.- Env´ confirmaci´n de la operaci´n ıa o o al actorFlujo alternativo: 4a.- Verifica que el Equipo existe 5.- Pregunta al actor si desea ingresar otro Equipo 144
  • 147. CAP´ ITULO B. CASOS DE USO 145Caso de Uso 2.2 Vincular Competidor a EquipoActor: Usuario autenticadoProp´sito: oTipo: Secundario, EsencialReferencias: RF 2.13Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea Vincularse a un equipo en un Juego 2.- Solicita una lista de los juegos activos 3.- Proporciona la lista de los juegos 4.- Selecciona juego y solicita una lista de los equipos 5.- Proporciona la lista de los equipos en el juego 6.- Selecciona equipo a vincular 7.- Verifica 8.- Almacena la vinculaci´n o 9.- Env´ confirmaci´n de la operaci´n ıa o o al actorCaso de Uso 2.3 Listar Compa˜ eros de Equipo nActor: CompetidorProp´sito: oTipo: Primario, EsencialReferencias: RF 4.2Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea listar sus compa˜ eros de n equipo 2.- Muestra los compa˜ eros de equipo n del Actor
  • 148. CAP´ ITULO B. CASOS DE USO 146 Crear equipo Usuario autenticado Vincular competidor Listar compañeros Competidor Figura B.1: Diagrama de casos de uso: Equipos
  • 149. CAP´ ITULO B. CASOS DE USO 147 Gesti´n de lugares oCaso de Uso 3.1 Crear PistaActor: Usuario autenticadoProp´sito: Crear y almacenar la informaci´n de una Pista o oTipo: Secundario, EsencialReferencias: RF 2.1 , RF 2.2 , RF 5.3Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el Actor desea Crear una nueva Pista 2.- El Actor Solicita la ubicaci´n al GPS o 3.- El GPS Retorna la ubicaci´n o 4.- El Administrador solicita crear una nueva Pista al sistema 5.- Proporciona un formulario para in- gresar la informaci´n de la nueva Pista o 6.- Ingresa y env´ los datos al sistema ıa 7.- Verifica si la Pista no existe 8.- Almacena la informaci´n o 9.- Env´ confirmaci´n de la operaci´n ıa o o al ActorFlujo alternativo: 4a.- Verifica que la Pista existe 5.- Pregunta al actor si desea ingresar otra Pista
  • 150. CAP´ ITULO B. CASOS DE USO 148Caso de Uso 3.2 Buscar PistaActor: Usuario autenticadoProp´sito: Buscar Pista oTipo: Secundario, EsencialFlujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea buscar a una Pista en el sistema 2.- Proporciona un formulario 3.- Ingresa la informaci´n de la Pista a o buscar 4.- Muestra la informaci´n de Pista oCaso de Uso 3.3 Alertar Cercan´ıaActor: CompetidorProp´sito: Alertar cuando un competidor se encuentra cerca de alg´ n objeto de o u inter´s, pista o meta. eTipo: PrimarioReferencias:Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Cuando detecta que el Actor se en- cuentra carca de alg´ n objeto de in- u ter´s(pista o meta), el sistema env´ una e ıa notificaci´n al Actor en cuesti´n o o 2.- Observa la notificaci´n de cercan´ o ıa
  • 151. CAP´ ITULO B. CASOS DE USO 149 Usuario autenticado Crear pista Alertar cercanía Competidor Figura B.2: Diagrama de casos de uso: Lugares y pistas
  • 152. CAP´ ITULO B. CASOS DE USO 150 Gesti´n del juego oCaso de Uso 4.1 Comenzar JuegoActor: Usuario autenticadoProp´sito: Dar inicio a un juego, se env´ la pista inicial a todos los competidores o ıaTipo: Primario, EsencialReferencias:Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea dar comienzo a un Juego 2.- Solicita una lista con los juegos 2.- Proporciona una lista para selec- cionar el Juego a comenzar 3.- Selecciona el Juego 4.- Solicita confirmar el comienzo del Juego 5.- Confirma el comienzo 6.- Verifica 7.- Muestra confirmaci´n de la op- o eraci´n al actor o 8.- Muestra la pista inicial a todos los competidores del JuegoCaso de Uso 4.2 Crear JuegoActor: Usuario autenticadoProp´sito: Crear un nuevo juego, agregando las pistas y meta oTipo: SecundarioReferencias:Flujo normal: Acci´n del Actor o Respuesta del sistema
  • 153. CAP´ ITULO B. CASOS DE USO 151Caso de Uso 4.3 Buscar JuegoActor: Usuario autenticadoProp´sito: Buscar Juego oTipo: Secundario, EsencialFlujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea buscar a un Juego en el sistema 2.- Proporciona un formulario 3.- Ingresa la informaci´n del Juego a o buscar 4.- Muestra la informaci´n del Juego oCaso de Uso 4.4 Alertar posibilidad de recogerActor: CompetidorProp´sito: Alertar que puede recoger un objeto cuando un competidor se encuentra o lo suficientemente cerca cerca de alg´ n objeto de inter´s, pista o meta. u eTipo: PrimarioReferencias:Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Cuando detecta que el Actor se en- cuentra muy cerca de alg´ n objeto de u inter´s(pista o meta), el sistema env´ e ıa una notificaci´n al Actor en cuesti´n de o o que puede recoger este 2.- Observa la notificaci´n de cercan´ o ıa 3.- CU 4.5 o CU 4.6 si es Pista o Meta respectivamente
  • 154. CAP´ ITULO B. CASOS DE USO 152Caso de Uso 4.5 Recoger PistaActor: CompetidorProp´sito: oTipo: Primario, EsencialReferencias: RF 2.15Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el Actor esta cerca de alguna pista 2.- Proporciona una alerta de que puede recoger una pista 3.- Recoge la Pista 4.- Verifica 5.- Almacena el recoger 6.- Proporciona un formulario con la in- formaci´n de la pista seleccionada o 7.- Alerta del encuentro de una Pista a los compa˜ eros del Actor n
  • 155. CAP´ ITULO B. CASOS DE USO 153Caso de Uso 4.6 Recoger MetaActor: CompetidorProp´sito: oTipo: Primario, EsencialReferencias: RF 2.16Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea Recoger una Meta. Para esto el Actor debe estar lo suficiente- mente cerca para poder ver y recoger dicha Meta 2.- Proporciona un formulario para se- leccionar la Meta a recoger 3.- Selecciona y env´ los datos al sis- ıa tema 5.- Env´ confirmaci´n de la operaci´n ıa o o al actor 6.- Proporciona un formulario con la in- formaci´n de la Meta recogida o 7.- Env´ confirmaci´n del encuentro de ıa o la Meta a todos los participantesCaso de Uso 4.7 Listar Equipos de JuegoActor: CompetidorProp´sito: oTipo: Primario, EsencialReferencias:Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea listar los equipos de un Juego 2.- Muestra los equipos de un Juego
  • 156. CAP´ ITULO B. CASOS DE USO 154Caso de Uso 4.8 Ver JuegoActor: CompetidorProp´sito: oTipo: Primario, EsencialReferencias:Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea ver un Juego 2.- Muestra la informaci´n del Juego oCaso de Uso 4.9 Agregar Pista a JuegoActor: Usuario autenticadoProp´sito: Agregar una pista a un juego oTipo: SecundarioReferencias:Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- El actor selecciona el juego al que desea agregar una pista 2.- Muestra la notificaci´n que la pista o ha sigo agregada del Juego
  • 157. CAP´ ITULO B. CASOS DE USO 155 Comenzar Juego Usuario autenticado Crear Juego Alertar Posibilidad de Recoger Competidor Recoger Pista Recoger Meta Figura B.3: Diagrama de casos de uso: Juego
  • 158. CAP´ ITULO B. CASOS DE USO 156 Comunicaci´n oCaso de Uso 5.1 Enviar Mensaje a Compa˜ eros nActor: CompetidorProp´sito: oTipo: Primario, EsencialReferencias: RF 3.1Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea Enviar mensajes a sus com- pa˜ eros n 2.- Proporciona un formulario para in- gresar el mensaje a enviar 3.- Ingresa mensaje, y env´ los datos al ıa sistema 5.- Env´ confirmaci´n de la operaci´n ıa o o al actor 6.- Proporciona un formulario con la in- formaci´n del mensaje a los compa˜ eros o n seleccionados por el Actor Enviar Mensaje a Compañeros Competidor Figura B.4: Diagrama de casos de uso: Comunicaci´n o
  • 159. CAP´ ITULO B. CASOS DE USO 157 Localizaci´n y mapas oCaso de Uso 6.1 Ver MapaActor: Usuario autenticadoProp´sito: oTipo: Primario, EsencialReferencias: RF 4.2Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el Competidor desea ver el mapa 2.- El competidor solicita ver el mapa al sistema 3.- El sistema solicita los Tile al MapService 4.- El MapService retorna los tiles 5.- El sistema muestra el mapa al Com- petidorCaso de Uso 6.2 Ver Ubicaci´n de Compa˜ eros de Equipo o nActor: CompetidorProp´sito: oTipo: Primario, EsencialReferencias: RF 4.2Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea Ver la ubicaci´n de sus o compa˜ eros de equipo n 2.- Muestra en el Mapa la ubicaci´n de o los compa˜ eros del Actor n
  • 160. CAP´ ITULO B. CASOS DE USO 158Caso de Uso 6.3 Ver Ubicaci´n de Pistas del Equipo oActor: CompetidorProp´sito: oTipo: Primario, EsencialReferencias: RF 4.3Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- Este Caso de Uso comienza cuando el actor desea ver la ubicaci´n de las pis- o tas recogidas por su equipo. Para esto selecciona Ver Ubicaci´n de Pistas del o Equipo 2.- Muestra en el Mapa la ubicaci´n de o las pistas recogidas por el equipo del Ac- torCaso de Uso 6.4 Obtener Ubicaci´n oActor: CompetidorProp´sito: Obtener la ubicaci´n desde el GPS o oTipo: PrimarioReferencias:Flujo normal: Acci´n del Actor o Respuesta del sistema 1.- El Actor solicita su ubicaci´n o 2.- entrega la latitud y la longitud donde se encuentra el Actor
  • 161. CAP´ ITULO B. CASOS DE USO 159 Ver Mapa Usuario autenticado Ver Ubicación de Compañeros de Equipo Ver Ubicación de Pistas de Equipo Competidor Figura B.5: Diagrama de casos de uso: Localizaci´n y mapas o
  • 162. C. Matriz de caracter´ ısticas de Casos de UsoPriorizaci´n de Casos de Uso oCaso de uso a b c d e f SumaCU 1.4 2 1 2 1 1 1 8CU 1.7 1 1 1 1 1 1 6CU 1.1 3 1 3 1 2 2 12CU 1.2 1 1 1 1 1 1 6CU 1.3 1 1 1 1 2 1 7CU 1.6 1 2 1 1 2 1 8CU 1.8 2 2 4 3 3 1 15CU 3.1 2 3 2 2 3 2 14CU 2.1 2 3 3 2 2 2 14CU 2.3 1 1 1 1 2 1 7CU 2.2 2 2 3 1 3 3 14CU 5.1 2 2 2 3 4 3 16CU 4.1 5 5 5 5 5 5 30CU 3.3 3 3 3 4 4 3 20CU 4.4 3 3 3 4 4 3 20CU 4.5 3 4 2 2 3 3 17CU 6.2 3 2 3 4 5 2 19CU 6.3 3 2 3 4 5 2 19CU 6.1 1 3 3 3 3 2 15 Cuadro C.1: Tabla de caracter´sticas de priorizaci´n de casos de uso ı o 160
  • 163. D. Diagrama de Secuencia del sis- temaEquipos En esta secci´n se muestran algunos de los diagramas relacionados con equipos. o La Figura D.1 muestra la interacci´n del caso de uso CU 2.2 en el cual, un ojugador desea vincularse a un equipo dentro de un juego, para as´ poder competir ıposteriormente en el juego en cuesti´n. o :Client :Actor :System joinGame(game, team) joinGame(game, team) notification notification Figura D.1: Diagrama de secuencias: Vincular Competidor a Equipo CU 2.2Lugares En esta secci´n se muestran los diagramas relacionados con lugares. o 161
  • 164. CAP´ ITULO D. DIAGRAMA DE SECUENCIA DEL SISTEMA 162 La Figura D.2 muestra la interacci´n del caso de uso CU 3.1 en el cual, el oactor desea crear una pista, para ello debe tener las coordenadas geogr´ficas donde aestar´ ubicada la pista en cuesti´n, las que fueron obtenidas desde un GPS, posi- a ocionando un punto en un mapa, o de forma manual, es decir, ingresando el parlatitud,longitud de donde se encuentra ubicada la pista. :Client :Actor :System createPlace() form_data createPlace(hint) createPlace(hint) notification notification Figura D.2: Diagrama de secuencias: Crear Lugar(Pista) CU 3.1 La Figura D.3 muestra la interacci´n del caso de uso CU 3.3 , en el cual el osistema avisa al usuario que esta cerca de alg´ n lugar o pista. u :Client :Actor alert(Object) Figura D.3: Diagrama de secuencias: Alertar Cercan´a CU 3.3 ıJuegos En esta secci´n se muestran algunos de los diagramas relacionados con juegos. o
  • 165. CAP´ ITULO D. DIAGRAMA DE SECUENCIA DEL SISTEMA 163 La Figura D.4 muestra la interacci´n del caso de uso CU 4.1 en el cual, un ousuario da comienzo al juego, con lo cual se env´ la primera pista a los competi- ıadores de este. :Client :System :Actor :Competitors startGame(game) confirmation_request() confirmation_request() startGame(game) notification notification alert(initialHint) Figura D.4: Diagrama de secuencias: Comenzar Juego CU 4.1 La Figura D.6 muestra la interacci´n del caso de uso CU 4.3 en el cual, el actor odesea saber cuales son los juegos que existen en una ciudad o lugar en particular. :Actor :Client :System findGamesByCity(city) findGamesByCity(city) games:list games:list Figura D.5: Diagrama de secuencias: Buscar juegos por Ciudad CU 4.3
  • 166. CAP´ ITULO D. DIAGRAMA DE SECUENCIA DEL SISTEMA 164 :Actor :Client :System findGame(filter) findGame(filter) games:list games:list Figura D.6: Diagrama de secuencias: Buscar Juego CU 4.3 La Figura D.7 muestra la interacci´n del caso de uso CU 4.7 en el cual, el actor odesea ver los equipos en un juego, para por ejemplo decidir a cual de ellos deseaunirse. :Actor :Client :System findTeamsByGame(game) findTeamsByGame(game) teams:list teams:list Figura D.7: Diagrama de secuencias: Buscar equipos por juego CU 4.7 La Figura D.8 muestra la interacci´n del caso de uso CU 4.8 en el cual, el usuario odesea ver la informaci´n de un juego, como por ejemplo la cantidad de equipos que oparticipan, la ciudad donde es realizado el juego, la cantidad de pistas, fecha decreaci´n y fecha de inicio de juego. o
  • 167. CAP´ ITULO D. DIAGRAMA DE SECUENCIA DEL SISTEMA 165 :Client :System :Actor showGame(gameId) showGame(gameId) GameInfo formViewGameInfo Figura D.8: Diagrama de secuencias: Ver Juego CU 4.8 La Figura D.9 muestra la interacci´n del caso de uso CU 4.5 en el cual, el actor odesea recoger una pista o meta. En caso de que lo recogido sea una meta, el juegose da por terminado, teniendo el equipo del actor que la recogi´ como ganador del ojuego. :Client :Actor :System takeHint(hint, lat, lon) :team takeHint(hint, lat, lon) alert(hint) form_show(hint) form_show(hint) Figura D.9: Diagrama de secuencias: Recoger Pista CU 4.5
  • 168. CAP´ ITULO D. DIAGRAMA DE SECUENCIA DEL SISTEMA 166Comunicaci´n o En esta secci´n se muestran algunos de los diagramas relacionados con comuni- ocaci´n. o La Figura D.10 muestra la interacci´n del caso de uso CU 5.1 en el cual, el oactor desea enviar un mensaje a sus compa˜ eros de equipo, para ello debe haber nseleccionado con anterioridad a cuales compa˜ eros desea enviar el mensaje. n :Client :Actor sendMessage() :System form_data sendMessage(msg, sender, receiver) :team sendMessage(msg, sender, receiver) alert(msg) notification notification Figura D.10: Diagrama de secuencias: Enviar Mensaje a Compa˜eros CU 5.1 nLocalizaci´n y mapas o En esta secci´n se muestran algunos de los diagramas relacionados con local- oizaci´n geogr´fica y mapas. o a La Figura D.11 muestra la interacci´n del caso de uso CU 6.4 en el cual, el actor odesea obtener su ubicaci´n, para ello solicita dicha informaci´n al GPS. o o
  • 169. CAP´ ITULO D. DIAGRAMA DE SECUENCIA DEL SISTEMA 167 :Client :Actor :GPS Service getlocation() getlocation() location Figura D.11: Diagrama de secuencias: Solicitar Ubicaci´n CU 6.4 oLa Figura D.12 muestra la interacci´n del caso de uso CU 6.1 en el cual, el actor odesea ver el mapa. :Actor :Client :TilesService getMap(area) getTiles(area) tiles:list showMap Figura D.12: Diagrama de secuencias: Mostrar mapa CU 6.1 La Figura D.13 muestra la interacci´n del caso de uso CU 5.1 en el cual, el actor odesea ver la ubicaci´n de sus compa˜ eros de equipo sobre un mapa. o n
  • 170. CAP´ ITULO D. DIAGRAMA DE SECUENCIA DEL SISTEMA 168 :Client :Actor :System getUsers(team) getUsers(team) users:list Show(users:list) Figura D.13: Diagrama de secuencias: Ver ubicaci´n de compa˜eros CU 6.2 o n
  • 171. E. ContratosUsuarios En esta secci´n se muestran algunos de los contratos relacionados con usuarios. oCrear competidorContrato CO5Operaci´n o registerReferencias Cruzadas RF 1.1 , RF 1.2 , RF 5.1Caso de Uso CU 1.4NotasSalidaPrecondiciones El nombre de usuario del competidor no debe existirPoscondiciones El competidor es creado Se ha almacenado la informaci´n del competidor o 169
  • 172. CAP´ ITULO E. CONTRATOS 170Crear AdministradorContrato CO6Operaci´n o create adminReferencias Cruzadas RF 1.5 , RF 1.6 , RF 5.2Caso de Uso CU 1.5NotasSalidaPrecondiciones El actor debe estar autentificado con rol de admin- istrador El nombre de usuario del administrador no debe exi- stirPoscondiciones El Administrador es creado Se ha almacenado la informaci´n del Administrador oAutenticarseContrato CO7Operaci´n o loginReferencias Cruzadas RF 1.9Caso de Uso CU 1.1NotasSalidaPrecondiciones El actor debe existir El actor no debe estar autentificadoPoscondiciones El actor est´ Autentificado aGesti´n de Equipos o En esta secci´n se muestran algunos de los contratos relacionados con equipos. o
  • 173. CAP´ ITULO E. CONTRATOS 171Unirse a un EquipoContrato CO8Operaci´n o joinTeamReferencias Cruzadas RF 2.13Caso de Uso CU 2.2NotasSalidaPrecondiciones El actor debe estar autentificadoPoscondiciones El actor es miembro de un equipoGesti´n de lugares o En esta secci´n se muestran algunos de los contratos relacionados con lugares. oCrear PistaContrato CO9Operaci´n o createHintReferencias Cruzadas RF 2.1 , RF 2.2 , RF 5.3Caso de Uso CU 3.1NotasSalidaPrecondiciones El actor debe estar autentificadoPoscondiciones La Pista es creada Se ha almacenado la informaci´n de la Pista o
  • 174. CAP´ ITULO E. CONTRATOS 172Crear MetaContrato CO10Operaci´n o createGoalReferencias Cruzadas RF 2.5 , RF 2.6 , RF 5.4Caso de Uso CU 3.1NotasSalidaPrecondiciones El actor debe estar autentificadoPoscondiciones La Meta es creada Se ha almacenado la informaci´n de la Meta oGesti´n del juego o En esta secci´n se muestran algunos de los contratos relacionados con juegos. oUnirse a un JuegoContrato CO11Operaci´n o joinGameReferencias Cruzadas RF 2.13Caso de Uso CU 2.2NotasSalidaPrecondiciones El actor debe estar autentificadoPoscondiciones El actor es miembro de un equipo en un juego y puede comenzar a jugar
  • 175. CAP´ ITULO E. CONTRATOS 173Recoger Contrato CO12 Operaci´n o takeHint Referencias Cruzadas RF 2.15 , RF 2.16 Caso de Uso CU 4.5 Notas Salida Precondiciones El actor debe estar autentificado El actor debe pertenecer a un equipo, y debe estar jugando actualmente El actor debe estar lo suficientemente cerca del objeto como para recogerlo Poscondiciones Se asigna la pertenencia del objeto al equipo al que pertenece el actor Se notifica a los compa˜ eros del actor que una pista n sido recogida En caso de que el objeto es la meta el juego termina, teniendo como ganador el equipo al que pertenece el actorComunicaci´n o En esta secci´n se muestran algunos de los contratos relacionados con comuni- ocaci´n. o
  • 176. CAP´ ITULO E. CONTRATOS 174Enviar Mensaje Contrato CO13 Operaci´n o userSendsMessage Referencias Cruzadas RF 3.1 Caso de Uso CU 5.1 Notas Salida Precondiciones El actor debe estar autentificado Poscondiciones El actor envi´ un mensaje a un usuario o Se ha almacenado la informaci´n del Mensaje oLocalizaci´n y mapas o En esta secci´n se muestran algunos de los contratos relacionados con localizaci´n o ogeogr´fica y mapas. aActualizar Ubicaci´n o Contrato CO14 Operaci´n o updateLocation Referencias Cruzadas RF 4.1 Caso de Uso CU 1.8 Notas Salida Precondiciones El actor debe estar autentificado Poscondiciones El actor actualizo el lugar donde se encuentra Se ha almacenado la nueva posici´n del competidor o
  • 177. F. Diagrama de Interacci´n oEquipo En esta secci´n se muestran algunos de los diagramas de interacci´n relacionados o ocon equipos. En la Figura F.1 se aprecia la interacci´n del usuario con el sistema al momento ode unirse a un equipo. Client Server :View :TeamService :TeamManager team:Team Actor usersInTeam:User joinTeam(userId, teamId) joinTeam(userId, teamId) find(teamId) team:Team join(user) add(user) notification notification show(notification) Figura F.1: Diagrama de interacci´n - Vincularse a un equipo CU 2.2 o En las figuras F.2 y F.3 se muestra la interacci´n al momento de ver la ubicaci´n o olos compa˜ eros de un equipo. n En la Figura F.2 se muestra la interacci´n al momento de obtener la lista de los ousuarios que forman parte de un equipo. 175
  • 178. CAP´ ´ ITULO F. DIAGRAMA DE INTERACCION 176 Server Client Expert :TeamManager :Team t:Team :View usersInTeam:UserId :TeamService Actor findUsersByTeam(teamId) findUsersByTeam(teamId) find(teamId) find(teamId) t:Team t:Team getUsers() findAll() users:list users:list users:list Figura F.2: Diagrama de interacci´n - Listar compa˜eros CU 2.3 o n En la Figura F.3 se muestra la interacci´n al momento de obtener la informaci´n o ode localizaci´n de un conjunto de usuarios. o Client :View users:list Actor * [i:=1..N] : partner := users[i] getLatitude() latitude:int longitude:=getLongitude() longitude:int show Figura F.3: Diagrama de interacci´n - Ubicaci´n de compa˜eros CU 6.2 o o n
  • 179. CAP´ ´ ITULO F. DIAGRAMA DE INTERACCION 177Lugares En esta secci´n se muestran algunos de los diagramas de interacci´n relacionados o ocon lugares. En las figuras F.4 y F.5 se muestra la interacci´n al momento de crear una nueva opista. En la Figura F.4 se muestra la interacci´n al momento de crear un lugar. o Client :view Server Expert Actor Creator createHint() :HintService :HintManager h:Hint show :Hint createHint(name, description, latitude, longitude) createHint(name, description, latitude, longitude) createHint(name, description, latitude, longitude) <<create>> setName(name) setDescription(description) setLatitude(latitude) setLongitude(longitude) add(h) notification notification notification Figura F.4: Diagrama de interacci´n - Crear un lugar(pista), CU 3.1 o En la Figura F.5 se muestra la interacci´n al momento de agregar un lugar a un ojuego, con lo cual se le atribuye la calidad de pista en un juego en particular. Client Server :View Actor :GameService gid:Game hintsInGame:Place pid:Hint addHint(gid, pid) Creator addHint(gid, pid) addHint(pid) <<create>> add(pid) notification notification show(notification) Figura F.5: Diagrama de interacci´n - Asociar pista a juego, CU 4.9 o
  • 180. CAP´ ´ ITULO F. DIAGRAMA DE INTERACCION 178 En la Figura F.6 se aprecia la interacci´n del usuario con el sistema al momento ode buscar una pista. Expert Client Server Creator :View :HintService :HintManager h:Hint :Hint Actor find(hintId) find(hintId) find(hintId) find(hintId) h:Hint h:Hint h:Hint Figura F.6: Diagrama de interacci´n - Buscar Pista CU 3.2 oJuego En esta secci´n se muestran algunos de los diagramas de interacci´n relacionados o ocon juegos. En la Figura F.7 se aprecia la interacci´n del usuario con el sistema al momento ode buscar juegos seg´ n alg´ n criterio, el que puede ser el id, juegos activos, juegos u uterminados, juegos en una ciudad o localizaci´n en particular y juegos por usuarios. o Control Client Expert Server Actor :View :GameService :GameManager :Game find(filter) find(filter) find(filter) findAll() games:list games:list games:list games:list Figura F.7: Diagrama de interacci´n - Buscar juegos CU 4.3 o
  • 181. CAP´ ´ ITULO F. DIAGRAMA DE INTERACCION 179 En la Figura F.8 se aprecia la interacci´n del usuario con el sistema al momento ode buscar los equipos en un juego. Control Client Server Expert Actor :View :GameService g:Game :GameManager :Game findTeamsByGame(gameId) findTeamsByGame(gameId) find(gameId) find(gameId) g:Game g:Game getTeams() teams:list teams:list show(teams:list) Figura F.8: Diagrama de interacci´n - Buscar equipos por juego CU 4.7 o En la Figura F.9 se aprecia la interacci´n del usuario con el sistema al momento ode recoger una pista o meta. Expert Server Creator Client :GameService h:Hint :HintManager :TeamManager t:Team hintsIHave:Hint Actor :Hint :Team :View takeHint(user, hintId) takeHint(user, hintId, mylatitude, mylongitude) find(hintId) find(hintId) h:Hint h:Hint setOwner(user) findTeamByUser(user) findTeamByUser(user) t:Team t:Team addHint(h) addHint(hintId) notification notification Figura F.9: Diagrama de interacci´n - Recoger Pista CU 4.5 o
  • 182. CAP´ ´ ITULO F. DIAGRAMA DE INTERACCION 180Mensajes En esta secci´n se muestran algunos de los diagramas de interacci´n relacionados o ocon comunicaci´n. o En las figuras F.10 y F.11 se aprecia la interacci´n del usuario con el sistema al omomento de enviar un mensaje. En la Figura F.10 se muestra la interacci´n al momento de enviar un mensaje, oalmacenando la informaci´n del mensaje en cuesti´n y el estado de est´. o o e Client Server Creator :SendMessageView :MessageService :Message :MessageManager m:Message Actor sendMSG() Control show sendMSG(body, sender, receiver, type) sendMSG(body, sender, receiver, type) sendMSG(body, sender, receiver, type) <<create>> setBody(body) setSender(sender) setReceiver(receiver) setType(type) add(m) notification notification notificationFigura F.10: Diagrama de interacci´n - Enviar mensaje y almacenar informaci´n, o oCU 5.1 En la Figura F.11 se muestra la interacci´n al momento de almacenar la referen- ocia del mensaje enviado al remitente y destinatarios, notificando que ha enviado orecibido un mensaje a estos.
  • 183. CAP´ ´ ITULO F. DIAGRAMA DE INTERACCION 181 Server CreatorClient sender:User receiver:User :View :UserService :UserManager msg:MessageId msg:MessageId Control sendMSG(msgId, senderId, receiverId, type) find(senderId) find(receiverId) addAsSender(msgId) add(msgId) addAsReceiver(msgId) add(msgId) notificationFigura F.11: Diagrama de interacci´n - Asociar mensaje al remitente y destinatario, oCU 5.1Localizaci´n y Mapas o En esta secci´n se muestran algunos de los diagramas de interacci´n relacionados o ocon localizaci´n y mapas. o Para mantener el bajo acoplamiento entre nuestro juego y el hardware GPS,aplicando el patr´n de indirecci´n se utilizara una clase de apoyo para la interacci´n o o oentre el juego y el GPS, como se puede observar en la Figura F.12.
  • 184. CAP´ ´ ITULO F. DIAGRAMA DE INTERACCION 182 Client :GPS Interface Actor GPS Service getLocation() getLocation() location show(location) Figura F.12: Solicitar localizaci´n, CU 6.4 o
  • 185. G. IteracionesIteraci´n 1 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con la persitencia, es decir, entitidades y accessors. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.server.xxx.model.entity com.jpizarro.th.server.xxx.model.persistence.accessorPruebas En esta iteraci´n se hicieron pruebas de creaci´n, interaci´n y persistencia de o o olos objetos, para ello se hizo seguimiento a los resultados en la base de datos, y larecuperaci´n de objetos desde esta. o Las pruebas fueron: crear y eliminar buscar un objeto existente buscar un objeto no existente(InstanceNotFoundException) crear dos veces un mismo objeto(DuplicateInstanceException) 183
  • 186. CAP´ ITULO G. ITERACIONES 184Iteraci´n 2 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con los casos de uso o acciones de los usuario y equipos. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.server.user.model.service com.jpizarro.th.server.team.model.servicePruebas En esta iteraci´n se hicieron pruebas de la implementaci´n de los casos de uso o oo servicios, para ello se hizo seguimiento a los resultados en la base de datos, yla recuperaci´n de objetos desde esta tomando como unidades los m´todos de los o eservicios, los que interact´ an con varios objetos y/o accessors a la vez, como por uejemplo obtener los miembros de un equipo. Las pruebas fueron: Verificar el correcto funcionamiento de cada m´todo eIteraci´n 3 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con los casos de uso o acciones de los lugares, pistas y metas. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.server.place.model.service
  • 187. CAP´ ITULO G. ITERACIONES 185Pruebas En esta iteraci´n se hicieron pruebas de la implementaci´n de los casos de uso o oo servicios, para ello se hizo seguimiento a los resultados en la base de datos, yla recuperaci´n de objetos desde esta tomando como unidades los m´todos de los o eservicios, los que interact´ an varios objetos y/o accessors a la vez. u Las pruebas fueron: Verificar el correcto funcionamiento de cada m´todo eIteraci´n 4 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con los casos de uso o acciones de los juegos. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.server.game.model.servicePruebas En esta iteraci´n se hicieron pruebas de la implementaci´n de los casos de uso o oo servicios, para ello se hizo seguimiento a los resultados en la base de datos, yla recuperaci´n de objetos desde esta tomando como unidades los m´todos de los o eservicios, los que interact´ an con varios objetos y/o accessors a la vez. u Las pruebas fueron: Verificar el correcto funcionamiento de cada m´todo eIteraci´n 5 o El objetivo de esta iteraci´n es la implementaci´n e intregraci´n de todos los o o opaquetes que tienen relaci´n con los casos de uso o acciones, adem´s de implementar o ala mensajer´ ıa.
  • 188. CAP´ ITULO G. ITERACIONES 186Paquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.server.user.model.service com.jpizarro.th.server.team.model.service com.jpizarro.th.server.place.model.service com.jpizarro.th.server.hint.model.service com.jpizarro.th.server.game.model.service com.jpizarro.th.server.msg.model.servicePruebas En esta iteraci´n se hicieron pruebas de la implementaci´n de los casos de uso o oo servicios, para ello se hizo seguimiento a los resultados en la base de datos, yla recuperaci´n de objetos desde esta tomando como unidades los m´todos de los o eservicios, los que interact´ an con varios objetos y/o accessors a la vez. u Las pruebas fueron: Verificar el correcto funcionamiento de cada m´todo y la integraci´n este estos e o Verifican distintos escenarios posibles de juegoIteraci´n 6 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con el servicio Web Axis. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.server.game.view.axis
  • 189. CAP´ ITULO G. ITERACIONES 187Pruebas En esta iteraci´n se hicieron pruebas de la implementaci´n de los servicios Web o oaxis, para ello se hizo seguimiento a los resultados en la base de datos, y la re-cuperaci´n de objetos desde esta, implementando un cliente que interact´ a con el o uservidor de juego tomando como unidades los m´todos de los servicios, los que in- eteract´ an con varios objetos y/o accessors a la vez. u Las pruebas fueron: Verificar el correcto funcionamiento de cada m´todo e En G.1 se muestra la informaci´n de usuario que entrega el servidor de juego en ola interfaz Axis. C´digo G.1: Informaci´n de usuario Axis o o <ns:findUserByIdResponse> <ns:return xsi:type="ax21:UserTO"> <ax21:latitude>0</ax21:latitude> <ax21:longitude>0</ax21:longitude> <ax21:name xsi:nil="true"/> <ax21:password>1234</ax21:password> <ax21:role>ROLE_USER</ax21:role> <ax21:userId>2</ax21:userId> <ax21:username>Juan</ax21:username> </ns:return> </ns:findUserByIdResponse>Iteraci´n 7 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n la interfaz REST. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.server.game.view.Web.ws
  • 190. CAP´ ITULO G. ITERACIONES 188Pruebas En esta iteraci´n se hicieron pruebas de la implementaci´n de los servicios Web o oREST, para ello se hizo seguimiento a los resultados en la base de datos, y la re-cuperaci´n de objetos desde esta, implementando un cliente que interact´ a con el o uservidor de juego tomando como unidades los m´todos de los servicios, los que in- eteract´ an con varios objetos y/o accessors a la vez. u Las pruebas fueron: Verificar el correcto funcionamiento de cada m´todo e En G.2 se muestra la informaci´n de usuario que entrega el servidor de juego en ola interfaz REST. C´digo G.2: Informaci´n de usuario REST o o <user> <userId>2</userId> <username>Juan</username> <password>1234</password> <latitude>0</latitude> <longitude>0</longitude> <role>ROLE_USER</role> </user>Iteraci´n 8 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n la interfaz Web. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.server.game.view.Web
  • 191. CAP´ ITULO G. ITERACIONES 189Pruebas En esta iteraci´n se hicieron pruebas de la implementaci´n de la interfaz Web, o opara ello se hizo seguimiento a los resultados en la base de datos, y la recuperaci´n ode objetos desde esta, utilizando un cliente Web. Las pruebas fueron: Verificar el correcto funcionamiento de cada p´gina a crear, buscar, listar objetos Figura G.1: Interfaz WebIteraci´n 9 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con la comunicaci´n entre el cliente Android y el servidor de juego. o oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.client.model.util.http com.jpizarro.th.client.model.service
  • 192. CAP´ ITULO G. ITERACIONES 190Pruebas En esta iteraci´n se hicieron pruebas de la implementaci´n del cliente Android, o opara ello se hizo seguimiento a los resultados en la base de datos, y la recuperaci´n de oobjetos desde esta, utilizando un cliente Android sin implementaci´n de la interfaz ogr´fica. a Las pruebas fueron: Verificar la comunicaci´n con el servidor de juego o Verificar el correcto funcionamiento de cada m´todo de los servicios e crear, buscar, listar objetos Figura G.2: Cliente Android para test de comunicaci´n con el servidor oIteraci´n 10 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con la Interfaz de mapa en el cliente Android. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.client.activity
  • 193. CAP´ ITULO G. ITERACIONES 191 com.jpizarro.th.client.common.actions com.jpizarro.th.client.common.dialogsPruebas En esta iteraci´n se hicieron pruebas de la implementaci´n del cliente Android, o opara ello se hizo seguimiento a los resultados en la base de datos, y la recuperaci´n ode objetos desde esta, utilizando un cliente Android. Las pruebas fueron: Probar la interfaz de mapa Corroborar la interacci´n con el servidor de juego y el despliego de informaci´n o o en el mapa Verificar el correcto funcionamiento del mapa y su resultado en el servidor de juego Se realizaron recorridos para corroborar la correcta utilizaci´n del GPS y los o mapas Figura G.3: Mapa en cliente Android
  • 194. CAP´ ITULO G. ITERACIONES 192Iteraci´n 11 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con la Interfaz del cliente Android. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.client.activity com.jpizarro.th.client.common.actions com.jpizarro.th.client.common.dialogsPruebas En esta iteraci´n se hicieron pruebas de la implementaci´n del cliente Android, o opara ello se hizo seguimiento a los resultados en la base de datos, y la recuperaci´n ode objetos desde esta, utilizando el cliente Android. Las pruebas fueron: Probar la interfaz gr´fica a Corroborar la interacci´n correcta con el servidor de juego y la informaci´n o o mostrada. Verificar el correcto funcionamiento de cada pantalla y su resultado en el servi- dor de juego crear, buscar, listar objetosAspectos importantes La interfaz de gr´fica del cliente Android, esta compuesta de un conjunto de vis- atas o actividades, las que se muestran en la Figura G.4.
  • 195. CAP´ ITULO G. ITERACIONES 193 Figura G.4: Actividades del Cliente Android
  • 196. CAP´ ITULO G. ITERACIONES 194Re-impletaci´n del juego basado en arquitectura SOA oIteraci´n 12 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con el sub-sistema de usuarios, persistencia y acciones o casos de uso. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.lib.user.entity com.jpizarro.th.server.user.model.entity com.jpizarro.th.server.user.model.persistence com.jpizarro.th.server.user.model.serviceIteraci´n 13 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con el sub-sistema de equipos, persistencia y acciones o casos de uso. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.lib.team.entity com.jpizarro.th.team.user.model.entity com.jpizarro.th.team.user.model.persistence com.jpizarro.th.team.user.model.serviceIteraci´n 14 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con el sub-sistema de lugares, persistencia y acciones o casos de uso. o
  • 197. CAP´ ITULO G. ITERACIONES 195Paquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.lib.place.entity com.jpizarro.th.place.user.model.entity com.jpizarro.th.place.user.model.persistence com.jpizarro.th.place.user.model.serviceIteraci´n 15 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con el sub-sistema de mensajes, persistencia y acciones o casos de uso. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.lib.message.entity com.jpizarro.th.message.user.model.entity com.jpizarro.th.message.user.model.persistence com.jpizarro.th.message.user.model.serviceIteraci´n 16 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con el sub-sistema de juego, persistencia y acciones o casos de uso. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.lib.game.entity com.jpizarro.th.game.user.model.entity
  • 198. CAP´ ITULO G. ITERACIONES 196 com.jpizarro.th.game.user.model.persistence com.jpizarro.th.game.user.model.serviceIteraci´n 17 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con la interfaz REST de los distintos sub-sistemas. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.server.user.view.rest com.jpizarro.th.server.team.view.rest com.jpizarro.th.server.place.view.rest com.jpizarro.th.server.message.view.rest com.jpizarro.th.server.game.view.restIteraci´n 18 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con el servicio Web Axis de los distintos sub-sistemas. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.server.user.view.axis com.jpizarro.th.server.team.view.axis com.jpizarro.th.server.place.view.axis com.jpizarro.th.server.message.view.axis com.jpizarro.th.server.game.view.axis
  • 199. CAP´ ITULO G. ITERACIONES 197Iteraci´n 19 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con la interfaz Web del sub-sistema de juego. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.server.game.view.WebIteraci´n 20 o El objetivo de esta iteraci´n es la implementaci´n de los paquetes que tienen o orelaci´n con el cliente Android. oPaquetes y clases Se realizaron implementaciones en los siguientes paquetes: com.jpizarro.th.client.model.util.http com.jpizarro.th.client.model.service com.jpizarro.th.client.activity com.jpizarro.th.client.common.actions com.jpizarro.th.client.common.dialogs

×