HandbApp Score. App Score de partidos de balonmano

Escuela Ingenier´ıa Inform´atica Trabajo de fin de grado Grado en Ingenier ´ ıa Inform´ atica Menci´ on Tecnolog ´ ıas de la Informaci´ on HandbApp Score. App Score de partidos de balonmano Autor: Mar´ıa Varela Alonso Escuela Ingenier´ıa Inform´atica Trabajo de fin de grado Grado en Ingenier ´ ıa Inform´ atica Menci´ on Tecnolog ´ ıas de la Informaci´ on HandbApp Score. App Score de partidos de balonmano Autor: Mar´ıa Varela Alonso Tutora: Margarita Gonzalo Tasis Contenidos 1. Introducci´on 11 1.1. Motivaci´on ............................................ 11 1.2. Objetivos ............................................. 11 1.3. Estructuradelamemoria .................................... 12 1.4. Reglasdelbalonmano ...................................... 12 1.5. An´alisis de aplicaciones similares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.5.1. HandballScoreboard................................... 13 1.5.2. Scoreboard Handball ++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.5.3. Conclusiones extra´ıdas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2. Planificaci´on del proyecto 15 2.1. Introducci´on............................................ 15 2.1.1. Prop´osito, alcance y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2. Gesti´ondelproyecto ....................................... 15 2.2.1. Metodolog´ıa........................................ 15 2.2.2. Restricciones ....................................... 17 2.2.3. Estructura organizativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3. Plandetrabajo.......................................... 18 2.4. Plandegesti´onderiesgos .................................... 21 2.5. Seguimientodelproyecto..................................... 24 2.6. Presupuesto............................................ 25 3. An´alisis del sistema 27 3.1. Requisitos............................................. 27 3.1.1. Requisitosfuncionales .................................. 27 3.1.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.1.3. Reglasdenegocio..................................... 28 3.2. Casosdeuso ........................................... 29 3.2.1. Descripci´on de los casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3. Modelodedominio........................................ 39 3.4. Diagramadeactividad...................................... 39 3.5. Diagramadesecuencia...................................... 51 4. Dise˜no 66 4.1. Arquitecturadelsistema..................................... 66 4.2. Patrones.............................................. 68 4.2.1. Patr´onMVVM...................................... 68 4.2.2. Patr´onDAO ....................................... 69 4.2.3. Patr´onCommand .................................... 69 2 CONTENIDOS 3 4.2.4. Patr´onFactory...................................... 69 4.2.5. Patr´onSingleton ..................................... 69 4.2.6. Patr´onObserver ..................................... 69 4.3. CiclodevidadeActivities.................................... 69 4.4. Diagramadedespliegue ..................................... 70 4.5. Dise˜nodelabasededatos.................................... 70 4.6. Privacidad............................................. 71 4.7. Dise˜nodelainterfaz ....................................... 72 4.7.1. Prototipoinicial ..................................... 73 5. Implementaci´on 76 5.1. Herramientasutilizadas ..................................... 76 5.1.1. IntelliJ........................................... 76 5.1.2. Java............................................ 76 5.1.3. SQLite........................................... 77 5.1.4. VisualParadigm ..................................... 77 5.1.5. Github........................................... 78 5.1.6. MicrosoftProject..................................... 78 5.2. Controldeversiones ....................................... 78 5.3. Versiones de Android soportadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6. Pruebas 80 6.1. Listadodepruebas........................................ 80 6.2. Resultados............................................. 82 6.3. Pruebas de interfaz con usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 7. Conclusiones 90 7.1. Trabajofuturo .......................................... 90 Bibliograf´ıa 91 Anexos A. Manual de instalaci´on 94 B. Manual de usuario 96 Lista de figuras 1.1. Captura de pantalla de la aplicaci´on Handball Scoreboard. . . . . . . . . . . . . . . . . . . 14 1.2. Captura de pantalla de la aplicaci´on Scoreboard Handball++ . . . . . . . . . . . . . . . . 14 2.1. ProcesoUnificado. ........................................ 16 2.2. FasesdeProcesoUnificado. ................................... 17 2.3. Calendarizaci´on de la fase de inicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4. Diagrama de Gantt de la fase inicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.5. Calendarizaci´on de la fase de elaboraci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.6. Diagrama de Gantt de la fase de elaboraci´on. . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.7. Calendarizaci´on de la fase de construcci´on primera iteraci´on. . . . . . . . . . . . . . . . . 19 2.8. Diagrama de Gantt de la fase construcci´on primera iteraci´on. . . . . . . . . . . . . . . . . 20 2.9. Calendarizaci´on de la fase de construcci´on segunda iteraci´on. . . . . . . . . . . . . . . . . 20 2.10. Diagrama de Gantt de la fase construcci´on segunda iteraci´on. . . . . . . . . . . . . . . . . 20 2.11. Calendarizaci´on de la fase de transici´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.12. Diagrama de Gantt de la fase de transici´on. . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1. DiagramadeCasosdeUso. ................................... 29 3.2. Modelodedominio. ....................................... 39 3.3. Diagrama de Actividad UC001. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.4. Diagrama de Actividad UC002. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.5. Diagrama de Actividad UC003. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.6. Diagrama de Actividad UC004. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.7. Diagrama de Actividad UC005. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.8. Diagrama de Actividad UC006. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.9. Diagrama de Actividad UC007. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.10. Diagrama de Actividad UC008. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.11. Diagrama de Actividad UC009. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.12. Diagrama de Actividad UC010. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.13. Diagrama de Actividad UC011. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.14. Diagrama de Actividad UC012. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.15. Diagrama de Actividad UC013. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.16. Diagrama de Actividad UC014. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.17. Diagrama de Actividad UC015. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.18. Diagrama de Actividad UC016. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.19. Diagrama de Actividad UC017. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.20. Diagrama de Actividad UC018. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.21. Diagrama de Actividad UC019. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.22. Diagrama de Actividad UC020. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.23.SD001.A˜nadirjugador. ..................................... 51 4 LISTA DE FIGURAS 5 3.24.SD002.Configurarpartido. ................................... 51 3.25.SD003.Cambiodejugador. ................................... 52 3.26.SD004.Consultardatos...................................... 53 3.27. SD005. Seleccionar jugador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.28.SD006.Recuperaci´on. ...................................... 55 3.29.SD007.Sumargoljugador. ................................... 56 3.30.SD008.Tirarpenalti........................................ 57 3.31.SD009.Tirarapuerta....................................... 57 3.32.SD010.Exclusi´on. ........................................ 58 3.33.SD011.A˜nadirfalta........................................ 59 3.34.SD012.TarjetaAmarilla. .................................... 60 3.35.SD013.Tarjetaroja. ....................................... 61 3.36.SD014.Tiempomuerto. ..................................... 61 3.37. SD015. Reanudar tiempo muerto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.38.SD016.Sumargolalequipo................................... 62 3.39. SD017. Restar gol al jugador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.40. SD018. Restar gol al equipo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.41.SD019.Crearequipo........................................ 65 3.42.SD020.Crearpartido. ...................................... 65 4.1. Diagramadepaquetes....................................... 66 4.2. Diagrama decomposition style del paquete Modelo. . . . . . . . . . . . . . . . . . . . . . . 67 4.3. Diagrama decomposition style del paquete ViewModel. . . . . . . . . . . . . . . . . . . . . 67 4.4. Diagrama decomposition style del paquete Vista. . . . . . . . . . . . . . . . . . . . . . . . 67 4.5. Diagrama decomposition style del paquete datos. . . . . . . . . . . . . . . . . . . . . . . . 68 4.6. EsquemaPatr´onMVVM. .................................... 68 4.7. Ciclo de vida de una actividad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.8. Diagramadedespliegue...................................... 70 4.9. Diagrama entidad-relaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.10.Bocetopantallainicial....................................... 73 4.11. Boceto pantalla a˜nadir jugadores al equipo. . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.12. Boceto pantalla cambiar tiempos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.13.Bocetopantalladejuego. .................................... 74 4.14. Boceto pantalla estad´ıstica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.1. LogotipoIntelliJIDEA. ..................................... 76 5.2. LogotipoJava. .......................................... 76 5.3. LogotipoSQLite ......................................... 77 5.4. LogotipoVisualParadigm. ................................... 77 5.5. LogotipoGithub.......................................... 78 5.6. Logotipo Microsoft Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.7. Tabla versiones de Android y distribuci´on acumulativa. . . . . . . . . . . . . . . . . . . . 79 5.8. Tabla versiones de Android con porcentaje real. . . . . . . . . . . . . . . . . . . . . . . . . 79 A.1. Captura de pantalla de instalaci´on de aplicaciones de origen desconocido en Xiaomi. . . . 94 A.2. Activar instalaci´on de fuentes desconocidas Samsung J5. . . . . . . . . . . . . . . . . . . . 94 A.3. Captura de pantalla para instalar la aplicaci´on Handbapp Score. . . . . . . . . . . . . . . 95 A.4. Captura de pantalla para abrir la aplicaci´on Handbapp Score. . . . . . . . . . . . . . . . . 95 B.1.PrimerapantallaHandbapp.................................... 96 6LISTA DE FIGURAS B.2. Pantalla configuraci´on Handbapp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 B.3. Pantalla a˜nadir jugadores Handbapp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 B.4. Pantalla iniciar partido Handbapp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 B.5. Pantalla partido creado Handbapp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 B.6.Botonesdeljugador........................................ 99 B.7. Pantalla men´u del jugador Handbapp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 B.8.Muestradatosdelpartido..................................... 100 B.9.Cambiodejugador......................................... 100 B.10.Cambio de jugador realizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 B.11.Resultadofinal .......................................... 101 Lista de tablas 2.1. Exposici´onalriesgo. ....................................... 22 2.2. Riesgo R001. Fallo de la planificaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3. Riesgo R002. Disponibilidad del desarrollador . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.4. Riesgo R003. Falta de conocimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5. Riesgo R004. P´erdida de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.6. Riesgo R005. Dise˜no incorrecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.7. Riesgo R006. Fallo en el entorno de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.8. Riesgo R007. Modificaci´on de requisitos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.9. Planificaci´on real del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.10.Presupuestocostesfijos. ..................................... 25 2.11.Presupuesto............................................ 26 3.1. Requisitosfuncionales....................................... 27 3.2. Requisitosnofuncionales. .................................... 28 3.3. Reglasdenegocio. ........................................ 28 3.4. UC001.A˜nadirjugadores..................................... 30 3.5. UC002.Configurarpartido. ................................... 30 3.6. UC003.Cambiodejugador.................................... 31 3.7. UC004.Consultardatos...................................... 31 3.8. UC005. Seleccionar jugador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.9. UC006.Recuperaci´on. ...................................... 32 3.10.UC007.Sumargol......................................... 33 3.11.UC008.Tirarpenalti. ...................................... 33 3.12.UC009.Tirarapuerta....................................... 34 3.13.UC010.Exclusi´on. ........................................ 34 3.14.UC011.A˜nadirfalta. ...................................... 35 3.15.UC012.Tarjetaamarilla. .................................... 35 3.16.UC013.Tarjetaroja. ...................................... 36 3.17.UC014.Tiempomuerto...................................... 36 3.18. UC015. Reanudar tiempo muerto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.19. UC016. A˜nadir gol al equipo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.20. UC017. Restar gol al jugador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.21. UC018. Restar gol al equipo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.22.UC019.Crearequipo. ...................................... 38 3.23.UC020.Crearpartido........................................ 39 6.1. CP001. A˜nadir jugadores a un equipo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.2. CP002. A˜nadir menos o ning´un jugadores titulares de los seleccionados. . . . . . . . . . . 82 6.3. CP003. A˜nadir un equipo sin nombre. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 7 1.5. AN ´ ALISIS DE APLICACIONES SIMILARES CAP´ ITULO 1. INTRODUCCI ´ ON Figura 1.1: Captura de pantalla de la aplicaci´on Handball Scoreboard. 1.5.2. Scoreboard Handball ++ La aplicaci´on m´ovil Scoreboard Handball ++ es un marcador al uso con las funcionalidades b´asicas. Consta de dos pantallas, una de configuraci´on en la que podemos cambiar los minutos y el n´umero de partes del partido, el n´umero de segundos que va a tener la exclusi´on y si se va a tener tiempo muerto o no. Adem´as se puede activar un sonido para cuando acabe el tiempo. En la pantalla del partido se puede cambiar el nombre a cada equipo, sumar goles al marcador y marcar el tiempo muerto y una exclusi´on de cada equipo. Las valoraciones de los usuarios son positivas y destacan la rapidez a la hora de insertar los datos en los partidos. Como puntos d´ebiles podemos destacar que no sabemos que jugador es el que marca el tanto o al que excluyen. Adem´as no se tiene en cuenta el resto de acciones que pueden ocurrir en un partido. Los usuarios de Play Store la valoran de forma positiva a pesar de a˜nadir que es muy sencilla y simplemente les vale como un tablero digital, no como una pizarra para anotar las acciones. Mi opini´on sobre esta aplicaci´on es que le faltan muchas funcionalidades para que sea una aplicaci´on completa de balonmano. No se pueden a˜nadir jugadores, no podemos marcar las acciones de ellos, solo se puede excluir simult´aneamente una vez por equipo. Es una aplicaci´on sencilla que solo valdr´ıa para llevar el conteo de los goles de los equipos como si fuera un tablero digital. Figura 1.2: Captura de pantalla de la aplicaci´on Scoreboard Handball++ 1.5.3. Conclusiones extra´ıdas Del an´alisis de las aplicaciones anteriores se puede concluir que son aplicaciones sencillas y pr´acticas pero que ninguna llega a tener todas las acciones que pueden ocurrir a lo largo del partido. Para las personas que quieran llevar un control del partido total no son unas aplicaciones v´alidas porque son bastante limitadas. 14 Cap´ıtulo 2 Planificaci´on del proyecto 2.1. Introducci´on En esta secci´on se muestra una visi´on general del desarrollo del proyecto. Este TFG ha sido ofertado por la profesora Margarita Gonzalo Tasis con la finalidad de crear una aplicaci´on m´ovil para poder usarse en partidos de balonmano y poder llevar un registro tanto de los goles como de las situaciones y acciones que ocurren durante el transcurso de dichos partidos. 2.1.1. Prop´osito, alcance y objetivos El objetivo de este proyecto es la creaci´on de una aplicaci´on para m´ovil con Sistema Operativo Android mediante la cual se podr´a anotar las diferentes acciones que van ocurren en directo en un partido de balonmano. Esta aplicaci´on permitir´a al usuario la creaci´on de los dos equipos que vayan a disputar el partido y a˜nadir a los jugadores. Una vez el partido haya comenzado se podr´a sumar goles, marcar los diferentes tipos de tarjetas, ver el tiempo que queda y otras funcionalidades que son detalladas en los siguientes cap´ıtulos. 2.2. Gesti´on del proyecto 2.2.1. Metodolog´ıa Para la creaci´on de este proyecto se aplicar´a Proceso Unificado[1]. Es un proceso que se caracteriza por estar dirigido por los casos de uso, adem´as es iterativo e incremental. Est´a compuesto de cuatros fases: inicio, elaboraci´on, construcci´on y transici´on. El resultado de cada iteraci´on es un programa ejecutable aunque est´e incompleto, se ir´an realizando diferentes iteraciones hasta que est´e completamente desarrollado. 15 2.2. GESTI ´ ON DEL PROYECTO CAP´ ITULO 2. PLANIFICACI ´ ON DEL PROYECTO Figura 2.1: Proceso Unificado. Inicio: Se desarrolla una descripci´on del producto final y se presenta el an´alisis del proyecto. •Determinar objetivos. •Encontrar una arquitectura adecuada. •Planteamiento de los casos de uso. •Estimaci´on de los riesgos. Elaboraci´on: Se elaboran los requisitos de dise˜no y se encuentra una arquitectura estable para la fase de construcci´on. •Crear la arquitectura. •Establecer un plan para las siguientes iteraciones. •Casos de uso que describen la funcionalidad del sistema. •Plan de proyecto que contenga costes, un calendario y los componentes que se van a utilizar. Construcci´on: Se crea el producto. Al final de esta fase el producto tiene todos los casos de uso implementados aunque puede tener fallos. •Optimizaci´on de procesos. •Minimizar costes. •Completar el an´alisis y dise˜no para realizar pruebas. •Conseguir versiones funcionales. •Manual inicial de usuario. Transici´on: Se termina el proyecto y el software queda disponible para el usuario final. •Pruebas para validar el sistema. •Manual de usuario terminado para que se valga por si mismo a la hora de usar la aplicaci´on. •Reajustes de la aplicaci´on para que cumpla con los requisitos esperados. •Despliegue del producto final. 16 CAP´ ITULO 2. PLANIFICACI ´ ON DEL PROYECTO 2.2. GESTI ´ ON DEL PROYECTO Figura 2.2: Fases de Proceso Unificado. 2.2.2. Restricciones Las restricciones respecto al sistema son: 1. Restricciones de planificaci´on: Se llevar´a un seguimiento del desarrollo del sistema. El proyecto debe estar finalizado antes de la convocatoria de fin de grado julio 2021. 2. Restricciones de aplicaci´on: La interfaz debe estar hecha para un tel´efono en posici´on horizontal y para cualquier dispositivo m´ovil. El sistema operativo debe ser Android. La aplicaci´on ser´a instalable en dispositivos Android cuya versi´on de API sea igual o superior a la 23 (Android 6.0 Marshmallow). Seg´un el sitio Web de desarroladores de Android se cubre el 84.9 % de los dispositivos en los que se puede usar [5]. 2.2.3. Estructura organizativa Dentro de un equipo de proyecto encontramos los siguientes roles: Jefe de proyecto: Se encarga de planificar, definir y asignar recursos y responsabilidades, coordinar y supervisar. Gestiona t´ecnicamente el proyecto y se encarga de la interacci´on con el cliente. Analista: Su responsabilidad es la especificaci´on de requisitos para posteriormente poder dise˜nar el sistema. Dise˜nador: Se encarga de realizar el dise˜no de software a partir de los requisitos. Programador: Desarrolla el software en funci´on del dise˜no y los requisitos. Tester: Encargados de hacer pruebas en el proyecto para as´ı poder encontrar posibles fallos o mejoras. Generalmente son personas externas al equipo. Este proyecto estar´a formado por una ´unica persona que realizar´a cada uno de los roles en el momento que sea oportuno. 17 2.3. PLAN DE TRABAJO CAP´ ITULO 2. PLANIFICACI ´ ON DEL PROYECTO 2.3. Plan de trabajo Un plan de trabajo es una herramienta que se utiliza para la planificaci´on y organizaci´on de un proyecto, de forma que se pueda tener una visi´on del trabajo a realizar con objetivos y cronogramas definidos. A continuaci´on se detallar´a la planificaci´on inicial de las tareas que se van a realizar a lo largo del proyecto en cada una de las fases junto con la duraci´on estimada para ellas. Estos tiempos pueden varias a lo largo del desarrollo. Se ha estimado que se trabajar´a en el proyecto de lunes a viernes, con un tiempo de 20 horas a la semana. La duraci´on total del proyecto se estima para 77 d´ıas, que ser´ıan unas 308 horas en completar todo el proyecto. Figura 2.3: Calendarizaci´on de la fase de inicio. Figura 2.4: Diagrama de Gantt de la fase inicio. 18 CAP´ ITULO 2. PLANIFICACI ´ ON DEL PROYECTO 2.3. PLAN DE TRABAJO Figura 2.5: Calendarizaci´on de la fase de elaboraci´on. Figura 2.6: Diagrama de Gantt de la fase de elaboraci´on. Figura 2.7: Calendarizaci´on de la fase de construcci´on primera iteraci´on. 19 2.3. PLAN DE TRABAJO CAP´ ITULO 2. PLANIFICACI ´ ON DEL PROYECTO Figura 2.8: Diagrama de Gantt de la fase construcci´on primera iteraci´on. Figura 2.9: Calendarizaci´on de la fase de construcci´on segunda iteraci´on. Figura 2.10: Diagrama de Gantt de la fase construcci´on segunda iteraci´on. 20 CAP´ ITULO 2. PLANIFICACI ´ ON DEL PROYECTO 2.4. PLAN DE GESTI ´ ON DE RIESGOS Figura 2.11: Calendarizaci´on de la fase de transici´on. Figura 2.12: Diagrama de Gantt de la fase de transici´on. 2.4. Plan de gesti´on de riesgos La finalidad de la gesti´on de riesgos es identificar, analizar y tratar los riesgos que pueden ocurrir durante el desarrollo de un proyecto. Las fases de la gesti´on de riesgos son: 1. Identificar: Localizar los riesgos antes de que se presenten. 2. Analizar: Evaluar el impacto y la probabilidad. 21 2.4. PLAN DE GESTI ´ ON DE RIESGOS CAP´ ITULO 2. PLANIFICACI ´ ON DEL PROYECTO 3. Planificar: Elaborar un plan de actuaci´on para en caso de que ocurra un riesgo saber como actuar para as´ı disminuir el efecto del riesgo. 4. Monitorizar: Seguir los indicadores de riesgo durante el proyecto. Para poder saber el impacto que un riesgo va a tener en un proyecto es necesario realizar una cuantificaci´on de riesgos [3]. El porcentaje asociado a cada probabilidad es el siguiente: Muy alto: 80 %-100 % Alto: 60 %-80 % Medio: 40 %-60 % Bajo: 20 %-40 % Muy bajo: 0 %-20 % Impacto/Probabilidad Muy Alto Alto Medio Bajo Muy Bajo Catastr´ofico Alto Alto Moderado Moderado Bajo Cr´ıtico Alto Alto Moderado Bajo Ninguno Marginal Moderado Moderado Bajo Ninguno Ninguno Despreciable Moderado Bajo Bajo Ninguno Ninguno Tabla 2.1: Exposici´on al riesgo. Una vez que el grado de exposici´on al riesgo se sabe, se crea un plan de contingencia que es un plan alternativo que se utiliza si uno de los riesgos previstos ocurre. De esta forma se reducir´a el impacto negativo de un evento de riesgo. A continuaci´on se va a mostrar el an´alisis de los riesgos identificados para este proyecto. Fallo de la planificaci´on Identificador R001 Descripci´on No se cumplen los tiempos estimados en la calendarizaci´on anterior. Impacto Cr´ıtico Probabilidad Alto Exposici´on Alto Plan de contingencia Volver a planificar las tareas en la calendarizaci´on para poder desarrollarlo en el mejor tiempo posible. Tabla 2.2: Riesgo R001. Fallo de la planificaci´on 22 CAP´ ITULO 2. PLANIFICACI ´ ON DEL PROYECTO 2.4. PLAN DE GESTI ´ ON DE RIESGOS Disponibilidad del desarrollador Identificador R002 Descripci´on Retraso en el trabajo establecido debido a la situaci´on laboral del desarrollador o a una baja temporal por motivos de salud o personales. Impacto Cr´ıtico Probabilidad Medio Exposici´on Moderado Plan de contingencia Reorganizar el trabajo en base a la disponibilidad del desarrollador y de las prioridades de las tareas. Dedicar d´ıas no laborables para intentar recuperar el tiempo que se ha retrasado. Tabla 2.3: Riesgo R002. Disponibilidad del desarrollador Falta de conocimiento Identificador R003 Descripci´on No se tienen las habilidades para poder desarrollar el proyecto correctamente. Impacto Cr´ıtico Probabilidad Bajo Exposici´on Bajo Plan de contingencia Investigar y aprender las tecnolog´ıas utilizadas para poder solventar los problemas. Reorganizar la planificaci´on teniendo en cuenta estos retrasos. Tabla 2.4: Riesgo R003. Falta de conocimiento P´erdida de datos Identificador R004 Descripci´on P´erdida total o parcial de alg´un documento o de la aplicaci´on. Impacto Catastr´ofico Probabilidad Muy Bajo Exposici´on Bajo Plan de contingencia Realizar copias de seguridad en diferentes sitios. Evaluar los da˜nos y reorganizar la planificaci´on. Tabla 2.5: Riesgo R004. P´erdida de datos 23 3.2. CASOS DE USO CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA 3.2.1. Descripci´on de los casos de uso UC-001 A˜nadir jugadores Versi´on 1.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario a˜nadir jugadores a los equipos. Precondici´on La aplicaci´on debe estar instalada en un dispositivo m´ovil y en ejecuci´on y debe haber ejecutado el caso de uso UC019. Secuencia normal Paso Acci´on 1 El usuario indicar´a los dorsales de los jugadores y selecciona si es titular o no y pulsa guardar. 2 El sistema guarda los datos y el caso de uso finaliza. Excepciones Paso Acci´on 1 El usuario cancela la operaci´on. El caso de uso queda sin efecto. Tabla 3.4: UC001. A˜nadir jugadores. UC-002 Configurar partido Versi´on 1.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario configurar como desee el partido, con distintos tiempos, partes y n´umero de jugadores titulares. Precondici´on El usuario debe estar en la pantalla de crear partido Secuencia normal Paso Acci´on 1 El actor usuario selecciona la opci´on configuraci´on del partido. 2 El sistema muestra un desplegable con el n´umero de minutos, el n´umero de tiempos y el n´umero de titulares. 3 El actor selecciona las opciones que desee. 4 El sistema guarda los datos y el caso de uso finaliza. Excepciones Paso Acci´on 3 El usuario cancela la operaci´on. El caso de uso queda sin efecto. Tabla 3.5: UC002. Configurar partido. 30 CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA 3.2. CASOS DE USO UC-003 Cambio de jugador. Versi´on 1.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario cambiar de jugador. Precondici´on El usuario debe estar en la pantalla principal con el partido iniciado. Secuencia normal Paso Acci´on 1 El actor usuario selecciona con una pulsaci´on prolongada el jugador titular que desea quitar del partido. 2 El sistema muestra el jugador titular desplaz´andose. 3 El actor usuario suelta el jugador titular sobre el jugador suplente que sea sacar al partido. 4 El sistema cambia el jugador y el caso de uso finaliza. Excepciones Paso Acci´on 3 El usuario cancela la operaci´on. El caso de uso queda sin efecto. Tabla 3.6: UC003. Cambio de jugador. UC-004 Consultar datos. Versi´on 1.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario consultar el registro de jugadas que se han ido anotando. Precondici´on El usuario debe estar en la pantalla principal. Secuencia normal Paso Acci´on 1 El actor usuario selecciona la opci´on de consultar datos. 2 El sistema muestra una pantalla con las acciones que han ido ocurriendo y el caso de uso finaliza. Tabla 3.7: UC004. Consultar datos. 31 3.2. CASOS DE USO CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA UC-005 Seleccionar jugador. Versi´on 1.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario seleccionar un jugador.. Precondici´on El usuario debe estar en la pantalla principal con el partido iniciado. Secuencia normal Paso Acci´on 1 El actor usuario selecciona el dorsal del jugador del que quiere indicar una acci´on. 2 El sistema muestra una ventana emergente con todas las acciones posibles del jugador y el caso de uso finaliza. Excepciones Paso Acci´on 3 El usuario cancela la operaci´on. El caso de uso queda sin efecto. Tabla 3.8: UC005. Seleccionar jugador. UC-006 Recuperaci´on. Versi´on 1.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario indicar la recuperaci´on del bal´on de un jugador. Precondici´on El usuario debe haber completado el caso de uso UC005 con ´exito. Secuencia normal Paso Acci´on 1 El actor usuario selecciona el bot´on de recuperaci´on en el desplegable. 2 El sistema almacena una recuperaci´on de ese jugador y el caso de uso finaliza. Flujo Alternativo Paso Acci´on 1 El actor usuario selecciona el bot´on de recuperaci´on en la etiqueta del jugador. 2 El sistema almacena una recuperaci´on de ese jugador. El caso de uso finaliza. Tabla 3.9: UC006. Recuperaci´on. 32 CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA 3.2. CASOS DE USO UC-007 Sumar gol. Versi´on 1.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario a˜nadir un gol de un jugador. Precondici´on El usuario debe haber completado el caso de uso UC005 con ´exito. Secuencia normal Paso Acci´on 1 El actor usuario selecciona el bot´on de gol en el desplegable. 2 El sistema almacena un gol de ese jugador y en el marcador del equipo. El caso de uso finaliza. Flujo Alternativo Paso Acci´on 1 El actor usuario selecciona el bot´on de gol en la etiqueta del jugador. 2 El sistema almacena un gol de ese jugador y en el marcador del equipo. El caso de uso finaliza. Tabla 3.10: UC007. Sumar gol. UC-008 Tirar penalti. Versi´on 1.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario indicar qu´e jugador tira un penalti. Precondici´on El usuario debe haber completado el caso de uso UC005 con ´exito. Secuencia normal Paso Acci´on 1 El actor usuario selecciona el bot´on de penalti en el desplegable. 2 El sistema almacena un penalti de ese jugador y el caso de uso finaliza. Tabla 3.11: UC008. Tirar penalti. 33 3.2. CASOS DE USO CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA UC-009 Tirar a puerta. Versi´on 1.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario indicar el tiro a puerta de un jugador. Precondici´on El usuario debe haber completado el caso de uso UC005 con ´exito. Secuencia normal Paso Acci´on 1 El actor usuario selecciona el bot´on de tiro a puerta en el desplegable. 2 El sistema almacena un tiro de ese jugador y el caso de uso finaliza. Flujo Alternativo Paso Acci´on 1 El actor usuario selecciona el bot´on de tirar en la etiqueta del jugador. 2 El sistema almacena un tiro de ese jugador. El caso de uso finaliza. Tabla 3.12: UC009. Tirar a puerta. UC-010 Exclusi´on. Versi´on 1.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario indicar que un usuario est´a en tiempo de exclusi´on. Precondici´on El usuario debe haber completado el caso de uso UC005 con ´exito. Secuencia normal Paso Acci´on 1 El actor usuario selecciona el bot´on de exclusi´on en el desplegable. 2 El sistema mostrar´a un cron´ometro de 2 minutos en los que el jugador no podr´a realizar acciones, almacena la informaci´on y el caso de uso finaliza. Excepciones Paso Acci´on 2 El sistema detecta que se ha excluido al jugador 3 veces en el partido y ejecuta el caso de uso UC013. Tabla 3.13: UC010. Exclusi´on. 34 CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA 3.2. CASOS DE USO UC-011 A˜nadir falta. Versi´on 1.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario indicar la falta de un jugador. Precondici´on El usuario debe haber completado el caso de uso CU005 con ´exito. Secuencia normal Paso Acci´on 1 El actor usuario selecciona el bot´on de falta en el desplegable. 2 El sistema almacena una falta de ese jugador y el caso de uso finaliza. Flujo Alternativo Paso Acci´on 1 El actor usuario selecciona el bot´on de falta en la etiqueta del jugador. 2 El sistema almacena una falta de ese jugador. El caso de uso finaliza. Tabla 3.14: UC011. A˜nadir falta . UC-012 Tarjeta amarilla. Versi´on 2.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario indicar que un jugador ha sido amonestado. Precondici´on El usuario debe haber completado el caso de uso UC005 con ´exito. Secuencia normal Paso Acci´on 1 El actor usuario selecciona el bot´on de tarjeta amarilla en el desplegable. 2 El sistema almacena una tarjeta amarilla a ese jugador y el caso de uso finaliza. Excepciones Paso Acci´on 2a El sistema detecta que se ha amonestado a un jugador 2 veces y ejecuta el caso de uso UC010. 2b El sistema detecta que hay m´as de 3 tarjetas amarillas en el equipo y ejecuta el caso de uso UC010. Tabla 3.15: UC012. Tarjeta amarilla . 35 3.2. CASOS DE USO CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA UC-013 Tarjeta roja. Versi´on 2.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario indicar una tarjeta roja a un jugador. Precondici´on El usuario debe haber completado el caso de uso UC005 con ´exito. Secuencia normal Paso Acci´on 1 El actor usuario selecciona el bot´on de tarjeta roja en el desplegable. 2 El sistema almacena una tarjeta roja a ese jugador, mostrar´a un cron´ometro de 2 minutos en el que no puede ser sustituido y pasado ese tiempo, se mostrar´an los jugadores que pueden sustituirle. 3 El actor usuario selecciona el jugador que desea que haga la sustituci´on. 4 El sistema sustituye al jugador y el caso de uso finaliza. Tabla 3.16: UC013. Tarjeta roja . UC-014 Tiempo muerto. Versi´on 1.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario indicar tiempo muerto de un equipo. Precondici´on El usuario debe estar en la pantalla principal con el partido iniciado. Secuencia normal Paso Acci´on 1 El actor usuario selecciona el bot´on de tiempo muerto del equipo. 2 El sistema parar´a el tiempo del juego hasta que el usuario lo reanude y lo almacenar´a. El caso de uso finaliza. Tabla 3.17: UC014. Tiempo muerto. 36 CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA 3.2. CASOS DE USO UC-015 Reanudar tiempo muerto. Versi´on 1.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario reanudar el cron´ometro despu´es de un tiempo muerto. Precondici´on El usuario debe haber completado el caso de uso CU014 con ´exito. Secuencia normal Paso Acci´on 1 El actor usuario selecciona el bot´on reanudar. 2 El sistema reanudar´a el tiempo del cron´ometro y el caso de uso finaliza. Tabla 3.18: UC015. Reanudar tiempo muerto. UC-016 A˜nadir gol al equipo. Versi´on 2.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario a˜nadir un gol al marcador de un equipo sin necesidad de estar asociado a un jugador. Precondici´on El usuario debe estar en la pantalla principal con el partido iniciado. Secuencia normal Paso Acci´on 1 El actor usuario selecciona el marcador del equipo. 2 El sistema sumar´a un gol global al marcador del equipo y el caso de uso finaliza. Tabla 3.19: UC016. A˜nadir gol al equipo. UC-017 Restar gol al jugador. Versi´on 2.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario restar un gol asociado a un jugador. Precondici´on El usuario debe haber completado el caso de uso UC005 con ´exito. Secuencia normal Paso Acci´on 1 El actor usuario selecciona el bot´on de anular gol en el desplegable. 2 El sistema restar´a un gol al jugador y al equipo y el caso de uso finaliza. Tabla 3.20: UC017. Restar gol al jugador. 37 3.2. CASOS DE USO CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA UC-018 Restar gol al equipo. Versi´on 2.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario restar un gol al marcador de un equipo sin necesidad de estar asociado a un jugador. Precondici´on El usuario estar en la pantalla principal con el partido iniciado. Secuencia normal Paso Acci´on 1 El actor usuario selecciona el bot´on de restar gol de al lado del marcador. 2 El sistema restar´a un gol al jugador al equipo y el caso de uso finaliza. Tabla 3.21: UC018. Restar gol al equipo. UC-001 Crear equipo Versi´on 2.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario crear un equipo. Precondici´on La aplicaci´on debe estar instalada en un dispositivo m´ovil y en ejecuci´on. Secuencia normal Paso Acci´on 1 El actor usuario selecciona a˜nadir equipo. 2 El sistema pregunta el nombre del equipo 3 El usuario introduce el nombre del equipo. 4 El sistema almacena el nombre del equipo y ejecuta el caso de uso UC001 (A˜nadir equipo) y el caso de uso finaliza. Excepciones Paso Acci´on 3 El actor usuario cancela la operaci´on y el caso de uso queda sin efecto. 4 El sistema detecta que no hay suficientes titulares y muestra mensaje de error. Tabla 3.22: UC019. Crear equipo. 38 CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA 3.3. MODELO DE DOMINIO UC-001 Crear partido. Versi´on 2.0 Autores Mar´ıa Varela Alonso Descripci´on El sistema deber´a permitir al actor usuario crear un equipo. Precondici´on El sistema debe haber ejecutado el caso de uso UC019 dos veces. Secuencia normal Paso Acci´on 1 El actor usuario selecciona el bot´on crear partido. 2 El sistema muestra la ventana del partido. Excepciones Paso Acci´on 1 El actor usuario cancela la operaci´on y el caso de uso queda sin efecto. Tabla 3.23: UC020. Crear partido.. 3.3. Modelo de dominio En la siguiente figura se muestra el diagrama de dominio a nivel de an´alisis. Se encuentran las clases identificadas a nivel de an´alisis y las relaciones entre ellas. Figura 3.2: Modelo de dominio. 3.4. Diagrama de actividad Los diagramas de actividad en UML[12] pertenecen al grupo de diagramas de comportamiento y representa una secuencia de actividades. Se considera especialmente ´util para visualizar los flujos de trabajo y los casos de uso. A continuaci´on se muestran los diferentes diagramas de actividad correspondientes a cada caso de uso. 39 3.4. DIAGRAMA DE ACTIVIDAD CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA Figura 3.13: Diagrama de Actividad UC011. Figura 3.14: Diagrama de Actividad UC012. 46 CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA 3.4. DIAGRAMA DE ACTIVIDAD Figura 3.15: Diagrama de Actividad UC013. Figura 3.16: Diagrama de Actividad UC014. 47 3.4. DIAGRAMA DE ACTIVIDAD CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA Figura 3.17: Diagrama de Actividad UC015. Figura 3.18: Diagrama de Actividad UC016. 48 CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA 3.4. DIAGRAMA DE ACTIVIDAD Figura 3.19: Diagrama de Actividad UC017. Figura 3.20: Diagrama de Actividad UC018. 49 3.4. DIAGRAMA DE ACTIVIDAD CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA Figura 3.21: Diagrama de Actividad UC019. Figura 3.22: Diagrama de Actividad UC020. 50 CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA 3.5. DIAGRAMA DE SECUENCIA 3.5. Diagrama de secuencia Los diagramas de secuencia son los usados para modelar las interacciones a lo largo del tiempo de los objetos en el sistema, se modela para cada caso de uso. Figura 3.23: SD001. A˜nadir jugador. Figura 3.24: SD002. Configurar partido. 51 3.5. DIAGRAMA DE SECUENCIA CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA Figura 3.25: SD003. Cambio de jugador. 52 CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA 3.5. DIAGRAMA DE SECUENCIA Figura 3.26: SD004. Consultar datos. 53 3.5. DIAGRAMA DE SECUENCIA CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA Figura 3.27: SD005. Seleccionar jugador. 54 CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA 3.5. DIAGRAMA DE SECUENCIA Figura 3.28: SD006. Recuperaci´on. 55 3.5. DIAGRAMA DE SECUENCIA CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA Figura 3.38: SD016. Sumar gol al equipo 62 CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA 3.5. DIAGRAMA DE SECUENCIA Figura 3.39: SD017. Restar gol al jugador. 63 3.5. DIAGRAMA DE SECUENCIA CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA Figura 3.40: SD018. Restar gol al equipo. 64 CAP´ ITULO 3. AN ´ ALISIS DEL SISTEMA 3.5. DIAGRAMA DE SECUENCIA Figura 3.41: SD019. Crear equipo. Figura 3.42: SD020. Crear partido. 65 Cap´ıtulo 4 Dise˜no Tras el an´alisis, el siguiente paso en el proceso es el dise˜no de la aplicaci´on. Se destallar´an las decisiones de dise˜no tomadas y el dise˜no de la interfaz de la aplicaci´on. 4.1. Arquitectura del sistema La aplicaci´on se estructura a alto nivel en los siguientes paquetes. Figura 4.1: Diagrama de paquetes. El paquete Modelo representa la capa de l´ogica de negocio. El paquete ViewModel representa la capa de l´ogica de presentaci´on. El paquete Vista representa la capa de presentaci´on. El paquete Datos representa la capa de datos. A continuaci´on se mostrar´a con m´as detalle el contenido de cada paquete mediante el diagrama decomposition style de cada paquete hasta nivel de clase. 66 CAP´ ITULO 4. DISE ˜ NO 4.1. ARQUITECTURA DEL SISTEMA Figura 4.2: Diagrama decomposition style del paquete Modelo. Figura 4.3: Diagrama decomposition style del paquete ViewModel. Figura 4.4: Diagrama decomposition style del paquete Vista. 67 4.2. PATRONES CAP´ ITULO 4. DISE ˜ NO Figura 4.5: Diagrama decomposition style del paquete datos. 4.2. Patrones En est´a secci´on se enumeran los patrones de software utilizados que se han utilizado para desarrollar la aplicaci´on. Se explican estos patrones y se detalla c´omo y d´onde se aplican en la aplicaci´on. 4.2.1. Patr´on MVVM El patr´on Modelo Vista VistaModelo (MVVM) se basa en separar la vista de la l´ogica de negocio(el modelo), para ello incluye un nuevo componente intermedio para realizar la comunicaci´on entre ellas, el ViewModelo. La diferencia con el MVC es que el controlador desaparece y la vista es capaz de gestionar las acciones que pide el usuario. La descripci´on de cada capa ser´a: Modelo: Representa la capa de datos y la l´ogica de negocio. Contiene la informaci´on, pero no las acciones que la manipulan. No tiene dependencia con la vista. Vista: Se encarga de mostrar la informaci´on al usuario gr´aficamente. Define la estructura que saldr´a por pantalla e invoca los m´etodos del Viewmodel. ViewModel: Efect´ua la comunicaci´on entre la vista y el modelo. Controla la l´ogica de la vista y maneja las invocaciones al modelo para obtener los datos. Contiene toda la l´ogica de presentaci´on. Figura 4.6: Esquema Patr´on MVVM. Las ventajas de este patr´on es que permite desacoplar la l´ogica de negocio de la interfaz de usuario, es f´acil de probar y mantener ya que se pueden hacer pruebas para el modelo y para el viewmodel sin necesidad de utilizar la vista. 68 CAP´ ITULO 4. DISE ˜ NO 4.3. CICLO DE VIDA DE ACTIVITIES 4.2.2. Patr´on DAO El patr´on Data Access Object (DAO) se utiliza como patr´on de acceso a datos. Separa por completo la l´ogica de negocio de la l´ogica para acceder a los datos. El DAO proporciona los m´etodos necesarios para insertar, actualizar, borrar y consultar la informaci´on. 4.2.3. Patr´on Command El patr´on Command permite solicitar una operaci´on a un objeto sin saber el contenido de esa operaci´on. Se encapsulan las peticiones como objetos. La aplicaci´on necesita que algunas acciones se deshagan, como marcar un gol, por lo que se ha decidido utilizar el patr´on Command para realizar esta operaci´on y de esta manera poder ejecutar las acciones de una manera orientada a objetos y garantizar la encapsulaci´on de las clases implicadas. 4.2.4. Patr´on Factory El patr´on factory permite crear objetos sin tener que especificar su clase exacta. Separa la creaci´on de los objetos de los propios objetos. Se ha utilizado el patr´on Factory para crear los jugadores para la escalabilidad del c´odigo. De esta forma se asegura la encapsulaci´on del modelo respecto a la vista 4.2.5. Patr´on Singleton El patr´on Singleton se basa en disponer de una ´unica estancia de clase y un ´unico punto de acceso a ella. Permite restringir la creaci´on de objetos pertenecientes a una clase o el valor de un tipo a un ´unico objeto. Dado que se necesitaba implementar varias clases est´aticas, como las clases del paquete ViewModel, se ha decidido utilizar el patr´on Singleton para facilitar el acceso a dichas clases y el testeo. 4.2.6. Patr´on Observer El patr´on Observer es un patr´on de comportamiento que permite a un objeto notificar a otros objetos sobre cambios en su estado. Se ha utilizado para el gestionar el cron´ometro, ya que necesita ser usado en varias clases. Se ha decidido que lo mejor era crear un wrapper alrededor de la clase CountDownTimer que proporciona Android/Java, que implementa el patr´on observador dando la oportunidad a cualquier otra clase de observar el cron´ometro. 4.3. Ciclo de vida de Activities Los diferentes estados por los que pasa una Activity cuando el usuario interact´ua con la app componen el ciclo de vida de la actividad. Con lo diferentes estados se puede controlar el comportamiento de la aplicaci´on. Para pasar de un estado a otro del ciclo de la vida, se nos proporcionan 6 m´etodos: onCreate(), onStart(), onResume(), onPause(), onStop() y onDestroy(). Dependiendo de la complejidad de la aplicaci´on, ser´a o no necesario implementar todos los m´etodos para tener un funcionamiento ´optimo. 69 4.4. DIAGRAMA DE DESPLIEGUE CAP´ ITULO 4. DISE ˜ NO Figura 4.7: Ciclo de vida de una actividad. 4.4. Diagrama de despliegue El diagrama de despliegue muestra la distribuci´on f´ısica de los componentes software en nodos. En este caso no tiene conexi´on ninguna con una base de datos en un servidor, ya que con la base de datos local es suficiente. Por lo que quedar´ıa de la siguiente forma. Figura 4.8: Diagrama de despliegue. 4.5. Dise˜no de la base de datos Para almacenar los datos se ha utilizado SQLite de forma local. Es una base de datos relacional, por lo que est´a basada en tablas. Se ha escogido SQLite porque es muy ´util y sencilla para aplicaciones m´oviles y entornos peque˜nos. 70 CAP´ ITULO 4. DISE ˜ NO 4.6. PRIVACIDAD Figura 4.9: Diagrama entidad-relaci´on. Una vez realizado la transformaci´on del modelo conceptual de datos al modelo relacional, se utiliza la librer´ıa de Google GSON permite la serializaci´on y deserializaci´on entre la base de datos y los objetos del dominio de la aplicaci´on. Lo que hace es convertir el objeto en un JSON para de esta forma poder almacenarlo en un campo de tipo texto. Para poder utilizarlo tenemos que a˜nadir al archivo build.gradle del proyecto la siguiente linea. implementation ’ com . google . code . gson : gson :2.8.7 ’ 4.6. Privacidad Cuando se instala una aplicaci´on en el tel´efono m´ovil mantener la privacidad del usuario se ha convertido en una necesidad, ya que la propia aplicaci´on puede requerir permisos para obtener acceso a todos los registros del usuario e informaci´on de cuentas, entre otras. El nuevo Reglamento Europeo de Protecci´on de datos incluye ahora el concepto Privacy Design[20]. Es un concepto que se basa en 7 medidas: Proactivo, ya que previenen y anticipan los problemas de privacidad antes de que ocurran. Privacidad como configuraci´on predeterminada, lo que significa que no requiere ninguna acci´on por parte del usuario para proteger su privacidad. Los datos personales deben estar autom´aticamente protegidos. Privacidad incrustada en el dise˜no, la protecci´on de datos personales es parte integral del sistema, y no debe influir en sus funcionalidad. Funcionalidad total, un producto puede estar con todas las funcionalidades activas sin dejar de lado la privacidad del usuario. 71 5.2. CONTROL DE VERSIONES CAP´ ITULO 5. IMPLEMENTACI ´ ON 5.1.5. Github Figura 5.5: Logotipo Github. GitHub[10] es una plataforma colaborativa donde alojar proyectos utilizando el control de versiones. Como es un repositorio, el c´odigo se puede descargar y ser revisado por cualquier usuario. En junio del 2018 fue comprado por Microsoft 5.1.6. Microsoft Project Figura 5.6: Logotipo Microsoft Project. Microsoft Project[11] es un software de administraci´on de proyectos y programas desarrollado por Microsoft. Ayuda a la persona que crea un proyecto a asignar recursos a las tareas, llevar un seguimiento del progreso, dar presupuestos y analizar cargas de trabajo. 5.2. Control de versiones Se ha utilizado Gitlab para el control de versiones, con un repositorio cuya direcci´on url es: https://gitlab.inf.uva.es/marvare/handbappscore/-/tree/master 5.3. Versiones de Android soportadas Para poder crear una aplicaci´on es necesario especificar un nivel de API m´ınimo, es decir, a partir de que versi´on se puede usar nuestra aplicaci´on. Para poder tomar esta decisi´on hay que comprobar que versi´on de API usa la mayor´ıa de los usuarios. Un dato a tener en cuenta es que las aplicaciones compatibles con versiones anteriores son compatibles con las posteriores, pero no en el caso contrario. Estos datos se pueden encontrar en Android Studio[17], aunque todav´ıa no han proporcionado datos sobre Android 11. 78 CAP´ ITULO 5. IMPLEMENTACI ´ ON 5.3. VERSIONES DE ANDROID SOPORTADAS Figura 5.7: Tabla versiones de Android y distribuci´on acumulativa. Figura 5.8: Tabla versiones de Android con porcentaje real. Como podemos observar, la mayor´ıa de los usuarios cuentan con versiones de API oscilando entre la 23 y la 28 (Marshmallow 6.0 y Pie 9.0). Por estos datos se decide que el nivel m´ınimo de API sea la 23 (Marshmallow 6.0) con un 84,9 % de soporte en la mayor´ıa de los dispositivos Android. 79 Cap´ıtulo 6 Pruebas Se denomina prueba al conjunto de actividades que proporcionan informaci´on objetiva sobre la calidad de un producto para as´ı poder detectar los posibles errores que tenga dicho producto. Podemos encontrar diferentes tipos de prueba: Pruebas de caja blanca, son aquellas que se realizan mirando el c´odigo y la estructura del producto para poder hacer dichas pruebas. Se requieren conocimientos de implementaci´on y programaci´on para realizar estas pruebas, por lo que normalmente las realizan los desarrollados. Pruebas de caja negra, son aquellas en las que el c´odigo no se visualiza ya que solo importa las entradas que recibe y las respuestas que produce sin importar el funcionamiento interno. No se necesitan conocimientos de programaci´on e implementaci´on para hacer estas pruebas, las realizan los testers. En este proyecto el tipo de pruebas que se han realizado , han sido las de caja negra. Se ha probado cada m´etodo de cada clase utilizando estas pruebas, pero solo se van a mostrar las pruebas de caja negra por caso de uso. Para realizar las pruebas de funcionalidad se han intentado hacer pruebas para todos los casos de uso descritos con anteriormente. De esta forma comprobaremos el correcto o incorrecto funcionamiento de la aplicaci´on, y estos resultados ser´an mostrados. Al hablar de una aplicaci´on con interfaz gr´afica, tambi´en es importante realizar pruebas sobre la interfaz de usuario. Este tipo de pruebas est´an orientadas a comprobar el correcto funcionamiento de las pantallas y la navegaci´on entre ellas. Hay que comprobar el correcto funcionamiento de la aplicaci´on en diferentes versiones de Android, ya que esta aplicaci´on tiene como API m´ınima requerida la 23. Para ello se probar´a en diferentes dispositivos con diferentes versiones, a continuaci´on se muestra el modelo y el n´umero de versi´on. 1. Xiaomi Mi 8 Lite - Android 10.0 (API 29) 2. Samsung Galaxy S10 - Android 11 (API 30) 3. Samsung J5 - Android Marshmallow 6.0.1 (API 23) 6.1. Listado de pruebas A˜nadir jugadores a un equipo. A˜nadir menos o ning´un jugadores titulares de los seleccionados. 80 CAP´ ITULO 6. PRUEBAS 6.1. LISTADO DE PRUEBAS A˜nadir un equipo sin nombre. Cambiar n´umero de minutos del partido. Cambiar n´umero de partes del partido. Iniciar temporizador del partido. Pausar temporizador del partido sin a˜nadir tiempo muerto de un equipo. A˜nadir tiempo muerto de un equipo. Reanudar temporizador del partido. A˜nadir acciones sin que el tiempo est´e activo. Consultar las estad´ısticas del partido. Cambiar un jugador por un suplente. Cambiar un suplente por un jugador. Cambiar un jugador de un equipo por otro. Sumar un gol a un marcador. Restar un gol a un marcador. A˜nadir tarjeta roja a un jugador. A˜nadir dos tarjetas rojas a un jugador. A˜nadir un penalti a un jugador. A˜nadir una exclusi´on a un jugador. A˜nadir tres exclusiones a un jugador. A˜nadir una tarjeta amarilla a un jugador. A˜nadir dos tarjetas amarillas a un jugador. A˜nadir m´as de dos tarjetas amarillas a un jugador. A˜nadir cuatro tarjetas amarillas a un equipo. A˜nadir un gol a un jugador. Anular un gol a un jugador. A˜nadir falta a un jugador. A˜nadir tiro a un jugador. A˜nadir recuperaci´on a un jugador. Cambiar el n´umero de titulares antes de crear un equipo. 81 6.2. RESULTADOS CAP´ ITULO 6. PRUEBAS 6.2. Resultados En esta secci´on se mostrar´an los resultados obtenidos al ejecutar la serie de pruebas anteriores en los diferentes dispositivos. Se mostrar´a en la tabla los resultados obtenidos, tanto si son exitosos como si se producen fallos, y en el caso de producirse fallo si se ha podido corregir y de que forma. CP001 A˜nadir jugadores a un equipo. Entrada Desde la pantalla principal se selecciona el bot´on con el icono de a˜nadir, y en la siguiente pantalla se introducen el n´umero de jugadores deseados. Resultado esperado Se han a˜nadido los datos correctamente y se muestra el nombre del equipo en la pantalla principal. Resultado obtenido Correcto Tabla 6.1: CP001. A˜nadir jugadores a un equipo. CP002 A˜nadir menos o ning´un jugadores titulares de los seleccionados. Entrada Desde la pantalla principal se selecciona el bot´on con el icono de a˜nadir, y en la siguiente pantalla se introducen menos titulares de los indicados anteriormente. Resultado esperado Se muestra un mensaje de error indicando que hay insuficientes titulares. Resultado obtenido Correcto Tabla 6.2: CP002. A˜nadir menos o ning´un jugadores titulares de los seleccionados. CP003 A˜nadir un equipo sin nombre. Entrada Desde la pantalla principal se selecciona el bot´on con el icono de a˜nadir, y en la siguiente pantalla no se introduce el nombre al equipo. Resultado esperado Se muestra un mensaje de error indicando que falta el nombre del equipo. Resultado obtenido Correcto Tabla 6.3: CP003. A˜nadir un equipo sin nombre. CP004 Cambiar n´umero de minutos del partido. Entrada Desde la pantalla principal se selecciona “Configuraci´on de partido” y se escoge el n´umero de minutos que se desea. Resultado esperado Los minutos aparecen correctamente en la pantalla del partido. Resultado obtenido Correcto Tabla 6.4: CP004. Cambiar n´umero de minutos del partido. 82 CAP´ ITULO 6. PRUEBAS 6.2. RESULTADOS CP005 Cambiar n´umero de partes del partido. Entrada Desde la pantalla principal se selecciona “Configuraci´on de partido” y se escoge el n´umero de partes de partido que se desea. Resultado esperado Se guarda el n´umero de partes y se muestran en el partido. Resultado obtenido Correcto Tabla 6.5: CP005. Cambiar n´umero de partes del partido. CP006 Iniciar temporizador del partido. Entrada En la pantalla de juego se selecciona el bot´on “Inicio”. Resultado esperado El temporizador empieza a descontar segundos. Resultado obtenido Correcto Tabla 6.6: CP006. Iniciar temporizador del partido. CP007 Pausar temporizador del partido sin a˜nadir tiempo muerto de un equipo. Entrada En la pantalla de juego se selecciona el bot´on “Pausa”. Resultado esperado El temporizador se para. Resultado obtenido Correcto Tabla 6.7: CP007. Pausar temporizador del partido sin a˜nadir tiempo muerto de un equipo. CP00 A˜nadir tiempo muerto de un equipo. Entrada En la pantalla de juego se selecciona el bot´on “Tiempo Muerto” del equipo deseado. Resultado esperado El temporizador se para y se muestra en la pantalla de estad´ıstica que equipo lo par´o. Resultado obtenido Correcto Tabla 6.8: CP008. A˜nadir tiempo muerto de un equipo. CP009 Reanudar temporizador del partido. Entrada En la pantalla de juego se selecciona el bot´on “Seguir”. Resultado esperado El temporizador vuelve a funcionar desde el minuto y el segundo que se hab´ıa quedado. Resultado obtenido Correcto Tabla 6.9: CP009. Reanudar temporizador del partido. 83 6.2. RESULTADOS CAP´ ITULO 6. PRUEBAS CP010 A˜nadir acciones sin que el tiempo est´e activo. Entrada En la pantalla de juego, ante de darle al bot´on de “Inicio”, se a˜naden acciones a un jugador. Resultado esperado No marca ninguna acci´on. Resultado obtenido Fallo Tabla 6.10: CP010. A˜nadir acciones sin que el tiempo est´e activo. CP011 Consultar las estad´ısticas del partido. Entrada En la pantalla de juego, se selecciona el bot´on “Datos”. Resultado esperado Aparece la pantalla estad´ıstica con las acciones que han ocurrido durante el partido. Resultado obtenido Correcto Tabla 6.11: CP011. Consultar las estad´ısticas del partido. CP012 Cambiar un jugador por un suplente. Entrada En la pantalla de juego, se realiza una pulsaci´on larga sobre el jugador titular que se quiere sustituir y se baja en el scroll hacia el suplente que lo va a sustituir y se suelta encima. Resultado esperado El jugador titular se deshabilita y el jugador suplente se habilita. Resultado obtenido Correcto Tabla 6.12: CP012. Cambiar un jugador por un suplente. CP013 Cambiar un suplente por un jugador. Entrada En la pantalla de juego, se realiza una pulsaci´on larga sobre el suplente que va a salir a jugar y se mantiene hasta llegar al jugador titular que va a salir del partido y se suelta encima. Resultado esperado El jugador titular se deshabilita y el jugador suplente se habilita. Resultado obtenido Fallo. No se contempl´o este caso a la hora de la implementaci´on. Tabla 6.13: CP013. Cambiar un suplente por un jugador. 84 CAP´ ITULO 6. PRUEBAS 6.2. RESULTADOS CP014 Cambiar un jugador de un equipo por otro. Entrada En la pantalla de juego, se realiza una pulsaci´on larga sobre un jugador y se intenta llevar al equipo contrario para sustituir a otro jugador.. Resultado esperado El jugador titular se deshabilita y el jugador suplente se habilita. Resultado obtenido Correcto Tabla 6.14: CP014. Cambiar un jugador de un equipo por otro. CP015 Sumar un gol a un marcador. Entrada En la pantalla de juego, se pulsa encima del marcador el equipo deseado. Resultado esperado Se suma un gol al marcador de ese equipo. Resultado obtenido Correcto Tabla 6.15: CP015. Sumar un gol a un marcador. CP016 Restar un gol a un marcador. Entrada En la pantalla de juego, se pulsa encima del icono menos del marcado del equipo deseado. Resultado esperado Se resta un gol al marcador de ese equipo. Resultado obtenido Correcto Tabla 6.16: CP016. Restar un gol a un marcador. CP017 A˜nadir tarjeta roja a un jugador. Entrada En la pantalla de juego, se pulsa encima del dorsal del jugador y se selecciona “Tarjeta roja” Resultado esperado Se deshabilita ese jugador, se a˜nade un temporizador de 2 minutos y pasado el tiempo se selecciona al jugador que lo va a sustituir. Resultado obtenido Correcto. Tabla 6.17: CP017. A˜nadir tarjeta roja a un jugador. CP018 A˜nadir dos tarjetas rojas a un jugador. Entrada En la pantalla de juego, se pulsa encima del dorsal del jugador y se selecciona “Tarjeta roja” Resultado esperado No se pueden a˜nadir dos tarjetas rojas a un jugador. Resultado obtenido Correcto. Se encuentra deshabilitado. Tabla 6.18: CP018. A˜nadir dos tarjetas rojas a un jugador. 85 6.2. RESULTADOS CAP´ ITULO 6. PRUEBAS CP019 A˜nadir un penalti a un jugador. Entrada En la pantalla de juego, se pulsa encima del dorsal del jugador y se selecciona “Penalti” Resultado esperado Se a˜nade un penalti al jugador. Resultado obtenido Correcto Tabla 6.19: CP019. A˜nadir un penalti a un jugador. CP020 A˜nadir una exclusi´on a un jugador. Entrada En la pantalla de juego, se pulsa encima del dorsal del jugador y se selecciona “Exclusi´on” Resultado esperado Se bloquea el jugador durante 2 minutos y se muestra un temporizador. Resultado obtenido Correcto. Tabla 6.20: CP020.A˜nadir una exclusi´on a un jugador. CP021 A˜nadir tres exclusiones a un jugador. Entrada En la pantalla de juego, se pulsa encima del dorsal del jugador y se selecciona “Exclusi´on” Resultado esperado Se le a˜nade una tarjeta roja al jugador y durante dos minutos no puede sustituirle nadie. Resultado obtenido Fallo. Corregido. No se quitaba el booleano de excluido al terminar el cron´ometro, entonces nunca se liberaba. Ya que una condici´on era que un jugador excluido no pudiera volver a ser excluido al mismo tiempo. Tabla 6.21: CP021. A˜nadir tres exclusiones a un jugador. CP022 A˜nadir una tarjeta amarilla a un jugador. Entrada En la pantalla de juego, se pulsa encima del dorsal del jugador y se selecciona “Tarjeta amarilla” Resultado esperado Se a˜nade una tarjeta amarilla al jugador, y se suma una al equipo. Resultado obtenido Correcto Tabla 6.22: CP022. A˜nadir una tarjeta amarilla a un jugador. 86 CAP´ ITULO 6. PRUEBAS 6.2. RESULTADOS CP023 A˜nadir dos tarjetas amarillas a un jugador. Entrada En la pantalla de juego, se pulsa encima del dorsal del jugador y se selecciona “Tarjeta amarilla” Resultado esperado Se excluye al jugador durante dos minutos y se suma una amarilla al equipo. Resultado obtenido Correcto. Tabla 6.23: CP023. A˜nadir dos tarjetas amarillas a un jugador. CP024 A˜nadir m´as de dos tarjetas amarillas a un jugador. Entrada En la pantalla de juego, se pulsa encima del dorsal del jugador y se selecciona “Tarjeta amarilla” Resultado esperado No se pueden a˜nadir m´as de dos tarjetas amarillas a un jugador. Resultado obtenido Fallo. Corregido. No se comprobaba el n´umero de amarillas del jugador. Tabla 6.24: CP024. A˜nadir m´as de dos tarjetas amarillas a un jugador. CP025 A˜nadir cuatro tarjetas amarillas a un equipo. Entrada En la pantalla de juego, se pulsa encima del dorsal del jugador y se selecciona “Tarjeta amarilla” Resultado esperado Se detecta que hay m´as de 3 tarjetas amarillas y se excluye directamente. Resultado obtenido Correcto. Tabla 6.25: CP025. A˜nadir cuatro tarjetas amarillas a un equipo. CP026 A˜nadir un gol a un jugador. Entrada En la pantalla de juego, se pulsa encima del dorsal del jugador y se selecciona “Gol” Resultado esperado Se suma un gol y un tiro al jugador, y un gol al marcador global. Resultado obtenido Correcto Tabla 6.26: CP026. A˜nadir un gol a un jugador. 87 Anexo A Manual de instalaci´on Los pasos para instalar la aplicaci´on son los mismos que se siguen con cualquier otra aplicaci´on Android que no est´a alojada en la Play Store. Hay que activar en el tel´efono la opci´on de “Permitir instalar aplicaciones de origen desconocido”. El dispositivo tiene que tener las siguientes caracter´ısticas: Versi´on m´ınima de Android: Android Marshmallow 6.0 Espacio m´ınimo requerido: 16MB Figura A.1: Captura de pantalla de instalaci´on de aplicaciones de origen desconocido en Xiaomi. (a) Ajustes (b) Pantalla bloqueo y seguridad (c) Fuentes desconocidas Figura A.2: Activar instalaci´on de fuentes desconocidas Samsung J5. 94 ANEXO A. MANUAL DE INSTALACI ´ ON Figura A.3: Captura de pantalla para instalar la aplicaci´on Handbapp Score. Figura A.4: Captura de pantalla para abrir la aplicaci´on Handbapp Score. Para poder tener la aplicaci´on en el m´ovil se puede pasar el archivo a trav´es del ordenador e instalarlo, o acceder mediante el enlace del repositorio para poder descargarla y seguir lo mismos pasos de instalaci´on. La url del repositorio es la siguiente: https://gitlab.inf.uva.es/marvare/handbappscore/-/tree/ master 95 Anexo B Manual de usuario En esta secci´on se indican los pasos a seguir para cada una de las funcionalidades de la aplicaci´on. Una vez instalada la aplicaci´on, nos encontramos con la siguiente pantalla. Figura B.1: Primera pantalla Handbapp. En ella podemos realizar dos acciones, a˜nadir los jugadores a los equipos y cambiar la configuraci´on del partido. La configuraci´on por defecto est´a puesta a dos partes de 30 minutos cada una, con 7 jugadores titulares. Si se quiere cambiar esta configuraci´on predeterminada se debe pulsar el bot´on “Configuraci´on del partido” 96 ANEXO B. MANUAL DE USUARIO Figura B.2: Pantalla configuraci´on Handbapp. En esta pantalla se selecciona las preferencias del partido en el desplegable. Una vez obtenida la configuraci´on desea, se pulsa el bot´on “Guardar” y se vuelve a la pantalla principal. A continuaci´on se presiona sobre el el bot´on “+” , que nos llevar´a a la pantalla de configuraci´on del equipo. Figura B.3: Pantalla a˜nadir jugadores Handbapp Una vez se llega a esta pantalla, se escribe el nombre del equipo y se selecciona los jugadores presionando sobre las camisetas, pulsando una vez se convierten en titulares(color azul), pulsando dos veces se convierten en suplentes(color verde), y si los pulsamos una tercera vez se quedan sin seleccionar. Cuando se haya terminado se pulsa el dibujo de guardar y volvemos a la primera pantalla. Se tiene que repetir la misma operaci´on con el otro bot´on “+” para crear el segundo equipo. Entonces saldr´a el bot´on “Jugar” que se debe pulsar para ir a la pantalla del partido. 97 ANEXO B. MANUAL DE USUARIO Figura B.4: Pantalla iniciar partido Handbapp. Figura B.5: Pantalla partido creado Handbapp. En esta pantalla es donde se va a desarrollar todo el partido, se puede observar que en cada lado de la pantalla se encuentra un equipo con sus jugadores, y que est´a marcado el tiempo que se ha seleccionado y la parte del partido en la que se encuentra. Para comenzar el partido se selecciona el bot´on “Inicio”, y el temporizador comenzar´a a funcionar. Si se quiere a˜nadir tiempo muerto al partido, se selecciona el bot´on “Tiempo Muerto” del equipo deseado para parar el tiempo. Cuando haya que volver a continuar el partido se pulsa el bot´on “Seguir”. Se pueden a˜nadir goles al marcador de cada equipo sin necesidad de estar asociado a un jugador, simplemente con pulsar sobre el marcador del equipo se sumar´a. Si por el contrario, se quiere restar goles del marcador de un equipo, se pulsar´a el bot´on “-” de al lado del marcador del equipo al que se quiera quitar un gol. Para seleccionar las acciones de un jugador se tienen dos maneras. 98 ANEXO B. MANUAL DE USUARIO Figura B.6: Botones del jugador. Figura B.7: Pantalla men´u del jugador Handbapp. En la Figura B.6 se puede seleccionar los botones para a˜nadir un tiro, una recuperaci´on, un gol y una falta a un jugador. La Figura B.7 se obtiene pulsando sobre la camiseta del jugador, ah´ı podemos seleccionar el resto de acciones disponibles. Si en la pantalla del partido se pulsa sobre la imagen ´´Datos”, se pasa a la pantalla de las estad´ısticas. 99 ANEXO B. MANUAL DE USUARIO Figura B.8: Muestra datos del partido. Aqu´ı se pueden observar las distintas acciones que han ido haciendo los jugadores de cada equipo. Se muestra el nombre del equipo, el jugador que ha hecho la acci´on, el evento que ha hecho y el minuto. Para realizar el cambio de jugador, se presiona de forma prolongada el jugador y se desplaza hacia el suplente, solt´andolo encima de ´el para que se realice la sustituci´on. Figura B.9: Cambio de jugador. 100 ANEXO B. MANUAL DE USUARIO Figura B.10: Cambio de jugador realizado. Una vez finalizado el partido, se muestra un peque˜no resumen del resultado final. Figura B.11: Resultado final 101