Desarrollo de aplicación para la generación de juegos geográficos a medida

Escuela de Ingeniería Informática Trabajo Fin de Grado Grado en Ingeniería Informática Mención Ingeniería de Software Desarrollo de aplicación para la generación de juegos geográficos a medida Autor: Dª. Cristina Gómez Escribano 2 3 Escuela de Ingeniería Informática Trabajo Fin de Grado Grado en Ingeniería Informática Mención Ingeniería de Software Desarrollo de aplicación para la generación de juegos geográficos a medida Autor: Dª. Cristina Gómez Escribano Tutores: Dª. Yania Crespo González-Carvajal D. Cristian Tejedor García 4 5 Agradecimientos Me gustaría aprovechar este momento para dar las gracias a todos aquellos que me han ayudado durante toda mi formación. A mis abuelos, Juan y María por haber sido y ser los pilares principales de mi desarrollo personal y profesional. A mí tío, Miguel Ángel por haberme ayudado lo máximo posible durante mi carrera como Ingeniera Informática. A mis padres, Juan Antonio y María Inmaculada, por estar ahí siempre. A mi pareja, Javier por ser quien más me ha apoyado durante el desarrollo de este Trabajo de Fin de Grado. Y por último, a todos los profesores que han participado de mi formación como Ingeniera, y en especial a mi tutora Yania, por darme la oportunidad de realizar este proyecto, y por todo lo que me ha enseñado durante estos años. 6 7 Resumen En este documento se describe el desarrollo de una aplicación web social para la creación de juegos geográficos a medida. Se trata de una aplicación, que estará disponible en diferentes dispositivos y navegadores, en la que se puede crear juegos propios, agregar amigos, compartir juegos y logros, y jugar en diferentes modos de juego y en diferentes niveles de dificultad. Este proyecto se ha realizado siguiendo el Proceso Unificado orientado a Educación, que consta de las fases de Inicio, Elaboración, Construcción y Transición. En la fase de Inicio se ha realizado un análisis de la aplicación a nivel de gestión del proyecto, se han desarrollado tareas como la calendarización o la gestión de riesgos. En la fase de Elaboración se ha llevado a cabo la parte de análisis y diseño de la aplicación, con tareas como la especificación de casos de uso o el desarrollo de la arquitectura. En la fase de Construcción se ha desarrollado el código necesario para implementar la aplicación, teniendo en cuenta el análisis previo. Por último, en la fase de Transición se han desarrollado los manuales de usuario e instalación, y las pruebas de la aplicación. Se ha desarrollado una arquitectura basada en microservicios con Spring, y se ha hecho énfasis en definir un diseño de interfaz responsive que permite adaptarse a diferentes formatos y tamaños de pantalla. Se ha documentado un riguroso plan de pruebas tanto de la funcionalidad como de la portabilidad entre diferentes navegadores y sistemas operativos. 8 9 Abstract This document describes the development of a social website application intended to customize geographic games. The application allows you to create your own games, to join friends, to share games and achievements and to play different game modes at different levels of difficulty. It will also be available on different devices and browsers. This project has been developed following the Unified Process for Education, which is formed by phases of Inception, Elaboration, Construction and Transition. In the Inception phase, an initial analysis of the application was done at the project management level, tasks such as scheduling or risk management were developed. In the Elaboration phase, the application’s analysis and design was carried out with tasks such as the specification of use cases or architectural design. In the Construction phase, it has been implemented the application’s source code according to previous analysis. Finally, in the Transition phase, the user and installation manuals and application tests were done. The application uses an architecture based on microservices with Spring. The main focus has been put on defining a responsive interface design that allows adapting to different formats and screen sizes. A rigorous test plan for both functionality and portability between different browsers and operating systems has been documented. 16 1.3. Objetivos El objetivo de este proyecto es el desarrollo de una aplicación web social que permita la generación de juegos geográficos a medida, y que esté disponible en diferentes dispositivos y navegadores. Se creará un juego a partir de una serie de puntos geográficos, y se podrá jugar en diferentes modalidades de juego y dificultad, para permitir el aprendizaje al usuario. En base a esto, podemos definir los siguientes objetivos: Objetivos de la aplicación  Desarrollar una aplicación que sea compatible con los principales navegadores: Google Chrome, Microsoft Edge, Mozilla Firefox y Safari.  Diseño de una interfaz atractiva y responsive que se adapte a los diferentes tamaños de dispositivos.  Desarrollo de varios modos de juego, para permitir que cada usuario elija lo que más se adapte a sus necesidades.  Desarrollo de diferentes niveles de dificultad para mejorar el aprendizaje.  Permitir la creación de juegos propios.  Fomentar el aprendizaje a través de la consecución de logros.  Al ser una aplicación social, permitir el envío de solicitudes de amistad a otros usuarios, así como la gestión de la lista de amigos.  Facilitar la compartición de juegos y logros con otros usuarios.  Para potenciar la competitividad entre usuarios, disponer de un ranking por juego. Objetivos de formación  Estudio de OpenStreetMap, Leaflet y Nominatim, para mostrar el mapa al usuario y gestionar la búsqueda y mostrado de los puntos geográficos.  Estudio y aprendizaje del framework Spring: Spring Boot y Spring Security, para la parte servidora y, de AngularJS, para la parte cliente.  Estudio de AngularTranslate, para permitir que la aplicación esté disponible en varios idiomas: Inglés y Español.  Realizar todas las fases y documentación de un proyecto software como preparación para el ejercicio de la profesión 17 1.4. Estado de la cuestión En la actualidad, estamos completamente inmersos en las tecnologías. Los dispositivos electrónicos cada vez están más presentes en nuestra vida diaria, usándose para cosas que nunca hubiéramos imaginado. Muchos, ya pagan con sus teléfonos o relojes inteligentes [3], y se espera que su uso continúe creciendo [4]. Pocos escriben todavía en papel, se toman notas en el teléfono o en el ordenador, de igual forma se estudia a través de internet, a través del ordenador. En muchos colegios, ya están impartiendo clases a través de dispositivos electrónicos, como tablets, y dejando de lado los libros [5]. En mi opinión, todo esto no ha hecho nada más que empezar, y dentro de pocos años, todo estará conectado y no podremos vivir sin un dispositivo electrónico a nuestro lado. Por ello, una forma de adaptarse a los nuevos tiempos y a las nuevas tecnologías es dar la posibilidad de que los usuarios puedan aprender a través de cualquiera de sus dispositivos y en cualquier lugar. Es una buena opción para facilitar el aprendizaje de los niños, dándoles la posibilidad de mejorar y a la vez de divertirse. Permitiendo que puedan aprender jugando e interactuando con sus amigos, y que compitan por ser los mejores en un juego concreto, lo que llevará a que aprendan mucho más sin apenas esfuerzo. Un ejemplo de esto, podría ser la iniciativa que se realizó en un colegio de Zaragoza para el aprendizaje a través de experimentos [6]. En cuanto al uso de la gamificación en la educación, encontramos ventajas y desventajas que hay que valorar. Entre las ventajas que podemos encontrar, destacan: la motivación, para conseguir que los contenidos académicos sean más atractivos, o el trabajo en equipo, ya que se fomenta la cooperación para conseguir un objetivo común [7]. Como principales desventajas, destaca el coste que conlleva este tipo de educación, ya que es costoso preparar este tipo de materiales [8]. Por otro lado, es interesante comentar las diferentes posibilidades que tenemos para el uso de los mapas en las aplicaciones, existen dos fuertes competidores: Google Maps y OpenStreetMaps. Google Maps, es ampliamente conocido y posee grandes cantidades de información de cualquier lugar del mundo, por el contrario OpenStreetMap, sólo dispone de grandes cantidades de información de los lugares más poblados, ya que la información se va completando de forma colaborativa por los editores. En cuanto al coste también encontramos diferencias, ya que OpenStreetMap es libre, mientras que Google Maps, ofrece una cantidad de peticiones gratuitas pero al superarlas sería una plataforma de pago [9]. En nuestra aplicación hemos optado por el desarrollo con la plataforma libre, OpenStreetMap, al tratarse de un proyecto académico. 18 Existen multitud de aplicaciones para aprender geografía. Cada una de ellas proporciona distintas formas de aprendizaje y diferentes funcionalidades. En la Tabla 1.1, podemos observar algunas aplicaciones existentes y sus características. Aplicación Resumen National Giraffic [10] Se trata de una aplicación para móvil que permite aprender los países y capitales del mundo. Dispone de diferentes niveles de dificultad, y de logros. Se trata de colocar los diferentes países en su posición en el mapa, en forma de puzzle. Quiz -Juego de Geografía [11] Se trata de una aplicación Android que permite aprender monumentos, banderas y países, a través de preguntas con opciones. GeoExpert - Geografía Mundial [12] Se trata de una aplicación disponible para móvil, que permite aprender países, montañas, ríos, capitales o banderas, a través de juegos ya creados. Tabla 1.1: Aplicaciones para aprender geografía Por último, destacar que la idea principal para poner en marcha este proyecto proviene del Trabajo de Fin de Grado de Maykel Olivares, quien desarrolló una aplicación Android para la generación de juegos geográficos a medida: http://uvadoc.uva.es/handle/10324/15194. 1.5. Estructura de la Memoria El contenido de la memoria se organiza de la siguiente forma: Capítulo 1: Introducción. En este capítulo se presenta el proyecto. Se ofrece una visión general sobre la aplicación desarrollada, incluyendo el contexto, los objetivos, el estado de la cuestión del tema tratado y, la estructura y contenido de la memoria. Capítulo 2: Elicitación de requisitos y Análisis. Se trata de la fase de análisis de la aplicación. Incluye la definición de los roles de la aplicación, la elicitación de requisitos, la especificación de los casos de uso y el diagrama de clases. Capítulo 3: Plan de Proyecto. En este capítulo se incluye el documento de planificación del proyecto. Se describen las tareas a realizar, su calendarización, la metodología utilizada en el proceso de desarrollo, la gestión de riesgos y el presupuesto. 19 Capítulo 4: Diseño. Se trata de la fase de diseño de la aplicación. En este capítulo, se adaptan los diagramas elaborados en la fase de análisis de cara a la implementación de la aplicación. Se incluye la arquitectura del sistema, el diagrama de clases de diseño, los patrones utilizados en el desarrollo, la explicación de la API REST, el modelo de datos y el diagrama de realización de un caso de uso representativo. Capítulo 5: Implementación. En este capítulo se describen los detalles de implementación de la aplicación. Entre ellos, las tecnologías y herramientas utilizadas. Capítulo 6: Plan de Pruebas y Evaluación. Se incluye la descripción de las pruebas realizadas, así como sus resultados, para comprobar que la aplicación funciona correctamente. También se incluyen los casos de error. Capítulo 7: Conclusiones y Trabajo Futuro. Se trata de una descripción con los resultados obtenidos en el desarrollo, una valoración personal y posibles líneas de trabajo futuras. Capítulo 8: Bibliografía. Contiene las referencias bibliográficas consultadas a lo largo del desarrollo del proyecto. Anexos. En esta sección se encuentran los dos manuales de la aplicación: Manual de Instalación y Manual de Usuario. Además se encuentra la estructura del CD entregado con el proyecto. 20 21 Capítulo 2 Elicitación de Requisitos y Análisis En este punto, se pasa a describir de forma detallada la aplicación a desarrollar. Se definen los actores y roles, se especifican los requisitos y los casos de uso, de manera que se pueda realizar posteriormente un buen diseño, y por consiguiente una buena codificación del sistema. 2.1. Descripción de los actores y roles de la aplicación En este primer punto, se describen los roles que van a formar parte de la aplicación. Para esta versión de la aplicación sólo se va a tener en cuenta un único actor, que podrá realizar cualquier acción que se haya implementado. 2.1.1. Usuario Este será el único actor, para una primera versión de la aplicación. El rol “Usuario” lo representará cualquier persona que se registre e inicie sesión en la aplicación, con el propósito de usarla. Podrá jugar a un juego, crearlo, interactuar con sus amigos, y en general, realizar cualquier caso de uso identificado en el proceso de análisis. 2.2. Especificación de requisitos 2.2.1. Requisitos funcionales En la Tabla 2.1, se detallan los requisitos funcionales de la aplicación: ID Descripción RF01 El sistema permitirá al usuario registrarse en la aplicación RF02 El sistema permitirá al usuario identificarse en la aplicación RF03 El sistema permitirá al usuario modificar los datos personales de usuario 22 RF04 El sistema permitirá al usuario cerrar sesión RF05 El sistema permitirá al usuario enviar solicitudes de amistad a otros usuarios RF06 El sistema permitirá al usuario aceptar una solicitud de amistad. (Ver: 2.2.6. Diccionario de datos: Estado de solicitud de amistad). RF07 El sistema permitirá al usuario rechazar una solicitud de amistad. (Ver: 2.2.6. Diccionario de datos: Estado de solicitud de amistad). RF08 El sistema permitirá al usuario eliminar amigos RF09 El sistema permitirá al usuario consultar la lista de amigos de un usuario RF10 El sistema permitirá al usuario buscar a otros usuarios por nombre o login RF11 El sistema permitirá al usuario consultar el perfil completo de un usuario: Nombre, Email, Avatar, Logros y Juegos. RF12 El sistema permitirá al usuario indicar que un juego es privado, compartido con amigos o público RF13 El sistema permitirá al usuario seleccionar una modalidad de juego. (Ver: 2.2.6. Diccionario de datos: Modalidad de juego) RF14 El sistema permitirá al usuario seleccionar un nivel de dificultad. (Ver: 2.2.6. Diccionario de datos: Niveles de dificultad). RF15 El sistema permitirá al usuario iniciar una partida de un juego RF16 El sistema permitirá al usuario compartir un logro RF17 El sistema deberá permitir al usuario consultar su lista de logros RF18 El sistema permitirá al usuario añadir un comentario a un juego RF19 El sistema permitirá al usuario eliminar un comentario de un juego RF20 El sistema permitirá al usuario editar un comentario de un juego RF21 El sistema permitirá al usuario compartir un juego RF22 El sistema deberá permitir al usuario consultar su lista de juegos RF23 El sistema permitirá al usuario consultar la lista de juegos global 23 RF24 El sistema permitirá al usuario consultar los comentarios de un juego RF25 El sistema permitirá al usuario consultar el ranking de puntos de un juego RF26 El sistema permitirá a los usuarios buscar juegos por nombre RF27 El sistema permitirá al usuario crear un juego RF28 El sistema permitirá al usuario modificar el nombre de un juego RF29 El sistema permitirá al usuario agregar un punto geográfico a un juego propio RF30 El sistema permitirá al usuario eliminar un punto geográfico de un juego propio RF31 El sistema permitirá al usuario eliminar un juego RF32 El sistema permitirá al usuario consultar su lista de notificaciones RF33 El sistema permitirá al usuario consultar la ayuda Tabla 2.1: Requisitos funcionales En la Tabla 2.2, se muestra una serie de requisitos de baja prioridad y que no se llevarán a cabo en esta primera entrega del proyecto. ID Descripción RF34 El sistema permitirá al usuario enviar un mensaje asíncrono a otro usuario RF35 El sistema permitirá al usuario consultar su lista de mensajes asíncronos recibidos y enviados RF36 El sistema permitirá al usuario eliminar un mensaje asíncrono enviado a otro usuario Tabla 2.2: Requisitos funcionales (Baja prioridad) 2.2.2. Requisitos de información En la Tabla 2.3, se detallan los requisitos de información del sistema, que representan todos los datos que se necesita almacenar en la aplicación. 24 ID Descripción RI01 El sistema guardará información de los usuarios concretamente: nombre, login, password, email y avatar. RI02 El sistema almacenará información de los juegos, en particular: puntos que lo forman, usuario que lo creó, puntuaciones de los jugadores y estado de visibilidad del juego. RI03 El sistema almacenará información de los puntos geográficos, en particular, nombre, latitud, longitud, tipo de punto, país y continente. RI04 El sistema almacenará información del tipo de punto, en particular, si se trata de tipo Costero, Hidrográfico, Relieve o Político. (Ver: 2.2.6. Diccionario de datos: Tipos de punto). RI05 El sistema almacenará información de los logros definidos, concretamente: nombre del logro, descripción, número de puntos que se requieren para conseguirlo, característica común de los puntos; tipo o localización. RI06 El sistema almacenará información del estado de visibilidad de los logros conseguidos por el usuario. RI07 El sistema almacenará información sobre el nivel de dificultad de una partida. Los niveles pueden ser: Fácil, Medio y Avanzado. (Ver: 2.2.6. Diccionario de datos: Niveles de dificultad). RI08 El sistema almacenará información sobre la modalidad de juego de una partida. Las modalidades pueden ser: Localizar punto y Nombrar punto. (Ver: 2.2.6. Diccionario de datos: Modalidad de juego) RI09 El sistema almacenará información de los comentarios concretamente: descripción, emisor, receptor y fecha de emisión. RI10 El sistema almacenará información de las solicitudes de amistad, en particular: emisor, receptor, fecha de envío y estado de la solicitud. RI11 El sistema almacenará el tipo de estado de la solicitud de amistad: Rechazada, Aceptada, o Pendiente. (Ver: 2.2.6. Diccionario de datos: Estado de solicitud de amistad) RI12 El sistema almacenará el estado de visibilidad de los logros y los juegos: Público, Amigos o Privado. (Ver: 2.2.6. Diccionario de datos: Estado de visibilidad de logros y juegos) Tabla 2.3: Requisitos de información 25 En la Tabla 2.4, se muestra una serie de requisitos de información de baja prioridad, y que no se llevarán a cabo en esta primera entrega del proyecto. ID Descripción RI13 (RI03) El sistema almacenará información de los puntos geográficos, en particular, nombre, coordenadas, tipo de punto y tipo de punto concreto. RI14 El sistema almacenará información del tipo de punto concreto, en particular, si se trata de tipo Playa, Bahía, Cabo, Golfo, Río, Mar, Océano, Lago, Valle, Montaña, Pico, Cordillera, Ciudad o País. (Ver: 2.e Diccionario de datos: Tipos de punto concreto). Tabla 2.4: Requisitos de información (Baja prioridad) 2.2.3. Casos de uso En esta sección, en la Tabla 2.5, se detalla la lista de casos de uso identificados en el proceso de análisis, para la aplicación. Estos representan las acciones que puede realizar el usuario en la aplicación. ID Descripción ID Descripción CU01 Identificarse CU16 Jugar a Localizar punto CU02 Registrarse CU17 Seleccionar modo de juego CU03 Cerrar sesión CU18 Seleccionar nivel de juego CU04 Modificar datos personales CU19 Agregar comentario CU05 Agregar amigo CU20 Editar comentario CU06 Eliminar amigo CU21 Eliminar comentario CU07 Consultar amigos CU22 Consultar juegos CU08 Rechazar solicitud de amistad CU23 Crear juego CU09 Enviar solicitud de amistad CU24 Modificar nombre de juego CU10 Buscar usuario CU25 Agregar punto CU11 Compartir juego CU26 Eliminar punto 32 CU/RF RF1 RF2 RF3 RF4 RF5 RF6 RF7 RF8 RF09 RF10 RF11 CU1 X CU2 X CU3 X CU4 X CU5 X CU6 X CU7 X CU8 X CU09 X CU10 X X Tabla 2.19a: Matriz de correspondencia (CU/RF) CU/RF RF12 RF13 RF14 RF15 RF16 RF17 RF18 RF19 RF20 RF21 RF22 RF23 CU11 X X CU12 X CU13 X CU14 X CU15 X CU16 X CU17 X CU18 X CU19 X CU20 X CU21 X CU22 X X Tabla 2.19b: Matriz de correspondencia (CU/RF) 33 CU/RF RF24 RF25 RF26 RF27 RF28 RF29 RF30 RF31 RF32 RF33 CU23 X CU24 X CU25 X CU26 X CU27 X X X CU28 X CU29 X CU30 X Tabla 2.19c: Matriz de correspondencia (CU/RF) 2.3. Casos de uso 2.3.1. Diagrama de casos de uso En la Figura 2.1, se presenta el diagrama de casos de uso desarrollado para la aplicación. Figura 2.1: Diagrama de casos de uso 34 2.3.2. Especificación de los casos de uso En las tablas (Tabla 2.20 - Tabla 2.50), se encuentran las especificaciones textuales de todos los casos de uso identificados. CU-01 Identificarse Versión 1.0 Dependencias Actores Usuario Precondición El usuario está registrado en el sistema Descripción El usuario inicia sesión en el sistema a través de sus datos Secuencia normal Paso Acción 1. El usuario selecciona la opción de Identificarse 2. El sistema solicita el login y el password del usuario 3. El usuario introduce el login y el password 4. El sistema comprueba que los datos son correctos 5. El sistema muestra la página principal del usuario y el caso de uso finaliza Postcondición Se ha iniciado sesión en el sistema Excepciones Paso Acción 4a. El sistema comprueba que los datos no son correctos, el caso de uso se retoma en el paso 2 3a. El usuario cancela y el caso de uso queda sin efecto Comentarios Tabla 2.20: Descripción del caso de uso: Identificarse 35 CU-02 Registrarse Versión 1.0 Dependencias Actores Usuario Precondición Descripción Se ha creado un nuevo usuario en el sistema Secuencia normal Paso Acción 1. El usuario selecciona la opción de “Registrarse” 2. El sistema solicita los campos: nombre, login, contraseña, confirmación de contraseña y correo electrónico 3. El usuario introduce los campos: nombre, login, contraseña, confirmación de contraseña y correo electrónico 4. El sistema comprueba que los datos son correctos y pide confirmación al actor 5. El usuario confirma 6. El sistema registra el nuevo usuario y el caso de uso finaliza Postcondición Se crea el nuevo usuario en el sistema Excepciones Paso Acción 3a, 5a. El usuario cancela y el caso de uso queda sin efecto 4a. El sistema comprueba que el nombre no contiene al menos una palabra o tiene más de 30 caracteres o menos de 3, se informa al usuario del error y el caso de uso vuelve al paso 2 4b. El sistema comprueba que el login no contiene solo números y letras o un rango de caracteres distintos de 3-12, se informa al usuario del error y el caso de uso vuelve al paso 2 36 4c. El sistema comprueba que el correo electrónico tiene más de 30 caracteres o no responde al formato: ([a-z]|[A-Z]|[0-9]|[\-,\_,\.])+@([a-z]|[A-Z]|[0-9]|[\-,\_,\.])+[az][a-z][a-z]? Se informa al usuario del error y el caso de uso vuelve al paso 2 4d. El sistema comprueba que la contraseña tiene un rango de caracteres distintos de 7-12, se informa al usuario del error y el caso de uso vuelve al paso 2 4e. El sistema comprueba que el login ya existe en el sistema, se informa al usuario del error y el caso de uso vuelve al paso 2 4f. El sistema comprueba que las contraseñas no coinciden, se informa al usuario del error y el caso de uso vuelve al paso 2 Comentarios Tabla 2.21: Descripción del caso de uso: Registrarse CU-03 Cerrar sesión Versión 1.0 Dependencias Actores Usuario Precondición El usuario está identificado en el sistema Descripción El usuario cierra la sesión de la aplicación Secuencia normal Paso Acción 1. El usuario selecciona la opción “Cerrar sesión” 2. El sistema solicita confirmación 3. El actor confirma 4. El sistema cierra la sesión del usuario y el caso de uso finaliza Postcondición Se ha cerrado la sesión del usuario en el sistema. 37 Excepciones Paso Acción 3a. El actor cancela y el caso de uso queda sin efecto. Comentarios Tabla 2.22: Descripción del caso de uso: Cerrar sesión CU-04 Modificar datos personales Versión 1.0 Dependencias Actores Usuario Precondición El usuario está identificado en el sistema Descripción El usuario modifica sus datos personales en el sistema Secuencia normal Paso Acción 1. El usuario selecciona la opción “Modificar datos personales” 2. El sistema muestra los datos del usuario: nombre, contraseña, correo electrónico y avatar, y solicita modificación 3. El usuario modifica sus datos 4. El sistema comprueba que los datos son correctos y solicita confirmación 5. El usuario confirma 6. El sistema actualiza los datos del usuario, muestra mensaje y el caso de uso finaliza Postcondición Se han actualizado los datos del usuario en el sistema 38 Excepciones Paso Acción 3a, 5a. El usuario cancela y el caso de uso queda sin efecto 4a. El sistema comprueba que el nombre no contiene al menos una palabra o tiene más de 30 caracteres o menos de 3, se informa al usuario del error y el caso de uso vuelve al paso 2 4b. El sistema comprueba que el correo electrónico tiene más de 30 caracteres o no responde al formato: ([a-z]|[A-Z]|[0-9]|[\-,\_,\.])+@([a-z]|[A-Z]|[0-9]|[\- ,\_,\.])+[a-z][a-z][a-z]? Se informa al usuario del error y el caso de uso vuelve al paso 2 4c. El sistema comprueba que la contraseña tiene un rango de caracteres distintos de 3-12, se informa al usuario del error y el caso de uso vuelve al paso 2 4d. Si se ha modificado la contraseña, el sistema comprueba que las contraseñas no coinciden, se informa al usuario del error y el caso de uso vuelve al paso 2 Comentarios Tabla 2.23: Descripción del caso de uso: Modificar datos personales CU-05 Agregar amigo Versión 1.0 Dependencias Actores Usuario Precondición Se ha realizado el caso de uso: “Identificarse”. Se ha recibido una solicitud de amistad. Descripción Se agrega un amigo a la lista de amigos 39 Secuencia normal Paso Acción 1. El usuario selecciona la opción: “Notificaciones” 2. El sistema muestra las notificaciones del usuario 3. El usuario selecciona una solicitud de amistad 4. El sistema solicita “Aceptar” la solicitud 5. El usuario selecciona la opción “Aceptar” 6. El sistema registra la nueva relación entre los usuario, muestra mensaje y caso de uso finaliza Postcondición Se ha agregado un nuevo amigo a la lista de amigos del usuario Excepciones Paso Acción 3a, 5a. El usuario cancela, y el caso de uso queda sin efecto 2a. Si el usuario no tiene solicitudes de amistad, se muestra mensaje y el caso de uso queda sin efecto Comentarios Tabla 2.24: Descripción del caso de uso: Agregar amigo CU-06 Eliminar amigo Versión 1.0 Dependencias Actores Usuario Precondición Se ha realizado el caso de uso: “Identificarse” Descripción Proceso de eliminar un amigo de la lista de amigos del usuario 40 Secuencia normal Paso Acción 1. El usuario selecciona la opción: “Eliminar amigo” 2. El sistema muestra la lista de amigos del usuario y solicita seleccionar uno 3. El usuario selecciona un amigo de la lista 4. El sistema solicita confirmación 5. El usuario confirma 6. El sistema elimina el amigo de la lista de los usuarios, muestra un mensaje y el caso de uso finaliza Postcondición Se ha eliminado la relación de amistad entre dos usuarios Excepciones Paso Acción 3a, 5a. El usuario cancela, y el caso de uso queda sin efecto 2a. Si la lista de amigos está vacía, el caso de uso queda sin efecto 5b. Si el usuario no confirma, el caso de uso queda sin efecto Comentarios Tabla 2.25: Descripción del caso de uso: Eliminar amigo CU-07 Consultar amigos Versión 1.0 Dependencias Actores Usuario Precondición Se ha realizado el caso de uso: “Identificarse” Descripción Proceso de consultar la lista de amigos del usuario 41 Secuencia normal Paso Acción 1. El usuario selecciona la opción: “Amigos” 2. El sistema muestra la lista de amigos del usuario y el caso de uso finaliza Postcondición Se ha consultado la lista de amigos del usuario Excepciones Paso Acción 2a.. Si la lista de amigos es vacía, el sistema muestra un mensaje y el caso de uso queda sin efecto. Comentarios Tabla 2.26: Descripción del caso de uso: Consultar amigos CU-08 Rechazar solicitud de amistad Versión 1.0 Dependencias Actores Usuario Precondición Se ha realizado el caso de uso: “Identificarse” Se ha recibido una solicitud de amistad Descripción Se rechaza la relación de amistad entre dos usuarios Secuencia normal Paso Acción 1. El usuario selecciona la opción: “Notificaciones” 2. El sistema muestra las notificaciones del usuario 3. El usuario selecciona una solicitud de amistad 4. El sistema solicita “Rechazar” la solicitud 5. El usuario selecciona la opción “Rechazar” 6. El sistema actualiza la solicitud de amistad y caso de uso finaliza 48 Secuencia normal 9. El sistema comprueba los logros del usuario 10. El sistema muestra la puntuación obtenida y, solicita almacenarla 11. El actor confirma 12. El sistema registra la puntuación del juego y, el caso de uso finaliza Postcondición Se ha registrado la partida en el sistema, añadiendo la puntuación obtenida. Excepciones Paso Acción 3a, 7a, 11a. El usuario cancela y el caso de uso queda sin efecto 2a. El sistema muestra una lista de juegos vacía, y el caso de uso queda sin efecto. 4a. Si el usuario quiere seleccionar un nivel de juego, se realiza el caso de uso “Seleccionar nivel de juego”, a continuación este caso de uso continúa. 5a. Si el usuario quiere seleccionar el modo de juego, se realiza el caso de uso “Seleccionar modo de juego”, a continuación el caso de uso continúa. 8a. Si se ha seleccionado el modo de juego: “Localizar punto”, se realiza el caso de uso: “Jugar a Localizar punto”, a continuación el caso de uso continúa. 8b. Si se ha seleccionado el modo de juego: “Nombrar punto”, se realiza el caso de uso: “Jugar a Nombrar punto”, a continuación el caso de uso continúa. 8c. Si no se ha podido jugar la partida en el modo seleccionado, el caso de uso queda sin efecto. 9a. Si existen logros cumplidos, se muestra el mensaje y el caso de uso continúa por el paso 12. 11a. El usuario no confirma, y el caso de uso finaliza 49 Comentarios Anotación de usabilidad: Si el usuario, ya ha seleccionado un nivel de juego previamente, se asumirá por defecto ese nivel y no el nivel establecido por defecto. Tabla 2.33: Descripción del caso de uso: Jugar CU-15 Jugar a Nombrar punto Versión 1.0 Dependencias Actores Usuario Precondición Se ha realizado el caso de uso: “Identificarse” Descripción El usuario juega una partida en el modo: Nombrar punto Secuencia normal Paso Acción 1. El sistema solicita el nombre del punto geográfico 2. El actor introduce el nombre del punto 3. El sistema comprueba que el nombre introducido es correcto 4. El sistema muestra mensaje de finalización de la partida, y el caso de uso finaliza. Postcondición Se ha jugado una partida en el modo: Nombrar punto. Excepciones Paso Acción 2a. El usuario cancela y el caso de uso queda sin efecto. 3a. Si se ha seleccionado el nivel de dificultad “Fácil”, se muestra el mensaje de acierto del punto, el caso de uso continúa por el paso 4. 3b. Si se ha seleccionado el nivel de dificultad “Medio”, se muestra el mensaje de acierto del punto durante un tiempo limitado, el caso de uso continúa por el paso 4. 3c. El sistema comprueba que el nombre introducido es incorrecto, se muestra el mensaje de error si ha seleccionado el nivel “Fácil”, el caso de uso continúa por el paso 4. 50 Excepciones 3d. El sistema comprueba que el nombre introducido es incorrecto, se muestra el mensaje de error durante un tiempo limitado si ha seleccionado el nivel “Medio”, el caso de uso continúa por el paso 4. 4a. Si existen más puntos sin localizar se vuelve al paso 1. Comentarios Tabla 2.34: Descripción del caso de uso: Jugar a Nombrar punto CU-16 Jugar a Localizar punto Versión 1.0 Dependencias Actores Usuario Precondición Se ha realizado el caso de uso: “Identificarse” Descripción El usuario juega una partida en el modo: Localizar punto Secuencia normal Paso Acción 1. El sistema solicita localizar un punto por nombre. 2. El usuario selecciona la localización correspondiente en el mapa. 3. El sistema comprueba que la localización seleccionada es correcta. 4. El sistema muestra mensaje de finalización de la partida, y el caso de uso finaliza. Postcondición Se ha jugado una partida en el modo: Localizar punto. Excepciones Paso Acción 2a. El usuario cancela y el caso de uso queda sin efecto 3a. Si el usuario ha seleccionado el nivel “Fácil”, se muestra el mensaje de acierto del punto, el caso de uso continúa 51 Excepciones 3b. Si el usuario ha seleccionado el nivel “Medio”, se muestra el mensaje de acierto del punto durante un tiempo limitado, el caso de uso continúa 3c. El sistema comprueba que el nombre introducido es incorrecto, se muestra el mensaje de error si ha seleccionado el nivel ”Fácil”, el caso de uso continúa 3d. El sistema comprueba que el nombre introducido es incorrecto, se muestra el mensaje de error durante un tiempo limitado si ha seleccionado el nivel “Medio”, el caso de uso continúa 4a. Si existen más puntos sin localizar se vuelve al paso 1 Comentarios Tabla 2.35: Descripción del caso de uso: Jugar a Localizar punto CU-17 Seleccionar modo de juego Versión 1.0 Dependencias Actores Usuario Precondición Se ha realizado el caso de uso: “Identificarse” Se ha iniciado una partida Descripción Proceso de elección de una modalidad de juego de una partida. Secuencia normal Paso Acción 1. El sistema solicita la modalidad de juego 2. El usuario introduce la modalidad de juego 3. El sistema comprueba que la modalidad de juego sea “Nombrar punto” o “Localizar punto”, y el caso de uso finaliza Postcondición Se ha seleccionado un modo de juego 52 Excepciones Paso Acción 2a El usuario cancela y el caso de uso queda sin efecto 3a. El sistema comprueba que la modalidad de juego no es “Nombrar punto” o “Localizar punto”, se muestra mensaje y el caso de uso vuelve al paso 1. Comentarios Tabla 2.36: Descripción del caso de uso: Seleccionar modo de juego CU-18 Seleccionar nivel de juego Versión 1.0 Dependencias Actores Usuario Precondición Se ha realizado el caso de uso: “Identificarse” Se ha iniciado una partida Descripción Proceso de elección de un nivel de dificultad de una partida. Secuencia normal Paso Acción 1. El sistema solicita el nivel de dificultad 2. El usuario introduce el nivel de dificultad 3. El sistema comprueba que el nivel de dificultad sea “Fácil”, “Medio” o “Avanzado”, y el caso de uso finaliza Postcondición Se ha seleccionado un nivel de dificultad Excepciones Paso Acción 2a El usuario cancela y el caso de uso queda sin efecto 3a. El sistema comprueba que el nivel de dificultad no es “Fácil”, “Medio” o “Avanzado”, se muestra mensaje y el caso de uso vuelve al paso 1. Comentarios Tabla 2.37: Descripción del caso de uso: Seleccionar nivel de juego 53 CU-19 Agregar comentario Versión 1.0 Dependencias Actores Usuario Precondición Se ha realizado el caso de uso: “Identificarse” Descripción Proceso de añadir un comentario nuevo por parte del usuario a un juego. Secuencia normal Paso Acción 1. Se realiza el caso de uso: “Buscar juego” 2. El usuario selecciona la opción: “Agregar comentario” 3. El sistema solicita el mensaje a agregar 4. El usuario introduce el mensaje 5. El sistema comprueba el mensaje y solicita confirmación 6. El usuario confirma el guardado del mensaje 7. El sistema añade el nuevo comentario al juego, muestra mensaje y el caso de uso finaliza. Postcondición Se añade un nuevo comentario a un juego Excepciones Paso Acción 2a, 4a, 6a. El usuario cancela y el caso de uso queda sin efecto 1a. Si el caso de uso no finaliza correctamente, se vuelve al paso 1. 5a. El sistema comprueba que el mensaje no está entre el rango 3 y 150 de caracteres, muestra el mensaje de error y el caso de uso vuelve al paso 4 Comentarios Tabla 2.38: Descripción del caso de uso: Agregar comentario 54 CU-20 Editar comentario Versión 1.0 Dependencias Actores Usuario Precondición Se ha realizado el caso de uso: “Identificarse” El actor identificado es el creador del comentario Descripción Proceso de editar un comentario de un usuario en un juego. Secuencia normal Paso Acción 1. Se realiza el caso de uso: “Buscar juego” 2. El usuario selecciona la opción: “Editar comentario” 3. El sistema muestra la lista de comentarios del juego 4. El usuario selecciona el comentario a editar 5. El sistema comprueba que el mensaje está escrito por el usuario y solicita el mensaje nuevo 6. El usuario introduce el mensaje nuevo 7. El sistema comprueba el mensaje y solicita confirmación 8. El usuario confirma el guardado del mensaje 9. El sistema registra la modificación del comentario en el juego, muestra mensaje y el caso de uso finaliza. Postcondición Se ha editado un comentario de un juego Excepciones Paso Acción 2a, 4a, 6a, 8a. El usuario cancela y el caso de uso queda sin efecto 1a. Si el caso de uso no finaliza correctamente, se vuelve al paso 1. 3a. Si la lista de comentarios está vacía, se muestra mensaje y se vuelve al paso 1. 55 Excepciones 5a. El sistema comprueba que el mensaje no está escrito por el usuario, muestra mensaje y se vuelve al paso 3. 7a. El sistema comprueba que el mensaje no está entre el rango 3 y 150 de caracteres, muestra el mensaje de error y el caso de uso vuelve al paso 5. Comentarios Tabla 2.39: Descripción del caso de uso: Editar comentario CU-21 Eliminar comentario Versión 1.0 Dependencias Actores Usuario Precondición Se ha realizado el caso de uso: “Identificarse” El actor identificado es el creador del comentario Descripción Proceso de eliminar un comentario de un usuario en un juego. Secuencia normal Paso Acción 1. Se realiza el caso de uso: “Buscar juego” 2. El usuario selecciona la opción: “Eliminar comentario” 3. El sistema muestra la lista de comentarios del juego 4. El usuario selecciona el comentario a eliminar 5. El sistema comprueba que el mensaje está escrito por el usuario y solicita confirmación 6. El usuario confirma la eliminación del mensaje 7. El sistema elimina el comentario del juego, muestra mensaje y el caso de uso finaliza. Postcondición Se ha eliminado un comentario de un juego 56 Excepciones Paso Acción 2a, 4a, 6a. El usuario cancela y el caso de uso queda sin efecto. 1a. Si el caso de uso no termina correctamente, se vuelve al paso 1. 3a. Si la lista de comentarios está vacía, se muestra mensaje y se vuelve al paso 1. 5a. El sistema comprueba que el mensaje no está escrito por el usuario, se muestra mensaje y se vuelve al paso 3. Comentarios Tabla 2.40: Descripción del caso de uso: Eliminar comentario CU-22 Consultar juegos Versión 1.0 Dependencias Actores Usuario Precondición Se ha realizado el caso de uso: “Identificarse” Descripción Proceso de consultar la lista de juegos disponibles del usuario Secuencia normal Paso Acción 1. El usuario selecciona la opción: “Juegos” 2. El sistema muestra la lista de juegos disponibles del usuario y el caso de uso finaliza Postcondición Se ha consultado la lista de juegos disponibles del usuario Excepciones Paso Acción 2a. Si la lista de juegos es vacía, el sistema muestra un mensaje y el caso de uso queda sin efecto. Comentarios Tabla 2.41: Descripción del caso de uso: Consultar juegos 57 CU-23 Crear juego Versión 1.0 Dependencias Actores Usuario Precondición Se ha realizado el caso de uso: “Identificarse” Descripción Se registra un nuevo juego en la lista de juegos del usuario Secuencia normal Paso Acción 1. El usuario selecciona la opción: “Crear juego” 2. El sistema solicita añadir un punto geográfico 3. Se realiza el caso de uso: “Agregar punto” 4. El sistema solicita el nombre del juego 5. El usuario introduce el nombre del juego 6. El sistema comprueba el nombre y solicita crear el juego 7. El usuario selecciona la opción de crear 8. El sistema muestra el resumen y solicita confirmación para crear el juego 9. El usuario confirma 10. El sistema registra el juego y el caso de uso finaliza Postcondición Se ha añadido un nuevo juego a la lista de juegos del usuario Excepciones Paso Acción 5a, 7a, 9a El usuario cancela y el caso de uso queda sin efecto 3a. Si el caso de uso incluido no termina correctamente, se vuelve al paso 2. 6a. El sistema comprueba que el nombre no contiene al menos una palabra o tiene más de 30 caracteres o menos de 3, se informa al usuario del error y el caso de uso vuelve al paso 5 64 Secuencia normal 2. El sistema muestra la lista de Solicitudes de amistad, Logros compartidos y Juegos compartidos con el usuario, y el caso de uso finaliza Postcondición Se ha consultado la lista de notificaciones del usuario Excepciones Paso Acción 2a. Si la lista de notificaciones es vacía, el sistema muestra un mensaje y el caso de uso queda sin efecto. Comentarios Tabla 2.48: Descripción del caso de uso: Consultar notificaciones CU-30 Consultar ayuda Versión 1.0 Dependencias Actores Usuario Precondición Descripción Proceso de consultar la ayuda de la aplicación Secuencia normal Paso Acción 1. El usuario selecciona la opción: “Ayuda” 2. El sistema muestra la ayuda de la aplicación Postcondición Se ha consultado la ayuda de la aplicación Excepciones Paso Acción Comentarios Tabla 2.49: Descripción del caso de uso: Consultar ayuda 2.4. Modelo de dominio En la Figura 2.2, se muestra el modelo de dominio. En este, se encuentran las clases identificadas a nivel de análisis, las relaciones entre ellas y restricciones. 65 Figura 2.2: Modelo del Dominio 66 67 Capítulo 3 Plan de proyecto 3.1. Resumen del proyecto 3.1.1. Propósito, Alcance y Objetivos El objetivo de este proyecto es conseguir una aplicación web, apta para diferentes dispositivos y navegadores, que permita jugar a juegos sobre geografía con el propósito de aprender. Esta aplicación permitirá crear un juego propio, jugar en diferentes modalidades y con diferentes niveles de dificultad. También permitirá la interacción con otros usuarios, a través de relaciones de amistad y de la compartición de juegos y logros, además de otras funcionalidades. Todas ellas están detalladas en profundidad en el Capítulo 2. 3.1.2. Definiciones y Acrónimos En la Tabla 3.1, se muestra la lista de acrónimos y definiciones que aparecen a lo largo del documento presente. Acrónimo Significado UPEDU Unified Process for EDUcation, conjunto de mejores prácticas que permiten agilizar las actividades de desarrollo de software. Es una personalización del Proceso Unificado, pero orientado al entorno educativo. HTML5 HyperText Markup Language, versión 5. Se trata del lenguaje de marcado para el desarrollo de páginas web. CSS3 Cascading Stylesheets, versión 3. Se trata del lenguaje específico para definir los estilos y la presentación de las páginas web. JPA Java Persistence API. Se trata de una API de persistencia que se usa para realizar la correlación entre la base de datos y el modelo orientado a objetos. 68 API Application Programming Interface, es una serie de funciones, rutinas, métodos o variables, que se ofrecen para que lo pueda usar otro software como una capa de abstracción. UI User Interface. Se refiere a la interfaz de usuario de una aplicación. MSProject Microsoft Project. Se trata de un software para realizar la planificación de proyectos. IDE Integrated Development Environment. Aplicación que facilita el desarrollo de software. MySQL Structured Query Language. Lenguaje específico para intercambiar información con una base de datos. MySQL, es un sistema de gestión de bases de datos relacionales, que se basa en el lenguaje SQL. UVa Universidad de Valladolid. TFG Trabajo de Fin de Grado MVC Modelo Vista Controlador Tabla 3.1: Acrónimos 3.1.2. Artefactos del Proyecto En este caso, al utilizar la metodología UPEDU tenemos los siguientes artefactos a desarrollar [15]:  Plan de Desarrollo de Software  Requisitos  Análisis y diseño  Implementación  Test 3.1.3. Evolución del Plan El Plan de Proyecto es un documento que describe la planificación del proyecto en detalle. Este documento se irá actualizando en cada fase del proyecto. En él, se incluyen las tareas a desarrollar y la calendarización de las mismas. A lo largo del desarrollo del proyecto, se llevará un seguimiento de todas las tareas, las cuales se irán completando con el tiempo real de trabajo. También se llevará un seguimiento de los riesgos que se produzcan para actuar en consecuencia. 69 3.2. Plan de Proceso Para el desarrollo de la aplicación se ha decidido utilizar la metodología UPEDU. En la Figura 3.1, se puede observar el proceso de ingeniería de software sobre el que se trabaja en UPEDU [15]. Figura 3.1: Proceso de ingeniería de software [15] Consiste en realizar iteraciones sobre las funcionalidades requeridas para la aplicación. Primero se realiza la planificación, se desarrollan los requisitos, el análisis, el diseño, y después la implementación, y pruebas de esa funcionalidad. Una vez que se ha probado se despliega. En el momento, que surgen nuevos requisitos y cambios se realiza una nueva iteración en el proceso de desarrollo. A partir de este proceso, surgen los diferentes artefactos y en cada iteración se van refinando hasta que se desarrollan completamente, y termina el proyecto. 3.2.1. Ciclo de vida del proyecto A continuación, se describen las cuatro fases de las que se compone el ciclo de vida en UPEDU: Inicio, Elaboración, Construcción y Transición [15]. La Figura 3.2, representa el ciclo de vida del proceso unificado orientado a educación. 70 Figura 3.2: Ciclo de vida del proceso unificado orientado a educación [15] Inicio: El objetivo de la fase de inicio es, fundamentalmente, el análisis del proyecto. Análisis de requisitos, análisis de riesgos, presupuestos y costes. Para comprobar su viabilidad. - Determinar lo que se va a hacer y lo que no. - Casos de uso críticos y principales. - Arquitectura candidata - Estimar los costes y cronología del proyecto - Estimación de riesgos - Preparar el entorno del proyecto Actividades: - Alcance del proyecto: Esto implica capturar el contexto y, los requisitos y restricciones más importantes. - Planificación y preparación de un caso de negocio: Análisis y Gestión de riesgos, plan de proyecto y costes. - Sintetizar una arquitectura candidata: Costes y viabilidad del proyecto. - Preparar el entorno, evaluar el proyecto: Herramientas. 71 Elaboración: El objetivo de la fase de elaboración es, a partir de la arquitectura del sistema, proporcionar una base estable para la parte de diseño e implementación, en la fase de construcción. La arquitectura evoluciona a partir de los requisitos más importantes (aquellos que tienen un gran impacto en la arquitectura del sistema) y una evaluación del riesgo. La estabilidad de la arquitectura se evalúa a través de uno o más prototipos arquitectónicos. Actividades: - Definir y validar la arquitectura. - Refinación de la visión, estableciendo una sólida comprensión de los casos de uso más críticos. - Crear y alinear planes de iteración detallados para la fase de construcción. - Refinar el caso de desarrollo y poner en marcha el entorno de desarrollo, proceso, herramientas. - Refinando la arquitectura y seleccionando componentes. Componentes que se van a usar. Sirve para determinar los costes y el calendario de la fase de construcción. Construcción: El objetivo de la fase de construcción es aclarar los requisitos restantes y completar el desarrollo. Consiste en el proceso de fabricación. Objetivos: - Minimizar los costes de desarrollo. - Calidad adecuada - Versiones (alfa, beta y otras versiones de prueba). - Completar el análisis, diseño, desarrollo y prueba de todas las funcionalidades. - Desarrollar de forma iterativa e incremental un producto completo que esté listo para la transición al usuario. Describir los casos de uso restantes, completar el diseño, la implementación y probar el software. - Paralelismo en el desarrollo con diferentes tareas. Actividades: - Gestión de recursos, control y optimización de procesos. - Desarrollo y prueba de componentes completos para ver si cumplen los requisitos. - Evaluación de lanzamientos de productos contra los criterios de aceptación. 72 Transición: Garantizar que el software esté disponible para el usuario final. Probar el producto haciendo reajustes. Ajustar problemas de producto: configuración, instalación o usabilidad. Ya se han cumplido todos los requisitos y lo único que falta es cerrar el proyecto. Objetivos: - Pruebas para validar los requisitos el usuario. - Entrenamiento de usuarios - Despliegue - Ajustes de la aplicación - Permitir que el usuario pueda usarlo sin ayuda Actividades: - Despliegue de la aplicación - Terminar el material de soporte del usuario final - Probar el producto entregable en el sitio de desarrollo - Crear una versión de producto - Comentarios de los usuarios - Ajustar el producto basado en comentarios - Poner el producto a disponibilidad de los usuarios 3.3. Gestión de Proceso 3.3.1. Plan de Puesta en Marcha En la estimación de las tareas a desarrollar, se tendrá como referencia otros proyectos realizados antes de características similares. Para poder desarrollar el proyecto con calidad y de forma correcta se necesita adquirir ciertas habilidades:  Conocimientos de tecnologías de la parte Front: HTML5, CSS3, JavaScript, AngularJS, jQuery y, Angular Translate y configuración.  Conocimientos de tecnologías de la parte Back: Java, JPA e Hibernate.  Conocimiento del framework Spring y configuración.  Configuración del proyecto y arranque de la aplicación en el servidor TomCat.  Desarrollo con OpenStreetMap y Leaflet.  Conocimientos en Spring Security y configuración. No se necesitará nada adicional, puesto que es un proyecto educativo, y por tanto su desarrollo será en Local (casa particular) o en lugares públicos, como la universidad o bibliotecas. 73 3.3.2. Plan de Trabajo En esta sección, se describen las tareas a desarrollar en cada una de las fases del proyecto, así como su calendarización. Fase de Inicio Nombre de tarea Duración Comienzo Fin Inicio 16 días vie 10/11/17 dom 10/12/17 Inicio de la fase de inicio 0 días vie 10/11/17 vie 10/11/17 Búsqueda del UPEDU 1 día vie 10/11/17 vie 10/11/17 Análisis de requisitos iniciales 2 días sáb 11/11/17 dom 12/11/17 Definición de las tareas a desarrollar 4 días vie 17/11/17 vie 24/11/17 Calendarización 2 días sáb 25/11/17 dom 26/11/17 Gestión de riesgos 2 días vie 01/12/17 sáb 02/12/17 Documento de seguimiento 1 día dom 03/12/17 dom 03/12/17 Presupuesto 2 días mié 06/12/17 vie 08/12/17 Documento de costes 1 día sáb 09/12/17 sáb 09/12/17 Preparar el entorno y herramientas 1 día dom 10/12/17 dom 10/12/17 Finalización de fase de inicio 0 días dom 10/12/17 dom 10/12/17 Tabla 3.2: Calendarización fase de inicio En las tablas, Tabla 3.3 - Tabla 3.13, se encuentra la descripción de cada una de las tareas de la fase de Inicio. 80 ID-15 Especificación de casos de uso Predecesoras 14 Duración 3 días Descripción Elaboración de una especificación textual de los casos de usos identificados en el sistema. Tabla 3.18: Tarea - Especificación de casos de uso ID-16 Modelo de dominio Predecesoras 15 Duración 3 días Descripción Consiste en obtener el diagrama de todas las entidades del dominio de la aplicación con sus atributos, relaciones y restricciones. Tabla 3.19: Tarea - Modelo de dominio ID-17 Diseño de la base de datos Predecesoras 16 Duración 2 días Descripción Elaboración del diagrama entidad-relación que representa lo que se va a almacenar en la base de datos, con sus relaciones entre sí. Generar los scripts de creación y población de la base de datos. Tabla 3.20: Tarea - Análisis de la base de datos ID-18 Investigación de OpenStreetMap y Leaflet Predecesoras 17 Duración 2 días Descripción Realizar una investigación del funcionamiento de OpenStreetMap y Leaflet, realización de pruebas para entender cómo funciona y, poder aplicarlo más fácilmente a la aplicación. Tabla 3.21: Tarea - Investigación y pruebas de OpenStreetMap 81 ID-19 Investigación y pruebas de Angular Translate Predecesoras 18 Duración 2 días Descripción Realizar una investigación del funcionamiento de la Angular Translate, para poder traducir a diferentes idiomas la aplicación. Realización de pruebas para entender cómo funciona y, poder aplicarlo más fácilmente a la aplicación. Tabla 3.22: Tarea - Investigación y pruebas de Angular Translate ID-20 Investigación y pruebas de Spring Security Predecesoras 19 Duración 2 días Descripción Realizar una investigación del funcionamiento de Spring Security, para añadir seguridad a la aplicación. Realización de pruebas para entender cómo funciona y, poder aplicarlo más fácilmente a la aplicación. Tabla 3.23: Tarea - Investigación y pruebas de Spring Security ID-21 Diseño de las vistas UI Predecesoras 20 Duración 4 días Descripción Realización de los bocetos de las vistas de la aplicación para su posterior desarrollo. Tabla 3.24: Tarea - Diseño de las vistas UI ID-22 Arquitectura de la aplicación Predecesoras 21 Duración 1 día Descripción Consiste en la realización de los diagramas correspondientes a la arquitectura de la aplicación. Diagrama de la arquitectura general, del lado del cliente y del lado del servidor. Planificar la estructura. Tabla 3.25: Tarea - Arquitectura de la aplicación 82 ID-23 Diagramas de clases de diseño Predecesoras 22 Duración 3 días Descripción Elaboración de los diagramas de clases de diseño. Representar todas las clases de la aplicación en diseño. Tabla 3.26: Tarea - Diagramas de clases de diseño ID-24 Diagramas de realización de los casos de uso Predecesoras 23 Duración 6 días Descripción Elaboración de los diagramas de realización para un caso de uso representativo de la aplicación. Tabla 3.27: Tarea - Diagramas de realización de los casos de uso ID-25 Fin de la fase de Elaboración Predecesoras 24 Duración 0 días Descripción - Tabla 3.28: Tarea - Fin de la fase de Elaboración En la Figura 3.4, se muestra el Diagrama de Gantt de la Fase de Elaboración. 83 Figura 3.4: Tareas y diagrama de Gantt de la Fase de Elaboración 84 Fase de Construcción Nombre de tarea Duración Comienzo Fin Construcción 51 días vie 16/02/18 sáb 02/06/18 Inicio de la fase de construcción 0 días vie 16/02/18 vie 16/02/18 Configuración del cliente 3 días sáb 17/02/18 vie 23/02/18 Configuración del servidor 3 días sáb 24/02/18 vie 02/03/18 Implementar las vistas estáticas 14 días sáb 03/03/18 mié 28/03/18 Implementar la funcionalidad de la vista 18 días jue 29/03/18 vie 04/05/18 Implementar los servicios 31 días jue 29/03/18 sáb 02/06/18 Fin de la fase de construcción 0 días sáb 02/06/18 sáb 02/06/18 Tabla 3.29: Calendarización de la fase de construcción En las tablas, Tabla 3.30 - Tabla 3.36, se encuentra la descripción de cada una de las tareas de la fase de Construcción. ID-26 Inicio de la fase de Construcción Predecesoras 25 Duración 0 días Descripción - Tabla 3.30: Tarea - Inicio de la fase de Construcción 85 ID-27 Configuración del cliente Predecesoras 25 Duración 3 días Descripción Consiste añadir todas las dependencias del lado del cliente. Dejar configuradas todas las herramientas que se utilizan, entre ellas, Angular Translate, Bootstrap y jQuery. Tabla 3.31: Tarea - Configuración del cliente ID-28 Configuración del servidor Predecesoras 26 Duración 3 días Descripción Consiste en la configuración de la parte servidora con todas las dependencias necesarias, creación y población de la base de datos con datos de prueba, y configuración de la base de datos y de Spring Security. Tabla 3.32: Tarea -Configuración del servidor ID-29 Implementar las vistas estáticas Predecesoras 27 Duración 14 días Descripción Consiste en la elaboración de todos los HTML y CSS de las páginas que se diseñaron anteriormente, sin funcionalidad asociada. Tabla 3.33: Tarea - Implementar las vistas estáticas 86 ID-30 Implementar la funcionalidad de la vista Predecesoras 28 Duración 18 días Descripción Elaboración de toda la funcionalidad asociada a las vistas, navegación entre páginas, validación de campos, controladores, servicios, funcionalidad del juego, mostrado de errores y conexión con el servidor. Tabla 3.34: Tarea - Implementar la funcionalidad de la vista ID-31 Implementar los servicios Predecesoras 28 Duración 31 días Descripción Consiste en la elaboración los controladores, servicios, entidades y persistencia de la parte back end del sistema, además de las excepciones y las conexiones con el front end. Tabla 3.35: Tarea - Implementar los servicios ID-32 Fin de la fase de Construcción Predecesoras 29; 30 Duración 0 días Descripción - Tabla 3.36: Tarea - Fin de la fase de Construcción En la Figura 3.5, se muestra el Diagrama de Gantt de la Fase de Construcción. 87 Figura 3.5: Tareas y diagrama de Gantt de la Fase de Construcción 88 Fase de Transición Nombre de tarea Duración Comienzo Fin Transición 19 días sáb 02/06/18 dom 15/07/18 Inicio de la fase de transición 0 días sáb 02/06/18 sáb 02/06/18 Pruebas de la aplicación completa 10 días dom 03/06/18 dom 24/06/18 Elaborar el manual de usuario 3 días vie 29/06/18 dom 01/07/18 Elaborar el manual de instalación 3 días vie 06/07/18 dom 08/07/18 Elaborar el manual del programador 3 días vie 13/07/18 dom 15/07/18 Fin de la fase de transición 0 días dom 15/07/18 dom 15/07/18 Tabla 3.37: Calendarización de la fase de transición En las tablas, Tabla 3.38 - Tabla 3.43, se encuentra la descripción de cada una de las tareas de la fase de Transición. ID-33 Inicio de la fase de Transición Predecesoras 31 Duración 0 días Descripción Tabla 3.38: Tarea - Inicio de la fase de Transición ID-34 Pruebas de la aplicación completa Predecesoras 32 Duración 10 días Descripción Consiste en la realización de todas las pruebas de la aplicación y la resolución de errores en caso necesario. Asegurarse de que la aplicación funciona correctamente. Documentar las pruebas y los casos de error. Tabla 3.39: Tarea - Pruebas de la aplicación completas 89 ID-35 Elaborar el manual de usuario Predecesoras 33 Duración 3 días Descripción Consiste en la redacción del manual de uso de la aplicación, para su uso correcto. Tabla 3.40: Tarea - Elaborar el manual de usuario ID-36 Elaborar el manual de instalación Predecesoras 34 Duración 3 días Descripción Consiste en la redacción del manual de instalación de la aplicación. En este se explicará cómo desplegar y poner en marcha la aplicación. Tabla 3.41: Tarea - Elaborar el manual de instalación ID-37 Elaborar el manual del programador Predecesoras 35 Duración 3 días Descripción Consiste en la redacción del manual del programador del sistema. En este se explicará cómo seguir el desarrollo de la aplicación en caso de ser necesario. Tabla 3.42: Tarea - Elaborar el manual del programador ID-38 Fin de la fase de Transición Predecesoras 36 Duración 0 días Descripción - Tabla 3.43: Tarea - Fin de la fase de Transición En la Figura 3.6, se muestra el Diagrama de Gantt de la Fase de Transición. 96 Seguimiento de la Fase de Transición En la Tabla 3.47, se muestra el seguimiento de las tareas para la Fase de Transición. Nombre de tarea Duración prevista Duración real Comienzo previsto Fin previsto Comienzo real Fin real Transición 19 días 18 días sáb 02/06/18 dom 15/07/18 mié 02/01/2019 jue 28/02/2019 Inicio de la fase de transición 0 días 0 días sáb 02/06/18 sáb 02/06/18 mié 02/01/2019 mié 02/01/2019 Pruebas de la aplicación completa 10 días 6 días dom 03/06/18 dom 24/06/18 mié 02/01/2019 sáb 26/01/2019 Revisión de errores - 3 días - - lun 07/01/2019 sáb 19/01/2019 Elaborar el manual de usuario 3 días 2 días vie 29/06/18 dom 01/07/18 sáb 02/02/2019 dom 03/02/2019 Elaborar el manual de instalación 3 días 1 día vie 06/07/18 dom 08/07/18 vie 08/02/2019 vie 08/02/2019 Elaborar el manual del programador 3 días - vie 13/07/18 dom 15/07/18 - - Desarrollo de la memoria - 6 días - - sáb 09/02/2019 jue 28/02/2019 Fin de la fase de transición 0 días 0 días dom 15/07/18 dom 15/07/18 jue 28/02/2019 jue 28/02/2019 Tabla 3.47: Seguimiento de la fase de Transición 97 3.3.3. Plan de Gestión de Riesgos La Gestión de Riesgos es el proceso de valorar y controlar los riesgos que afectan a un producto, proceso o proyecto de software. Se trata de identificar problemas que pueden ocurrir durante el desarrollo del proyecto para tomar medidas en caso de producirse. En este proceso, se deben realizar las siguientes tareas: 1. Identificar los posibles riesgos 2. Analizar la probabilidad de ocurrencia y el impacto, obteniendo así la exposición al riesgo para poder realizar una priorización de ellos. 3. Planificar las acciones a llevar a cabo en caso de producirse algún riesgo. Esto es a lo que se llama Plan de Contingencia de un riesgo. 4. Seguimiento de los indicadores de riesgos durante el desarrollo del proyecto, para poder tomar las medidas necesarias con antelación. Para poder realizar un buen análisis de riesgos y evitar posibles retrasos e inconvenientes en el desarrollo del proyecto, se debe realizar una cuantificación de los riesgos. Para ello, en el proceso de análisis de los riesgos se debe obtener el grado de exposición al riesgo. Esto se puede obtener a partir de los datos de la Tabla 3.48. Tabla 3.48: Exposición al riesgo: Impacto/Probabilidad [16] Una vez identificados los riesgos, y analizado el grado de exposición de cada uno de ellos, se debe realizar un plan de contingencia, teniendo especial relevancia aquellos riesgos que tengan una alta exposición. Una vez realizado esto, se llevará un seguimiento a lo largo de todo el desarrollo del proyecto, tomando las medidas necesarias y replanificando riesgos si fuera necesario. 3.3.3.1. Análisis de riesgos En esta sección se encuentra el análisis de los riesgos identificados para el proyecto a desarrollar. Para cada uno de ellos se ha elaborado una tabla, con los siguientes campos: 98 - Identificador del riesgo - Breve descripción del riesgo identificado - Impacto: Grado de importancia del riesgo - Probabilidad de ocurrencia del riesgo - Exposición al riesgo: Probabilidad/Impacto del riesgo según la Tabla 3.48 - Plan de mitigación: Medidas de prevención del riesgo - Plan de contingencia: Medidas a tomar en caso de ocurrencia del riesgo En las tablas, Tabla 3.49 - Tabla 3.58, se muestran la serie de riesgos identificados. Identificador R01- Fallo en la planificación Descripción La planificación de tiempos no es suficiente para el desarrollo de las tareas y por tanto no se cumplen los plazos establecidos en la calendarización Impacto Crítico Probabilidad 60% Exposición Alto Plan de mitigación Analizar las tareas adecuadamente para evitar planificar tiempos insuficientes. Realizar la estimación con un margen de tiempo relativo a los periodos de entrega. Desarrollar el trabajo que se ha planificado en los tiempos establecidos Plan de contingencia Priorizar las tareas a desarrollar, establecer las consecuencias, desarrollar los cambios en la aplicación, reevaluar los riesgos que puedan producirse, y replanificar las tareas en tiempo (calendarización) para conseguir desarrollarlo en el menor tiempo posible Tabla 3.49: R01 - Fallo en la planificación Identificador R02 - Indisponibilidad del desarrollador Descripción No se puede cumplir con el trabajo establecido debido a la indisponibilidad por trabajo, ya que el desarrollador se encuentra empleado por otra empresa Impacto Crítico Probabilidad 60% Exposición Alto 99 Plan de mitigación Dedicar los días no laborales sin excepción al desarrollo del proyecto, es decir, cumplir con la calendarización. Realizar la planificación con margen de tiempo ante posibles retrasos Plan de contingencia Replanificar las tareas en tiempo para ocupar el margen de tiempo que se dejó, priorizar las tareas, realizarlas y reevaluar los riesgos Tabla 3.50: R02 - Indisponibilidad del desarrollador Identificador R03 - Enfermedad Descripción No se puede cumplir con el trabajo establecido debido a enfermedad o motivos personales del desarrollador Impacto Marginal Probabilidad 30% Exposición Ninguno Plan de mitigación Dedicar los días no laborales sin excepción al desarrollo del proyecto, es decir, cumplir con la calendarización. Realizar la planificación con margen de tiempo ante posibles retrasos Plan de contingencia Replanificar las tareas en tiempo para ocupar el margen de tiempo que se dejó, priorizar las tareas, realizarlas y reevaluar los riesgos Tabla 3.51: R03 - Enfermedad Identificador R04 - Pérdida de datos o/y documentos Descripción Se produce la pérdida de algún documento o de datos ya desarrollados, es decir, pérdida de tiempo empleado en el desarrollo del proyecto Impacto Catastrófico Probabilidad 10% Exposición Bajo Plan de mitigación Realizar copias de seguridad en la nube, y en local cada vez que se realice algún documento o se haya avanzado consecuentemente en el trabajo 100 Plan de contingencia Evaluar el impacto y volver a planificar en consecuencia Tabla 3.52: R04 - Pérdida de datos o/y documentos Identificador R05 - Fallo en la máquina Descripción Avería del entorno de trabajo producida por causas naturales Impacto Crítico Probabilidad 25% Exposición Bajo Plan de mitigación Utilizar el ordenador de manera adecuada y cuidadosa, controlar posibles anomalías detectadas Plan de contingencia Arreglar u obtener otra máquina, y montar el entorno de nuevo ya que estará disponible en el repositorio remoto Tabla 3.53: R05 - Fallo en la máquina Identificador R06- Ausencia de comunicación Descripción No se consigue contacto entre el desarrollador y el cliente, y por tanto, no se puede continuar con el trabajo Impacto Crítico Probabilidad 60% Exposición Alto Plan de mitigación Contactar con antelación a los periodos críticos para detectar posibles errores cuanto antes Plan de contingencia Replanificar las tareas en tiempo para ocupar el margen de tiempo que se dejó, priorizar las tareas, realizarlas y reevaluar los riesgos Tabla 3.54: R06 - Ausencia de comunicación 101 Identificador R07 - Falta de comprensión de los requisitos Descripción No se han entendido correctamente algunos requisitos indispensables para el funcionamiento de la aplicación Impacto Crítico Probabilidad 60% Exposición Alto Plan de mitigación En las primera fases del proyecto, comunicar cualquier duda al cliente para realizar un análisis lo más cercano posible a los requerimientos Plan de contingencia Replanificar las tareas y corregir el error Tabla 3.55: R07 - Falta de comprensión de los requisitos Identificador R08 - Diseño mal elaborado Descripción El diseño no se ajusta a lo que realmente se requiere Impacto Crítico Probabilidad 50% Exposición Moderado Plan de mitigación Ante cualquier duda comunicárselo al cliente y realizarlo con respecto al documento de análisis previamente elaborado Plan de contingencia Replanificar las tareas y corregir el error Tabla 3.56: R08 - Diseño mal elaborado Identificador R09 - Conocimiento insuficiente sobre las tecnologías Descripción El tiempo que se ha establecido para aprender las tecnologías y herramientas a usar, no es suficiente para desarrollar todo lo que se requiere en la aplicación. Impacto Crítico 102 Probabilidad 40% Exposición Bajo Plan de mitigación Realizar una labor de investigación para ver que nivel de conocimiento se va a necesitar de cada tecnología, y establecer el tiempo de aprendizaje en base a las partes que se van a usar, para ser más precisos en tiempo. Plan de contingencia Replanificar las tareas y priorizarlas, dedicando más tiempo a la búsqueda de ejemplos y usos de las tecnologías desconocidas, para poder avanzar Tabla 3.57: R09 - Conocimiento insuficiente sobre las tecnologías Identificador R10 - Cambios en los requisitos Descripción Durante el desarrollo del proyecto se han encontrado nuevos requisitos que no se tuvieron en cuenta en un principio Impacto Crítico Probabilidad 10% Exposición Ninguno Plan de mitigación Centrarse en el análisis de requisitos y comentar las dudas en las primeras fases del proyecto. Tener claros los requisitos al inicio al ser un proyecto libre Plan de contingencia Evaluar el impacto, replanificar las tareas, priorizarlas y realizar las acciones necesarias para resolverlo Tabla 3.58: R10 - Cambios en los requisitos 3.3.3.2. Seguimiento de riesgos En esta sección, se detalla el seguimiento realizado de los riesgos producidos para cada una de las fases del proyecto. Seguimiento de la Fase de Inicio En esta fase de han producido los siguientes riesgos: - R02 - Indisponibilidad del desarrollador: No se ha dispuesto de disponibilidad para poder desarrollar las tareas en los días planificados. Se ha tenido que replanificar el desarrollo de esas tareas, de forma que se han realizado en otras fechas fuera del periodo planificado. 103 - R07 - Falta de compresión de los requisitos: Al ser el principio del proyecto, se han tenido bastantes dudas, respecto a los requisitos. Se ha solventado con la comunicación con el cliente. También se ha tenido que replanificar el desarrollo de tareas fuera del periodo establecido. En esta fase, como se puede ver en la Tabla 3.44 del punto 3.3.2.1. Seguimiento del plan de trabajo, la fecha de fin prevista era del día 10/12/17 y su fin real se ha producido el día 04/02/18. Por tanto, debido a los riesgos producidos, hemos obtenido un retraso en la entrega de dos meses, sin embargo se han dedicado los días de trabajo que fueron planificados. Seguimiento de la Fase de Elaboración - R02 - Indisponibilidad del desarrollador: No se ha dispuesto de disponibilidad para poder desarrollar las tareas en los días planificados. - R07 - Falta de compresión de los requisitos: Al ser el principio del proyecto, se han tenido bastantes dudas, respecto a los requisitos. - R06- Ausencia de comunicación: Al hacer el proyecto a distancia, se han producido problemas a la hora de resolución de dudas. - R09 - Conocimiento insuficiente sobre las tecnologías: El desconocimiento de las tecnologías de Spring Security y Angular Translate, han supuesto una desviación en los tiempos establecidos. - R10 - Cambios en los requisitos: Ha supuesto tareas adicionales de revisión de los requisitos, casos de uso, modelo de dominio y modelo de datos. Todos estos riesgos han supuesto la replanificación de tareas fuera del periodo de tiempo establecido, y por consiguiente, la ampliación de tiempo de finalización del proyecto. Como podemos ver en el punto 3.3.2.1. Seguimiento del plan de trabajo en la Tabla 3.45, en esta fase, el fin previsto era del día 16/02/18 y su fin real se ha producido el día 15/08/2018. En este caso, los días de trabajo han sido superiores a los planificados, concretamente en treinta y cinco días más, puesto que se han producido los riesgos comentados y además han surgido tareas de revisión. Seguimiento de la Fase de Construcción - R02 - Indisponibilidad del desarrollador: No se ha dispuesto de disponibilidad para poder desarrollar las tareas en los días planificados. - R03 - Enfermedad: Debido a enfermedad por parte del desarrollador, no se ha podido cumplir con las tareas en los días planificados. 104 Esto ha tenido como consecuencia el retraso en la entrega del proyecto, ya que se han tenido que replanificar las tareas para desarrollarlas en días no contemplados. De esta forma, como podemos ver en la Tabla 3.46 del apartado 3.3.2.1. Seguimiento del plan de trabajo, se han dedicado seis meses más para la consecución de esta fase, ya que su fecha de fin se planificó para el 02/06/2018 y se ha finalizado el 12/12/2018. En este caso, sólo ha supuesto el retraso en la entrega del proyecto, ya que el tiempo dedicado al desarrollo de la fase ha sido igual al planificado, 51 días. Seguimiento de la Fase de Transición En esta fase no se ha producido ningún riesgo, ya que se han desarrollado las tareas en los periodos de tiempo que se establecieron una vez realizada la replanificación en la fase anterior. Además, el tiempo dedicado para el desarrollo de la fase, ha sido de un día menos de los planificados, a pesar de surgir alguna nueva tarea. Cómo podemos ver en la Tabla 3.47 del apartado 3.3.2.1. Seguimiento del plan de trabajo, se han dedicado 7 meses más para la consecución de esta fase, ya que su fecha de fin se planificó para el 15/07/18, y se ha finalizado el 28/02/2019. La desviación en el tiempo de finalización se debe al retraso que ya llevaba el proyecto de las fases anteriores. 3.4. Presupuesto El proyecto contará con una persona como desarrollador, y además se necesitarán otra serie de recursos para poder realizarlo, entre ellas, un equipo y una serie de herramientas. En esta sección se describen todos los recursos necesarios para desarrollar el proyecto.  Recursos personales: En este caso el desarrollo lo realizará una persona, que irá adquiriendo diferentes roles a lo largo del proyecto, con diferentes costes asociados. Los roles a desempeñar serán: o Jefe de proyecto o Analista o Diseñador o Programador o Probador  Equipos y herramientas: Se necesitarán las siguientes herramientas para el desarrollo: o Ordenador portátil 105 o MSProyect o Astah Professional o IDE Eclipse o Google Drive o Postman o Spring Boot o MySQL o Bitbucket  Materiales: Otros materiales no informáticos: o Papel o Bolígrafos o Otros  Servicios necesarios: o Conexión a internet  Espacio: Principalmente, la aplicación se desarrollará en casa  Tiempo: En nuestro caso, acorde con la planificación, necesitaremos las siguientes horas de cada rol para la consecución del proyecto: o Jefe de proyecto - 160 horas o Analista - 88 horas o Diseñador - 176 horas o Programador - 408 horas o Probador - 80 horas  Dinero: Necesario para la adquisición de ciertos recursos. En base a todos estos recursos necesarios, se puede obtener un coste final estimado para el desarrollo del proyecto. El tiempo estimado necesario de cada uno de los roles que se han definido anteriormente, proviene de dividir en horas la planificación que se ha desarrollado con anterioridad en la calendarización. En este caso, puesto que el proyecto se va a desarrollar por una persona, con menos de un año de experiencia, el coste se calculará a partir del sueldo de un desarrollador junior, independientemente del rol, a excepción del rol: Jefe de proyecto, que tendrá otro coste. 112 Figura 4.1: Arquitectura lógica 4.2.1.1. Despliegue En la Figura 4.2, se representa el diagrama de despliegue de la aplicación. Contamos con una arquitectura cliente-servidor. En este caso, tenemos nuestra aplicación desplegada en un Apache Tomcat, que se conecta con el servidor de MySQL para acceder a la base de datos. Por otro lado, el cliente, que puede ser un ordenador, una tablet o un teléfono inteligente, se conecta a nuestro servidor a través de un navegador web por http. Figura 4.2: Diagrama de despliegue 113 4.2.2. Arquitectura Cliente En la Figura 4.3 se muestra la arquitectura en la parte Cliente. En este caso se está usando el patrón MVC, detallado en el punto 4.6.1. Patrón MVC. En la sección 4.7. Diseño más detallado, se detallan todos los artefactos que se encuentran dentro cada paquete y la funcionalidad de cada uno. Figura 4.3: Arquitectura del lado del cliente 4.2.3. Arquitectura Servidor En la Figura 4.4, se muestra la arquitectura en la parte Servidor. Como se puede observar, se está utilizando una arquitectura de capas. Tenemos la capa “controllers” que incluye los controladores que reciben las peticiones del cliente. Estos se conectan con la capa “services” que contiene los servicios disponibles, que se conectan con la capa “persistence”. Esta capa se encarga de la conexión con la base de datos, en ella se definen todas las consultas necesarias. La capa “resources” contiene todas las entidades del dominio. Por otro lado, disponemos de un paquete “exceptions” que dispone de todas las excepciones definidas en el sistema. También tenemos un paquete “conf”, que contiene las clases de configuración de la aplicación en el lado de servidor, e incluye otro paquete con la configuración de seguridad. El paquete “security” se conecta con la capa “services” para comprobar la existencia de un usuario cuando se inicia sesión en la aplicación. 114 Figura 4.4: Arquitectura del lado del servidor 4.3 Spring Framework En el desarrollo de nuestra aplicación, se ha optado por el uso de Spring. Se trata de un framework del lenguaje Java utilizado, principalmente, en el desarrollo de aplicaciones Java Empresariales (JEE). Como cualquier framework, facilita el desarrollo de las aplicaciones ofreciendo funcionalidades que pueden adaptarse a un sistema específico, sin tener que volver a implementarlas. Por tanto, permite desarrollar de forma más limpia, con menos líneas de código, y de forma más simple, facilitando el trabajo del programador. Spring permite desarrollar utilizando los principios de alta cohesión y bajo acoplamiento, a través del uso de interfaces y de unas capas bien diferenciadas. Además, promueve el uso de clases simples de Java (POJO) como objetos del negocio, para la configuración de servicios y la programación a través de interfaces. Es decir, trata el paradigma de programación AOP (Programación Orientada a Aspectos). Este propone la modularización de las aplicaciones y el reparto de responsabilidades entre los diferentes módulos, cada uno tendrá una responsabilidad. Este framework, se puede definir en base a dos patrones de software que son: la Inversión de Control, 4.6.4. Patrón IoC, y la Inyección de Dependencias, 4.6.3. Patrón DI. 115 Se divide en un conjunto de módulos que se pueden utilizar en el desarrollo de las aplicaciones. No tienen que utilizarse todos en una misma aplicación. En la Figura 4.5, se muestra un esquema con los módulos que Spring proporciona. Figura 4.5: Spring Framework Runtime [22] El Core Container es el componente principal de Spring. Este componente gestiona el ciclo de vida de los objetos, llamados Beans, desde su creación hasta su destrucción, y se encarga de inyectar un bean del tipo correspondiente en la variable que corresponda. Estos Beans pueden definirse en ficheros XML o, directamente, con código Java a través del uso de anotaciones. Como podemos observar también dispone de módulos para Web, módulos de acceso a datos, como ORM, además permite integrar tecnologías como JPA o Hibernate, ver 4.4. Hibernate. También dispone de un módulo, test, para realizar pruebas sobre el código. En definitiva, es un framework muy potente que, actualmente, se usa en gran variedad de proyectos, al ofrecer muchas posibilidades. Spring también dispone de proyectos, que facilitan el desarrollo y configuraciones iniciales de las aplicaciones. En nuestro caso, de la gran lista de proyectos de los que dispone, se han usado Spring Boot y Spring Security. 116 Spring Boot, es un proyecto de Spring, que permite la creación de un proyecto con parte de configuración ya incluida. Para desarrollar un proyecto Spring, necesitaríamos crear un proyecto Maven y descargar todas las dependencias necesarias a través del pom.xml, después desarrollar el código, y por último desplegar la aplicación en un servidor web. Spring Boot, facilita la creación del proyecto, ofrece la posibilidad de crearlo a través de un asistente vía web [23], añadiendo todas las dependencias que se necesiten. De esta forma, no se necesitarán pasos previos de configuración del proyecto a través de Maven. Ya tendremos nuestro proyecto con la estructura Maven configurada, y listo para ser lanzado, ya que Spring Boot, también provee de un servidor web para lanzar la aplicación. Por tanto, en nuestro proyecto, nos servirá para agilizar el proceso y desarrollo al inicio. Adicionalmente, también se tendrá que añadir configuración específica de nuestra aplicación, ya que esto es algo general. Spring Security, permite asegurar las aplicaciones desarrolladas con Spring. Ofrece funcionalidades de autenticación y de control de acceso, que se pueden adaptar de forma sencilla a cada aplicación específica. Protege contra ataques por fijación de sesiones, clickjacking, falsificación de solicitudes entre sitios, entre otros. En nuestro caso, desarrollaremos una aplicación creada a través de Spring Boot, que dispondrá de las dependencias Web, y de Seguridad. Además, también incluiremos la dependencia de JPA, que incluye ORM e Hibernate para el acceso a base de datos. 4.4 Hibernate Hibernate [24] es un framework ORM (Object-Relational Mapping) que facilita la relación entre la aplicación y la base de datos utilizada. Es una herramienta, disponible para aplicaciones Java, que permite el mapeo entre los atributos de una base de datos relacional y las entidades del dominio de la aplicación. El uso de Hibernate permite la realización automática de las operaciones básicas de acceso a datos, CRUD (Create Read Update Delete), que se utilizan en la mayoría de los casos. Es decir, con solo configurar Hibernate para nuestra aplicación, se pueden realizar de forma automática estas operaciones, y sólo tendríamos que crear nuevas consultas a la base de datos para las operaciones más complejas que se necesiten. Todo esto, se consigue a través de una serie de anotaciones que es necesario incluir en las clases del dominio, para realizar el mapeo con la tabla correspondiente de la base de datos. Hibernate puede usarse con JPA (Java Persistence API), que también ofrece una serie de definiciones y reglas para la persistencia. Aunque el uso de JPA no es necesario ya que Hibernate cuenta con lo que se necesita para realizar este mecanismo de persistencia, en nuestra aplicación también lo vamos a utilizar, ya que esta API nos ofrece diferentes clases que facilitan la realización de las consultas a la base de datos. Hibernate suele usarse con Spring, ya que estos dos frameworks, nos permiten desarrollar aplicaciones de forma ágil, sin tener que preocuparnos de realizar grandes labores de configuración, pudiendo centrarnos en el problema real a resolver. Es una forma de facilitar el desarrollo, y disponer de un código legible y mantenible. 117 4.5. Diseño de la API REST En este punto se detallan todas las características de la API REST separadas por cada uno de los recursos disponibles en la aplicación. 4.5.1. Autenticación GET /authentication Devuelve un usuario autenticado en el sistema. Ejemplo: http://localhost:8080/authentication Ejemplo de respuesta: { "login":"PatriPerez", "nombre":"Patricia Pérez Pérez", "email":"[email protected]", "avatar":"4", "juegos":[ { "idJuego":103, "nombre":"Mares de Europa", "visibilidad":{ "idTipoVisibilidad":3, "tipoVisibilidad":"publico" }, "fechaCreacion":1536570000000 } ], "partidasJugadas":[ ], "comentariosCreados":[ { } ], "logros":[ { } ] } 118 4.5.2. Login POST /login Realiza el login de un usuario con Spring Security. Los atributos se envían como parámetros de la petición. Header Valor content-type application/x-www-form-urlencoded Atributo Tipo Requerido Descripción username String Si Representa el id del usuario. password String Si Caracteres entre 7 y 12 Ejemplo: http://localhost:8080/login 4.5.3. Usuario POST /usuarios/registro Registra un nuevo usuario en el sistema. Atributo Tipo Requerido Descripción login String Si Representa el id del usuario. Debe seguir el siguiente formato con caracteres entre 3 y 12: [azA-zñÑ0-9] nombre String Si Caracteres entre 3 y 30 con formato: [a-zA- zäÄëËïÏöÖüÜáéíóúáéíóúÁÉÍÓÚÂÊÎÔÛâêîôûàèìòù ÀÈÌÒÙñÑ ] email String Si Máximo 30 caracteres con formato: ([a-z]|[A-Z]|[0- 9]|[\-,\_,\.])+@([a-z]|[A-Z]|[0-9]|[\-,\_,\.])+[a-z][az][a-z]? password String Si Caracteres entre 7 y 12 avatar Integer Si Número entre 0 y 7 119 Ejemplo:http://localhost:8080/usuarios/registro { “login”:“Rober22”, “nombre”:“Roberto García García”, “email”:“[email protected]”, “password”:“mypassword123”, “avatar”:"0" } Ejemplo de respuesta: No aplica GET /usuarios Obtiene todos los usuarios del sistema. Atributo Tipo Requerido Descripción text String No Si es vacío se devuelven todos los usuarios del sistema. Si se incluye, se obtienen los usuarios cuyo nombre o login contenga el valor de text. Ejemplo: http://localhost:8080/usuarios?text=pat Ejemplo de respuesta: [ { "login":"PatriPerez", "nombre":"Patricia Pérez Pérez", "email":"[email protected]", "avatar":"4", "juegos":[ { "idJuego":103, "nombre":"Mares de Europa", "visibilidad":{ "idTipoVisibilidad":3, "tipoVisibilidad":"publico" }, "fechaCreacion":1536570000000 } ], "partidasJugadas":[ ], "comentariosCreados":[{ }], "logros":[{}]] 120 GET /usuarios/:login Devuelve un usuario por login. Atributo Tipo Requerido Descripción login String Si Representa el id del usuario. Ejemplo: http://localhost:8080/usuarios/PatriPerez Ejemplo de respuesta: { "login":"PatriPerez", "nombre":"Patricia Pérez Pérez", "email":"[email protected]", "avatar":"4", "juegos":[ { "idJuego":103, "nombre":"Mares de Europa", "visibilidad":{ "idTipoVisibilidad":3, "tipoVisibilidad":"publico" }, "fechaCreacion":1536570000000 } ], "logros":[ { "id":{ "tipoLogro":{ "idTipoLogro":4, "logro":"Máster en España", "descripcion":"Se han conseguido 10 puntos de España", "puntosAConseguir":10, "idTipoPunto":null, "continente":null, "pais":"spain" } }, "fechaConseguido":1531422900000, "fechaModificacion":1536660972000, "tipoVisibilidad":{ "idTipoVisibilidad":3, "tipoVisibilidad":"publico"}}]} 121 GET /usuarios/:login/amigos Obtiene los amigos de un usuario concreto. Atributo Tipo Requerido Descripción login String Si Representa el id del usuario. Ejemplo: http://localhost:8080/usuarios/Rober22/amigos Ejemplo de respuesta: [ { "login":"Javi12", "nombre":"Javier López Diez", "email":"[email protected]", "avatar":"1", "juegos":[ { "idJuego":104, "nombre":"Cabos de españa", "visibilidad":{ "idTipoVisibilidad":2, "tipoVisibilidad":"amigos" }, "fechaCreacion":1536570000000 } ], "logros":[ { "id":{ "tipoLogro":{ "idTipoLogro":5, "logro":"Máster en Hidrografia", "descripcion":"Se han conseguido 5 puntoS de tipo hidrografico", "puntosAConseguir":5, "idTipoPunto":{ }, "continente":null, "pais":null } }, "fechaConseguido":1534097400000, "fechaModificacion":1536660972000, 128 Atributo Tipo Requerido Descripción login String Si Representa el id del usuario nombre String Si Caracteres entre 3 y 30 con formato: [a-zA- zäÄëËïÏöÖüÜáéíóúáéíóúÁÉÍÓÚÂÊÎÔÛâêîôûàèìò ùÀÈÌÒÙñÑ ] puntos JSON Si, debe incluir mínimo un punto Lista de puntos geográfico en formato json. En el punto 4.5.6. Punto geográfico, se describe el formato en el POST. Ejemplo: http://localhost:8080/usuarios/Cris2/juegos { "nombre":"Capitales de España", "puntos":[ { "nombre":"Valladolid", "latitud":"41.6521328", "longitud":"-4.728562", "pais":"spain", "continente":"europe", "tipoPunto":"politico" }, { "nombre":"Madrid", "latitud":"40.4167047", "longitud":"-3.7035825", "pais":"spain", "continente":"europe", "tipoPunto":"politico" } ] } Ejemplo de respuesta: No aplica GET /usuarios/:login/juegos Obtiene los juegos de un usuario. 129 Atributo Tipo Requerido Descripción login String Si Representa el id del usuario Ejemplo: http://localhost:8080/usuarios/Cris2/juegos Ejemplo de respuesta: [ { "idJuego":71, "nombre":"Capitales de España", "visibilidad":{ "idTipoVisibilidad":1, "tipoVisibilidad":"privado" }, "fechaCreacion":1548441166000 } ] GET /juegos Obtiene una serie de juegos por coincidencia con un texto. Atributo Tipo Requerido Descripción text String No Si es vacío se obtendrán todos los juegos con visibilidad pública o amigos (para amigos del usuario identificado). Si no es vacío, se obtendrán los juegos con visibilidad pública o amigos (para amigos del usuario identificado), cuyo nombre contenga el text introducido. Ejemplo: http://localhost:8080/juegos?text=cap Ejemplo de respuesta: [ { "idJuego":105, "nombre":"Capitales de españa", "visibilidad":{ "idTipoVisibilidad":3, "tipoVisibilidad":"publico" }, "fechaCreacion":1536656400000 } ] 130 GET /juegos/:idJuego Obtiene un juego por identificador. Atributo Tipo Requerido Descripción idJuego Integer Si Representa el id de un juego Ejemplo: http://localhost:8080/juegos/105 Ejemplo de respuesta: { "nombre":"Capitales de españa", "visibilidad":{ }, "creador":{ "login":"Rober22", "nombre":"Roberto García Muñ", "avatar":"7" }, "fechaCreacion":1536656400000, "fechaModificacion":1536656400000, "partidas":[ ], "comentarios":[ { "idComentario":100, "descripcion":"Me ha gustado mucho, jugar si podéis.", "fechaCreacion":1536570000000, "fechaModificacion":1536570000000, "creador":{ "login":"PatriPerez", "nombre":"Patricia Pérez Pérez", "avatar":"0" } }, { "idComentario":101, "descripcion":"Lo he creado para ayuda de todos. ¡Aprender las capitales de España ya!", "fechaCreacion":1536656400000, "fechaModificacion":1536656400000, "creador":{ "login":"Rober22", "nombre":"Roberto García Muñ", "avatar":"7" 131 } } ], "puntos":[ { "idPunto":106, "nombre":"Madrid", "latitud":40.4167047, "longitud":-3.7035825, "pais":"spain", "continente":"europe", "idTipoPunto":{ "idTipoPunto":4, "tipoPunto":"politico" } }, { "idPunto":107, "nombre":"Valladolid", "latitud":41.6521328, "longitud":-4.728562, "pais":"spain", "continente":"europe", "idTipoPunto":{ "idTipoPunto":4, "tipoPunto":"politico" } } ] } PUT /usuarios/:login/juegos/:idJuego Actualiza los datos de un juego. Atributo Tipo Requerido Descripción login String Si Representa el id de un usuario idJuego Integer Si Representa el id de un juego nombre String Solo si no se ha introducido visibilidad Caracteres entre 3 y 30 con formato: [a-zA- zäÄëËïÏöÖüÜáéíóúáéíóúÁÉÍÓÚÂÊÎÔÛâêîôûàèìòùÀÈ ÌÒÙñÑ ] 132 visibilidad Integer Solo si no se ha introducido nombre Número entre 1 y 3: 1. Privada. 2. Amigos 3. Pública Ejemplo: http://localhost:8080/usuarios/Cris2/juegos/71?visibilidad=3 Ejemplo de respuesta: { "idJuego":71, "nombre":"Capitales de España", "visibilidad":{ "idTipoVisibilidad":3, "tipoVisibilidad":"publico" }, "fechaCreacion":1548441166000 } DELETE /usuarios/:login/juegos/:idJuego Elimina un juego por identificador Atributo Tipo Requerido Descripción login String Si Representa el id de un usuario idJuego Integer Si Representa el id de un juego Ejemplo: http://localhost:8080/usuarios/Cris2/juegos/71 Ejemplo de respuesta: No aplica 4.5.6. Punto geográfico POST /juegos/:idJuego/puntos Agregar un nuevo punto geográfico a un juego Atributo Tipo Requerido Descripción idJuego Integer Si Representa el id de un juego nombre String Si Caracteres que representan el nombre del punto 133 latitud Double Si Representa a latitud geográfica de un punto longitud Double Si Representa la longitud geográfica de un punto idTipoPunto JSON Si Deber tener el formato:{ "tipoPunto":"politico" } El tipoPunto puede tener los siguientes valores: “politico, “hidrografico”, “relieve” o “costero” pais String Si Caracteres que representa el país del punto continente String Si Caracteres que representan un continente Ejemplo:http://localhost:8080/juegos/74/puntos { "nombre":"Salamanca", "latitud":"40.9651572", "longitud":"-5.6640182", "idTipoPunto":{ "tipoPunto":"politico" }, "pais":"spain", "continente":"europe” } Ejemplo de respuesta: No aplica GET /juegos/:idJuego/puntos Obtiene los puntos geográficos de un juego Atributo Tipo Requerido Descripción idJuego Integer Si Representa el id de un juego Ejemplo:http://localhost:8080/juegos/74/puntos Ejemplo de respuesta: [ { "idPunto":75, "nombre":"Madrid", 134 "latitud":40.4167047, "longitud":-3.7035825, "pais":"spain", "continente":"europe", "idTipoPunto":{ "idTipoPunto":4, "tipoPunto":"politico" } }, { "idPunto":76, "nombre":"Valladolid", "latitud":41.6521328, "longitud":-4.728562, "pais":"spain", "continente":"europe", "idTipoPunto":{ "idTipoPunto":4, "tipoPunto":"politico" } }, { "idPunto":77, "nombre":"Salamanca", "latitud":40.9651572, "longitud":-5.6640182, "pais":"spain", "continente":"europe", "idTipoPunto":{ "idTipoPunto":4, "tipoPunto":"politico" } } ] DELETE /juegos/:idJuego/puntos/:idPunto Elimina un punto de un juego por identificador Atributo Tipo Requerido Descripción idJuego Integer Si Representa el id de un juego idPunto Integer Si Representa el id de un punto geográfico 135 Ejemplo: http://localhost:8080/juegos/74/puntos/75 Ejemplo de respuesta: No aplica 4.5.7. Partida POST /juegos/:idJuego/partidas Crea una nueva partida de un juego Atributo Tipo Requerido Descripción idJuego Integer Si Representa el id de un juego puntuacion Integer Si Número con los puntos obtenidos. Debe ser mayor o igual que 0. modalidadJuego JSON Si JSON con formato: { "modalidad":"localizar" } El valor de modalidad puede ser: “localizar” o “nombrar”. nivelDificultad JSON Si JSON con formato: { "nivelDificultad":"medio" } El valor de nivelDificultad puede ser: “facil”, “medio” o “avanzado”. puntosAcertados JSON Si Debe tener el formato que se describe en el POST de un punto en 4.5.5. Punto geográfico puntosFallados JSON Si Debe tener el formato que se describe en el POST de un punto en 4.5.5. Punto geográfico Ejemplo: http://localhost:8080/juegos/74/partidas { "puntuacion":5, "modalidadJuego":{ "modalidad":"localizar" }, "nivelDificultad":{ "nivelDificultad":"medio" 136 }, "puntosAcertados":[ { "idPunto":76, "nombre":"Valladolid", "latitud":41.6521328, "longitud":-4.728562, "pais":"spain", "continente":"europe", "idTipoPunto":{ "idTipoPunto":4, "tipoPunto":"politico" } } ], "puntosFallados":[ { "idPunto":77, "nombre":"Salamanca", "latitud":40.9651572, "longitud":-5.6640182, "pais":"spain", "continente":"europe", "idTipoPunto":{ "idTipoPunto":4, "tipoPunto":"politico" } } ] } Ejemplo de respuesta: No aplica 4.5.8. Comentario POST /juegos/:idJuego/comentarios Agrega un nuevo comentario a un juego Atributo Tipo Requerido Descripción idJuego Integer Si Representa el id de un juego creador String Si Representa el id del usuario que crea el comentario descripcion String Si Caracteres con un mínimo de 3 y un máximo de 150 137 Ejemplo: http://localhost:8080/juegos/74/comentarios { "creador":"Cris2", "descripcion":"Hola soy un nuevo comentario" } Ejemplo de respuesta: No aplica GET /juegos/:idJuego/comentarios Obtiene los comentarios de un juego Atributo Tipo Requerido Descripción idJuego Integer Si Representa el id de un juego Ejemplo: http://localhost:8080/juegos/74/comentarios Ejemplo de respuesta: [ { "idComentario":79, "descripcion":"Hola soy un nuevo comentario", "fechaCreacion":1548444562000, "fechaModificacion":1548444562000, "creador":{ "login":"Cris2", "nombre":"Cristina Gómez", "avatar":"0" } }, { "idComentario":80, "descripcion":"Otro comentario", "fechaCreacion":1548444866000, "fechaModificacion":1548444866000, "creador":{ "login":"Cris2", "nombre":"Cristina Gómez", "avatar":"0" } } ] 144 Figura 4.7: Controllers Disponemos del paquete services, que incluye los servicios que se encargan de realizar las llamadas HTTP al servidor y devolver la respuesta a los controladores. En la figura 4.8, se detallan los servicios definidos. Figura 4.8: Services También disponemos de un paquete css que incluye el estilos.css que contiene todos los estilos definidos para la capa de presentación. Además, dentro de este paquete también disponemos de un directorio images, que contiene las imágenes que se usan en la aplicación, y otro directorio iconos, que contiene los iconos de avatar disponibles. 145 En el paquete lib se incluyen todas las librerías utilizadas, detalladas en la Figura 4.9. Figura 4.9: Lib El paquete translations, ver Figura 4.10, contiene los json de cada idioma, en este caso, disponemos de dos idiomas Español e Inglés, teniendo un json para cada uno: es.json y en.json. Figura 4.10: Translations 146 4.8. Modelo de datos En la Figura 4.11 se incluye el modelo entidad-relación de la base de datos. En este diagrama se representan las tablas, las relaciones entre ellas y los campos necesarios para la aplicación. Figura 4.11: Diagrama Entidad-Relación 147 4.9. Diseño de la Interfaz de Usuario Para el desarrollo de la capa de presentación, o lado del cliente, se utilizará el framework AngularJS. Además, se usará el patrón MVC que ofrece este framework para desarrollar esta parte de la aplicación. En el punto 4.6.1. Patrón MVC, se detalla cómo se usa el patrón MVC a través de AngularJS, y en el punto 4.2.2. Arquitectura Cliente, se representa su uso en el sistema. 4.10. Realización en diseño de casos de uso En este punto, se detalla la comunicación entre las diferentes capas del lado del cliente y del servidor para realizar un caso de uso concreto. Para explicar esta interacción, en el punto 4.10.1. Crear juego, se muestra el diagrama de realización del caso de uso Crear juego. Sólo se ha detallado un único caso de uso, ya que todos los demás siguen la misma lógica. 4.10.1. Crear juego En las siguientes figuras, Figura 12 a la Figura 23, se muestra la realización en diseño del caso de uso Crear juego mediante diagramas de secuencia. En la Figura 12, podemos ver la secuencia principal de este caso de uso, en la cual aparecen las clases principales que participan tanto del lado cliente como del lado servidor. En las siguientes figuras, desde la Figura 13 hasta la Figura 23, se muestra el detalle de cada parte que compone la secuencia principal de este caso de uso. 148 Figura 4.12: Secuencia principal para Crear Juego 149 Figura 4.13: Agregar punto en la vista Figura 4.14: Buscar punto geográfico 150 Figura 4.15: Añadir punto en la vista Figura 4.16: Obtener usuario 151 Figura 4.17: Proceso para crear un juego en lado servidor 152 Figura 4.18: Obtener datos del json del juego Figura 4.19: Obtener tipo visibilidad Figura 4.20: Obtener tipo de punto geográfico 153 Figura 4.21: Crear juego Figura 4.22: Obtener datos json del punto geográfico