Plataforma de gestión de un club de balonmano

Universidad de Valladolid Escuela de Ingeniería Informática TRABAJO FIN DE GRADO Grado en Ingeniería Informática (Mención en Ingeniería de Software) Plataforma de gestión de un club de balonmano Autor: D. Jorge Manuel Moncadas Gutiérrez Universidad de Valladolid Escuela de Ingeniería Informática TRABAJO FIN DE GRADO Grado en Ingeniería Informática (Mención en Ingeniería de Software) Plataforma de gestión de un club de balonmano Autor: D. Jorge Manuel Moncadas Gutiérrez Tutora: Dña. Margarita Gonzalo Tasis Plataforma de gestión de un club de balonmano 5 Agradecimientos Me gustaría agradecer, en primer lugar, a mi familia y amigos que durante estos años me han acompañado en este viaje y me han apoyado tanto en los buenos como en los malos momentos, hasta la consecución de este sueño que tenía desde pequeño de estudiar Ingeniería Informática. Por último, a todos los profesores que han participado en mi formación de los que he aprendido tantas cosas y en especial a mi tutora Margarita que tanto me ha apoyado durante este proyecto. Muchas gracias a todos. Plataforma de gestión de un club de balonmano 7 Resumen Hoy en día, la aparición en internet es muy importante para cualquier entidad, si además esta necesita visibilidad como es el caso de un club deportivo, en este caso de balonmano, se podría catalogar como indispensable. Esto es debido al interés por conseguir público, ya sea para participar dentro del club o para que lo apoyen como seguidores. Por otro lado, en un club la gestión también es algo importante que antes se realizaba en papel y que en la actualidad se opta en general por llevar de forma informatizada. Este trabajo pretende juntar estas dos facetas en una única aplicación. El proyecto software ha sido realizado siguiendo el método RUP, dividiéndolo en fases e iteraciones mediante las cuales se ha avanzado por todas las fases de un desarrollo software: análisis, diseño, implementación y pruebas. Además, el software ha sido construido usando el framework Spring que ha ganado un gran interés en el ámbito del desarrollo web en los últimos años. Plataforma de gestión de un club de balonmano 9 Abstract Nowadays, the appearance on the internet is very important for any entity, and if it also needs visibility, as is the case of a sports club, in this case a handball club, it could be considered essential. This is due to the interest in reaching the public, either to participate in the club or to support it as followers. On the other hand, the management of a club is also something important that used to be done on paper and that nowadays is generally computerized. This work aims to bring these two aspects together in a single application. The software project has been carried out following the RUP methodology, dividing it into phases and iterations through which it has progressed over all the phases of software development: analysis, design, implementation and testing. In addition, the software has been built using the Spring framework that has gained great interest in web development the last years. Plataforma de gestión de un club de balonmano 17 Capítulo 2 2 Planificación del proyecto Este capítulo describe la metodología elegida para el desarrollo, su funcionamiento, la planificación ideal del proyecto, los riesgos y el plan de gestión de riesgos, un presupuesto orientativo sobre el coste del desarrollo y el seguimiento del proyecto. 2.1 Plan de desarrollo Para el desarrollo del proyecto la metodología elegida ha sido RUP (Rational Unified Process) [2]. RUP está basado en cinco principios clave: • Adaptar el proceso: el proceso debe adaptarse a las características específicas del proyecto. • Equilibrio de prioridades: durante el desarrollo puede haber distintas necesidades que sean opuestas, se debe encontrar un equilibrio que satisfaga a todos. • Valor iterativo: al tratarse de un proceso iterativo debe mostrar valores añadidos con cada iteración. • Colaboración entre equipos: en los proyectos normalmente suelen participar varios equipos en el desarrollo y se debe mantener una buena comunicación, en este caso al ser un desarrollo de una persona este punto es menos interesante. • Abstracción: mantener un nivel de abstracción alto abre la puerta a discusiones sobre las posibles soluciones arquitectónicas y promueve una mayor calidad del desarrollo. 2.1.1 Ciclo de vida El ciclo de vida de RUP es una implementación del desarrollo en espiral. Las tareas están organizadas en fases e iteraciones. Hay cuatro fases en las que se hacen iteraciones, estas fases son: • Inicio: en esta fase se hace mayor énfasis en la parte de modelado de negocio y requisitos. • Elaboración: durante esta fase se trabaja en la mejora de lo hecho en la fase de inicio, análisis y diseño. • Construcción: en esta fase se construye el producto a través de iteraciones, en las que se pasa por las fases de un desarrollo software como se muestra en la Figura 2.1, hasta que se termina. • Transición: durante esta fase se terminan de concretar los aspectos necesarios para poder presentar un producto. Plataforma de gestión de un club de balonmano 18 Figura 2.1: Iteración en fase de construcción En la Figura 2.2 podemos observar el grado de trabajo de las distintas áreas durante las fases de RUP. Figura 2.2: Trabajo a lo largo de las distintas fases Plataforma de gestión de un club de balonmano 19 2.2 Planificación ideal En la Figura 2.3 se pueden ver las tareas de todo el proyecto con sus horas de trabajo estimadas y en que fases e iteraciones del proyecto se encuentran, sumando entre todas las 300 horas establecidas para el TFG. Figura 2.3: Planificación ideal Para ver de forma más gráfica la división de tiempo del proyecto entre las distintas tareas, fases e iteraciones, en la Figura 2.4 se muestra el diagrama de Gantt. Plataforma de gestión de un club de balonmano 20 Figura 2.4: Diagrama de Gantt Plataforma de gestión de un club de balonmano 21 2.3 Plan de gestión de riesgos Para estimar la importancia de los riesgos se ha decidido utilizar un sistema propuesto por Barry Boehm [3] que consiste en hacer descripciones cualitativas del posible impacto y la probabilidad de cada riesgo y colocarlos en la llamada matriz de probabilidad de impacto. Tabla 2.1: Descripción del nivel de probabilidad Nivel de impacto Rango Alto Más del 40% de retraso en tiempo Significante 25 – 39% de retraso en tiempo Moderado 10 – 25% de retraso en tiempo Bajo Menos del 10% de retraso en tiempo Tabla 2.2: Descripción del nivel de impacto A continuación, se listan los riesgos identificados con sus probabilidades y plan de gestión: Referencia Riesgo Plan de gestión R01 Demora por el uso de tecnologías desconocidas. Aceptación. En otros proyectos se podría evitar con personal especializado, cambiando las tecnologías, o también transferirlo externalizando parte del proyecto, pero debido a su carácter académico se opta por aceptarlo y aprovechar esa demora en aprendizaje como beneficio para el futuro. Probabilidad Impacto Alto Moderado Tabla 2.3: Riesgo de demora por el uso de tecnologías desconocidas Referencia Riesgo Plan de gestión R02 Enfermedad o indisponibilidad del trabajador. Aceptación. Probabilidad Impacto Significante Alto Tabla 2.4: Riesgo de enfermedad o indisponibilidad del trabajador. Nivel de probabilidad Rango Alto Más del 50% de probabilidad de ocurrir Significante 30 – 50% de probabilidad de ocurrir Moderado 10 – 29% de probabilidad de ocurrir Bajo Menos del 10% de probabilidad de ocurrir Plataforma de gestión de un club de balonmano 22 Referencia Riesgo Plan de gestión R03 Al cliente no le guste la apariencia de la web. Mitigación. Durante la fase de elaboración se creará un prototipo de la IU sobre el que se realizarán pruebas y que posteriormente será revisado y actualizado en base a los resultados obtenidos. Probabilidad Impacto Baja Alto Tabla 2.5 : Riesgo de que al cliente no le guste la apariencia de la web Referencia Riesgo Plan de gestión R04 Incumplimiento de la planificación por dedicación del trabajador a otras tareas. Aceptación. Probabilidad Impacto Significante Bajo Tabla 2.6: Riesgo de incumplimiento de la planificación por dedicación del trabajador a otras tareas Referencia Riesgo Plan de gestión R05 Modificaciones en los requisitos. Mitigación. Tras la fase de inicio en la que se especifican los requisitos, en la fase de elaboración se harán dos iteraciones, que permitirán modificar los requisitos en una fase temprana del proyecto. Probabilidad Impacto Alta Significante Tabla 2.7: Riesgo de modificaciones en los requisitos. Referencia Riesgo Plan de gestión R06 Inclusión de características o funciones software innecesarias que solo retrasen el proyecto. Mitigación. Con las dos revisiones de requisitos en la fase de elaboración, como se explica en el R05, se pretende también reducir la probabilidad de incluir características innecesarias. Por otra parte, en la fase de construcción dividida en dos iteraciones se priorizarán las funciones más importantes, de manera que, las que pudiesen llegar a ser innecesarias no lastren la implementación de las más importantes. Probabilidad Impacto Moderada Moderado Tabla 2.8: Riesgo de inclusión de características o funciones software innecesarias que solo retrasen el proyecto. Plataforma de gestión de un club de balonmano 23 Referencia Riesgo Plan de gestión R07 La planificación es poco realista debido a la inexperiencia en dicho ámbito. Aceptación. En otros proyectos se podrían valorar otras alternativas para evitarlo como contratar un jefe de proyecto con más experiencia, sin embargo, al tratarse de un Trabajo de Fin de Grado realizado por una única persona asumirlo parece lo más lógico. Probabilidad Impacto Alta Moderado Tabla 2.9: Riesgo de planificación poco realista debido a la inexperiencia en dicho ámbito. Impacto Alto R03 R02 Significante R05 Moderado R06 R01, R07 Bajo R04 Bajo Moderado Significante Alto Probabilidad Tabla 2.10: Matriz de probabilidad de impacto En la parte superior derecha de la Tabla 2.10 hay una línea de tolerancia que separa los riesgos en dos zonas, los riesgos que aparecen en la zona marcada en rojo necesitan especial atención. 2.4 Presupuesto Para la realización del proyecto se han identificado cinco tipos diferentes de trabajadores que han de participar en distintas tareas: • Jefe de proyecto • Analista • Diseñador • Desarrollador web • Tester En la Figura 2.3 de la planificación ideal del proyecto se puede ver la asignación de tareas a estos trabajadores y en la Figura 2.5 las horas de trabajo que acumulan, su salario por horas y su salario final. Figura 2.5: Trabajo y salario de los trabajadores Plataforma de gestión de un club de balonmano 24 Estos datos han sacado en base a los salarios anuales aproximados de los distintos tipos de trabajadores [4] y el cómputo anual de una jornada de trabajo [5] para establecer un salario por horas. Por otro lado, a este presupuesto hay que sumarle el precio de alquilar un espacio donde trabajar y poder recibir a los clientes, para esto se ha elegido un espacio de coworking en Valladolid [6] que incluye en el precio la conexión a internet, añadiéndole 205€/mes al costo del proyecto. Sumándolo todo el presupuesto asciende a 4.988,61€. 2.5 Seguimiento El proyecto comienza en el curso 2019-2020, sin embargo, por motivos de la pandemia del coronavirus que comenzaba en ese curso y continua hasta la actualidad (curso 2020-2021) el proyecto se ha visto retrasado y ha dificultado su desarrollo. Esto es debido a que la situación provocada por la pandemia no tiene precedentes. Este riesgo no fue identificado al principio del proyecto, ya que al no haberse dado nunca era difícil imaginar. Por otro lado, en relación con los riesgos previstos que han afectado al proyecto se encuentra el R01. El aprendizaje de una nueva herramienta es algo beneficioso y uno de los objetivos buscados en el proyecto, pero también ha provocado retrasos en el desarrollo. Consumiendo tiempo en la comprensión de su funcionamiento, como se llevan a cabo ciertas tareas especificas, solución de errores desconocidos, etc. El R04 también se ha manifestado y aunque su impacto está catalogado como bajo debido a lo comentado al principio de este punto se ha visto agravado afectando en mayor medida al proyecto, puesto que la pandemia también afectó a otras tareas. Otro riesgo importante sufrido ha sido el R07. Este proyecto es el primer proyecto software de esta magnitud llevado a cabo por el alumno y también en el que se ha llevado la gestión, más allá de alguna práctica mucho más ligera que este trabajo. Este riesgo ha sido asimismo agravado por la pandemia haciendo que gestión escapara más allá de una situación habitual y dificultándola en gran medida. Entre los riegos restantes algunos han aparecido, pero se ha seguido el plan de gestión y han podido ser asumidos sin sufrir demasiada penalización en el desarrollo del proyecto. Para finalizar, como consecuencia de los riegos sufridos explicados anteriormente el conteo de horas del trabajo excede la planificación inicial de 300 horas y llega hasta las 378 horas, desarrolladas durante dos cursos académicos. Plataforma de gestión de un club de balonmano 25 Capítulo 3 3 Análisis En este capítulo abordamos la fase de análisis de este proyecto software realizando el análisis de requisitos, la identificación de especificación de casos de uso, el modelo de dominio y los diagramas de secuencia de cada caso de uso. 3.1 Análisis de requisitos 3.1.1 Requisitos funcionales Referencia Nombre Descripción RF01 Registrar usuario El sistema debe permitir registrar nuevos usuarios al administrador. RF02 Eliminar usuario El sistema debe permitir eliminar usuarios existentes al administrador. RF03 Editar usuario El sistema debe permitir editar la información de usuarios previamente registrados al administrador. RF02 Iniciar sesión El sistema deberá permitir identificarse a los usuarios. RF03 Crear categoría El sistema debe permitir crear una categoría al administrador. RF04 Eliminar categoría El sistema debe permitir eliminar una categoría existente al administrador. RF05 Crear equipo El sistema debe permitir crear un equipo al administrador. RF06 Eliminar equipo El sistema debe permitir eliminar un equipo existente al administrador. RF07 Nuevas noticias El sistema debe permitir crear noticias a los usuarios de tipo administrador. RF08 Editar noticias El sistema debe permitir editar noticias a los usuarios de tipo administrador. RF09 Eliminar noticias El sistema debe permitir eliminar noticias a los usuarios de tipo administrador. Plataforma de gestión de un club de balonmano 32 CU03 Ir a inicio Descripción El usuario quiere ir a la página principal del sitio web. Precondición Secuencia normal Paso Acción 1 El usuario pulsa el enlace de inicio. 2 El caso de uso finaliza. Postcondición El sistema muestra la página de inicio. Excepciones Frecuencia Alta. Tabla 3.6: Caso de uso ir a inicio CU04 Ir a noticias Descripción El usuario quiere ir a la página de noticias. Precondición Secuencia normal Paso Acción 1 El usuario pulsa el enlace de noticias. 2 El caso de uso finaliza. Postcondición El sistema muestra la página de noticias. Excepciones Frecuencia Media. Tabla 3.7: Caso de uso ir a noticias CU05 Ver una noticia Descripción El usuario quiere ver una noticia. Precondición Estar en una página que muestre enlaces a alguna noticia (Inicio/Noticias). Secuencia normal Paso Acción 1 El usuario pulsa en una noticia. 2 El caso de uso finaliza. Postcondición El sistema muestra la noticia seleccionada. Excepciones Frecuencia Media. Tabla 3.8: Caso de uso ver una noticia CU06 Comentar una noticia Descripción El usuario quiere comentar en una noticia. Precondición Estar la página de una noticia. Secuencia normal Paso Acción Plataforma de gestión de un club de balonmano 33 1 El usuario rellena los campos y pulsa el botón comentar. 2 El caso de uso finaliza. Postcondición El comentario queda registrado en el sistema. Excepciones Paso Acción 1’ Si algún campo está vacío o los datos son incorrectos se notifica y vuelve al paso 2. 1’’ Si el usuario abandona la página se avanza al paso 4 y el caso de uso queda sin efecto. Frecuencia Baja Tabla 3.9: Caso de uso comentar una noticia CU07 Ir a próximos partidos Descripción El usuario quiere ir a la página de próximos partidos. Precondición Secuencia normal Paso Acción 1 El usuario pulsa el enlace de próximos partidos. 2 El caso de uso finaliza. Postcondición El sistema muestra la página de próximos partidos. Excepciones Frecuencia Media. Tabla 3.10: Caso de uso ir a próximos partidos CU08 Ir a clasificación Descripción El usuario quiere ir a la página de clasificación. Precondición Secuencia normal Paso Acción 1 El usuario pulsa el enlace de clasificación. 2 El caso de uso finaliza. Postcondición El sistema muestra la página de clasificación. Excepciones Frecuencia Media. Tabla 3.11: Caso de uso ir a clasificación CU09 Ir a patrocinadores Descripción El usuario quiere ir a la página de patrocinadores. Precondición Secuencia normal Paso Acción 1 El usuario pulsa el enlace de patrocinadores. 2 El caso de uso finaliza. Postcondición El sistema muestra la página de patrocinadores. Plataforma de gestión de un club de balonmano 34 Excepciones Frecuencia Baja. Tabla 3.12: Caso de uso ir a patrocinadores CU10 Validar usuario Descripción El administrador quiere validar un usuario Precondición Haber iniciado sesión con una cuenta de administrador. Secuencia normal Paso Acción 1 El administrador pulsa el enlace de administración y selecciona la opción gestión de usuarios en el desplegable. 2 El sistema muestra la página de gestión de usuarios con sus opciones. 3 El administrador selecciona la opción de validar usuarios. 4 El sistema muestra la página de validación de usuarios con la lista de usuarios pendientes de validación y sus datos. 5 El administrador pulsa el botón “validar” del usuario que desea validar. 6 El caso de uso finaliza. Postcondición El usuario seleccionado por el administrador queda validado en el sistema. Excepciones Paso Acción 5 Si el usuario pulsa el botón “volver a gestión de usuarios” se avanza al paso 8 y el caso de uso queda sin efecto. Frecuencia Alta. Tabla 3.13: Caso de uso validar usuario CU11 Editar usuario Descripción El administrador quiere editar un usuario. Precondición Haber iniciado sesión con una cuenta de administrador. Secuencia normal Paso Acción 1 El administrador pulsa el enlace de administración y selecciona la opción gestión de usuarios en el desplegable. 2 El sistema muestra la página de gestión de usuarios con sus opciones. 3 El administrador pulsa el botón de editar usuarios. 4 El sistema muestra la página de edición de usuarios con la lista de usuarios activos. 5.a1 El administrador realiza una búsqueda por nombre de usuario. 5.a2 El sistema muestra la lista de usuarios que coinciden con la búsqueda. Plataforma de gestión de un club de balonmano 35 5.a3/b El administrador pulsa el botón “editar” del usuario que desea editar. 6 El sistema muestra campos editables con los datos del usuario que pueden ser modificados. 7 El administrador cambia los datos que quiere y pulsa en el botón guardar. 8 El caso de uso finaliza. Postcondición El cambio en los datos del usuario queda registrado. Excepciones Paso Acción 5.a3/b’ Si el usuario pulsa el botón “volver a gestión de usuarios” se avanza al paso 8 y el caso de uso queda sin efecto. 7’ Si algún campo está vacío o los datos son incorrectos, se notifica y vuelve al paso 6. 7’’ Si el usuario pulsa el botón “volver a edición de usuarios” se vuelve al paso 4. Frecuencia Media. Tabla 3.14: Caso de uso editar usuario CU12 Eliminar usuario Descripción El administrador quiere eliminar un usuario. Precondición Haber iniciado sesión con una cuenta de administrador. Secuencia normal Paso Acción 1 El administrador pulsa el enlace de administración y selecciona la opción gestión de usuarios en el desplegable. 2 El sistema muestra la página de gestión de usuarios con sus opciones. 3 El administrador pulsa el botón de editar usuarios. 4 El sistema muestra la página de edición de usuarios con la lista de usuarios activos. 5.a1 El administrador realiza una búsqueda por nombre de usuario. 5.a2 El sistema muestra la lista de usuarios que coinciden con la búsqueda. 5.a3/b El administrador pulsa el botón “eliminar” del usuario que desea eliminar. 6 El sistema muestra una ventana de confirmación para eliminar ese usuario. 7 El administrador pulsa en el botón de confirmar. 8 El caso de uso finaliza. Postcondición La eliminación del usuario queda registrada en el sistema. Excepciones Paso Acción Plataforma de gestión de un club de balonmano 36 5.a3/b’ Si el usuario pulsa el botón “volver a gestión de usuarios” se avanza al paso 8 y el caso de uso queda sin efecto. 7’ Si el usuario pulsa el botón cancelar se avanza al paso 8 y el caso de uso queda sin efecto. Frecuencia Baja. Tabla 3.15: Caso de uso eliminar usuario CU13 Crear categoría Descripción El administrador quiere crear una categoría. Precondición Haber iniciado sesión con una cuenta de administrador. Secuencia normal Paso Acción 1 El administrador pulsa el enlace de administración y selecciona la opción gestión de equipos en el desplegable. 2 El sistema muestra la página de gestión de equipos con sus opciones. 3 El administrador pulsa el botón de crear categoría. 4 El sistema muestra un formulario con los datos a rellenar. 5 El administrador rellena el formulario y pulsa el botón de crear categoría. 6 El caso de uso finaliza. Postcondición La creación del equipo queda registrada en el sistema. Excepciones Paso Acción 5’ Si el usuario pulsa el botón “volver a gestión de categorías” se avanza al paso 6 y el caso de uso queda sin efecto. 5’’ Si algún campo está vacío o los datos son incorrectos, se notifica y vuelve al paso 4. Frecuencia Baja. Tabla 3.16: Caso de uso crear categoría CU14 Eliminar categoría Descripción El administrador quiere eliminar una categoría. Precondición Haber iniciado sesión con una cuenta de administrador. Secuencia normal Paso Acción 1 El administrador pulsa el enlace de administración y selecciona la opción gestión de equipos en el desplegable. 2 El sistema muestra la página de gestión de equipos con sus opciones. 3 El administrador pulsa el botón de eliminar categoría. 4 El sistema muestra la página de eliminación de categorías con la lista de categorías. Plataforma de gestión de un club de balonmano 37 5 El administrador pulsa el botón “eliminar” de la categoría deseada. 6 El sistema muestra una ventana de confirmación para eliminar esa categoría. 7 El administrador pulsa en el botón de confirmar. 8 El caso de uso finaliza. Postcondición La eliminación de la categoría queda registrada en el sistema. Excepciones Paso Acción 5’ Si el usuario pulsa el botón “volver a gestión de equipos” se avanza al paso 8 y el caso de uso queda sin efecto. 5’’ Si la categoría tiene algún equipo no se permitirá la eliminación, se notificará y vuelve al paso 4. 7’ Si el usuario pulsa el botón cancelar se avanza al paso 8 y el caso de uso queda sin efecto. Frecuencia Baja. Tabla 3.17: Caso de uso eliminar categoría CU15 Crear equipo Descripción El administrador quiere crear un equipo. Precondición Haber iniciado sesión con una cuenta de administrador. Secuencia normal Paso Acción 1 El administrador pulsa el enlace de administración y selecciona la opción gestión de equipos en el desplegable. 2 El sistema muestra la página de gestión de equipos con sus opciones. 3 El administrador pulsa el botón de crear equipo. 4 El sistema muestra un formulario con los datos a rellenar. 5 El administrador rellena el formulario y pulsa el botón de crear equipo. 6 El caso de uso finaliza. Postcondición La creación del equipo queda registrada en el sistema. Excepciones Paso Acción 5’ Si el usuario pulsa el botón “volver a gestión de categorías” se avanza al paso 6 y el caso de uso queda sin efecto. 5’’ Si algún campo está vacío o los datos son incorrectos, se notifica y vuelve al paso 4. Frecuencia Baja. Tabla 3.18: Caso de uso crear equipo Plataforma de gestión de un club de balonmano 38 CU16 Eliminar equipo Descripción El administrador quiere eliminar un equipo. Precondición Haber iniciado sesión con una cuenta de administrador. Secuencia normal Paso Acción 1 El administrador pulsa el enlace de administración y selecciona la opción gestión de equipos en el desplegable. 2 El sistema muestra la página de gestión de equipos con sus opciones. 3 El administrador pulsa el botón de eliminar equipo. 4 El sistema muestra la página de eliminación de equipos con la lista de categorías. 5 El administrador pulsa el botón “eliminar” del equipo deseado. 6 El sistema muestra una ventana de confirmación para eliminar ese equipo. 7 El administrador pulsa en el botón de confirmar. 8 El caso de uso finaliza. Postcondición La eliminación del equipo queda registrada en el sistema. Excepciones Paso Acción 5’ Si el usuario pulsa el botón “volver a gestión de equipos” se avanza al paso 8 y el caso de uso queda sin efecto. 7’ Si el usuario pulsa el botón cancelar se avanza al paso 8 y el caso de uso queda sin efecto. Frecuencia Baja. Tabla 3.19: Caso de uso eliminar equipo CU17 Crear noticia Descripción El administrador quiere crear una noticia. Precondición Haber iniciado sesión con una cuenta de administrador. Secuencia normal Paso Acción 1 El administrador pulsa el enlace de administración y selecciona la opción gestión de noticias en el desplegable. 2 El sistema muestra la página de gestión de noticias con sus opciones. 3 El administrador pulsa el botón de crear noticia. 4 El sistema muestra un formulario con los datos a rellenar. 5 El administrador rellena el formulario y pulsa el botón de crear noticia. 6 El caso de uso finaliza. Postcondición La creación de la noticia queda registrada en el sistema. Excepciones Paso Acción Plataforma de gestión de un club de balonmano 39 5’ Si el usuario pulsa el botón “volver a gestión de noticias” se avanza al paso 6 y el caso de uso queda sin efecto. 5’’ Si algún campo está vacío o los datos son incorrectos, se notifica y vuelve al paso 4. Frecuencia Alta. Tabla 3.20: Caso de uso crear noticia CU18 Editar noticia Descripción El administrador quiere editar una noticia. Precondición Haber iniciado sesión con una cuenta de administrador. Secuencia normal Paso Acción 1 El administrador pulsa el enlace de administración y selecciona la opción gestión de noticias en el desplegable. 2 El sistema muestra la página de gestión de noticias con sus opciones. 3 El administrador pulsa el botón de editar noticias. 4 El sistema muestra la página de edición de noticias con la lista de noticias. 5 El administrador pulsa el botón “editar” de la noticia que desea editar. 6 El sistema muestra campos editables con los datos de la noticia que pueden ser modificados. 7 El administrador cambia los datos que quiere y pulsa en el botón guardar. 8 El caso de uso finaliza. Postcondición La edición de la noticia queda registrada en el sistema. Excepciones Paso Acción 5’ Si el usuario pulsa el botón “volver a gestión de noticias” se avanza al paso 8 y el caso de uso queda sin efecto. 7’ Si el usuario pulsa el botón “volver a edición de noticias” se vuelve al paso 4. 7’’ Si algún campo está vacío o los datos son incorrectos, se notifica y vuelve al paso 6. Frecuencia Baja. Tabla 3.21: Caso de uso editar noticia CU19 Eliminar noticia Descripción El administrador quiere eliminar una noticia. Precondición Haber iniciado sesión con una cuenta de administrador. Secuencia normal Paso Acción Plataforma de gestión de un club de balonmano 40 1 El administrador pulsa el enlace de administración y selecciona la opción gestión de noticias en el desplegable. 2 El sistema muestra la página de gestión de noticias con sus opciones. 3 El administrador pulsa el botón de editar noticia. 4 El sistema muestra la página de edición de noticias con la lista de noticias. 5 El administrador pulsa el botón “eliminar” de la noticia deseada. 6 El sistema muestra una ventana de confirmación para eliminar esa noticia. 7 El administrador pulsa en el botón de confirmar. 8 El caso de uso finaliza. Postcondición La eliminación de la noticia queda registrada en el sistema. Excepciones Paso Acción 5’ Si el usuario pulsa el botón “volver a gestión de noticias” se avanza al paso 8 y el caso de uso queda sin efecto. 7’ Si el usuario pulsa el botón cancelar se avanza al paso 8 y el caso de uso queda sin efecto. Frecuencia Baja. Tabla 3.22: Caso de uso eliminar noticia CU20 Eliminar comentario Descripción El administrador quiere eliminar un comentario. Precondición Haber iniciado sesión con una cuenta de administrador. Secuencia normal Paso Acción 1 El administrador pulsa el enlace de administración y selecciona la opción gestión de noticias en el desplegable. 2 El sistema muestra la página de gestión de noticias con sus opciones. 3 El administrador pulsa el botón de editar noticias. 4 El sistema muestra la lista de noticias. 5 El administrador pulsa el botón de comentarios de la noticia deseada. 6 El sistema muestra la página de eliminación de comentarios con la lista de comentarios de la noticia seleccionada. 7 El administrador pulsa el botón “eliminar” del comentario deseado. 8 El sistema muestra una ventana de confirmación para eliminar ese comentario. 9 El administrador pulsa en el botón de confirmar. Plataforma de gestión de un club de balonmano 41 10 El caso de uso finaliza. Postcondición La eliminación del comentario queda registrada en el sistema. Excepciones Paso Acción 7’ Si el usuario pulsa el botón “volver a gestión de noticias” se avanza al paso 8 y el caso de uso queda sin efecto. 9’ Si el usuario pulsa el botón cancelar se avanza al paso 8 y el caso de uso queda sin efecto. Frecuencia Baja. Tabla 3.23: Caso de uso eliminar comentario CU21 Crear cuota Descripción El administrador quiere crear una cuota. Precondición Haber iniciado sesión con una cuenta de administrador. Secuencia normal Paso Acción 1 El administrador pulsa el enlace de administración y selecciona la opción gestión de cuotas en el desplegable. 2 El sistema muestra la página de gestión de cuotas con sus opciones. 3 El administrador pulsa el botón de crear cuota. 4 El sistema muestra un formulario con los datos a rellenar. 5 El administrador rellena el formulario y pulsa el botón de crear cuota. 6 El caso de uso finaliza. Postcondición La creación de la cuota queda registrada en el sistema. Excepciones Paso Acción 5’ Si el usuario pulsa el botón “volver a gestión de cuotas” se avanza al paso 6 y el caso de uso queda sin efecto. 5’’ Si algún campo está vacío o los datos son incorrectos, se notifica y vuelve al paso 4. Frecuencia Alta. Tabla 3.24: Caso de uso crear cuota CU22 Editar cuota Descripción El administrador quiere editar una cuota. Precondición Haber iniciado sesión con una cuenta de administrador. Secuencia normal Paso Acción 1 El administrador pulsa el enlace de administración y selecciona la opción gestión de cuotas en el desplegable. 2 El sistema muestra la página de gestión de cuotas con sus opciones. 3 El administrador pulsa el botón de editar cuotas. Plataforma de gestión de un club de balonmano 48 3.3 Modelo de dominio En la Figura 3.3 se puede ver el modelo de dominio después de identificar las clases y sus relaciones a nivel de análisis. Figura 3.3: Modelo de Dominio inicial Plataforma de gestión de un club de balonmano 49 Tras una de las iteraciones se ha tomado la decisión de eliminar unos requisitos (ya comentados en el apartado 3.2.2) y por tanto los casos de uso derivados de los mismos, provocando la eliminación de la clase Evento y el enumerado TipoEvento. Por otro lado, se ha decidido cambiar el atributo talla de la clase Elemento a DetalleElemento. Figura 3.4: Modelo de dominio tras la modificación Plataforma de gestión de un club de balonmano 50 3.4 Diagramas de secuencia En este punto se mostrarán los diagramas de secuencia de cada caso de uso, los casos de uso del 3 – 5 y 7 – 9 no se mostrarán al tratarse de la navegación principal del sitio web (que es extremadamente simple). Figura 3.5: Diagrama de secuencia del CU01 Figura 3.6: Diagrama de secuencia registro de mayor de edad (CU01) Plataforma de gestión de un club de balonmano 51 Figura 3.7: Diagrama de secuencia registro de menor de edad (CU01) Figura 3.8: Diagrama de secuencia del CU02 Plataforma de gestión de un club de balonmano 52 Figura 3.9: Diagrama de secuencia del CU06 Figura 3.10: Diagrama de secuencia del CU10 Plataforma de gestión de un club de balonmano 53 Figura 3.11: Diagrama de secuencia del CU11 Plataforma de gestión de un club de balonmano 54 Figura 3.12: Diagrama de secuencia del CU12 Figura 3.13: Diagrama de secuencia del CU13 Plataforma de gestión de un club de balonmano 55 Figura 3.14: Diagrama de secuencia del CU14 Figura 3.15: Diagrama de secuencia del CU15 Plataforma de gestión de un club de balonmano 56 Figura 3.16: Diagrama de secuencia del CU16 Figura 3.17: Diagrama de secuencia del CU17 Plataforma de gestión de un club de balonmano 57 Figura 3.18: Diagrama de secuencia del CU18 Figura 3.19: Diagrama de secuencia del CU19 Plataforma de gestión de un club de balonmano 64 propagación de eventos, carga de recursos y la creación transparente de contexts. La interfaz de ApplicationContext es el punto clave en el que se enfoca este módulo. Por último, el módulo Expression Language proporciona un poderosos lenguaje de expresiones para consultar y manipular objetos en tiempo de ejecución. Este es una extensión del lenguaje de expresiones unificadas (unified EL). • Data Access/Integration: estos módulos dan soporte a distintas formas de acceso a datos. • Web: El módulo Web proporciona características de integración básicas orientadas a sitios web como la funcionalidad multipart file-upload y la inicialización del contenedor IoC utilizando servlets listeners y un application context orientado a web. El módulo Servlet contiene la implementación del Modelo-Vista-Controlador (MVC) de Spring para aplicaciones web. Para finalizar, el módulo Portlet proporciona la implementación MVC para ser utilizada en un entorno portlet y refleja la funcionalidad del módulo Servlet. • AOP (Aspect Oriented Programming): proporciona compatibilidad con la implementación de programación orientada a aspectos. • Instrumentation: proporciona implementaciones de las clases instrumentation y classloader para ser utilizadas en ciertos servidores de aplicaciones. • Test: proporciona soporte para la realización de pruebas a componentes de Spring con JUnit o TestNG. La Figura 4.2 muestra el ciclo de vida de una petición en Spring MVC, a continuación, se describen sus pasos [8]: 1) DispatcherServlet recibe la petición. 2) DispatcherServlet remite la tarea de seleccionar un controlador apropiado a HandlerMapping. HandlerMapping selecciona el controlador que esta mapeado para la petición URL entrante y devuelve el Handler seleccionado y Controller al DispatcherServlet. 3) DispatcherServlet remite la tarea de ejecutar la lógica de negocio del Controller al HandlerAdapter. 4) HandlerAdapter llama al proceso de la lógica de negocio del Controller. 5) Controller ejecuta la lógica de negocio, establece el resultado del proceso en el Model y devuelve el nombre lógico de la vista al HandlerAdapter. 6) DispatcherServlet remite la tarea de resolver la View correspondiente al nombre de la vista al ViewResolver. ViewResolver devuelve la View mapeada al nombre de la vista. 7) DispatcherServlet remite el procesamiento a la View devuelta. 8) View procesa los datos del Model y devuelve la respuesta. Plataforma de gestión de un club de balonmano 65 Figura 4.2: Ciclo de vida de una petición en Spring MVC 4.2 Hibernate Hibernate es una herramienta de mapeo objeto-relacional (ORM) bajo licencia GNU LGPL para Java, que facilita el mapeo de atributos en una base de datos tradicional, y el modelo de objetos de una aplicación mediante archivos declarativos o anotaciones en los beans de las entidades que permiten establecer estas relaciones [9]. En muchos programas existen dos modelos de datos que coexisten: el de la memoria de la computadora (orientación a objetos) y el usado en la base de datos (modelo relacional). Hibernate trata de solucionar este problema permitiéndonos detallar como es nuestro modelo de datos por medio de un documento XML o de anotaciones donde corresponde un atributo de una clase con una columna de la base de datos o una clase con una tabla. Con toda esta información Hibernate puede manipular los datos en la base de datos operando sobre objetos y manteniendo las características de la programación orientada a objetos. De esta manera Hibernate genera por nosotros las sentencias SQL aliviando mucho el trabajo del desarrollador y manteniendo la portabilidad entre todos los motores de bases de datos con un ligero incremento en el tiempo de ejecución. Plataforma de gestión de un club de balonmano 66 4.3 Arquitectura 4.3.1 Arquitectura Lógica En la Figura 4.3 se muestra la arquitectura lógica del sistema, es una arquitectura de tres capas estrictas, utilizando el patrón arquitectónico MVC de acuerdo con uno de los requisitos del proyecto, viéndose la división entre Cliente y Servidor. Esta estructura en tres capas facilita que la interfaz de usuario y la base de datos sean modificables. En el cliente se encuentra la capa de presentación que tiene las vistas y sus controladores y en lado del servidor está la API REST, que trabaja con la base de datos y es con la que se comunica el cliente. Figura 4.3: Arquitectura lógica Plataforma de gestión de un club de balonmano 67 4.3.2 Presentación La capa de presentación presenta el patrón arquitectónico MVC. En la figura 4.4 se puede ver en detalle el paquete que contiene las vistas, en este caso los HTML en los que se usa Thymeleaf, una biblioteca Java que implementa un motor de plantillas con un módulo para su integración con Spring MVC reemplazando a los archivos JSP [10]. Thymeleaf permite la creación de plantillas HTML que puedan ser correctamente mostradas en buscadores y que trabajen como prototipos estáticos. Figura 4.4: Diagrama detallado de los HTML, CSS y scripts de la capa de presentación (1) Además, en esta parte se incluyen los estilos CSS y archivos JavaScript que son necesarios para la interacción en las páginas. Por otro lado, tenemos los controladores como se muestra en la Figura 4.5. Estos han sido divididos por las distintas partes del sitio web que se encargan de controlar. WebController para la navegación habitual, incluyendo registro e inicio de sesión y cada uno de los demás para su correspondiente parte de administración: usuarios, noticias, equipos (y categorías), cuotas y equipamientos. Cada controlador Plataforma de gestión de un club de balonmano 68 cuenta con una baseUrl que contiene la dirección de la API REST y con un objeto RestTemplate para ejecutar las peticiones a la API. En el paquete config están la clase Config, en la que entre otras cosas se configura la seguridad de la aplicación y se crea el encoder para las contraseñas y el AttributeEncryptor en el que se define la contraseña de encriptación para los datos sensibles que se guardarán en la base de datos. Figura 4.5: Diagrama detallado de la capa de presentación (2) 4.3.3 Lógica de Negocio En esta capa se encuentran los modelos, que también son utilizados por la capa de presentación formando parte del patrón MVC. En la Figura 4.6 se pueden ver las clases anotadas como <<entity>> que representan las tablas en la base de datos. Además de ellas aparecen también los enumerados, PK_Rol representando la clave primaria de la tabla Rol, debido a que es una clave compuesta, y dos clases auxiliares para el trabajo de los controladores y las vistas: Familia y CreacionEquipamiento. Plataforma de gestión de un club de balonmano 69 Figura 4.6: Diagrama detallado de capa lógica de negocio (1) Por otro lado, como se puede ver en la Figura 4.7 aparecen el controlador y los servicios de la API REST. El controlador es el que atiende todas las peticiones de: acceso (GET), creación (POST), eliminación (DELETE) y actualización (PUT). Y posteriormente, valiéndose de los servicios y estos a su vez de sus correspondientes repositorios, las resuelven. En otros diagramas y en este en concreto se pueden ver las interfaces en notación de icono representadas como círculos. Plataforma de gestión de un club de balonmano 70 Figura 4.7: Diagrama detallado de la capa lógica de negocio (2) Plataforma de gestión de un club de balonmano 71 4.3.4 Acceso a Datos Por último, en esta capa de acceso a datos se encuentran los repositorios de la API REST como se puede ver en la Figura 4.8. Todos extienden las interfaces JpaRepository y QuerydslPredicateExecutor menos ElementoRepository que solo extiende de JpaRepository. Con JPA obtenemos las operaciones básicas CRUD y con QueryDsl conseguimos hacer consultas más complejas de manera más simple utilizando los modelos que se crean automáticamente a partir de tus entities con el mismo nombre precedidos de la letra “Q”. De tal manera que, por ejemplo, podrías utilizar el EquipoRepository para hacer una consulta en función del nombre de un equipo utilizando como parámetro: QEquipo.equipo.nombre.eq(“nombre”). Figura 4.8: Diagrama detallado de la capa de acceso a datos 4.4 Patrones arquitectónicos En la aplicación se usan varios patrones arquitectónicos ya mencionados brevemente a lo largo de la memoria, en este punto se explicarán más detalladamente sus implicaciones y el motivo de su uso. Plataforma de gestión de un club de balonmano 72 4.4.1 Modelo Vista Controlador (MVC) Este es un patrón muy usado en desarrollo web porque ayuda a la separación de los componentes. Este patrón se basa en desacoplar los objetos del dominio (modelo) de las ventanas (vistas) para mejorar la reusabilidad de los objetos del dominio y minimizar el impacto de los cambios de la interfaz en los objetos del dominio. En el caso que nos ocupa se usa la variante pasiva del MVC, implicando que el controlador manipula de forma exclusiva el modelo. En este escenario el modelo es completamente independiente a la vista y el controlador. En nuestro proyecto la vista está representada por los archivos HTML en el paquete templates que utilizan los estilos para mostrar la interfaz de usuario. El controlador son los controladores que aparecen en el paquete controllers, que controlan todos los eventos que lanzan las vistas, se comunican con el modelo si fuese necesario y actualizan la vista. Por último, el modelo aparece en el paquete modelos donde se encuentran los objetos que representan la base de datos de los que la vista obtiene la información que necesita mostrar. Con todo esto podemos explicar el flujo de la siguiente manera: el usuario interactúa con la vista, la vista lanza un evento, el controlador recibe el evento, realiza las operaciones necesarias, incluyendo la comunicación con la base de datos de la que obtiene o actualiza el modelo y devuelve lo necesario a la vista. 4.4.2 Data Access Object (DAO) El patrón DAO se basa en usar un objeto DAO que abstraiga y encapsule el acceso a la fuente de datos. De tal forma el DAO gestiona la conexión con la fuente de datos para obtener y almacenar la información. En la Figura 4.9 se puede ver cuál es la estructura de este patrón. Figura 4.9: Patrón DAO En nuestra aplicación los objetos DAO se encuentran en la capa de acceso a datos en el paquete repositories, y estos a través de JPA ya nos facilitan las implementaciones básicas de acceso a datos CRUD (Create Read Update Delete) de manera que, solo nos haría falta implementar otros métodos para acciones más complejas. Plataforma de gestión de un club de balonmano 73 Por otro lado, como objeto de transferencia de datos son usadas las clases del paquete modelos que como entities representan las tablas de la base de datos. Los beneficios que ofrece este patrón son: • Favorece la transparencia. • Facilita la migración de los componentes. • Reduce la complejidad del código. • Centraliza todo el acceso a datos en una capa. 4.4.3 Front Controller Este patrón implica que hay un controlador que maneja todas las peticiones a un sitio web. Como se puede ver en la Figura 4.2 mostrada en el punto 4.1 donde se explica el framework Spring, este usa el patrón Front Controller y aparece representado como el Dispatcher Servlet y una serie de handlers en los que delega para las distintas responsabilidades que tiene, como encontrar el controlador indicado para una petición concreta o resolver la vista que se necesita. Este patrón es común en otros frameworks MVC como Struts. 4.4.4 Singleton Este patrón se basa en la creación de una instancia única para una clase. Este patrón se lleva a cabo a través de Spring con anotaciones, de tal manera que, se define un método que cree la instancia y se pone la anotación @Bean. De esta manera cuando en una clase pongamos una variable de ese tipo y la anotemos con @Autowired no tenemos que crearla, sino que Spring inyectará el bean por nosotros. 4.4.5 Inversión de Control (IoC) La inversión de control [11] no es un patrón sino un principio de software que se basa en la introspección, a través de ella el framework es capaz de leer los metadatos de la aplicación para entender como funciona. Estos metadatos se pueden encontrar en XML y o en las propias aplicaciones con anotaciones. De esta manera es como el control de la aplicación es traspasado al framework que es capaz de entenderla. Este sistema se puede conseguir implementando diferentes patrones software y en el caso de Spring lo logra con la inyección de dependencias que se explica en el siguiente apartado. 4.4.6 Inyección de Dependencias (DI) La inyección de dependencias [12] es un patrón que se sirve de las dependencias que definen unos objetos sobre otros. Estas dependencias se mantienen en un contenedor que se encargará de inyectarlas y crear los beans. Plataforma de gestión de un club de balonmano 81 Capítulo 6 6 Pruebas En este capítulo se expondrán las pruebas realizadas para estudiar el funcionamiento de la aplicación y corregir los fallos detectados. Cada método ha sido probado, sin embargo, se mostrarán las pruebas de caja negra guiadas por caso de uso más interesantes o que hayan ayudado con la detección de errores para no saturar el documento y posteriormente los resultados obtenidos en dichas pruebas. 6.1 Casos de prueba 6.1.1 Iniciar sesión CP01 Iniciar sesión como administrador Descripción Un usuario quiere iniciar sesión como administrador. Entrada • usuario: admin • contraseña: admin Salida esperada Página de inicio con sesión iniciada como admin. Tabla 6.1: Caso de prueba iniciar sesión como administrador CP02 Iniciar sesión como usuario Descripción Un usuario quiere iniciar sesión en el sistema. Entrada • usuario: henry • contraseña: henry Salida esperada Página de inicio con sesión iniciada como henry. Tabla 6.2: Caso de prueba iniciar sesión como usuario CP03 Iniciar sesión sin estar validado Descripción Un usuario inicia sesión sin estar validado. Entrada • usuario: andres • contraseña: andres Salida esperada Recargar página con mensaje de error por no estar validado. Tabla 6.3: Caso de prueba iniciar sesión sin estar validado Plataforma de gestión de un club de balonmano 82 CP04 Iniciar sesión con credenciales erróneas Descripción Un usuario inicia sesión con credenciales incorrectas. Entrada • usuario: admin • contraseña: admi Salida esperada Recargar página con mensaje de error en las credenciales. Tabla 6.4: Caso de prueba iniciar sesión con credenciales erróneas 6.1.2 Registrarse CP05 Registrarse como mayor de edad Descripción Un usuario se registra como mayor de edad. Entrada • nombre: Perico • apellidos: Montes Azul • dni: 17283952A • fecha de nacimiento: 10/05/1995 • usuario: perico • email: [email protected] • contraseña: perico • repetir contraseña: perico • categoría: Alevín Masculino • equipo: Monte • rol: entrenador Salida esperada Página de inicio y usuario y persona creada Tabla 6.5: Caso de prueba registrarse como mayor de edad CP06 Registrarse como mayor de edad con fecha de menor Descripción Un usuario se registra como mayor de edad con una fecha de menor. Entrada • nombre: Perico • apellidos: Montes Azul • dni: 17283952A • fecha de nacimiento: 10/05/2020 • usuario: perico • email: [email protected] • contraseña: perico • repetir contraseña: perico • categoría: Alevín Masculino • equipo: Monte • rol: entrenador Salida esperada Recargar página con mensaje de error en la fecha. Tabla 6.6: Caso de prueba registrarse como mayor de edad con fecha de menor Plataforma de gestión de un club de balonmano 83 CP07 Registrarse como menor de edad Descripción Un usuario se registra como menor de edad. Entrada • nombre tutor: Mariano • apellidos tutor: Gómez Ámbar • dni tutor: 17283952B • nombre: Periquito • apellidos: Montes Azul • dni: 1728395C • fecha de nacimiento: 10/05/2020 • usuario: periquito • email: [email protected] • contraseña: periquito • repetir contraseña: periquito • categoría: Alevín Masculino • equipo: Monte • rol: jugador Salida esperada Página de inicio y usuario y personas creadas. Tabla 6.7: Caso de prueba registrarse como menor de edad CP08 Registrarse como menor de edad con fecha de mayor Descripción Un usuario se registra como menor de edad con una fecha de mayor. Entrada • nombre tutor: Mariano • apellidos tutor: Gomis Ámbar • dni tutor: 17283952B • nombre: Periquito • apellidos: Montes Azul • dni: 17283952C • fecha de nacimiento: 10/05/1996 • usuario: periquito • email: [email protected] • contraseña: periquito • repetir contraseña: periquito • categoría: Alevín Masculino • equipo: Monte • rol: jugador Salida esperada Recargar página con mensaje de error en la fecha. Tabla 6.8: Caso de prueba registrarse como menor de edad con fecha de mayor Plataforma de gestión de un club de balonmano 84 CP09 Registrarse con contraseñas que no coinciden Descripción Un usuario se registra con contraseñas que no coinciden. Entrada • nombre: Perico • apellidos: Montes Azul • dni: 17283952A • fecha de nacimiento: 10/05/2020 • usuario: perico • email: [email protected] • contraseña: perico • repetir contraseña: perico33 • categoría: Alevín Masculino • equipo: Monte • rol: entrenador Salida esperada Recargar página con mensaje de error en las contraseñas. Tabla 6.9: Caso de prueba registrarse con contraseñas que no coinciden CP010 Registrarse con DNI ya almacenado Descripción Un usuario se registra con un DNI ya registrado. Entrada • nombre: Perico • apellidos: Montes Azul • dni: 12341234A • fecha de nacimiento: 10/05/2020 • usuario: perico • email: [email protected] • contraseña: perico • repetir contraseña: perico33 • categoría: Alevín Masculino • equipo: Monte • rol: entrenador Salida esperada Recargar página con mensaje de error en el DNI. Tabla 6.10: Caso de prueba registrarse con DNI ya almacenado CP11 Registrarse con nombre de usuario ya almacenado Descripción Un usuario se registra con un nombre de usuario ya registrado. Entrada • nombre: Perico • apellidos: Montes Azul • dni: 12341234A • fecha de nacimiento: 10/05/2020 • usuario: henry • email: [email protected] Plataforma de gestión de un club de balonmano 85 • contraseña: perico • repetir contraseña: perico • categoría: Alevín Masculino • equipo: Monte • rol: entrenador Salida esperada Recargar página con mensaje de error en el nombre de usuario. Tabla 6.11: Caso de prueba registrarse con nombre de usuario ya almacenado 6.1.3 Editar noticia CP12 Editar noticia Descripción Un administrador accede a la edición de una noticia y cambia sus campos. Entrada Modifica el título, texto y selecciona una nueva imagen. Salida esperada Página de editar noticias y la noticia se actualizó. Tabla 6.12: Caso de prueba editar noticia CP13 Editar noticia con imagen muy pesada Descripción Un administrador accede a la edición de una noticia e intenta cambiar la imagen por una de más de 1MB. Entrada Selecciona una nueva imagen de más de 1MB. Salida esperada Mensaje de error al cambiar la imagen. Tabla 6.13: Caso de prueba editar noticia con imagen muy pesada 6.1.4 Crear equipo CP14 Crear equipo Descripción Un administrador crea un equipo. Entrada • nombre: Manzanos • categoría: Benjamín Masculino Salida esperada Página de administración de equipos y equipo creado. Tabla 6.14: Caso de prueba crear equipo CP15 Crear equipo con un nombre existente Descripción Un administrador crea un equipo con un nombre ya existente. Entrada • nombre: Monte • categoría: Benjamín Masculino Salida esperada Mensaje de error en el nombre. Tabla 6.15: Caso de prueba crear equipo con un nombre existente Plataforma de gestión de un club de balonmano 86 6.1.5 Eliminar categoría CP16 Eliminar categoría Descripción Un administrador elimina una categoría. Entrada Pulsa el botón eliminar de la categoría “Liga Asobal”. Salida esperada Recarga la página y la categoría ha sido eliminada. Tabla 6.16: Caso de prueba eliminar categoría CP17 Eliminar categoría con equipos Descripción Un administrador intenta eliminar una categoría con equipos. Entrada Pulsa el botón eliminar de la categoría “Benjamín Masculino”. Salida esperada Mensaje de error al eliminar la categoría. Tabla 6.17: Caso de prueba eliminar categoría con equipos 6.1.6 Crear cuota CP18 Crear cuota Descripción Un administrador crea una cuota. Entrada • importe: 50 • nombre: Manzanos • categoría: Benjamín Masculino Salida esperada Página de administración de cuotas y cuotas a los jugadores del equipo creadas. Tabla 6.18: Caso de prueba crear cuota CP19 Crear cuota con importe menor a 5 Descripción Un administrador intenta crear una cuota con un importe menor a 5. Entrada • importe: 4,99 • nombre: Manzanos • categoría: Benjamín Masculino Salida esperada Mensaje de error por importe inferior a 5. Tabla 6.19: Caso de prueba crear cuota con importe menor a 5 Plataforma de gestión de un club de balonmano 87 6.1.7 Editar cuota CP20 Editar cuota Descripción Un administrador edita una cuota. Entrada Modifica el importe a “67,99”, cambia el estado de pago de la cuota y pulsa en guardar. Salida esperada Página de edición de cuotas y cuota modificada. Tabla 6.20: Caso de prueba editar cuota CP21 Editar cuota con importe menor a 5 Descripción Un administrador intenta editar una cuota con un importe menor a 5. Entrada Modifica el importe por 4,99 y pulsa en guardar. Salida esperada Mensaje de error por importe inferior a 5. Tabla 6.21: Caso de prueba editar cuota con importe menor a 5 6.1.8 Registrar entrega equipamiento CP22 Registrar entrega de equipamiento Descripción Un administrador registra la entrega de un equipamiento. Entrada Pulsa en el botón registrar entrega de equipamiento. Salida esperada Recarga la página y el equipamiento queda actualizado como pagado a fecha del día actual. Tabla 6.22: Caso de prueba registrar entrega de equipamiento 6.2 Resultados de las pruebas Todas las pruebas han sido realizadas sobre un MacBook Pro (16 pulgadas, 2019) con un procesador de 2,6 GHz Intel Core i7 de 6 núcleos, memoria de 16 GB 2667 MHz DDR4 y con el navegador Google Chrome. Prueba Resultado Resolución CP01 Pasado - CP02 Pasado - CP03 Fallado. El usuario no inicia sesión, pero no obtiene mensaje de error. Se añade el control de los mensajes de error que no habían sido añadidos. Pasado. CP04 Pasado. - CP05 Pasado. - CP06 Fallado. Registra al usuario. Se añade el control de edad, calculándola a partir de la fecha de nacimiento y comprobando si es mayor de 18 años. Pasado. Plataforma de gestión de un club de balonmano 88 CP07 Pasado. - CP08 Fallado. Registra al usuario. Se añade el control de edad, calculándola a partir de la fecha de nacimiento y comprobando si es menor de 18 años. Pasado. CP09 Pasado. - CP10 Pasado. - CP11 Pasado. - CP12 Pasado. - CP13 Pasado. - CP14 Pasado. - CP15 Pasado. - CP16 Pasado. - CP17 Pasado. - CP18 Pasado. - CP19 Pasado. - CP20 Pasado. - CP21 Pasado. - CP22 Pasado. - Tabla 6.23: Resultados de las pruebas Plataforma de gestión de un club de balonmano 89 Capítulo 7 7 Conclusiones En este capítulo se exponen los objetivos cumplidos durante la realización de este proyecto, se proponen futuras mejoras para la aplicación y finaliza con la valoración personal del alumno sobre sobre este trabajo. 7.1 Objetivos cumplidos A continuación, se listarán los objetivos cumplidos durante el desarrollo de este proyecto: § Se ha aprendido a trabajar con el framework Spring y como usarlo para el desarrollo de una API REST en conjunto con una aplicación web. § Se ha aprendido a utilizar Thymeleaf para el desarrollo de páginas web junto con Spring sin tener que usar archivos JSP. § Se ha realizado el diseño de una interfaz sencilla y amable con el usuario. § Se ha aprendido sobre el funcionamiento de Spring Security, consiguiendo aplicar seguridad al sitio web y encriptar los datos sensibles para ser almacenados en la base de datos. § Se ha investigado sobre los términos, condiciones de uso y la ley de protección de datos en sitios web, consiguiendo la elaboración de unos términos acordes con la página de un club de balonmano. § Se ha conseguido la funcionalidad habitual de un sitio web usado para ver noticias e información de un club de balonmano. § Se ha conseguido la funcionalidad de gestión de un club de balonmano ofreciendo la posibilidad de gestionar: usuarios, noticias, cuotas, equipamientos, equipos y categorías. § Se ha aprendido sobre la herramienta nueva heroku para realizar el despliegue de aplicaciones, consiguiendo desplegar la aplicación remotamente, de forma que esta sea accesible desde cualquier sitio a través de internet. § Se ha aprendido sobre la gestión de proyectos software, consiguiendo desarrollar el proyecto siguiendo el plan de desarrollo RUP y elaborando: la planificación, la gestión de riesgos, el presupuesto y el seguimiento del proyecto. 7.2 Futuras mejoras En este punto se proponen una serie de funcionalidades y mejoras que podrían ser de utilidad para la evolución de la aplicación: Plataforma de gestión de un club de balonmano 97 Anexos Anexo I – Manual de instalación A continuación, se listan los pasos para desplegar la aplicación en heroku por si no funcionase el despliegue del alumno (en https://clubbalonmano-tfg.herokuapp.com/ ): 1. Crea un directorio para almacenar los archivos fuente de la aplicación y abre un terminal en el directorio, después ejecutamos: git clone https://gitlab.inf.uva.es/jormonc/club-balonmano-tfg.git 2. Si no tienes una cuenta en Heroku regístrate en https://signup.heroku.com/. 3. En heroku crea una nueva aplicación en tu dashboard. 4. En esa aplicación en la pestaña de Resources añade el add-ons: Heroku Postgres. 5. Ir a Heroku Postgres – Settings – View Credentials para ver las credenciales de la base de datos. 6. Hay que ejecutar los scripts SQL llamados schema-postgres y data-postgres situados en src/main/resources. Para ello puedes usar la herramienta pgAdmin o psql con el terminal. 7. Una vez creada y poblada la base de datos debes cambiar en el fichero application.properties los datos de la base de datos por los que aparecen en las credenciales de heroku (database, user, port y password). 8. En el terminal del directorio ejecutamos: a. heroku login b. heroku git:remote -a nombreAplicacionHeroku c. git add . d. git commit -am “puesta en marcha” e. git push heroku master 9. Al terminar el último comando pondrá la URL en la que se ha desplegado el proyecto. Cópiala y cambia las URLs que conectan con la API de los archivos situados en las carpetas src/main/resources/static/scripts (no todos los scripts usan la URL) y src/main/java/com/jorgemoncadas/webClubBalonmano/controllers (ten en cuenta que los baseUrl deben terminar en /api/). 10. Por último, repite los comandos c, d y e para actualizar la aplicación y ya podrás acceder a la aplicación con tu URL. Plataforma de gestión de un club de balonmano 99 Anexo II – Manual de administrador Lo primero es iniciar sesión como administrador, las credenciales que incluye la aplicación son usuario: “admin”, contraseña: “admin”. Al iniciar sesión podrá ver en la página de inicio una pestaña adicional llamada administración que al pulsar desplegará las distintas opciones de gestión del club. Todas las páginas de gestión tienen un botón para retroceder en la parte superior. Gestión de usuarios Cuenta con dos opciones validar y editar. La página de validación muestra los usuarios pendientes de validación para que sean aceptados o rechazados mediante los botones a la derecha de cada usuario. La página de edición permite acceder a la modificación de los datos de los usuarios incluyendo los menores y eliminar usuarios mediante los botones a la derecha de cada usuario. Esta página cuenta con un buscador por nombre de usuario para agilizar la búsqueda. Al pulsar en editar se mostrarán todos los datos editables del usuario y si se pulsa el botón de guardar quedarán almacenados. Al pulsar en eliminar saldrá una ventana de confirmación, si se pulsa el botón confirmar la eliminación se llevará a cabo. Gestión de noticias Cuenta con dos opciones crear y editar. La página de crear noticias permite su creación rellenando el formulario con un título, el cuerpo de la noticia y una imagen que no exceda 1MB de tamaño. La página de edición permite acceder a la modificación de los campos y las imágenes de las noticias, a los comentarios y eliminar noticias mediante los botones situados a la derecha de cada noticia. La edición de noticias funciona igual que la de usuarios, pero con sus respectivos campos. A través del botón de comentarios accederemos al listado de comentarios de la noticia y podremos eliminarlos mediante un botón situado a la derecha, si lo pulsamos nos pedirá confirmación. La eliminación de noticias funciona igual que las demás como se describe en la gestión de usuarios. Plataforma de gestión de un club de balonmano 100 Gestión de equipos Cuenta con cuatro opciones la creación y eliminación tanto de equipos como categorías. Estas acciones funcionan como las anteriormente descritas, teniendo en cuenta que para la eliminación de un equipo este no puede tener jugadores asignados y para la eliminación de una categoría esta no puede contener equipos. Gestión de cuotas Cuenta con tres opciones crear, editar y registrar pago. La creación de cuotas funciona seleccionando un importe que debe ser igual o superior a 5,00 y eligiendo el equipo al que se quiere cargar la cuota seleccionándolo a través de los desplegables de categoría y equipo. Estás cuotas se aplican solo a los jugadores del equipo y guardan la fecha de emisión y pago, aunque esta última al crearla no existirá hasta que se registre el pago. La edición funciona de forma similar a las anteriormente descritas con sus botones de editar y eliminar sobre un listado de cuotas ya individualizadas sobre las personas, además cuenta con un buscador por DNI a través del cual podrías buscar las cuotas de una persona concreta. La edición da la posibilidad de cambiar el estado de pago de una cuota, si se establece que no ha sido pagada se borrará la fecha de pago y si se establece como pagada se guardará la fecha actual. La opción de registrar pago nos permite establecer como pagadas las cuotas de una forma mucho más ágil, apareciendo un listado de las cuotas pendientes de pago, contando con un buscador por DNI y un botón situado a la derecha de cada cuota que al pulsar registrará el pago y guardará la fecha actual. Gestión de equipamientos Cuenta con cuatro opciones crear, editar, registrar pago y registrar entrega. La creación muestra los tipos de elementos que se pueden adquirir permitiendo seleccionar las tallas y unidades para cada uno y mostrando el precio unitario de cada elemento. Para que un equipamiento pueda ser encargado debe tener al menos una unidad de algún elemento. La función de editar funciona de la misma forma que la de las cuotas con el añadido de que aquí se almacena también si ha sido entregado o no y en qué fecha, de forma que además de poder establecer estado de pago puedes cambiar el estado de entrega. Los registros de pago y entrega funcionan exactamente igual que el registro de pago en las cuotas. Sirven para agilizar estos registros mostrando únicamente los equipamientos pendientes y anotarán la fecha actual en el pago o la entrega. Plataforma de gestión de un club de balonmano 101 Anexo III – Manual de usuario Cualquier persona que acceda al sitio web realizar las siguientes tareas: • Iniciar sesión: a través del enlace de inicio de sesión en la esquina superior derecha del sitio web y suministrando sus credenciales (usuario y contraseña). • Registrarse: a través del enlace de registro en la esquina superior derecha del sitio web cumplimentando el formulario pudiendo elegir el tipo de registro dependiendo en si el miembro del equipo es mayor o menor de edad. • Acceder a noticias, próximos partidos, clasificación y patrocinadores a través de sus respectivos enlaces en la cabecera de la página web. • Ver una noticia: clicando en cualquier noticia de las páginas de inicio o de noticias. • Comentar una noticia: estando en una noticia, en la parte inferior de la página después de los comentarios hay un formulario que cumplimentar para dejar tu comentario.