Aplicación Android de soporte a un juego de mesa

Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Aplicación Android de soporte a un juego de mesa Dpto. de Ingeniería Telemática Autor: Marcos Girón Fernández Tutor: Isabel Roman Martinez Sevilla, 201 8 iii Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Aplicación Android de soporte a un juego de mesa Autor: Marcos Girón Fernández Tutor: Isabel Roman Martinez Profesor titular Dpto. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2018 Proyecto Fin de Carrera: Aplicación Android de soporte a un juego de mesa v Autor: Marcos Girón Fernández Tutor: Isabel Roman Martinez El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2018 El Secretario del Tribunal vii A mi familia A mis maestros A mis amigos Resumen El avance imparable de los smartphones y la existencia de tiendas virtuales de aplicaciones móviles ha producido un cambio en el mercado, obligando a muchas empresas orientar sus productos al sector de la movilidad. Según un informe de ditrendia (digital marketing trends) de 2017, un 66% de la población mundial ya cuenta con móvil, y éste es el dispositivo más utilizado para acceder a internet en España, usado ya por el 94,6% de los españoles. En este proyecto hemos planificado, implementado y desplegado una aplicación Android distribuida que complementa un juego de mesa de temática financiera. Este desarrollo se ha realizado a petición de un cliente, propietario del juego y creador de las reglas. Por lo tanto, la comunicación con él ha sido crucial en el análisis de requisitos y en el desarrollo de las pruebas. La implementación se ha realizado con el IDE Android Studio debido a las numerosas opciones avanzadas que podemos encontrar en este entorno de desarrollo, y las facilidades que ofrece. ix Abstract The unstoppable advance of smartphones and the virtual presence of mobile application stores has produced a change in the market, forcing many companies to target their products to the mobility sector. According to a report of ditrendia (digital marketing trends) of 2017, 66% of the world's population already has a mobile phone, and this is the most used device to access the internet in Spain, already used by 94.6% of Spanish people. In this project we have planned, implemented and deployed a distributed Android application that complements a board game with a financial theme. This development was made at the request of a client, owner of the game and creator of the rules. Therefore, communication with him has been crucial in the analysis of requirements and in the development of the tests. The implementation has been made with the IDE Android Studio due to the many advanced options that we can find in this development environment, and the facilities it offers. Introducción 18 1 INTRODUCCIÓN ivimos en una sociedad que tiende a digitalizar gran parte de las tareas que antiguamente se realizaban manualmente o haciendo uso de una serie de componentes físicos. La llegada de los smartphones, y consecuentemente de las aplicaciones móviles, ha provocado que las personas utilicen estos dispositivos como una herramienta para realizar gran variedad de actividades que se han visto simplificadas por una pulsación en un botón. Esta evolución ha llegado a los juegos de mesa, es más, en la gran mayoría de las situaciones los ha sustituido. Son pocos aquellos que han conseguido mantener la esencia, que es estar reunidos con los amigos y compartir una divertida partida juntos, dando lugar al fortalecimiento de las relaciones entre ellos. Pero no podemos ignorar las ventajas que ofrecen las aplicaciones móviles, como es la automatización de procesos, simplificación de tareas y la posibilidad de conectar personas ubicadas en distintos lugares. Ésta es la reflexión que ha motivado la creación de este proyecto. La integración de una aplicación móvil en un juego de mesa tradicional ya creado, con nombre Financial Game, aprovechando los beneficios que ofrecen ambos elementos. Además, siendo consciente de la cada vez más popularidad del sistema operativo Android y sus aplicaciones, he querido realizar un trabajo de este tema para ampliar mis conocimientos sobre la materia, y vivir en persona el proceso para el desarrollo de una aplicación móvil. 1.1 Objetivos El objetivo principal de este proyecto es crear una aplicación Android nativa de soporte a un juego de mesa de temática financiera, y el resto de los componentes necesarios para ofrecer las funciones online. Los jugadores podrán utilizar el programa para llevar el ritmo de la partida, ver estadísticas de las puntuaciones de cada jugador, participar en la comunidad online de Financial Game, participar en partidas online, y visualizar en formato digital las reglas del juego. Para ello, se deberá realizar las distintas actividades propias de un proceso de desarrollo software. En los siguientes capítulos del documento se tratarán cada una de estas fases. 1.2 Descripción del documento En el segundo capítulo de este documento, mostraremos una visión general del proyecto Android y de la aplicación desarrollada. También enumeraremos las tecnologías utilizadas que nos han permitido obtener el programa deseado. En el tercer capítulo se desarrollará la especificación de requisitos, que son un conjunto de características deseables fruto de la indagación sobre el problema y negociación con el cliente. En el cuarto capítulo partimos de la especificación de requisitos para proceder al diseño detallado de los distintos subsistemas que componen el proyecto. En el quinto capítulo se presentará el plan de pruebas seguido para garantizar que la aplicación surgida cumpla con los requisitos expuestos en el capítulo tercero. Finalmente, en el sexto capítulo se extraerán una serie de conclusiones del trabajo realizado, se listarán una serie de posibles mejoras, y se indicarán los pasos a seguir para completar aquello que no hemos podido tratar. V 19 19 Aplicación Android de soporte a un juego de mesa 2 ENTORNO DE TRABAJO Y TECNOLOGÍAS Continuación, se lista el software utilizado para el desarrollo del proyecto, además de las tecnologías elegidas para alcanzar nuestro objetivo. 2.1 Android Studio Figura: 1. Android Studio Android Studio es el entorno de desarrollo oficial para la plataforma Android, disponible de forma gratuita y con soporte para una gran variedad de sistemas operativos. El lenguaje de programación es Java, y utiliza xml para la organización de componentes en las interfaces de usuario. Implementa Gradle para la estructuración de los proyectos, facilitando la compilación y la integración de librerías externas. Además, disponemos de una gran variedad de herramientas esenciales para la depuración de la aplicación desarrollada, como el modo debug (para depurar paso a paso) y el AVD (Administrador de Dispositivos Virtuales). Por último, este programa cuenta con la posibilidad de integrar el proyecto con repositorios de control de versiones, en nuestro caso con GitHub. Este IDE ha sido el elegido para el desarrollo de la aplicación móvil. En la librería Java especial que ofrece esta herramienta para el desarrollo de aplicaciones móviles, debemos destacar las siguientes clases:  Activity: Clase que representa una pantalla de la interfaz, gestiona eventos producidos por la interacción del usuario con la pantalla y muestra la información.  Fragment: Clase que representa una parte de la interfaz gestionada por una Activity.  AsyncTask: Clase que automatiza el uso de hilos de ejecución, procesándolos en background y devolviendo el resultado.  Application: Clase base de la aplicación Android, y la primera en instanciarse al ejecutarse el programa. A Entorno de trabajo y tecnologías 20 Por último, debemos indicar que la interfaz de usuario se codifica por medio de layouts, que son archivos xml. 2.2 Control de versiones A continuación, se muestran dos imágenes que representan los repositorios creados en la comunidad de control de versiones GitHub específicamente para el proyecto. También se indica la url debajo de cada una. Aunque ha sido un proyecto llevado a cabo por una persona, el uso del control de versiones nos ha permitido continuar el trabajo en distintos equipos y llevar un mejor control de las versiones del programa. Figura: 2. https://github.com/MarcoKun93/TFG_FinancialGame Esta figura corresponde al repositorio creado para el proyecto Android. Figura: 3. https://github.com/MarcoKun93/app.financialgame.com Esta figura corresponde al proyecto php creado para el desarrollo de los servicios web. 21 21 Aplicación Android de soporte a un juego de mesa 2.3 PhpStorm Figura: 4. PhpStorm PhpStorm es un entorno de desarrollo integrado de carácter comercial para PHP. Ofrece un editor para dicho lenguaje y también HTML y JavaScript. Se ha utilizado para el desarrollo de los servicios web en PHP. 2.4 JSON Figura: 5. Ejemplo mensaje con estructura JSON JSON es un formato de texto ligero para el intercambio de datos. Originalmente estaba pensado para la sintaxis de objetos de JavaScript, pero debido a su popularidad, se considera un formato de lenguaje independiente. Principalmente se ha utilizado para estructurar la información enviada en los mensajes HTTP entre cliente y servidor. Gracias a las facilidades ofrecidas por este lenguaje a la hora de decodificar la información, se han podido procesar los datos según las necesidades del proyecto. La imagen superior es un ejemplo de la información recibida del servidor, ante la petición de un servicio web, en formato JSON. Entorno de trabajo y tecnologías 22 2.5 REST web services Los servicios web son imprescindibles para cualquier desarrollo de sistemas distribuidos. Existen sitios web que ofrecen un API de métodos para ser invocados y consumirlos. Sin embargo, en nuestro caso, debemos crear ese conjunto de tareas desde cero. Existen dos enfoques distintos para los servicios web, SOAP orientado a métodos y REST orientado a recursos. Se ha elegido la segunda opción debido a la mejor integración con las aplicaciones Android. REST está orientado a recursos y estandariza de forma amigable su transferencia entre aplicaciones. Un recurso es todo aquello relacionado con datos los cuales estamos interesados en comunicar (en nuestro caso, registros de las tablas de la BBDD). Utiliza una estructura de urls para representar los recursos, y para poder acceder a ellos hace uso de los comandos HTTP GET, POST, PUT, y DELETE. A continuación, se muestra una captura de las urls de los servicios web implementados, y que utilizamos en el cliente para acceder a los recursos. Figura: 6. URLs de los servicios web 2.6 Volley Figura: 7. Implementación de Volley en el proyecto de Android Studio Volley es una librería de Google que no viene integrada en el SDK de Android Studio. Es una herramienta 23 23 Aplicación Android de soporte a un juego de mesa ideal para simplificar el proceso de conexión y descarga de información del servidor. Las llamadas a la red del cliente mediante Volley son asíncronas por lo que no tendremos que gestionar las tareas en segundo plano, ya que lo hace por nosotros. Las peticiones se gestionan por prioridades, y también tiene una caché que mejora la eficiencia del software. Existen varios tipos de peticiones, la utilizada en este proyecto en la JsonObjectRequest, que obtiene una respuesta de tipo JSONObject a partir de un recurso con este formato. Las peticiones tendrán un listener para capturar la respuesta recibida del servidor, implementando el patrón Callback. En la imagen superior se muestra la clase VolleyApplication que es la encargada de gestionar las peticiones en el proyecto Android. Como es recomendable tener sólo una cola de peticiones por aplicación, se aplica el patrón Singleton. 2.7 Librerías externas utilizadas Figura: 8. Dependencias de las librerías externas en Android Studio En esta imagen se muestra la integración de las librerías externas en nuestro proyecto Android. Para ello, se debe añadir la dependencia correspondiente en el archivo build.gradle para que Gradle nos permita acceder a los distintos recursos externos. A continuación, se listan las librerías integradas y su uso:  Librería Volley (com.android.volley:volley:1.0.0): Necesaria para integrar Volley en el proyecto Android.  Librería MPAndroidChart (com.github.PhilJay:MPAndroidChart:v3.0.2): Conjunto de gráficas avanzadas diseñadas para Android. Utilizada para la representación de las puntuaciones de la partida de forma gráfica y clara.  Librería NumberPicker (com.github.travijuu:numberpicker:1.0.7): Conjunto de elementos personalizables que hacen la misma función que un numberPicker normal de los layout de Android Studio. Utilizado para ofrecer una alternativa al elemento básico ofrecido, poco intuitivo y tosco en la interfaz de usuario, en la pantalla correspondiente a la introducción de puntuaciones.  Librería AndroidPdfViewer (com.github.barteksc:android-pdf-viewer:2.8.2): Visualizador avanzado de archivos pdf en Android. Permite al usurio navegar cómodamente por un documento y hacer zoom. Utilizado para la visualización de las instrucciones y el manual de la aplicación. 2.8 Tokens Para una aplicación con funcionalidades online, y que ofrecen servicios a un usuario, una de las más importantes cuestiones es cómo mantener la conexión cliente-servidor, almacenando de forma segura el identificador del usuario. Existen varias alternativas como el uso de cookies o dejarle al servidor el trabajo del mantenimiento de sesión. Sin embargo, en una aplicación Android que siempre busca la simplicidad, haremos Entorno de trabajo y tecnologías 24 uso de la autenticación sin estado con Tokens. Además, este método se integra a la perfección con los servicios web REST. En nuestro caso, el usuario se identificará haciendo uso de una clave única para cada usuario (la claveAPI) que enviará el cliente en la cabecera del mensaje HTTP, tomando el rol de un Token. Esta nueva clave la obtendrá el usuario cuando haya iniciado sesión correctamente. No es más que una firma cifrada que permite identificar a la persona. 2.9 MagicDraw UML MagicDraw UML es una herramienta CASE compatible con el estándar UML para el diseño de software, y compatible con numerosos IDEs. Este programa se ha utilizado para la creación de los diagramas del diseño de nuestro sistema. 2.10 Pencil Project Pencil Project es una interfaz gráfica de usuario (GUI) que permite, de forma gratuita y sencilla, crear prototipos de aplicaciones de escritorio y móviles. Se ha utilizado en esta ocasión para el diseño de bocetos de la interfaz gráfica de la aplicación Android, que podemos ver en el apartado 3.9 de este documento (correspondiente a la especificación de requisitos). 2.11 Trello Figura: 9. Captura del portal web Trello Trello es un software de administración de proyectos con interfaz web. También dispone de clientes para IOs y Android. La creación de una cuenta es totalmente gratuita, y podrás compartir el proyecto creado con otros usuarios. Con esta herramienta se han podido gestionar las distintas tareas que han ido surgiendo durante el transcurso del proyecto, así como tener un historial de las distintas actividades realizadas. 25 25 Aplicación Android de soporte a un juego de mesa 3 ESPECIFICACIÓN DE REQUISITOS n este apartado, explicamos en detalle el análisis de los requisitos exigidos por el cliente, los objetivos a cumplir y la estructuración del sistema a desarrollar. 3.1 Introducción Financial Game App es una aplicación móvil, desarrollada para Android, que complementa a un juego de mesa ya existente. Partiendo de éste y respetando su objetivo, introducirá nuevas posibilidades enriqueciendo la experiencia y actualizándola a los tiempos que corren. Con la aplicación los usuarios podrán; comprar productos financieros dentro del plazo marcado por un temporizador de tiempo aleatorio, almacenar sus datos, ver eventos dinámicos, crear gráficos de la partida y subir información a la comunidad online. Debemos indicar que únicamente se necesitará un dispositivo Android con la aplicación instalada, evitando la molestia de obligar a todos los jugadores, que comparten ubicación, a cumplir ese requisito. Por último, se implementará la funcionalidad estrella del programa, poder realizar partidas online con otros usuarios registrados en el sistema. Para poder ofrecer todas las funciones online, será necesario implementar un servidor que ofrezca los servicios necesarios y satisfaga las peticiones de la aplicación Android, que realiza el rol de cliente. Este proyecto será presentado como Trabajo Fin de Grado, en el cual se hará uso de los conocimientos aprendidos en la rama de telemática del Grado de Ingeniería de las Telecomunicaciones. Está organizado en distintos módulos, los cuales se irán explicando en este documento. 3.1.1 Propósito del documento Este documento será de ayuda para entender las distintas partes de la aplicación software, los objetivos, quiénes interactúan con el software, cómo se comunican los distintos actores con la aplicación y los requisitos que debe satisfacer. Gran parte de los requisitos han surgido del proceso de análisis con el cliente, quien ha exigido que se respeten las ideas originales del producto que son la diversión y el aprendizaje. El papel de cliente lo ha realizado Antonio Escuder García, propietario del juego de mesa, creador de las reglas del juego y quien encargó la aplicación. Este documento servirá para establecer unas bases sobre las cuales desarrollaremos las siguientes fases. 3.1.2 Audiencia a la que va dirigido Este documento va dirigido a todas las personas interesadas en entender el funcionamiento de la aplicación que se quiere desarrollar y comprender sus módulos, principalmente al cliente. También va dirigido a los diseñadores, desarrolladores y probadores del sistema. 3.1.3 Alcance Lo primero de todo es dejar claro lo que hace y no hace el producto. La aplicación Android no será un sustituto del producto original (las reglas del juego en detalle están disponibles en el apartado Situación de Partida), ya que acompañará en todo momento al tablero y cartas. Será un complemento más, pero importante, para la partida. Los usuarios podrán con la aplicación; tener un temporizador de cada turno, ver el estado de las puntuaciones, ver eventos dinámicos que modificarán las variables del juego, introducir valores y ver un resumen de la partida finalizada. Tendrá características online como: un ranking de partidas y puntuaciones, sistema de registro y autenticación, sistema de logros, y ver información de perfil. Además, se introducirá el concepto de semilla distribuida, que consistirá en un escenario preestablecido que los usuarios conectados E Especificación de requisitos 32 3.7 Diagramas de casos de uso Como introducción a los siguientes apartados, mostraremos un diagrama de caso de uso generalista. En los próximos apartados iremos profundizando en cada uno de los subsistemas. Además, se incluyen las tablas de casos de uso para ofrecer más detalle. Figura: 10. Diagrama de casos de uso general del sistema Debemos indicar que, cuando una persona inicia la aplicación, la primera pantalla mostrada es la pantalla de carga. Se indica en la siguiente tabla. - Mostrar pantalla de carga Descripción: Cuando una persona lanza la aplicación, la primera pantalla mostrada será la pantalla de carga, que tendrá una duración de tres segundo como máximo. En esta vista aparecerá un indicador de carga y el logo de la app. 33 33 Aplicación Android de soporte a un juego de mesa 3.7.1 Gestión de partida offline A continuación, se muestra un diagrama de casos de uso referente al subsistema Gestión de partida offline: Figura: 11. Diagrama de casos de uso de partida offline CU01 Mostrar eventos Actores: Usuario, BBDD local Pre-condición: Tiempo del temporizador acabado. Descripción: La aplicación mostrará una ventana emergente con la información del evento seleccionado. Éste lo obtiene de la BBDD local. Post-condición: El usuario verá el evento, y actuará en consecuencia de la información mostrada. Especificación de requisitos 34 CU02 Activar temporizador Actores: Usuario Pre-condición: El usuario pulsa sobre el botón iniciar temporizador, o se acaba de cerrar una ventana de evento. Descripción: La aplicación ejecutará un temporizador de tiempo aleatorio. Se mostrará en pantalla un indicador del avance del tiempo. Post-condición: Al finalizar el tiempo, se ejecutará un aviso sonoro y mostrará automáticamente la ventana de evento. CU03 Introducir datos financieros de cada jugador al finalizar ronda Descripción: Al finalizar la ronda, se mostrará la pantalla de introducir las puntuaciones correspondientes de cada jugador. Cuando se pulse en confirmar datos, se guardarán en la base de datos local. Cuando todos los participantes hayan escrito y confirmado sus puntuaciones, volveremos a la pantalla de la partida si no hemos terminado el juego. En caso de numero de rondas jugadas igual al número de rondas establecido, se mostrará el fin de la partida. CU04 Introducir datos para iniciar partida Descripción: Antes de empezar una partida, la aplicación mostrará una pantalla donde los jugadores pueden configurar valores de la partida como número de rondas y los participantes. También ofrecerá la posibilidad de indicar si quiere utilizar la semilla distribuida en la partida. CU05 Mostrar el ganador de la partida y gráficas de la evolución de la partida Descripción: El programa mostrará una ventana con información del jugador ganador. Los participantes podrán acceder a una pantalla con gráficas, pulsando el botón correspondiente, que representan el historial de puntuaciones de cada jugador. 35 35 Aplicación Android de soporte a un juego de mesa CU06 Aplicar modificaciones de la Semilla Distribuida Descripción: En caso de que el jugador lo quiera, el sistema aplicará las modificaciones impuestas por la semilla distribuida seleccionada. CU07 Compartir partida Descripción: El usuario, al darle al botón correspondiente, indicará a la aplicación que suba al servidor los datos de la partida finalizada. CU08 Obtener semilla distribuida Descripción: El sistema manda una petición al servidor con el identificador de la semilla seleccionada, para obtener los datos de ésta. En caso de no enviar identificador, devolvería un listado con todas las semillas existentes. 3.7.2 Gestión de partida online A continuación, se muestra un diagrama de casos de uso referente al subsistema Gestión de partida online: Figura: 12. Diagrama de casos de uso de partida online Especificación de requisitos 36 CU09 Unir usuario a la partida online Actores: Usuario Pre-condición: El usuario selecciona una partida a la que unirse, o crea una partida online. Descripción: La aplicación manda una petición al servidor con el identificador de la partida para unir ese usuario con la partida online seleccionada. Post-condición: Usuario asignado y se mostrará la pantalla inicial de la partida online. CU10 Empezar partida Descripción: Si todos los jugadores online están preparados, empezará automáticamente la partida, mostrándose la siguiente pantalla de este módulo. CU11 Mostrar temporizador con turno aleatorio Actores: Usuario Pre-condición: Todos los usuarios preparados. Descripción: La aplicación mostrará en la pantalla de los dispositivos de todos los jugadores online el temporizador de tiempo aleatorio. Para ello realizará una petición al servidor para obtener el valor generado, el mismo para todos los participantes. Post-condición: Al finalizar el tiempo, se ejecutará un aviso sonoro y mostrará automáticamente la ventana de evento. CU12 Mostrar eventos Actores: Usuario Pre-condición: Tiempo del temporizador acabado. Descripción: El sistema realizará una petición al servidor para obtener el evento aleatorio generado, el mismo para todos los participantes. La aplicación mostrará una ventana emergente con la información del evento obtenido. Post-condición: Todos los jugadores online visualizarán el mismo 37 37 Aplicación Android de soporte a un juego de mesa evento. CU13 Introducir datos financieros al terminar la ronda Descripción: Al finalizar la ronda, se mostrará la pantalla de introducir las puntuaciones correspondientes de cada usuario. Cuando se pulse en confirmar datos, la aplicación mandará una petición con los datos introducidos para almacenarlos en la BBDD remota. Cuando todos los jugadores online estén preparados, volveremos a la pantalla de la partida si no hemos terminado el juego. En caso de numero de rondas jugadas igual al número de rondas establecido, se mostrará el fin de la partida CU14 Mostrar el ganador de la partida y gráficas de la evolución de la partida Descripción: El programa mandará petición al servidor para conocer el ganador de la partida, y se lo mostrará a todos los jugadores online. Acto seguido lanzará la vista de gráficas que ofrece más información del transcurso de la partida. CU15 Ofrecer servicio Jugador online Descripción: El servidor procesa las peticiones que recibe de los clientes respecto al recurso Jugador Online. CU16 Ofrecer servicio Partida Online Descripción: El servidor procesa las peticiones que recibe de los clientes respecto al recurso Partida Online. CU17 Ofrecer servicio temporizador Descripción: El servidor procesa las peticiones que recibe de los clientes respecto al recurso Temporizador. CU18 Ofrecer servicio evento Especificación de requisitos 38 Descripción: El servidor procesa las peticiones que recibe de los clientes respecto al recurso Evento. 3.7.3 Gestión de la comunidad A continuación, se muestra un diagrama de casos de uso referente al subsistema de Gestión de la comunidad: Figura: 13. Diagramas de casos de uso de comunidad CU19 Registrar usuario Descripción: El usuario accede a la ventana emergente correspondiente a registrar usuario. La aplicación manda al servidor la petición de crear usuario con los datos introducidos. CU20 Iniciar sesión Descripción: El usuario accede a la ventana emergente correspondiente a iniciar sesión. La aplicación manda al servidor la petición de identificar al usuario según los datos introducidos. CU21 Ver perfil del usuario Descripción: El usuario accederá a la ventana de perfil, dentro de comunidad, y podrá ver su información 39 39 Aplicación Android de soporte a un juego de mesa personal. Para ello, la aplicación deberá mandar una petición al servidor preguntando por los datos de éste. CU22 Ver ranking puntuaciones Descripción: El usuario accederá a la ventana de ranking, dentro de comunidad, y podrá ver una lista de las partidas con más puntuación final. Para ello, la aplicación deberá mandar una petición al servidor preguntando por las partidas subidas. CU23 Ver logros del usuario Descripción: El usuario accederá a la ventana de logros, dentro de comunidad, y podrá ver una lista con sus logros obtenidos catalogados según el tipo. Para ello, la aplicación deberá mandar una petición al servidor preguntando por los logros del usuario. CU24 Ofrecer servicio usuario Descripción: El servidor procesa las peticiones que recibe de los clientes respecto al recurso Usuario. CU25 Ofrecer servicio ranking Descripción: El servidor procesa las peticiones que recibe de los clientes respecto al recurso Ranking. CU26 Ofrecer servicio semilla Descripción: El servidor procesa las peticiones que recibe de los clientes respecto al recurso Semilla. CU27 Ofrecer servicio partida Descripción: El servidor procesa las peticiones que recibe de los clientes respecto al recurso Partida. CU28 Ofrecer servicio logro Especificación de requisitos 40 Descripción: El servidor procesa las peticiones que recibe de los clientes respecto al recurso Logro. 3.7.4 Consulta de instrucciones y manual de usuario A continuación, se muestra un diagrama de casos de uso referente al subsistema de Consulta de instrucciones y manual de usuario: Figura: 14. Diagrama de casos de uso manuales de usuario CU36 Consultar instrucciones del juego Descripción: El usuario podrá acceder a las instrucciones del juego a través de la sección correspondiente de la aplicación. Se mostrará un documento pdf. CU37 Consultar el manual de usuario de la aplicación Descripción: El usuario podrá acceder al manual de usuario de la aplicación a través de la sección correspondiente. Se mostrará un documento pdf. 41 41 Aplicación Android de soporte a un juego de mesa 3.7.5 Servidor de la aplicación El servidor desarrollado utiliza la arquitectura de software REST, por lo que ofrece representaciones de recursos. Éstos estarán identificados por URIs que el cliente deberá indicar en sus peticiones. La información enviada por el servidor estará representada en JSON, siendo tarea del cliente tratarla adecuadamente. Figura: 15. Diagrama de casos de uso del servidor CU29 Registrar usuario Descripción: El servidor registrará un nuevo usuario en la BBDD remota con la información recibida. CU30 Encriptar clave Descripción: Al registrar un usuario, la contraseña introducida por él será encriptada en un código seguro. Especificación de requisitos 48  Logros (IRQ-13)  Semilla (IRQ-12)  Partidas del usuario (IRQ - 11) Prioridad: Alta Comentario: Se ofrecerán servicios para que el usuario pueda acceder a su perfil. Para ello se le identificará con un código de acceso. IRQ-11 Información de la partida Versión: Versión 2.0 <16-05-2018> Objetivos asociados: OBJ-05 Descripción: El servidor almacenará información de las últimas partidas subidas. Datos específicos:  Identificador de la partida (Cadena de caracteres)  Identificador de usuario asociado (Entero)  Nº de Jugadores (Entero)  Fecha (Fecha)  Puntuación del ganador (Entero)  Nombre del ganador (Cadena de caracteres)  Nº de rondas (Entero)  Identificador de la semilla utilizada (Entero) Prioridad: Alta Comentario: Usuario asociado es quien se identificó en el sistema y subió la partida. Al jugar una partida, los jugadores podrán decidir si utilizar una semilla, en ese caso se indicará su identificador en la información de la partida. IRQ-12 Semilla distribuida Versión: Versión 2.0 <16-05-2018> Objetivos asociados: OBJ-01, OBJ-02, OBJ-03 Descripción: El servidor almacenará información sobre la semilla distribuida. Datos específicos:  Identificador de la semilla (Entero)  Título (Cadena de caracteres)  Descripción (Cadena de caracteres)  Variable afectada (Cadena de caracteres) 49 49 Aplicación Android de soporte a un juego de mesa  Valor (Entero) Prioridad: Media Comentario: La app cliente hará uso del servicio correspondiente para pedirla. La semilla afectará al valor de los activos financieros. Esta nueva característica se representará a los usuarios como “Escenario preestablecido”. IRQ-13 Logro Versión: Versión 2.0 <16-05-2018> Objetivos asociados: OBJ-01, OBJ-02, OBJ-03 Descripción: El servidor almacenará información sobre los logros disponibles. Datos específicos:  Identificador del logro (Entero)  Nombre (Cadena de caracteres)  Descripción (Cadena de caracteres)  Tipo (Cadena de caracteres) Prioridad: Media Comentario: Cuando un usuario sube una partida al servidor, se le pasará por una serie de filtros para comprobar si ha cumplido algún logro. En ese caso, a ese usuario se le asocia el identificador del logro. Sólo hay tres tipos de logros: bronce, plata y oro. Esta función es nueva respecto a las reglas del juego original. IRQ-14 Manuales de la aplicación Versión: Versión 2.0 <16-05-2018> Objetivos asociados: OBJ-06 Descripción: La aplicación almacenará la documentación referente a los distintos manuales para poder jugar y entender cómo se usa la app. Datos específicos:  Instrucciones de la partida  Manual de usuario de la aplicación Prioridad: Alta Comentario: Serán archivos de texto. Especificación de requisitos 50 3.8.2 Requisitos de reglas de negocio RN-01 Turnos por ronda Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-08 Descripción: Los usuarios no podrán modificar el número de eventos por ronda. El valor estará preestablecido por el sistema. Prioridad: Alta Comentario: Deberá tener un valor que no obstaculice la fluidez de la partida, comprendido entre 2 y 4 eventos. RN-02 Intervalo del temporizador Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-09 Descripción: Los usuarios no podrán modificar el intervalo de tiempo del temporizador. El intervalo estará preestablecido por el sistema. Antes de iniciar el temporizador, se cogerá un valor aleatorio comprendido en ese intervalo. Prioridad: Alta Comentario: Los valores mínimos y máximos no deben de diferenciarse en más de 30 segundos. RN-03 Partidas simultáneas Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-01 Descripción: Un mismo usuario sólo podrá participar en una partida a la vez (ya sean online u offline) Prioridad: Alta Comentario: Si el usuario sale de la ventana de una partida online en transcurso, será expulsado de ésta. RN-04 Configurar los valores iniciales de la partida 51 51 Aplicación Android de soporte a un juego de mesa Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-11, IRQ-12 Descripción: Los usuarios podrán elegir los valores de número de rondas, las personas que jugarán (sólo para partida offline), y si quieren utilizar alguna semilla antes de empezar la partida. Prioridad: Alta Comentario: - RN-05 Ver el temporizador en el transcurso de la partida Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-09 Descripción: Los jugadores podrán visualizar el temporizador del juego que aparece entre los distintos eventos. Aparecerá una ventana emergente con un indicador del progreso del temporizador. Prioridad: Alta Comentario: El tiempo del temporizador no es conocido ya que se coge un valor aleatorio de un intervalo. RN-06 Aviso al introducir las puntuaciones tras finalizar la ronda Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-01 Descripción: Al confirmar los datos introducidos por un usuario (en la vista correspondiente de introducir las puntuaciones de cada jugador), el sistema deberá mostrar un mensaje de aviso preguntando si está seguro de que los datos son correctos. Se le ofrecerá la posibilidad de modificarlos. Prioridad: Alta Comentario: Con este requisito nos aseguramos de que no haya datos introducidos accidentalmente. Especificación de requisitos 52 RN-07 Ver evento Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-03 Descripción: Se mostrará un evento al finalizar el temporizador. Se mostrará en una ventana emergente de la vista de la aplicación. En ella se verá: una imagen ilustrativa del tipo de evento, el tipo de evento, y atributos. Prioridad: Alta Comentario: El evento corresponde a una carta del mazo. RN-08 Introducir puntuación de los jugadores Versión: Versión 2.0 <16-05-2018> Requisitos asociados: OBJ-03 Descripción: Al terminar una ronda, los jugadores deberán introducir en el sistema sus puntuaciones. Prioridad: Alta Comentario: Si no se indica un valor en un campo, por defecto será cero. RN-09 Ver un resumen final de la partida Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-11 Descripción: Los jugadores podrán ver al final de la partida un resumen de ésta. Se utilizarán gráficas para mostrar el historial de puntuaciones totales de cada jugador, y para representar los distintos porcentajes de la puntuación final de cada jugador según el tipo de producto financiero comprado. Prioridad: Alta Comentario: Después de esta vista, el usuario podrá salir definitivamente de la partida. Se reiniciarán todos los valores. 53 53 Aplicación Android de soporte a un juego de mesa RN-10 Servicio de registro y autenticación Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-10 Descripción: El usuario podrá registrarse en el servidor del sistema. También podrá iniciar sesión en la aplicación para acceder a los servicios online. Prioridad: Media Comentario: Al registrarse podrá introducir un nombre de usuario, contraseña y correo electrónico. RN-11 Comprobar correo Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-10 Descripción: La aplicación al introducir un correo para registrar al usuario comprobará que tenga un formato válido. Prioridad: Baja Comentario: - RN-12 Servicio de compartir partida jugada Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-11 Descripción: Un usuario podrá subir al servidor una partida recientemente acabada (ya sea online u offline). Estará asociada a este usuario. Prioridad: Alta Comentario: Se subirá una instancia del modelo correspondiente a la partida. RN-13 Servicio de ranking Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-11 Especificación de requisitos 54 Descripción: Un usuario acreditado podrá ver un ranking de las puntuaciones obtenidas por los usuarios en las partidas subidas. Prioridad: Alta Comentario: Ordenado de mayor a menor. RN-14 Servicio de ver perfil del usuario Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-10 Descripción: Un usuario acreditado podrá ver su información de perfil. Prioridad: Media Comentario: Esta información podrá ser el correo, nombre de usuario, ultimas partidas subidas, contraseña y máxima puntuación obtenida. RN-15 Cambiar contraseña Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-10 Descripción: El usuario podrá cambiar su contraseña en la sección ver perfil de la aplicación. Prioridad: Baja Comentario: - RN-16 Servicio de logros Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-13 Descripción: El sistema, según el número de partidas jugadas, puntuación máxima conseguida y posición del ranking global, le ofrecerá una serie de recompensas en forma de medallas. Prioridad: Baja 55 55 Aplicación Android de soporte a un juego de mesa Comentario: Las medallas serán de bronce, plata y oro. No tendrán impacto en el transcurso de la partida. Se verá reflejado en el perfil del usuario. RN-17 Conseguir un logro Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-13, IRQ-11 Descripción: Un usuario no podrá tener copias de un mismo logro, si lo ha conseguido con anterioridad no podrá volver a obtenerlo. Prioridad: Baja Comentario: El servidor, antes de asignarle al usuario un logro, comprueba que no lo tenga ya asignado. RN-18 Servicio de obtener semilla distribuida Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-12 Descripción: El sistema ofrecerá la posibilidad a los jugadores de aplicar la semilla distribuida en la partida. Este elemento modificará variables de la partida. Prioridad: Media Comentario: Además de las modificaciones, también irá acompañado de una breve descripción para introducir a los jugadores en un contexto referente al mercado financiero. Alguna semilla sólo ofrece una descripción de nuevas reglas de juego, o variar el valor inicial de alguna variable del tablero. RN-19 Aplicar semilla distribuida Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-11, IRQ-12 Descripción: El usuario sólo podrá seleccionar una semilla a la vez. Por lo tanto, la aplicación sólo aplicará una semilla como máximo en la partida. No podrá cambiar de semilla en el transcurso de la partida. Especificación de requisitos 56 Prioridad: Baja Comentario: Si selecciona una nueva semilla, la nueva sustituirá a la antigua. RN-20 Consulta de manuales Versión: Versión 2.0 <16-05-2018> Requisitos asociados: IRQ-14 Descripción: Los usuarios podrán visualizar las instrucciones del juego y también el manual de usuario para aprender a usar la aplicación. Prioridad: Alta Comentario: La información se ofrecerá en forma de documento de texto. 3.8.3 Requisitos funcionales de conducta RNFC-01 Gestión de errores del acceso a los servicios Versión: Versión 2.0 <16-05-2018> Objetivos asociados: OBJ-02, OBJ-05 Descripción: Cada vez que se produzca un error al acceder a los servicios desde el cliente, se mostrará un mensaje en la vista de la aplicación con una breve descripción del error. Prioridad: Alta Comentario: El usuario no maneja los errores, esta acción corresponde al sistema. RNFC-02 Barajar las cartas de evento del mazo Versión: Versión 2.0 <16-05-2018> Objetivos asociados: OBJ-03 Descripción: Cuando la partida es iniciada, el sistema reordenará aleatoriamente el mazo de eventos almacenado en local. En caso de la partida online, esta acción la realiza el servidor. 57 57 Aplicación Android de soporte a un juego de mesa Prioridad: Alta Comentario: En ambos modos de juego, se instancia una lista que equivale al mazo y re reordena los índices de las cartas. RNFC-03 Mostrar la evolución de la partida durante el transcurso de ésta. Versión: Versión 2.0 <16-05-2018> Objetivos asociados: OBJ-03 Descripción: En la vista correspondiente al temporizador, se ofrecerá un ranking de los distintos jugadores de la partida y su puntuación. Prioridad: Alta Comentario: Ordenados de mayor a menor. Facilita a los jugadores conocer la situación de la partida en ese momento. RNFC-04 Actualización del mazo local Versión: Versión 2.0 <16-05-2018> Objetivos asociados: OBJ-05 Descripción: Se le ofrecerá al usuario identificado en el sistema, la posibilidad de actualizar el mazo de cartas almacenado en local. Prioridad: Baja Comentario: La aplicación cliente pregunta por la versión del mazo de eventos en el servidor. SI es mayor que la local, lo sustituye. 3.8.4 Requisitos no funcionales de fiabilidad RNFF-01 Inicio de sesión del usuario Versión: Versión 2.0 <16-05-2018> Objetivos asociados: OBJ-05 Descripción: Antes de iniciar sesión por parte del usuario, se le pedirá que se identifique con el correo y Especificación de requisitos 64 arquitectura Modelo Vista Controlador. Además, las clases destinadas a acceder a los servicios deberán implementar Singleton. Prioridad: Alta Comentario: Las vistas serán los layout de la app, los controladores serán las activities y servicios, y el modelo estará compuesto por las clases de las cuales se aplican los servicios. RT-03 Tipo de servidor Versión: Versión 2.0 <16-05-2018> Objetivos asociados: OBJ-02, OBJ-05 Descripción: EL servidor deberá contener los siguientes componentes: Apache + MySQL + PHP Prioridad: Alta Comentario: El proveedor de sitios web 000webhost cumple este requisito ya que ofrece esas herramientas en sus servidores gratuitos. RT-04 Tipo de aplicación Versión: Versión 2.0 <16-05-2018> Objetivos asociados: - Descripción: La aplicación deberá ser Android nativa. Prioridad: Alta Comentario: Será desarrollada con Android Studio. RT-05 Conexión con el servidor Versión: Versión 2.0 <16-05-2018> Objetivos asociados: OBJ-02, OBJ-05 Descripción: Para acceder a los servicios se hará uso de REST. Prioridad: Alta 65 65 Aplicación Android de soporte a un juego de mesa Comentario: Esto es debido a que es orientado a recursos y tiene mayor compatibilidad con sistemas móviles. 3.8.10 Requisitos de integración RI-01 Integración con librerías externas Versión: Versión 2.0 <16-05-2018> Objetivos asociados: - Descripción: El sistema por desarrollar deberá ser capaz de utilizar librerías externas, modificando el archivo de configuración correspondiente del proyecto Android. Prioridad: Alta Comentario: Por ejemplo, para la representación de gráficas, y el acceso a los servicios web para hacer peticiones http y gestionar la respuesta. 3.9 Interfaz gráfica La interfaz gráfica de nuestro software está pensada para ser una herramienta útil e intuitiva para los jugadores. Gracias a la interfaz, los usuarios podrán acceder a los distintos módulos de la aplicación de forma rápida y sencilla. Para ello, el diseño gráfico elegido deberá ser minimalista, acorde con la temática tratada (las financias). La división e interfaces se hará de la siguiente manera:  Vista de inicio y menú principal.  Modos de juego online y offline.  Gestión de la comunidad.  Visualización de manuales. 3.9.1 Vista de inicio y menú principal Cuando el usuario inicie la aplicación, lo primero que verá será una vista de carga (SplashScreen) con el logo y nombre del programa, en esta vista el usuario no podrá interactuar y deberá esperar. A continuación, aparecerá el menú principal, compuesto por los botones que mandarán al usuario a los distintos módulos de la app. También se ofrecerá un botón de acceso directo para iniciar sesión desde el menú. A continuación, se muestran unos bocetos de estas interfaces: Especificación de requisitos 66 Figura: 16. Boceto vista de carga Figura: 17. Boceto menú principal 3.9.2 Modos de juego online y offline Ambos modos de juego tendrán interfaces muy parecidas. Al principio aparecerá una vista para introducir valores iniciales de la partida, así como los nombres de los participantes. También estará el botón de empezar partida. La siguiente vista corresponde al escenario, donde aparece el temporizador, eventos y un ranking con la puntuación actualizada de los jugadores. Para iniciar el temporizador también se ofrecerá un botón, y los eventos se mostrarán en ventanas emergentes superpuestas a la vista principal. Estos eventos podrán ser quitados pulsando fuera del diálogo o en el botón cancelar correspondiente. La vista de introducir datos estará compuesta por dos secciones: valores globales y valores personales de cada jugador. En el primer caso se introducen valores numéricos de recursos financieros en común, y en el segundo cada jugador introduce cantidades de los productos en posesión. Habrá un botón para confirmar los datos 67 67 Aplicación Android de soporte a un juego de mesa escritos, y al pulsarlo aparecerá la ventana de aviso por si hay algún dato erróneo. Por último, la vista de resumen de la partida, en la que se podrá ver gráficas, volver al menú principal, y subir a la comunidad la partida jugada. A continuación, se muestran unos bocetos de estas interfaces: Figura: 18. Bocetos partida offline y online 3.9.3 Gestión de la comunidad Esta interfaz sólo incluye una vista, y varias ventanas (fragments), que irán variando según la opción que el usuario pulse en un menú. En ella podrá gestionar su perfil, ver el ranking online, ver sus partidas subidas, ver la semilla distribuida disponible y los logros obtenidos. A continuación, se muestra un boceto de esta interfaz: Especificación de requisitos 68 Figura: 19. Boceto vista comunidad 3.9.4 Visualización de manuales Esta interfaz estará compuesta por una sola vista, donde se mostrará distintos documentos en los cuales los jugadores podrán aprender cómo jugar y cómo utilizar la aplicación. Estos documentos serán archivos pdf embebidos en el programa. A continuación, se muestra un boceto de esta interfaz: Figura: 20. Boceto visualización de manuales 69 69 Aplicación Android de soporte a un juego de mesa 4 DISEÑO DEL SISTEMA partir de la Especificación de Requisitos del sistema, el siguiente paso es diseñar la aplicación. En este capítulo explicaremos, de forma estructurada y con la ayuda de diagramas UML, los distintos subsistemas del proyecto. El diseño se ha organizado por casos de uso. Empezaremos desde un punto de vista más general, veremos cómo gestiona la aplicación el acceso a los distintos módulos (gracias a la pantalla del menú principal), y continuaremos reduciendo el nivel de abstracción para diseñar más detenidamente cada subsistema. Debemos resaltar que se ha utilizado en el diseño los patrones Modelo Vista Controlador y Singleton, como se muestra en los diagramas. En el proyecto Android, la vista estará compuesta por todos los ficheros que representan el layout de la aplicación (son archivos xml), los controladores son todas las clases que gestionan los eventos e interacciones del usuario con el programa (actividades y fragmentos), además de las clases que gestionan las peticiones al servidor y procesar las respuestas. Finalmente, el modelo está compuesto por las clases que definen los datos y aquellas que trabajan directamente con la BBDD local (realizan sentencias sql). Todos los servicios y la clase VolleyApplication siguen el patrón Singleton. Para facilitar la lectura de los diagramas, sólo se mostrará en el primer diagrama de secuencia el intercambio de mensajes para obtener esa instancia, ya que el procedimiento es exactamente el mismo en todos los subsistemas. Además, utilizaremos el patrón Callback para procesar los datos recibidos del servidor, y actualizar dinámicamente la información mostrada en pantalla. Por último, debemos recordar que para poder acceder al servicio web (excepto identificar usuario y registrar), debemos identificar el cliente con el token ClaveAPI, almacenado localmente de forma persistente. 4.1 Diseño global 4.1.1 Diagrama de paquetes En este diagrama podemos ver cómo se divide el sistema, cumpliendo la especificación de requisitos. Figura: 21. Diagrama de paquetes del sistema A Diseño del sistema 70 4.1.1 Diagrama de componentes En esta imagen, hemos querido representar las distintas clases disponibles en la aplicación Android que gestionan las peticiones a servicios web alojados en el servidor. Para ello utilizan la clase VolleyApplication, que gestiona las peticiones HTTP en una cola y las manda. También atiende las respuestas del servidor. Como sabemos, todos los subsistemas que tengan funcionalidad online deberán conseguir la claveAPI. Por eso la clase AlmacenSessionImpl ofrece su interfaz con el método que devuelve esa información. Figura: 22. Diagrama de componentes, servicios web La interfaz REST del api correspondiente a los servicios web, la hemos denominado ServiciosWebOfrecidos. A continuación, se muestra una tabla de esa interfaz, identificando los recursos, url, métodos HTTP y parámetros necesarios para los mensajes POST y UPDATE. Recurso URL Método HTTP Parámetros Registrar usuario https://website/v1/usuario/registro POST {nombre, correo, contrasenia} Autenticar usuario https://website/v1/usuario/login POST {correo, contrasenia} Cambiar contraseña https://website/v1/usuario/cambiarContrasenia UPDATE {contrasenia nueva} Partidas subidas https://website/v1/partida/partidasSubidas GET - Ranking https://website/v1/partida/ranking GET - 71 71 Aplicación Android de soporte a un juego de mesa Partida https://website/v1/partida/#id POST GET DELETE {fecha, numrondas, nombreganador, numjugadores, puntuacionganador} Actualizar fecha conexión https://website/v1/usuario/actualizarConexion UPDATE {fecha} Logros https://website/v1/logro/obtenerLogros GET - Logro https://website/v1/logro/#id GET - Semillas https://website/v1/semilla/obtenerSemillas GET - Partidas Online https://website/v1/partidaonline/partidasOnline GET - Partida online https://website/v1/partidaonline/crearPartidaOn line/#id POST GET DELETE {nombreanfitrion, fecha, numrondas, numjugadores max} Jugador online https://website/v1/jugadoronline/jugadorOnline /#id POST GET DELETE {estado, isanfitrion, idPartidaOnline} Estado de la partida online https://website/v1/partidaonline/estadoPartidaO nline/#id UPDATE GET {estado} Jugadores online https://website/v1/jugadoronline/jugadoresOnli ne GET - Obtener identificadores online https://website/v1/jugadoronline/idsOnline GET - Estado del jugador online https://website/v1/jugadoronline/estadoJugador Online/#id GET UPDATE {estado} Diseño del sistema 72 4.1.2 Diagramas de clases En esta figura se representa el modelo de datos de la aplicación: atributos, métodos y relaciones entre ellos. Figura: 23. Diagrama de clases del sistema Debido a las peculiaridades de este proyecto (es una aplicación Android) es necesario especificar clases específicas de este tipo de desarrollos. Una actividad (Activity) es el controlador de la pantalla que visualiza el usuario en su dispositivo, mientras que un fragmento (Fragment) ocupa sólo una parte de ésta (como por ejemplo diálogos y ventanas emergentes). En la siguiente figura podemos ver todas las clases que heredan de este tipo de clases. 73 73 Aplicación Android de soporte a un juego de mesa Figura: 24. Diagrama de clases del sistema, herencias Aquellas clases con el estereotipo utility no gestionan elementos del modelo o de la vista, únicamente trabajan con otras clases del estereotipo controlador. Por lo tanto, no podemos catalogarla dentro del patrón MVC. Realizarán tareas varias como creación de subprocesos e hilos, o gestionar peticiones y respuestas HTTP. Figura: 25. Diagrama de clases del sistema, vista Diseño del sistema 80 4.1.5.2 Diagramas de objetos Figura: 32. Diagrama de objetos de partida offline en proceso En el siguiente diagrama muestra un momento concreto de una partida que está en proceso, con dos jugadores en la partida y sus respectivas puntuaciones. También hay activa una semilla, que afectará en las variables de la partida (en este caso planDePensiones). También tenemos un evento instanciado, con dos atributos. 81 81 Aplicación Android de soporte a un juego de mesa 4.1.5.3 Diagramas de actividad Figura: 33. Diagrama de actividad de partida offline En este diagrama se muestra la secuencia ordenada de las distintas actividades del sistema cuando el usuario entra en el módulo Partida offline y juega la partida. Podemos ver que cuando se inicia el temporizador, no pasamos a la siguiente actividad hasta que se haya acabado el tiempo, pero como se realiza en otro subproceso, el subsistema espera una señal para pasar al siguiente paso (lo que hace el subproceso es llamar a un método del proceso original). 4.1.5.4 Diagramas de secuencia A continuación, se representan los diagramas de secuencia de este módulo del sistema. Podemos ver claramente las clases organizadas según su estereotipo del patrón MVC. Aunque en estas imágenes aparecen todas las clases de la vista equivalente a cada actividad y fragmento (los layouts), en los diagramas de secuencia de los siguientes apartados se simplificará para hacer más limpio el diseño. Diseño del sistema 82 Figura: 34. Diagrama de secuencia de partida offline, primera parte Esta primera parte abarca desde que alguien entra en este módulo hasta cuando se guardan las puntuaciones de los jugadores. El servicio utilizado para almacenar y obtener datos de la BBDD local será PartidaServiceImpl. Cuando de crea una instancia del temporizador, toda la carga principal de su comportamiento de aloja dentro de doinBackground(), que a su vez se ejecuta en un proceso aparte, evitando que la aplicación se bloquee. La clase Escenario le ofrece un método callback para avisar del progreso del temporizador. Podemos ver dos bucles, el interno representa en transcurso de la serie de eventos que compone una ronda (variable del sistema), y el externo las rondas de la partida (variable modificable por el usuario). 83 83 Aplicación Android de soporte a un juego de mesa Figura: 35. Diagrama de secuencia de partida offline, segunda parte Partiendo del diagrama anterior, en este se muestra el final de la partida. Si el jugador quiere compartir la partida, la actividad correspondiente se comunica con el servicio que manda la petición al servidor. Finalmente, cuando se sale de la partida, vaciamos los datos almacenados en la BBDD local y se ejecuta automáticamente onDestroy(). 4.3.2 Gestión de partida online 4.1.5.5 Diagramas de clase Figura: 36. Diagrama de clases del modelo de partida online Diseño del sistema 84 En esta imagen vemos el tipo de clases que se utilizarán para el modelo. Ambas son hijas de una clase padre debido a su gran similitud, de esta manera nos ahorramos tener que repetir atributos y comportamientos redundantes. Figura: 37. Diagrama de clases de partida online Como podemos apreciar, algunos servicios implementan el método llamado parseJson(). Como sabemos del ERS, la información transmitida en mensaje http entre cliente-servidor utiliza la estructura JSON. Debido a esto, los servicios necesitan una herramienta para decodificar la información y convertirla en un objeto de nuestro sistema. Gracias a que nuestro modelo respeta la arquitectura de las tablas de la BBDD remota, esta conversión es más sencilla (todas las columnas de la tabla están representadas como atributos en nuestro modelo). 85 85 Aplicación Android de soporte a un juego de mesa 4.1.5.6 Diagramas de objetos Este diagrama muestra el momento concreto de una partida online iniciada, creada el 09-11-2018, con dos jugadores online participando, y uno de ellos (el de idJugador igual a 2) siendo el anfitrión. Figura: 38. Diagrama de objetos de partida online iniciada Diseño del sistema 86 4.1.5.7 Diagramas de actividad Figura: 39. Diagrama de actividad de partida online En esta figura se muestra de principio a fin la serie de actividades que realiza el usuario con la aplicación (y las tareas internas del sistema) de una partida online. Cada vez que la aplicación realiza una actividad que conlleva enviar una petición al servidor, su siguiente actividad no se realiza hasta que no haya recibido un mensaje de respuesta, por lo tanto, se utiliza un método callback para gestionar esa respuesta y continuar con la secuencia de acciones. Esta peculiaridad se produce siempre que hacemos uso de un servicio web y queremos procesar la respuesta (en los diagramas de secuencia se verá con más detalle). 87 87 Aplicación Android de soporte a un juego de mesa 4.1.5.8 Diagramas de secuencia Figura: 40. Diagrama de secuencia de partida online, primera parte Este diagrama muestra el intercambio de mensajes cuando un usuario entra en la actividad principal Partida Online, donde podrá crea una partida o unirse a una partida ya creada por otra persona. Aquí entra en escena la clase VolleyApplication. Permite mandar peticiones asíncronas al servidor, pudiendo controlar cuando nos llegue la respuesta. Podemos apreciar que la llamada a esta clase se realiza con un mensaje asíncrono. En el servicio correspondiente, ya se le indica el método callback para recoger y gestionar la respuesta desde el controlador. Por último, explicamos cómo funcionan los gestores de estado. Como vemos, es un subproceso que se ejecuta indefinidamente, y en otro proceso distinto al principal. Éste manda peticiones periódicas al servidor preguntando por los jugadores online (o partidas online) que tienen el estado indicado. El gestor se eliminará cuando no esté en primer plano la actividad que lo llama, o si es eliminada. Diseño del sistema 88 Figura: 41. Diagrama de secuencia de partida online, segunda parte En esta segunda parte, se muestra los mensajes intercambiados cuando el jugador ya se encuentra dentro de una partida. En esta pantalla podrá ver los jugadores unidos a la partida y si están preparados o no (la información se muestra dinámicamente gracias al uso de los gestores de estado). En caso de que el estado de todos los participantes sea Preparado, dará comienzo la partida arrancando la primera ronda (se mostrará la actividad EscenarioOnline). 4.1.5.9 Diagramas de estado Como hemos visto en el diagrama de clases, las clases JugadorOnline y PartidaOnline tienen una relación fuerte, por lo tanto, si una partida online es eliminada, también serán eliminados aquellos jugadores online referenciados. Una partida online es eliminada cuando el jugador marcado como Anfitrión sale de la partida, o cuando ésta ha finalizado. 89 89 Aplicación Android de soporte a un juego de mesa Figura: 42. Diagrama de estados de partida online, JugadorOnline Figura: 43. Diagrama de estados de partida online, PartidaOnline Diseño del sistema 96 Figura: 50. Diagrama de secuencia de comunidad, ranking y mis partidas En este caso, en realidad estamos mandando peticiones al servidor sobre el mismo tipo de recurso (partida). Sin embargo, accedemos a servicios web distintos que nos devuelven la información solicitada. De forma muy parecida en otras secciones, cuando recibimos los datos, los decodificamos y a continuación llamamos a un método callback del controlador para que actualice la información mostrada en pantalla. 97 97 Aplicación Android de soporte a un juego de mesa Figura: 51. Diagrama de secuencia de comunidad, perfil Esta imagen muestra los mensajes intercambiados cuando el usuario accede a la sección Perfil. En este caso, la información mostrada no requerirá mandar ninguna petición al servidor ya que los datos a mostrar ya se obtuvieron cuando inició sesión (y fueron almacenados de forma persistente). Sin embargo, si desea cambiar la contraseña, la aplicación sí mandará la petición correspondiente al servidor (con la nueva contraseña). Diseño del sistema 98 4.3.4 Consulta de instrucciones y manual de usuario 4.1.5.14 Diagramas de clases Figura: 52. Diagrama de clase de instrucciones y manual Este diagrama muestra las clases controlador del subsistema, y sus relaciones. 99 99 Aplicación Android de soporte a un juego de mesa 4.1.5.15 Diagramas de actividad Figura: 53. Diagrama de actividad de instrucciones y manual En este diagrama podemos ver la secuencia de acciones cuando el usuario quiere visualizar las instrucciones o el manual. Se puede deducir que la aplicación sólo muestra uno de los dos. Diseño del sistema 100 4.1.5.16 Diagramas de secuencia Figura: 54. Diagrama de secuencia de instrucciones y manual En el siguiente diagrama se muestran los mensajes intercambiados cuando el usuario quiere visualizar las instrucciones o el manual. Cuando selecciona una opción, se lanza la actividad correspondiente. Automáticamente, cuando esta se crea, muestra el documento pdf gracias a displayPDF(). 101 101 Aplicación Android de soporte a un juego de mesa 4.3.5 Servidor remoto 4.1.5.17 Diagramas de clase Figura: 55. Diagrama de clases de servidor remoto En el servidor remoto, los controladores tienen el mismo nombre de las tablas de la BBDD remota que gestionan. Todas las respuestas enviadas por el servidor tienen la misma estructura JSON, la cual está definida en la clase VistaJson. Implementación 102 5 IMPLEMENTACIÓN ontinuando con el ciclo de vida del desarrollo software, en este capítulo tratamos la implementación del sistema, que corresponde la programación de la aplicación software y la codificación de los servicios web. 5.1 Arquitectura del Proyecto En este apartado vamos a tratar cómo se ha organizado los proyectos en Android Studio, y el proyecto correspondiente al desarrollo de los servicios web en PhPStorm. La estructura de ambos proyectos toma como referencia el patrón Modelo Vista Controlador (MVC), agrupando las clases y archivos que realizan funciones del mismo rol, generando proyectos modulares y con componentes reutilizables. 5.1.1 Aplicación Android Figura: 56. Arquitectura del proyecto Android En la imagen mostrada se muestra la arquitectura del proyecto de Android Studio. En la carpeta java se encuentran las clases del programa, diferenciadas según su funcionalidad. En la carpeta controllers se encuentran las distintas actividades y fragmentos que gestionan los eventos y elementos de la interfaz de usuario (realizan el rol de controlador). En la carpeta model se sitúan las clases java que representan los distintos tipos de datos específicos de la aplicación, y en services las clases que los gestionan (ambos realizan el rol de modelo). En threads podemos encontrar los hilos que gestionan procesos independientes, y la clase VolleyApplication. Finalmente, en la carpeta res/layout, estarán contenidos los distintos ficheros xml que representan la interfaz de usuario (realizan el rol de vista). En la carpeta res/drawable se almacenan las imágenes e iconos de la aplicación. El fichero C 103 103 Aplicación Android de soporte a un juego de mesa res/values/strings.xml es de gran importancia ya que es un fichero de configuración donde tenemos definidas las url de los servicios web, además de otras cadenas de caracteres que haremos referencia en multitud de componentes del programa. El documento build.gradle ya lo hemos nombrado en el apartado de librerías externas, en él indicamos las dependencias de librerías externas, y otras opciones de configuración de la aplicación. Finalmente, dentro de assets/fonts guardamos las instrucciones y el manual en formato pdf. 5.1.2 El servidor Figura: 57. Arquitectura del proyecto servicios web En la imagen mostrada se representa la estructura del proyecto php correspondiente al desarrollo de los servicios web. Se muestra claramente el rol de los distintos documentos ya que se han agrupado con este propósito. Debemos indicar que cada clase php de controladores representa una tabla de la base de datos del servidor. El archivo index.php redireccionará la petición, según el recurso requerido, a la clase controladora de ese recurso. El objetivo del documento .htaccess es indicar que se realice un redireccionamiento a index.php. Implementación 104 5.2 La aplicación Financial Game A continuación, se explica con detalle la aplicación desarrollada, su funcionamiento y opciones que ofrece. Esta información también se mostrará en el documento Manual de Usuario ubicado en el programa, el cual los usuarios podrán visualizar libremente. 5.2.1 Acceder a las funciones online Antes de empezar y explicar los apartados más importantes de la aplicación, debemos resaltar que el programa ofrece un gran número de opciones online como compartir una partida, ver información de perfil, seleccionar un escenario preestablecido, ránking, etc. Para todo ello, es fundamental estar registrado. 5.2.2 Crear una cuenta Para crear una cuenta en Financial Game, únicamente se necesita un correo válido, contraseña y nombre de usuario. No se olvide del correo introducido y contraseña ya que son las credenciales para luego iniciar sesión. En la pantalla principal, seleccione en el símbolo de Usuario situado en la esquina superior izquierda. Aparecerá el diálogo de iniciar sesión. Pulse en REGISTRAR y le aparecerá el siguiente diálogo: Figura: 58. GUI Crear cuenta Introduzca los datos requeridos y confirme. Si todo ha ido bien, aparecerá un pequeño mensaje confirmando la acción. Ahora sólo tiene que iniciar sesión y disfrutar de la experiencia que ofrece Financial Game. 5.2.3 Menu principal Al menú principal se accederá automáticamente después de una pantalla de carga inicial. En esta sección, podrás:  Acceder a las opciones de iniciar sesión y registro.  Iniciar una partida offline.  Iniciar una partida online.  Entrar en la comunidad online de Financial Game.  Ver los manuales de la aplicación (instrucciones y manual de usuario). Recuerde que, para acceder a la comunidad y a las partidas online, deberá estar registrado e identificado. Figura: 59. GUI Menu principal 105 105 Aplicación Android de soporte a un juego de mesa 5.2.4 Partida offline 5.2.4.1 Iniciar partida En esta pantalla, deberán introducir los nombres de los participantes y el número de rondas de la partida. Podrá visualizar los jugadores registrados según se introducen. Finalmente, para comenzar la partida, pulse en el botón Play. 5.2.4.2 Escenario En esta pantalla la ronda ya ha sido iniciada, podrán ver los jugadores un ránking de las puntuaciones de cada jugador. Para iniciar temporizador pulsar en el botón Play. El temporizador está representado en un diálogo emergente, mostrando una barra de avance según pase el tiempo. Recuerde que es un período aleatorio, por lo tanto, no dudéis mucho en vuestras acciones. Al finalizar el temporizador, se activará un sonido para avisar a todos los jugadores. Al finalizar el temporizador, aparecerá un diálogo con un evento. Después de realizar las acciones requeridas, podrán cerrarlo pulsando en el botón Cerrar o bien fuera de la ventana. Figura: 60. GUI Iniciar partida offline Figura: 61. GUI Escenario 1 Figura: 62. GUI Escenario 2 Plan de pruebas 112 El plan de pruebas se organizará según los subsistemas definidos. El encargado de realizar las pruebas hará el papel del actor Usuario, y modificará los valores de número de rondas y el intervalo del temporizador para agilizar el proceso. Finalmente, se propondrá pruebas de aceptación para que el cliente pueda comprobar si el software cumple las expectativas. 6.1 Gestión de partida offline CP-01 Inicializar partida Descripción: Se probará que los participantes puedan introducir sus nombres, elegir número de rondas y que se crea una partida con esa información. Casos de uso asociados: CU04 Prerrequisitos: Disponible la actividad InicializarPartidaOffline. Resultado esperado: Los datos introducidos se almacenan en la BBDD local. CP-02 Temporizador Descripción: Se probará que la actividad Escenario lance el temporizador en un hilo aparte, obtenga el valor aleatorio comprendido entre el intervalo establecido, y se actualice la barra de avance mostrada en pantalla según avanza el tiempo. Casos de uso asociados: CU02 Prerrequisitos: Disponible la actividad Escenario, y la clase TemporizadorThread implementada. Resultado esperado: Se activa el temporizador y se actualizará correctamente la barra de estado. CP-03 Evento Descripción: Se probará que se muestre un evento en la actividad Escenario. Para ello, el servicio PartidaOfflineService deberá coger de la BBDD local un objeto de la clase evento, y devolvérselo al controlador. Casos de uso asociados: CU02 Prerrequisitos: Disponible la actividad Escenario, el servicio PartidaOfflineService implementado y también la clase Evento. 113 113 Aplicación Android de soporte a un juego de mesa Resultado esperado: Se muestra en pantalla el evento elegido, con sus atributos asociados. CP-04 Guardado de las puntuaciones introducidas Descripción: Se probará que los datos introducidos en la actividad IntroducirDatos se guarden en la BBDD local, y se asocien correctamente al jugador deseado. Casos de uso asociados: CU03 Prerrequisitos: Disponible la actividad IntroducirDatos, y el servicio PartidaOfflineService implementado. Resultado esperado: Las puntuaciones de cada jugador se almacenan correctamente en la BBDD local, y corresponden con los escritos. CP-05 Cambios debido a la semilla elegida Descripción: Se probará que, cuando un jugador introduce sus datos, si hay alguna variable afectada (un producto financiero) por la semilla distribuida ésta cambia al valor especificado. Casos de uso asociados: CU06 Prerrequisitos: Disponible la actividad IntroducirDatos, implementado el servicio PartidaOfflineService. Resultado esperado: Los valores de los productos financieros afectados por la semilla se modifican, y se aplican en el cómputo de la puntuación total del jugador. CP-06 Visualización de las gráficas de la partida Descripción: Se probará que se representen correctamente las gráficas que muestran información de la partida finalizada. Deben de poder verse las rondas jugadas, las puntuaciones totales de cada jugador, y el valor de cada producto financiero que la componen. Casos de uso asociados: CU05 Prerrequisitos: Disponible la actividad GraficasJugadores, implementado el servicio PartidaOfflineService, disponibles los fragmentos LineGraphFragment y Plan de pruebas 114 PieGraphFragment. Resultado esperado: Se mostrará las gráficas con la información correcta, y permitirá poder navegar entre sus opciones. CP-07 Partida compartida Descripción: Se probará que un usuario puede subir al servidor la partida offline jugada. Casos de uso asociados: CU07 Prerrequisitos: Actividad GraficasJugadores disponible, servicio PartidaOfflineService implementado, servicio PartidaService implementado, el servicio web ofrecido por el servidor probado y funcionando. Resultado esperado: Se subirá al servidor la partida deseada, creándose un nuevo registro en la tabla Partida de la BBDD remota. 6.2 Gestión de partida online CP-08 Incorporación de jugador a la partida Descripción: Se probará que el usuario se incorpore a la partida online seleccionada. Casos de uso asociados: CU09 Prerrequisitos: Actividad PrincipalPartidaOnline disponible, servicio PartidaOnlineService implementado, las clases PartidaOnline y JugadorOnline desarrolladas, el servicio web ofrecido por el servidor probado y funcionando. Resultado esperado: El usuario se unirá a la partida esperada, pasando a la siguiente actividad PartidaOnlineInicializada, y creándose su respectivo jugador en la tabla JugadorOnline. CP-09 Crear partida online Descripción: Se probará que un usuario pueda crear una partida online, introduciendo una serie de parámetros como el número de rondas y el número de jugadores máximos permitidos. 115 115 Aplicación Android de soporte a un juego de mesa Casos de uso asociados: CU10 Prerrequisitos: Actividad PrincipalPartidaOnline disponible, fragment CrearPartidaOnlineFragment disponible, servicio PartidaOnlineService implementado, las clases PartidaOnline y JugadorOnline desarrolladas, el servicio web ofrecido por el servidor probado y funcionando. Resultado esperado: Se registrará en la BBDD remota la nueva partida online, con los parámetros deseados. CP-10 Recarga dinámica de las partidas disponibles Descripción: Se comprobará que la lista de partidas online disponibles, mostrada en la actividad PrincipalPartidaOnline, se recargue dinámicamente, actualizándose la información periódicamente. Casos de uso asociados: CU09 Prerrequisitos: Actividad PrincipalPartidaOnline disponible, servicio PartidaOnlineService implementado, la clase PartidaOnline desarrollada, el gestor GestorEstadoPartidaOnline desarrollado, el servicio web ofrecido por el servidor probado y funcionando. Resultado esperado: Periódicamente, el gestor envía una petición preguntando por las partidas online creadas, y con esa información se actualizará el listado. CP-11 Inicio de la partida Descripción: Se comprobará que no se empieza la partida online hasta que todos los jugadores estén preparados. Casos de uso asociados: CU10 Prerrequisitos: La actividad PartidaOnlineInicializada disponible, el servicio JugadorOnlineServide programado, la clase JugadorOnline desarrollada, el gestor GestorEstadoJugadorOnline implementado, el servicio web ofrecido por el servidor probado y funcionando. Resultado esperado: No se mostrará la actividad Escenario online en el dispoitivo de los jugadores hasta que no estén todos preparados. Plan de pruebas 116 6.3 Gestión de la comunidad CP-12 Iniciar sesión Descripción: Se probará que, desde la aplicación, e introduciendo los datos requeridos, pueda iniciar sesión una persona. En caso de introducir datos erróneos, deberá mostrarse un mensaje emergente en la pantalla. Además, en caso positivo, deberá almacenarse en local la información de usuario. Casos de uso asociados: CU19 Prerrequisitos: La actividad MenuPrincipal disponible, el fragment IniciarSesionFragment disponible, los servicios UsuarioService y AlmacenSession desarrollados, la clase Usuario programada, el servicio web ofrecido por el servidor probado y funcionando. Resultado esperado: Una persona podrá identificarse en caso de introducir datos correctos, se capturará la respuesta del servidor, y se almacenará la información del usuario en el archivo de preferencias. CP-13 Registrar usuario Descripción: Se probará que una persona pueda registrar un nuevo usuario, escribiendo el correo, nombre y contraseña. Para ello, el correo introducido deberá estar en un formato correcto ([email protected]). Casos de uso asociados: CU20 Prerrequisitos: La actividad MenuPrincipal disponible, el fragment IniciarSesionFragment disponible, el servicio web ofrecido por el servidor probado y funcionando. Resultado esperado: En caso de introducir un correo con formato no válida, aparecerá un mensaje de error. En caso positivo, aparecerá mensaje confirmando la acción y en la BBDD remota aparecerá el nuevo registro en la tabla Usuario. CP-14 Ver perfil del usuario Descripción: Se comprobará que al acceder a la actividad Comunidad, por defecto aparezca la información de perfil del usuario identificado. 117 117 Aplicación Android de soporte a un juego de mesa Casos de uso asociados: CU21 Prerrequisitos: La actividad Comunidad disponible, el fragmento PerfilFragment disponible, el sevicio AlmacenSession implementado, la clase Usuario desarrollada. Resultado esperado: Se muestra la información de perfil del usuario. CP-15 Ver ranking Descripción: Se probará que al entrar en la sección Ranking de la actividad Comunidad, se muestre el ranking obtenido de la respuesta de la petición correspondiente al servidor. Casos de uso asociados: CU22 Prerrequisitos: La actividad Comunidad disponible, el fragment RankingFragment disponible, el servicio PartidaService implementado, la clase Partida desarrollada, el servicio web ofrecido por el servidor probado y funcionando. Resultado esperado: Se capturará la respuesta del servidor, cogemos el listado de partidas que compone el ranking, y se mostrará en la pantalla. CP-16 Semilla distribuida Descripción: Se probará que la entrar en la sección Escenario preestablecido de Comunidad se muestra un listado con todas las semillas disponibles. Además, al pulsar en una, se almacena en local la información de ésta. Casos de uso asociados: CU08 Prerrequisitos: La actividad Comunidad disponible, el fragment SemillaFragment disponible, los servicios SemillaService y AlmacenSession implementados, la clase Semilla desarrollada, el servicio web ofrecido por el servidor probado y funcionando. Resultado esperado: Se representarán en la pantalla el listado de semillas disponible, además al pulsar sobre una, se guardará su información en el archivo de preferencias. Plan de pruebas 118 CP-17 Logros Descripción: Se probará que la entrar en la sección Logros de Comunidad se muestra un listado con todos los logros disponibles, agrupados según el tipo. Casos de uso asociados: CU23 Prerrequisitos: La actividad Comunidad disponible, el fragment LogroFragment disponible, el servicio LogroService implementado, la clase Logro desarrollada, el servicio web ofrecido por el servidor probado y funcionando. Resultado esperado: El usuario podrá ver sus logros obtenidos, para ello capturamos la respuesta del servidor y cogemos el listado de logros devueltos. 6.4 Consulta de instrucciones y manual de usuario CP-18 Visualizar manuales Descripción: Se probará que una persona pueda acceder a las actividades Instrucciones y ManualDeUsuario desde el menú principal de la aplicación. Casos de uso asociados: CU36, CU37 Prerrequisitos: Las actividades MenuPrinicipal, Intrucciones y ManualDeUsuario disponibles, documentos pdf de prueba almacenados en la carpeta resources del proyecto Android. Resultado esperado: Se podrá seleccionar una de las dos opciones desde el menú principal y se redirigirá automáticamente a la actividad, se mostrará el documento elegido, navegar por él y hacer zoom. 6.5 Servidor de la aplicación CP-19 Usuario registrado Descripción: Se probará que, con la herramienta Advanced REST client, el servicio web correspondiente a registrar usuario funcione correctamente, registrando en la BBDD remota el nuevo usuario introducido. Para ello debemos indicar la URL del recurso y p oner los valores en el cuerpo del 119 119 Aplicación Android de soporte a un juego de mesa mensaje http en formato JSON (correo, nombre, contraseña). Casos de uso asociados: CU29, CU30, CU31 Prerrequisitos: Servicio web del registro desarrollado y activo en el servidor. Resultado esperado: Se creará un nuevo registro en la tabla Usuario con los datos mandados en la petición. CP-20 Identificar usuario Descripción: Se probará que, con la herramienta Advanced REST client, el servicio web correspondiente a identificar usuario funcione correctamente, recibiendo del servidor la respuesta con la información del usuario. Para ello debemos indicar la URL del recurso y poner los valores en el cuerpo del mensaje http en formato JSON (correo, contraseña). Casos de uso asociados: CU32, CU33 Prerrequisitos: Servicio web del usuario desarrollado y activo en el servidor. Resultado esperado: En caso de introducir un correo o contraseña erróneos, recibir mensaje de error. Si ponemos correo y contraseña existentes, recibiremos una respuesta confirmando la acción y con la información del usuario. CP-21 Servicio Logro Descripción: Se probará, con la herramienta Advanced REST client, el servicio web correspondiente a obtener los logros del usuario. Para ello debemos indicar la URL del recurso e indicar en la cabecera del mensaje http el parámetro authorization con valor una claveAPI. Casos de uso asociados: CU28 Prerrequisitos: Servicio web de logro desarrollado y activo en el servidor. Resultado esperado: En caso de enviar una claveAPI que no pertenece a ningún usuario del sistema, el servidor responderá con un error. En caso contrario, recibiremos el listado de logros de ese usuario en formato JSON. Plan de pruebas 120 CP-22 Servicio Semilla Descripción: Se probará, con la herramienta Advanced REST client, el servicio web correspondiente a obtener las semillas registradas en la BBDD remota. Para ello debemos indicar la URL del recurso e indicar en la cabecera del mensaje http el parámetro authorization con valor una claveAPI. Casos de uso asociados: CU26 Prerrequisitos: Servicio web de la semilla desarrollado y activo en el servidor. Resultado esperado: En caso de enviar una claveAPI que no pertenece a ningún usuario del sistema, el servidor responderá con un error. En caso contrario, recibiremos el listado de semillas en formato JSON. CP-23 Servicio partida Descripción: Se probará, con la herramienta Advanced REST client, los servicios web correspondientes a subir partida, obtener partida y borrar partida. Para ello debemos indicar la URL del recurso e indicar en la cabecera del mensaje http el parámetro authorization con valor una claveAPI. En caso de subir una partida debemos indicar en el cuerpo del mensaje http los datos de ésta, y si queremos borrarla el identificador. Casos de uso asociados: CU27 Prerrequisitos: Servicios web de la partida desarrollado y activo en el servidor. Resultado esperado: En caso de enviar una claveAPI que no pertenece a ningún usuario del sistema, el servidor responderá con un error. Si queremos borrar una partida e indicamos un identificador no válido, también recibiremos un error. Si no, deberemos obtener una respuesta positiva. CP-24 Servicio partida online Descripción: Se probará, con la herramienta Advanced REST client, el servicio web correspondiente a obtener las partidas online con el estado indicado. Para ello, en el cuerpo del mensaje http debemos indicar el estado buscado. 121 121 Aplicación Android de soporte a un juego de mesa Casos de uso asociados: CU16 Prerrequisitos: Servicio web de partida online desarrollado y activo. Resultado esperado: En caso de enviar una claveAPI que no pertenece a ningún usuario del sistema, el servidor responderá con un error. En caso contrario, recibiremos las partidas online registradas en la BBDD con identificador igual al indicado. CP-25 Servicio jugador online Descripción: Se probará, con la herramienta Advanced REST client, el servicio web correspondiente a crear un jugador online, y el servicio web correspondiente a obtener los jugadores online unidos a la misma partida online que el usuario. Para crear el jugador, debemos indicar en el cuerpo del mensaje http el identificador de la partida online a la que queremos unirnos. Casos de uso asociados: CU15 Prerrequisitos: Servicio web de jugador online desarrollado y activo. Resultado esperado: En caso de enviar una claveAPI que no pertenece a ningún usuario del sistema, el servidor responderá con un error. Si indicamos el identificador de una partida online que no existe, también recibiremos un error. Si no, se creará correctamente el jugador online (relacionándolo con la partida indicada), y recibiremos un listado en formato JSON con los jugadores si mandamos petición a ese servicio web. CP-26 Comprobación de logros Descripción: Se probará que, cuando subimos una partida al servidor, se le pasará por una serie de filtros para comprobar si cumple con los requisitos de algún logro. En caso positivo, debe crearse ese logro y asociarlo al usuario que compartió la partida. Casos de uso asociados: CU35 Prerrequisitos: Servicio web de jugador online desarrollado y activo, servicio web de subir partida probado y funcionando. Conclusiones 128 8.2 Línea futura de desarrollo Hay una serie de pasos claros que han quedado pendientes en el trabajo, que aumentarán el valor del producto y harán el sistema creado más sólido y profesional. El primero es el de migrar los servicios web a un servidor de pago, que satisfaga los requisitos, para que cualquiera que se descargue la aplicación pueda acceder a las funciones online que ofrece. Sería buena idea crear un sitio web en Hostinguer (https://www.hostinger.es/), que ofrece una gran variedad de subscripciones según las necesidades de cada persona. Actualmente, los servicios web se encuentran alojador en un portal web con suscripción gratuita, con limitaciones importantes como no permitir peticiones HTTP de tipo UPDATE y DELETE, comprometiendo el correcto funcionamiento de secciones claves del sistema. El segundo paso, y el que pondría a la vanguardia de las aplicaciones móviles distribuidas el programa, es agregar FireBase a nuestro proyecto. FireBase es una plataforma para el desarrollo de aplicaciones web y aplicaciones móviles distribuidas de Google. Ofrece una gran cantidad de servicios, como la posibilidad de ofrecer datos estadísticos sobre el uso de la aplicación, almacenamiento en la nube, hosting, y enviar mensajes orientados a los clientes (notificaciones push). Esta última característica sería la más interesante para nosotros, ya que la carga de trabajo en las partidas online se reduciría drásticamente en los clientes (actualmente mandan peticiones periódicamente preguntado por el estado) y el servidor (tiene que procesar y responderlas), de esta manera sería el servidor quien avisa a los consumidores sobre un evento, y éstos actuarían en consecuencia. Pero para utilizar esta ventaja, habría que modificar el sistema de identificación, autorización y registro por el impuesto por la plataforma nueva, e integrar también FireBase en los servicios web. Este paso requiere de mucho tiempo que no se ha dispuesto durante el transcurso del trabajo fin de carrera, pero se propone para una futura versión comercial del sistema. El tercer paso sería terminar el módulo de Partida Online, ya que debido a la falta de tiempo (y la envergadura del proyecto), sólo se consiguió implementar las tres primeras pantallas (creación, inicialización y escenario online). Esta mejora está muy relacionada con lo comentado en el párrafo anterior, ya que la implementación de FireBase en el sistema hará posible el desarrollo de esta funcionalidad. El cuarto paso corresponderá localizar la aplicación en distintos idiomas (originalmente sólo está en español), siendo el prioritario el inglés, seguido del francés y alemán. Por último, sería deseable programar el software de manera que sea compatible con más formatos de pantalla y resolución, además de permitir la orientación horizontal de la pantalla (muy útil en dispositivos tablet). 8.3 Conclusión La realización de este trabajo fin de grado ha sido una gran oportunidad para profundizar en los conceptos aprendidos en la carrera, relacionados con la rama de telemática. Es más, he obtenido nuevos conocimientos sobre tecnologías que me eran totalmente desconocidas. Soy consciente del rumbo que toma la sociedad, consumiendo cada vez más aplicaciones móviles, más complejas, atractivas visualmente e integradas en una comunidad online que permita a las personas interactuar con otras. Sin embargo, la codificación del sistema implementado ha sido posible gracias al trabajo de ingeniería de software realizado. La especificación de requisitos me ha permitido mejorar mis habilidades para entender las exigencias del cliente y estructurar bien las necesidades y objetivos que debe cumplir un software. Además, ha sido la primera vez que he tenido que hacer el diseño de una aplicación Android, resultando un proceso muy pedagógico. En conclusión, este proyecto me ha brindado experiencia en el desarrollo de aplicaciones Android distribuidas que considero muy valiosa, he profundizado en conceptos vistos en el grado como las tareas del desarrollo software, y me ha convertido en una persona más competente en el ámbito del desarrollo de aplicaciones móviles distribuidas. 129 129 Aplicación Android de soporte a un juego de mesa REFERENCIAS BIBLIOGRÁFICAS [1] Isabel Roman Martinez, Apuntes de la asignatura Ingeniería de Software, Departamento de Ingeniería Telemática, Universidad de Sevilla. [2] Jose Manuel Fornés Rumbao, Apuntes de la asignatura Diseño de aplicaciones móviles, Departamento de Ingeniería Telemática, Universidad de Sevilla. [3] Roberto Montero Miguel, 2014, Guía Práctica de Java 8, Madrid, Anaya Multimedia. [4] Jesús Tomás, 2017, El gran libro de Android, Tercera edición, Barcelona, Marcombo. [5] Wikipedia. Recuperado 15 de junio2018, desde https://es.wikipedia.org/wiki/MagicDraw_UML [6] WebHost. Recuperado el 15 de junio de 2018, desde https://www.000webhost.com/ [7] Hermosa Programación. Recuperado el 15 de junio de 2018, desde http://www.hermosaprogramacion.com/2015/10/servicio-web-restful-android-php-mysql-json/ [8] Codictados. Recuperado el 15 de junio de 2018, desde http://codictados.com/volley-web-services-para-principiantes/ [9] Hermosa Programación. Recuperado el 15 de junio de 2018, desde http://www.hermosaprogramacion.com/2015/02/android-volley-peticiones-http/ [10] Carlos Azaustre. Recuperado el 15 de junio de 2018, desde https://carlosazaustre.com/que-es-la-autenticacion-con-token/ [11] Android Developers. Recuperado el 15 de junio de 2018, desde https://developer.android.com/studio/publish/?hl=es-419 [12] Android Developers. Recuperado el 15 de junio de 2018, desde https://developer.android.com/guide/components/fragments?hl=es-419 [13] Android Developers. Recuperado el 15 de junio de 2018, desde https://developer.android.com/reference/android/app/Activity [14] Junta de Andalucía, MADEJA. Recuperado el 15 de junio de 2018, desde http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/407 [15] Hermosa Programación. Recuperado el 15 de junio de 2018, desde http://www.hermosaprogramacion.com/2016/06/android-push-notifications-firebase-cloud-messaging/ [16]Firebase. Recuperado el 15 de junio de 2018, desde http://www.hermosaprogramacion.com/2016/06/android-push-notifications-firebase-cloud-messaging/ [17] travijuu/NumberPicker. GitHub. Recuperado el 15 de junio de 2018, desde https://github.com/travijuu/NumberPicker [18] Google/Volley. GitHub. Recuperado el 15 de junio de 2018, desde https://github.com/google/volley Referencias bibliográficas 130 [19] PhilJay/MPAndroidChart. GitHub. Recuperado el 15 de junio de 2018, desde https://github.com/PhilJay/MPAndroidChart [20] barteksc/AndroidPdfViewer. GitHub. Recuperado el 15 de junio de 2018, desde https://github.com/barteksc/AndroidPdfViewer [21] Android Studio. Recuperado el 15 de junio de 2018, desde https://developer.android.com/studio/ [22] Wikipedia. Recuperado el 15 de junio de 2018, desde https://es.wikipedia.org/wiki/JSON 131 131 Aplicación Android de soporte a un juego de mesa GLOSARIO IDE: Entorno de Desarrollo Integrado BBDD: Base de Datos API: Application Programming Interface URL: Uniform Resource Locator CASE: Computer Aided Software Engineering REST: Representational State Transfer SOAP: Simple Object Access Protocol UML: Unified Modeling Language SDK: Software Development Kit GUI: Graphical User Interface