Aplicación para la gestión de ligas y torneos de pádel

Proyecto de Fin de Carrera. Escuela de Ingeniería Informática. ULPGC Aplicación para la gestión de ligas y torneos de pádel 2 Aday López Ramírez Las Palmas de Gran Canaria, Julio 2017 Proyecto de fin de carrera de la Escuela de Ingeniería Informática de la Universidad de Las Palmas de Gran Canaria, presentado por el alumno: Aday López Ramírez Título del Proyecto: Aplicación para la gestión de ligas y torneos de pádel Tutor: D. Alexis Quesada Arencibia 3 Índice Introducción ..................................................................................................................... 7 Estructura del documento ................................................................................................ 8 Objetivos ........................................................................................................................... 9 Estado del arte ................................................................................................................ 11 Conclusiones ............................................................................................................... 15 Metodología ................................................................................................................... 16 Modelo de proceso software ...................................................................................... 16 Modelado UML ........................................................................................................... 17 Recursos .......................................................................................................................... 18 Hardware .................................................................................................................... 18 Software ...................................................................................................................... 18 Tecnologías utilizadas ................................................................................................. 21 Análisis ............................................................................................................................ 25 Modelo de casos de uso ............................................................................................. 25 Identificación de actores ......................................................................................... 26 Relaciones Actores – Acciones ................................................................................ 27 Diagrama de casos de uso ....................................................................................... 34 Diseño ............................................................................................................................. 37 Modelo – Vista – Controlador ..................................................................................... 37 Diseño arquitectónico del sistema ............................................................................. 38 Diseño de la base de datos ......................................................................................... 39 Diseño de la interfaz de usuario ................................................................................. 41 4 Página principal ....................................................................................................... 42 Perfil de usuario ...................................................................................................... 44 Página de competición ............................................................................................ 45 Vista de planificador de jornadas ............................................................................ 48 Implementación .............................................................................................................. 50 Uso y estructura base del Framework Symfony2 ....................................................... 50 Paquetes añadidos ...................................................................................................... 57 Desarrollo de la interfaz de selección de horarios y almacenamiento de los rangos horarios ....................................................................................................................... 58 Algoritmo de planificación de jornadas ...................................................................... 60 Interfaz gráfica del planificador de jornadas .............................................................. 62 Pruebas ........................................................................................................................... 64 Pruebas de caja blanca ............................................................................................... 64 Pruebas de caja negra ................................................................................................. 64 Pruebas de rendimiento ............................................................................................. 65 Resultados y conclusiones .............................................................................................. 66 Futuras líneas de actuación ............................................................................................ 68 Mejora del algoritmo de autogeneración de horarios ............................................... 68 Ampliar a otros deportes o tipos de competición ...................................................... 68 Añadir un sistema de puntuación a las competiciones/organizadores ...................... 68 Desarrollar una aplicación móvil más ligera ............................................................... 68 Dar la posibilidad de exportar el horario, una vez planificado, en versión PDF ......... 69 Agradecimientos ............................................................................................................. 70 Bibliografía ...................................................................................................................... 71 Anexo I – Manual de usuario .......................................................................................... 74 Buscar competiciones ................................................................................................. 74 5 Acceder a la información detallada de una competición ........................................... 74 Buscar usuarios en la aplicación ................................................................................. 75 Registrarse en el sistema ............................................................................................ 76 Ingresar en la aplicación ............................................................................................. 77 Acceder al perfil de usuario ........................................................................................ 78 Modificar perfil de usuario ......................................................................................... 79 Sistema de mensajería ................................................................................................ 79 Sistema de notificaciones ........................................................................................... 81 Inscribirse en competiciones ya creadas .................................................................... 82 Crear competición nueva ............................................................................................ 83 Editar competición ...................................................................................................... 84 Añadir nuevo recurso a la competición .................................................................. 84 Cambiar el estado de la competición ...................................................................... 85 Modificar información general de la competición .................................................. 85 Generación de jornadas .............................................................................................. 86 Generar cruces de las distintas jornadas .................................................................... 87 Organización de partidos de la jornada ...................................................................... 87 Modificar resultado de partidos ................................................................................. 89 Anexo II – Manual de instalación ................................................................................... 92 Instalación de XAMPP ................................................................................................. 92 Descarga del proyecto y configuración....................................................................... 92 Anexo III – Casos de uso detallados ............................................................................... 96 Casos de uso de forma detallada ............................................................................ 96 Casos de uso: Usuario no registrado ....................................................................... 98 Casos de uso: Usuario registrado .......................................................................... 105 Casos de uso: Administrador del sistema ............................................................. 116 6 Casos de uso: Administrador de la competición ................................................... 123 Casos de uso: Participante en la competición ...................................................... 142 7 Introducción Desde hace algún tiempo, el pádel tenis se ha convertido en un deporte de moda en el ámbito territorial. Cada vez son más los aficionados que se dedican a practicar este deporte y cada vez son más las instalaciones que se habitúan a ello. Del mismo modo, bajo una mayor demanda, ha ido en aumento el número de competiciones, tanto profesionales como de aficionados, que se disputan durante todo el año. Así también, el avance tecnológico se encuentra integrado en todos los aspectos cotidianos del día a día, innovando en aspectos como la organización de competiciones y ayudando en varias facetas de esta tarea, tal como la creación de las jornadas y la organización de los usuarios. Aun así, uno de los aspectos más costosos a la hora de organizar estas competiciones es conseguir que los horarios de los partidos se adecuen a la disponibilidad de los participantes en la competición. A partir de esta necesidad surge la idea de crear una herramienta que sirva para organizar competiciones de pádel, pero que a su vez aligere la carga de trabajo que supone para el organizador el conseguir unos horarios que se ajusten a las necesidades de los participantes y a la disponibilidad de horario de las canchas en las que se jugarán los partidos. 8 Estructura del documento Para facilitar la lectura de este documento se procederá a detallar como se ha estructurado el mismo y aquellos aspectos destacables de mención. A continuación se procederá a comentar los objetivos que se tienen a la hora de desarrollar la aplicación y que necesidades pretende suplir. Antes de iniciar el diseño de la misma, se hará un estudio de las herramientas que se encuentran actualmente en el mercado, comentando así, dentro de la etapa de análisis, el estado de este campo en la actualidad. A continuación se detallarán las fases de análisis, diseño e implementación de la aplicación, para finalizar con la conclusión del desarrollo así como las futuras líneas de actuación que quedan abiertas para futuros trabajos sobre la herramienta. El apartado de implementación comenta los aspectos más destacables de la implementación, haciendo hincapié en aquellos más relevantes para entender como se ha estructurado la aplicación y aquellos a los que mayor dedicación se le ha prestado durante esta etapa. Aun así, el resto del código no mostrado en este apartado se encontrará en el repositorio web “https://github.com/AdayLopez/AplicacionPadel”. El documento cuenta también con una serie de anexos, separados para facilitar la lectura del mismo, quedando así separados de la estructura principal, el análisis detallado de los casos de uso así como un manual de usuario que pretende facilitar el uso de la aplicación. 9 Objetivos El objetivo principal de este proyecto es el desarrollo de una aplicación web para la organización de competiciones de pádel. Se propone crear una herramienta multiplataforma, a través de la cual cualquier usuario con conexión a internet pueda disfrutar de las facilidades que la aplicación ofrece. A través de esta herramienta multiplataforma se pretende permitir la creación de competiciones de pádel, así como ser una plataforma que sirva de difusión para las competiciones y una herramienta de comunicación entre sus distintos usuarios. A través de los módulos a desarrollar, se pretende, por un lado, ofrecer las herramientas básicas que ofrecen la mayoría de las redes sociales hoy en día, tales como comunicación o consultar la información de los diversos usuarios. Aparte, se pretende que sea una herramienta que ayude en la creación de nuevas competiciones, facilitando todas las tareas que el creador debe afrontar normalmente, así como también facilitar la tarea de aquellas personas que solamente quieran ser participantes de las distintas competiciones. A continuación se procede a exponer con más detalle los objetivos del desarrollo de esta aplicación:  Desarrollo de una red social: La aplicación cuenta con un factor de red social, a través de la cual se pretende unificar a usuarios que pretendan organizar o participar en torneos de pádel. Debido a ello se debe otorgar a la aplicación las capacidades básicas de comunicación necesarias para la correcta organización de las competiciones, permitiendo mandarse mensajes entre ellos así como ver notificaciones de sucesos importantes en las competiciones en las que el usuario se encuentre inscrito. 16 Metodología Modelo de proceso software El modelo en espiral [1] (Wikipedia), propuesto originalmente por Barry Boehm, es un modelo evolutivo que conjuga la naturaleza iterativa del prototipado con los aspectos sistemáticos y controlados del modelo en cascada. Provee del potencial para un desarrollo rápido incremental creando en cada iteración versiones más completas del software. Usando el modelo en espiral, el software se desarrolla en una serie de etapas evolutivas. Durante las primeras iteraciones, el resultado puede ser simplemente un modelo o un prototipo. A medida que se realizan más iteraciones se va creando una versión más completa del sistema. Este modelo está dividido en una serie de tareas definidas por el equipo de desarrollo. Cada una de las actividades está representada por un segmento de la espiral, tal y como se ilustra en la figura mostrada a continuación: Ilustración 5-Modelo de desarrollo en espiral 17 A lo largo del desarrollo, por lo tanto, se irán realizando las actividades girando alrededor de la espiral en sentido horario, comenzando en el centro de la misma. Cada paso por la región de planificación da como resultado ajustes en el plan del proyecto. El coste y la programación se ajustan en la fase de despliegue, basándose en la retroalimentación proporcionada por el cliente. Además, el número de iteraciones necesarias para terminar el proyecto se ajustan evolutivamente a medida que avanza el mismo. Ya que se parte de un proyecto que empieza de cero, se cree que esta metodología es la adecuada para ir desarrollando de manera incremental la aplicación, comenzando por desarrollar unas capacidades básicas de la misma para que, a medida que se hacen iteraciones en el proceso, ir construyendo una aplicación cada vez más robusta y completa, teniendo en cuenta siempre la retroalimentación con el cliente a medida que se va avanzando en el desarrollo. Modelado UML Desarrollado por Grady Booch, Ivar Jacobson y James Rumbaugh en los 90, UML [3] se ha convertido en la notación visual estándar por defecto para el modelado de sistemas software. A través de él se podrá definir, construir y visualizar el sistema, incluyendo tanto aspectos conceptuales como aspectos concretos. Cabe destacar que UML no es un proceso o un método, sino un “lenguaje” utilizado para detallar los artefactos del sistema y a su vez documentar y construir. Podemos definirlo así como el lenguaje en el que describiremos el modelo del sistema. UML cuenta con varios tipos de modelos, mostrando diferentes aspectos de las entidades representadas. Para la fase de análisis seguiremos el modelo UML de casos El lenguaje unificado de modelado “UML” es un “lenguaje estándar para escribir planos del software. UML puede ser usado para visualizar, especificar, construir y documentar los elementos de un sistema intensivo en software” [2]. 18 de uso, a través del cual se identificarán los actores y se especificarán lo más posibles todos los casos de uso del sistema. Recursos Hardware Para el adecuado desarrollo de este proyecto ha sido necesario el uso de un PC con conexión a Internet y la capacidad suficiente para soportar la ejecución de las diversas herramientas que se han usado para su correcta elaboración. A continuación se procede a detallar las características del PC usado: - Sistema operativo: Windows 10 Home - Intel Core i5 CPU@ 2.27GHz - 4,00 GB RAM - Monitor de 17’’ Software Entorno de desarrollo: NetBeans [4] Durante la mayor parte del desarrollo de la aplicación ha sido necesario el uso de un entorno de desarrollo que facilite en gran medida la gestión y construcción del proyecto. Debido a la experiencia previa y la gran cantidad de complementos, entre ellos los destinados al framework de PHP Symfony2, se ha optado por utilizar NetBeans 8.1 Editor de texto: Sublime [5] Considerando el entorno de desarrollo para las partes de mayor complejidad de código, habrá otras partes que requieran de una edición más rápida y sencilla que puede ser llevada a cabo a través de editores de texto más ligeros. De entre los existentes se ha optado por usar Sublime Text, mucho más ligero que el entorno de 19 desarrollo NetBeans pero que sigue ofreciendo ciertas características como el marcado de palabras clave y gran cantidad de atajos a la hora de la edición. Procesador de texto de alto nivel: Microsoft Word Professional Plus 2013 A lo largo de todo desarrollo de software ha sido necesario documentar las diferentes fases del proyecto, así como desarrollar manuales de ayuda y de uso de cara al usuario final. Para ello es necesario utilizar herramientas de edición de textos, en concreto se ha hecho uso de Microsoft Office Word 2013 para llevar a cabo toda la documentación, guías y manuales necesarios. Adobe Reader Lector de PDF desarrollado por Adobe Systems, necesario para el acceso a toda la documentación que se ha necesitado consultar durante el desarrollo de la aplicación. Herramienta de modelado UML: StarUML La mayoría de los diagramas elaborados en las etapas de análisis y diseño del proyecto han sido elaborados en el lenguaje UML. Ha sido necesaria, por lo tanto, una herramienta de edición que permita trabajar de forma sencilla y rápida con este lenguaje. En concreto, se ha utilizado el software denominado StarUML. Se trata de una herramienta de software libre de edición UML, bajo licencia modificada de GNU GPL. StarUML es compatible con la mayoría de los tipos especificados en el diagrama de UML 2.0 y fue desarrollada en Delphi. 20 Editor de imágenes: GIMP [6] Uno de los aspectos a tener en cuenta a la hora de desarrollar el proyecto, será la parte del diseño de su interfaz, que deberá ser sencilla, intuitiva y clara. Por lo tanto, se ha contado con herramientas software de edición de imágenes y diseño gráfico avanzados con el fin de crear interfaces lo más adecuadas posibles. Debido a las características que ofrece y por ser software libre y gratuito, se ha optado por la herramienta GIMP en su versión 2.8.16. Servidor XAMPP [7] Servidor independiente de plataforma y software libre que provee de diversas herramientas, de entre las cuales se han usado las siguientes:  Apache: Servidor Web de código abierto.  MySQL: Sistema de gestión de bases de datos.  PHP: Lenguaje de programación de uso general de código del lado del servidor originalmente diseñado para desarrollo web de contenido dinámico.  PHPMyAdmin: Interfaz web que permite la administración de la base de datos.  Servidor de SMTP: Servidor de correo SMTP (Simple Mail Transfer Protocol) que permite el envío de correos mediante la aplicación. Diseño de bases de datos: MySQL Workbench [8] Para el diseño de la base de datos se ha querido utilizar una herramienta que facilite la creación de la representación de nuestra base de datos usando el modelo EntidadRelación. MySQL Workbench es una herramienta visual de diseño de bases de datos que integra la administración, el diseño, la creación y el mantenimiento para sistemas de bases de datos MySQL. Git [9] Software de control de versiones distribuido, diseñado para optimizar la eficiencia y la confiabilidad del mantenimiento de versiones cuando éstas tienen un gran número de archivos de código fuente. 21 Aunque el control de los archivos se puede hacer de forma manual manteniendo copias de seguridad durante el desarrollo, cuando el proyecto cuenta con un gran número de archivos los VCS o Sistemas de Control de Versiones facilitan la tarea, administrando las distintas versiones del código fuente mientras este se va desarrollando. De esta forma se mantiene un mejor control de todas las versiones del proyecto y la posibilidad de volver a un punto anterior del desarrollo en caso de necesidad de revertir cambios. BitBucket [10] Se trata de un servicio de almacenamiento web para los proyectos que utilizan el sistema de control de versiones Mercurial y Git. Pudiendo crear una cuenta totalmente gratuita, permite almacenar en la nube el repositorio GIT sobre el que se está trabajando, permitiendo así tener una copia de seguridad online del proyecto. SourceTree [11] Se trata de un cliente GUI (Graphical User Interface) para GIT que permite el manejo de repositorios GIT. Gracias al uso de esta herramienta, que permite la integración con BitBucket, facilita en gran medida el uso de GIT, no necesitando así usar la línea de comandos para administrar el repositorio. Tecnologías utilizadas HTML [12] HyperText Markup Language, se trata de un lenguaje de marcado usado para la elaboración de páginas web. Define una estructura básica y un código (denominado código HTML) para la definición de contenido de una página web, como texto, imágenes, entre otros. Se ha utilizado para crear la estructura general de la página web desarrollada a lo largo de este proyecto. CSS [13] 22 Cascading Style Sheet es el lenguaje utilizado para describir la apariencia y el formato de un documento estructurado, en nuestro caso, escrito en HTML. CSS busca separar la estructura del documento de su presentación, por lo tanto, la información de estilo será definida en un documento separado, enlazando éste al documento HTML para aplicar así el estilo deseado a nuestro proyecto. Bootstrap [14] Desarrollado por Mark Otto y Jacbod Thornton de Twitter, se trata de un framework o conjunto de herramientas para el diseño de páginas web, conteniendo así plantillas de diseño con tipografía, formularios, botones, cuadros, menús de navegación y otros elementos de diseño basado en HTML y CSS, así como otros elementos JavaScript opcionales. A través del uso de este framework, conjuntamente con la plantilla Canvas detallada a continuación, permite acelerar el desarrollo del proyecto gracias a las facilidades que ofrece. Canvas – Responsive HTML Template [15] Para poder facilitar en gran medida el diseño visual Web y ofrecer un acabado profesional, se ha optado por adquirir la plantilla Canvas, plantilla basada en Bootstrap con soporte para HTML y CSS3. A través de esta plantilla se puede desarrollar una interfaz sencilla y amigable, a la vez que permite un diseño web responsivo, por lo que facilita que la página se muestre correctamente en cualquier navegador de cualquier dispositivo. Twig [16] Se trata de un motor de plantillas para el lenguaje PHP, de código abierto y con soporte incluido en el framework Symfony2. Gracias al uso de TWIG se consigue un desarrollo más eficaz y un código más ordenado en las vistas gracias a su sencilla sintáxis. 23 PHP [17] PHP es un lenguaje de programación interpretado, diseñado para la creación de páginas web dinámicas y usado principalmente para la interpretación del lado del servidor. El servidor será el encargado de ejecutar el intérprete PHP para procesar el script solicitado por el cliente, generando el contenido de manera dinámica. El resultado será enviado por el intérprete al servidor, que a su vez lo enviará al cliente. Framework PHP: Symfony2 [18] Framework desarrollado completamente en PHP 5.3, destinado a facilitar el desarrollo de aplicaciones web siguiendo el patrón Modelo-Vista-Controlador. Para empezar, separa la lógica de negocio, la lógica de servidor y la presentación de la aplicación web. Proporciona varias herramientas y clases encaminadas a reducir el tiempo de desarrollo de una aplicación web compleja. Además, automatiza las tareas más comunes, permitiendo al desarrollador dedicarse por completo a los aspectos específicos de cada aplicación. Composer [19] Se trata de un gestor de dependencias encargado de solucionar los conflictos por librerías, instalando las dependencias necesarias. También se puede encargar de desinstalar las librerías que ya no se necesiten o actualizarlas cuando sea necesario. SQL/MySQL [20] SQL o Structured Query Language es un lenguaje declarativo de acceso a base de datos relacionales que permite especificar diversos tipos de operaciones en ellas. MySQL será el sistema de gestión de bases de datos relacional que usaremos durante el desarrollo permitiéndonos acceder al sistema de datos y manipularlos. 24 Doctrine [21] Conjunto de librerías en PHP que comprenden un ORM [22] (Mapeador ObjetoRelacional) y un DBAL (Capa de abstracción de la base de datos). Gracias a esta técnica de programación que convierte datos entre el sistema de tipos utilizado en el lenguaje de programación orientado a objetos y la utilización de una base de datos relacional como motor de persistencia. Se consigue de esta forma facilitar el uso de la base de datos y abstraerse de la conversión de los tipos abstractos usados en la programación de alto nivel a los tipos sencillos que se usan para almacenar la información en la base de datos. JavaScript [23] Javascript es un lenguaje de programación interpretado. Se define como orientado a objetos, basado en prototipos, imperativo, débilmente tipado y dinámico. Su principal uso está relacionado con la interacción entre una página HTML, el navegador y el usuario. JQuery [24] Biblioteca multiplataforma de JavaScript que permite simplificar la manera de interactuar con los documentos HTML, manipular el árbol DOM, manejar eventos, desarrollar animaciones y agregar interacción con la técnica AJAX a páginas web. Se trata de software libre y de código abierto que simplifica en gran medida el código a través del uso de las funciones propias de la biblioteca, logrando así grandes resultados en menos tiempo y espacio. 25 Análisis En la etapa de análisis, el objetivo es extraer toda la información necesaria para la correcta realización de las posteriores etapas del desarrollo software, identificando y definiendo formalmente los requerimientos de la aplicación, es decir, que problema del usuario final del software debemos resolver. La comunicación entre los distintos usuarios y el desarrollador es de vital importancia durante el análisis del software, ya que esta comunicación y las habilidades adecuadas del desarrollador son las que permitirán identificar y analizar correctamente los requerimientos de la aplicación. Éste se trata de un proceso iterativo, que partiendo de una descripción general dada por el cliente construye el análisis, desarrollando así una especificación de la aplicación semiformal. Una vez realizada esta especificación surgirán algunos problemas, como lagunas o información no concisa que deberá volver a ser contrastada con el cliente, repitiendo este ciclo y añadiendo detalles hasta generar un análisis lo suficientemente preciso para abordar el diseño del software. Para poder realizar este análisis, el primer paso será identificar correctamente a los actores que intervendrán en el sistema para así poder, una vez identificados, recabar toda la información necesaria para realizar la identificación y desarrollo de los casos de uso [25]. Modelo de casos de uso A continuación se procederá a detallar los casos de uso del sistema. Primeramente se identificarán los actores del sistema, para, posteriormente, enumerar cada uno de los casos de uso asociados a ellos. Finalmente se mostrarán los diagramas de caso de uso en los que se detallarán de forma visual cada caso de uso asociado a su actor. En el Anexo II se puede consultar cada caso de uso comentado de forma detallada. 32 encuentro de un encuentro Modificar fecha de encuentro Modificar la fecha en la que se disputa un encuentro Modificar lugar de encuentro Modificar el lugar en el que se disputa un encuentro Actualizar resultados Una vez se ha disputado un encuentro, el administrador deberá actualizar la información del resultado en la herramienta Publicar en la sección de noticias Aquellas noticias o eventos interesantes para todos los integrantes de la competición podrán ser publicadas a modo de noticia en la página principal del torneo por parte del administrador Editar noticia Editar una noticia ya publicada en el tablón de anuncios Cerrar competición Cerrar la competición, manteniendo la información visible en la aplicación pero no pudiendo ser posteriormente modificable. Borrar competición Eliminar toda la información de la competición Participante en la competición Modificar disponibilidad horaria Cada participante de la competición podrá especificar restricciones horarias para que se tengan en cuenta a la hora de generar el horario de encuentros Solicitar cambio en partido Los participantes podrán solicitar un cambio de horario en algún partido, mandando una notificación a los contrincantes para que 33 validen el cambio Validar cambio en partido Si la pareja contrincante ha solicitado un cambio en algún partido, le llegará una notificación y podrá validar dicho cambio si así lo cree oportuno. Rechazar cambio en partido Si el cambio en el partido solicitado por el contrincante no le interesa, podrá rechazarlo y se mantendrá como estaba anteriormente Solicitar asignación de resultado Los participantes en el partido podrán asignar un resultado, debiendo validarse por la pareja contrincante para así asegurarse de que el resultado es el correcto Validar asignación de resultado Si una pareja ha intentado actualizar un resultado, la pareja debe confirmar que este resultado es correcto para que se modifique definitivamente Rechazar asignación de resultado Si el resultado introducido por la pareja contrincante no es correcto, podrá rechazarlo, indicando otro resultado para que sea validado o esperar a la intervención de un administrador Abandonar competición Abandonar la competición en la que se encuentra inscrito Tabla 3-Descripción de las relaciones Actores-Acciones 34 Diagrama de casos de uso Una vez identificados los actores del sistema procederemos a elaborar el diagrama de casos de uso, en el que presentaremos cada uno de los casos de uso a desarrollar. Usuario no registrado Ilustración 7 – Casos de uso - Usuario no registrado Usuario registrado Ilustración 8Casos de uso - Usuario Registrado 35 Administrador del sistema Ilustración 9 - Casos de uso - Administrador del sistema Administrador de la competición Ilustración 10Casos de uso - Administrador de la competición 1 36 Ilustración 11 - Casos de uso - Administrador de la competición 2 Participante en la competición Ilustración 12 - Casos de uso - Participante en la competición 37 Diseño Modelo – Vista – Controlador Se trata de un modelo arquitectónico que divide una determinada aplicación software en tres partes interconectadas, dividiendo así la representación interna de la información de la forma en que ésta se muestra al usuario, por lo que se consigue un mantenimiento más sencillo de las aplicaciones. El componente central del MVC, el modelo, se encarga de manejar la información, lógica y reglas de la aplicación, independientemente de la interfaz de usuario. La vista es la representación de la información, es decir, transforma el modelo en una interfaz que permite al usuario interactuar con la información, y es el controlador el encargado de procesar las interacciones de usuario y realizar los cambios apropiados en el modelo o en la vista. [26] Si comparamos los elementos de este patrón con los componentes de una aplicación web, la relación sería:  Vista – Página HTML  Controlador – Código que obtiene datos dinámicamente y genera contenido HTML.  Modelo – Información almacenada en una base de datos o XML. Controlador Vista Modelo MySQL Navegador Ilustración 14 - Modelo-Vista-Controlador Ilustración 13 - Modelo-Vista-Controlador 38 Diseño arquitectónico del sistema La Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema y consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco. Esta arquitectura esta seleccionada y diseñada con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también entran objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. La arquitectura del software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos (nodos y comunicaciones). La arquitectura se ha de elegir en función de las ventajas e inconvenientes que ofrecen para cada caso concreto. Debido a esto y a las características del sistema que se está desarrollando el estilo arquitectónico que se ha escogido es la Arquitectura Cliente – Servidor. Ilustración 15 - Arquitectura del software - Cliente-Servidor 39 Diseño de la base de datos A continuación se mostrará que estructura seguirá la base de datos en la que se almacenará toda la información del sistema, así como la forma en que se interconectarán todos estos datos. Así, para visualizar correctamente el sistema de información, se ha optado por usar el modelo Entidad-Relación, modelo muy extendido y adecuado para esta clase de proyectos. Para una correcta lectura del diagrama, no se han especificado todas las propiedades de todas las entidades, dado que se detallarán posteriormente. A continuación se muestra el código de colores que se ha seguido a la hora de elaborar el diagrama: Clase Forma Entidad Relación Propiedad Tabla 4-Leyenda del diagrama Entidad-Relación 40 Ilustración 16-Diagrama Entidad-Relación de la base de datos del sistema La aplicación cuenta con un sistema de mensajería entre usuarios, un sistema de notificación de eventos así como la lógica para la organización de las competiciones. Cualquier usuario puede enviar o recibir muchos mensajes, y el mismo mensaje puede tener varios destinatarios. Las notificaciones, creadas por el sistema en ciertos puntos del flujo de la aplicación, pueden tener varios usuarios destino, y un usuario puede haber recibido varias notificaciones. Cualquier usuario del sistema puede crear una competición, convirtiéndose en “usuario creador” y administrador de la misma, así como inscribirse a cualquier Destinatario Cuerpo Nombre Información Tipo Cuerpo Información Fecha Resultado Pareja Preferencia horaria Disponibilidad horaria Nombre Lugar 41 competición, pasando a ser “usuario participante de la misma”. Una competición solamente podrá tener un usuario creador, pero un usuario puede crear varias competiciones a la vez. Cualquier usuario, al inscribirse a una competición, creará una entidad “Inscripción” donde se almacenará el nombre de su pareja de juego, así como las preferencias horarias de esta. Un usuario puede realizar muchas inscripciones en distintas competiciones pero cada inscripción solamente estará relacionada con su usuario. Asimismo, el usuario creador podrá añadir recursos a su competición, dichos recursos serán las distintas canchas donde podrán celebrarse los partidos, así como el horario de disponibilidad del recurso. Por lo tanto, una competición podrá tener varios recursos pero cada recurso solo pertenecerá a una competición. Una competición se conforma de todas las inscripciones de los distintos usuarios, y cada una de estas inscripciones que almacenan la información detallada solo pertenecerá a su propia competición. Así pues, una vez poblada la competición con todos los participantes, se podrán generar los partidos, estos partidos son los emparejamientos de las distintas inscripciones, donde se almacenará la fecha, hora y recurso donde se celebrará, teniendo cada partido un recurso asignado, pero cada recurso varios partidos asignados en distintos horarios. Cada competición tendrá varios partidos, dependiendo del número de usuarios inscritos, pero cada partido pertenecerá solamente a una competición. Diseño de la interfaz de usuario La interfaz de usuario es el medio a través del cual el usuario puede comunicarse y acceder a todas las facilidades que ofrece la aplicación. Comprende todos los puntos de contacto entre el usuario y la aplicación en sí. Para crear una interfaz de calidad se han tenido en cuenta los puntos que se muestran a continuación:  Atractiva, siendo así llamativa para el usuario a la hora de ser usada.  Intuitiva, ofreciendo así una facilidad de manejo que permita al usuario sentirse cómodo y haciendo así que la curva de aprendizaje de uso de la aplicación no sea abrumadora. 48 A continuación se muestra la interfaz final: Ilustración 26 - Interfaz de reglamento y ajustes de la competición Vista de planificador de jornadas Ilustración 27-Prototipo de la interfaz del planificador de jornadas Una de las vistas fundamentales del proyecto y a una de las que más trabajo se le ha dedicado es la vista del planificador de jornadas. Uno de los puntos críticos a la hora de organizar un torneo es la organización de los partidos teniendo en cuenta la disponibilidad horaria tanto de los recursos como de las parejas, por lo tanto una de las mayores prioridades era realizar una interfaz útil para acelerar este proceso. Menú de la aplicación Fecha Menú de la aplicación Vista detallada de la semana Vista detallada del día seleccionado Listado de recursos Listado de partidos 49 En el prototipo de interfaz se puede observar que en la parte superior se muestra la fecha actual, indicando la semana sobre la que se está trabajando. En la parte izquierda de la interfaz se mostrará una vista detallada de la semana, dividida por horas e indicando la disponibilidad de los recursos en dicho horario. En dicha sección se podrá seleccionar específicamente un día, obteniendo así, a la derecha, una vista detallada del día seleccionado en la que se mostraran todos los recursos de dicho día y su disponibilidad. Finalmente, en la parte derecha de la interfaz, se mostrará un listado de los recursos de la competición así como un listado de los partidos de la jornada, que son los que se deberán colocar para poder finalmente guardar la organización de la jornada. Finalmente, la interfaz ha quedado como se muestra a continuación: Ilustración 28 - Interfaz del planificador de horarios 50 Implementación El resultado de la fase de implementación es el código resultante que se encontrar en el repositorio web “https://github.com/AdayLopez/AplicacionPadel”. Sin embargo, en este apartado se procederá a comentar aquellas secciones destacables debido a su importancia o a la forma que ha sido adoptada para resolver el problema que tratan. Por una parte se hablará brevemente del framework Symfony2 y aquellos paquetes utilizados para facilitar la tarea de la implementación, para posteriormente pasar a detallar aquellas partes del código de desarrollo propio y que suponen un gran peso en la aplicación. Uso y estructura base del Framework Symfony2 Symfony2 es un framework PHP que nos permite muy fácilmente utilizar la arquitectura MVC (Model-View-Controller) comentada anteriormente. Diseñado para optimizar el desarrollo de aplicaciones Web, proporciona herramientas que agilizan aplicaciones complejas y guían al desarrollador en el orden y buenas prácticas dentro del proyecto. Para comenzar el desarrollo de la aplicación utilizando Symfony2 bastaría con instalar “Symfony Installer” desde la página web del distribuidor a través de la siguiente orden: # Linux y macOS $ sudo mkdir -p /usr/local/bin $ sudo curl -LsS https://symfony.com/installer -o /usr/local/bin/symfony $ sudo chmod a+x /usr/local/bin/symphony # Windows C:\> php -r "readfile('https://symfony.com/installer');" > symfony 51 Una vez realizada la instalación, la creación de la aplicación Symfony se realizaría a través de la siguiente orden: Una vez hecho esto, habremos creado el directorio del proyecto sobre el que trabajar, que presentará la siguiente estructura, general para todos los proyectos Symfony: Ilustración 29 - Estructura del proyecto en Symfony2 /app En esta carpeta se encontrará por un lado, anidado bajo el directorio “app/Resources/view” la vista principal de la que heredaran el resto de vistas de la aplicación. Por otro lado bajo el directorio “app/config” los ficheros de configuración de la aplicación así como las traducciones. Por otro lado, en este directorio se encuentra el punto de entrada de la configuración de la aplicación, fichero llamado “AppKernel.php” en la que se encuentra la clase “registerBundles()”, que deberá incluir todos aquellos paquetes necesarios para ejecutar la aplicación: $ symfony new padelScheduler 52 /bin Ficheros ejecutables correspondientes al framework, como por ejemplo, la consola del mismo. /vendor En esta carpeta se encontrarán todas las dependencias de terceros de la aplicación, como son los paquetes declarados en el fichero de configuración mostrado previamente. /web El directorio raíz de la web. /src En este directorio se encontrará todo el código fuente, dividido en paquetes. En nuestro caso la aplicación se ha dividido en dos paquetes. Por un lado la lógica de administración de usuarios, y por otro lado la lógica general de la aplicación. A continuación se procederá a desarrollar de forma más detallada la estructura del paquete que contiene la lógica de la aplicación: public function registerBundles() { $bundles = array( new Symfony\Bundle\FrameworkBundle\FrameworkBundle(), new Symfony\Bundle\SecurityBundle\SecurityBundle(), new Symfony\Bundle\TwigBundle\TwigBundle(), new Symfony\Bundle\MonologBundle\MonologBundle(), new Symfony\Bundle\SwiftmailerBundle\SwiftmailerBundle(), new Symfony\Bundle\AsseticBundle\AsseticBundle(), new Doctrine\Bundle\DoctrineBundle\DoctrineBundle(), new Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle(), new PadelSchedule\MainBundle\PadelScheduleMainBundle(), new FOS\UserBundle\FOSUserBundle(), new FOS\JsRoutingBundle\FOSJsRoutingBundle(), new PadelSchedule\UserBundle\PadelScheduleUserBundle(), new Stinger\MomentJsBundle\StingerMomentJsBundle(), ); } 53 Ilustración 30 - Estructura del código /UserBundle Será el paquete encargado de toda la gestión de usuarios, tales como la identificación de usuarios. Para facilitar esta tarea se ha hecho uso de un paquete externo que facilita en gran medida toda la lógica correspondiente a este área, por lo que dentro de este paquete el único trabajo que se ha realizado ha sido la configuración y la sobrecarga de las plantillas de vista para que los formularios de registro, inicio de sesión y cambio de contraseña sigan el diseño acorde con el resto de la aplicación. /MainBundle Este será el paquete principal y sobre el que ha recaído la mayor carga de trabajo. Es el encargado de implementar toda la lógica de la aplicación y para seguir la estructura de Symfony2 la estructura que se ha seguido se muestra a continuación: /MainBundle/Controller Siguiendo el patrón de diseño de “Controlador frontal”, todas las peticiones que reciba la aplicación desarrollada en Symfony2 serán tramitadas por un controlador único, que será el desarrollado en esta carpeta y que seguirá la siguiente estructura: 54 Para cada acción se declarará una función que será la encargada de llevar la lógica necesaria para cargar la página o realizar las acciones necesarias, tales como acceder a la base de datos, cargar un formulario o finalmente cargar la vista correspondiente a la acción solicitada. A través del uso del metalenguaje designado para ello se define también la ruta designada a la acción. Este fichero “MainController.php”, por lo tanto, es el encargado de ser el punto de unión entre el modelo de datos y la vista de la aplicación. /MainBundle/Entity Dentro de Smyfony2 la gestión de la base de datos se realiza a través de un ORM (Object-Relational Mapper), llamado Doctrine, que facilita en gran medida el trabajo con la misma. De esta forma, se crearan las entidades necesarias para la aplicación y será el ORM el encargado de traducir dichas entidades en las posteriores tablas de la base de datos. Dichas entidades son objetos PHP cuyos atributos serán las distintas columnas pertenecientes a cada tabla. Trabajando sobre estos objetos y utilizando las funciones que Doctrine ofrece para ello, se podrán hacer las consultas a la base de datos así como la generación de nuevas entidades de una forma mucho más sencilla. A continuación se muestra un ejemplo de la estructura de una entidad: <?php namespace PadelSchedule\MainBundle\Controller; class MainController extends Controller { /** * @Route("/", name="home") */ public function indexAction() { } } ?> 55 En el ejemplo anterior se puede comprobar por lo tanto como se define cada propiedad de la entidad y, a través del metalenguaje que utiliza Doctrine, como se <?php namespace PadelSchedule\MainBundle\Entity; use Doctrine\ORM\Mapping as ORM; use Symfony\Component\Validator\Constraints as Assert; use Doctrine\Common\Collections\ArrayCollection; /** * Competicion * * @ORM\Table() * @ORM\Entity */ class Competicion { /** * @var integer * * @ORM\Column(name="id", type="integer") * @ORM\Id * @ORM\GeneratedValue(strategy="AUTO") */ protected $id; /** * @var string * * @ORM\Column(name="nombre", type="string", length=255) */ protected $nombre; public function __construct() { } /** * Get id * * @return integer */ public function getId() { return $this->id; } ?> 56 debe realizar el mapeo de entidad a tabla, definiendo las relaciones y el tipo que tendrá la entidad. Además se indican también los constructores, así como las funciones de acceso y modificación de cada entidad, que será la usada durante el código para facilitar el acceso a la base de datos. /MainBundle/Form Los formularios son una parte primordial en el desarrollo de aplicaciones web ya que es el modo de comunicación fundamental entre el cliente y el servidor, y Symfony2 integra un componente que facilita en gran medida esta tarea. A partir de una entidad ya creada, se puede utilizar el componente “FormBuilder” para crear el formulario asociado a dicha entidad. Este formulario se puede crear de forma automática a partir de la entidad, o indicar todos los atributos del formulario a través de una sencilla configuración como se muestra a continuación: <?php namespace PadelSchedule\MainBundle\Form\Type; class MensajeType extends AbstractType { public function buildForm(FormBuilderInterface $builder, array $options) { $builder ->add('destinatarioMensaje', 'entity', array( 'class' => 'PadelSchedule\UserBundle\Entity\User', 'choice_label' => 'username', 'expanded' => false, 'multiple' => true, 'mapped' => false, )) ->add('cabecera') ->add('cuerpo') ->add('submit', 'submit', array('label' => 'Enviar mensaje')) ; } } 57 Como se puede ver, se añade cada campo al formulario indicando a que atributo de la entidad corresponde, así como el tipo de campo a través del cual será representado en el formulario. En esta carpeta, por lo tanto, se crearán todos los objetos de tipo “Formulario” asociados a cada entidad y que luego serán usados en el controlador para que el formulario sea generado en la vista correspondiente. De esta forma, tanto la validación de errores como las acciones necesarias para el almacenamiento de la información se realizarán de una forma mucho más cómoda por parte del desarrollador. /MainBundle/Resources Finalmente, en la carpeta de recursos del paquete se incluirán tanto los recursos públicos (ficheros JavaScript, CSS, imágenes, etc), así como las vistas desarrolladas en Twig que se usarán a modo de plantilla para la visualización de las distintas partes de la aplicación. Paquetes añadidos A parte de las facilidades que ofrece Symfony2 para el desarrollo de aplicaciones web, existen muchos repositorios de paquetes a disponibilidad del desarrollador para facilitar otras tareas que no se encuentran por defecto en el framework. Para el desarrollo de nuestra aplicación se ha visto conveniente el uso de los siguientes paquetes externos: FOSUserBundle Paquete que incluye toda la lógica de usuarios del sistema, incluyendo los tipos de acceso así como los distintos formularios de registro, inicio de sesión y sistema de recuperación de contraseña. Una vez implementado este paquete con el sistema, el único trabajo a realizar ha sido la sobrecarga de las vistas para que el estilo de las mismas sea acorde con el de la aplicación. 64 Pruebas Sobre la fase de pruebas dentro del desarrollo del software recae someter a evaluación la aplicación, verificando así la calidad de la misma, posibles fallos de implementación y la usabilidad del sistema en general, consiguiendo finalmente comprobar si la aplicación cumple con todos los requisitos definidos durante la fase de análisis. Esta fase de pruebas no ha sido relegada a un momento concreto del desarrollo, sino que se ha ido aplicando a la vez que se ha ido construyendo la aplicación. De esta forma, se ha permitido detectar los posibles errores lo antes posible y así solucionarlos de una forma rápida y eficaz. Pruebas de caja blanca Estas pruebas se centran en los detalles procedimentales del software, tratando de encontrar errores concretos dentro de la implementación de cada algoritmo de la aplicación. [27] Para ello, se le aporta una serie de entradas, asegurándose que a partir de ellas se ejecutará cada flujo dentro del código pertinente, comprobando así el correcto funcionamiento de la subrutina y cerciorándose que se devuelven los valores de salida esperados. Debido a que estas pruebas se aplican a unidades del software por separado, estas pruebas se han llevado a cabo a medida que se ha ido finalizando cada subrutina dentro del proceso de implementación, pudiendo así comprobar lo antes posible el correcto funcionamiento de cada algoritmo desarrollado así como corregir los errores con la mayor rapidez y eficacia posible. Pruebas de caja negra En las pruebas de caja negras se estudia lo que se espera de cada módulo, sin tener en cuenta el funcionamiento interno del mismo. De esta forma se estudian de cada módulo las entradas que recibe y las salidas que se esperan del mismo, entendiendo 65 qué es lo que hace pero sin importarnos el cómo se hace. Para este tipo de pruebas deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz, pero no se precisa conocer los detalles internos de su funcionamiento. [28] Las pruebas de caja negra son ideales para el estudio de aplicaciones altamente modulares como los que se produce a partir del patrón Modelo-Vista-Controlador, pues gracias a este quedan muy bien definidas las entradas, salidas y dependencias entre módulos. Para aplicar estas pruebas lo que se ha hecho es hacer un uso minucioso del sistema, interpretando cada comando de la aplicación como una caja negra y comprobando que todos ellos reaccionan de la forma esperada a cada entrada que se le aporta. Pruebas de rendimiento Son aquellas pruebas que se realizan, desde una perspectiva, para determinar lo rápido que realiza una tarea un sistema bajo determinadas condiciones de trabajo. También puede servir para validar y verificar otros atributos de la calidad del sistema, tales como la estabilidad, fiabilidad y uso de los recursos. Esta práctica se esfuerza por mejorar el rendimiento de la aplicación. [29] En nuestro caso, se ejecutaron una serie de pruebas de carga, sometiendo al sistema a una gran carga de peticiones y comprobando que el resultado obtenido era el deseado. Para ello, se abrieron varios navegadores accediendo todos ellos a la aplicación y realizando distintas peticiones, comprobando así la reacción del sistema. 66 Resultados y conclusiones Tras el trabajo realizado a lo largo de todo el proyecto final de carrera, dividido en las etapas de estudio, análisis, diseño, implementación y pruebas, se obtienen por fin los resultados de todo este trabajo, que muestran el proceso de enfrentarse a un proyecto de esta envergadura y como ha llegado a su punto final. Tras los varios meses de trabajo, se ha conseguido desarrollar una aplicación web estable y multiplataforma, es decir, accesible a cualquier usuario con conexión a internet desde cualquier navegador. De esta forma, se consigue llegar a un mayor número de usuarios. Gracias al desarrollo de la aplicación como una aplicación web, se consigue obviar problemas de compatibilidad con los diversos sistemas operativos que se encuentran en el mercado, y dado al uso extendido que tenemos hoy en día de móviles y dispositivos con conexión a internet, se consigue que cualquier usuario procedente de cualquier parte del mundo pueda acceder y hacer uso de la aplicación de una forma rápida y sencilla. Otro de los objetivos que se perseguían era el de desarrollar una aplicación colaborativa, con ciertos aspectos de red social. De esta forma, se ha conseguido el desarrollo de una aplicación que permite poner en contacto a sus diversos usuarios a través del sistema de mensajería y notificaciones, y que, además, sirve a su propósito de facilitar la gestión de competiciones de pádel. Se convierte así en una aplicación que acompaña al usuario a lo largo de todo el proceso de creación de una competición, y automatiza todos los procesos susceptibles de ser automáticos, tales como la planificación de los horarios de los partidos, para la cual se ha desarrollado un algoritmo propio que disminuye en gran medida la carga de trabajo para el organizador. La aplicación también sirve como sitio web para poner en contacto a los distintos usuarios interesados en este deporte, tanto a jugadores que deseen buscar competiciones cercanas como a aquellos organizadores que busquen un sitio donde 67 poder publicar sus competiciones y conseguir jugadores para ellas, teniendo un nicho estable de competidores en las mismas. Se ha hecho especial énfasis también en la interfaz gráfica de la aplicación, centrándose en desarrollar una interfaz sencilla e intuitiva que resulte amigable para cualquier tipo de usuario, y que permita que todos los procesos que la aplicación ofrece se lleven a cabo de una manera eficaz y sin necesidad de horas de aprendizaje. Una de las interfaces más trabajadas ha sido la del planificador de jornadas, para que el administrador pueda solucionar los conflictos de horario entre los partidos de una forma eficaz. A nivel personal se ha conseguido trabajar con diversas tecnologías, consiguiendo tras un tiempo de estudio, trabajar de una manera cómoda con el framework Symfony2 sobre el que se ha creado la aplicación, y siendo capaz de utilizar todas las tecnologías que componen el framework (PHP, Doctrine, Twig) así como las tecnologías web necesarias para el correcto desarrollo de la aplicación tales como HTML, CSS, JavaScript, Jquery, etc. Una vez finalizado el proyecto, y habiendo cumplido todos los objetivos fijados en un principio, la experiencia más destacable es la de haber sabido enfrentarse a un proyecto de esta envergadura, adquiriendo una gran cantidad de conocimientos, no solo desde el punto de vista tecnológico ya mencionados anteriormente, sino las capacidades y experiencia obtenidas a lo largo de todo el proceso, tales como la planificación, búsqueda de información y demás aspectos necesarios a la hora de enfrentarse a un proyecto de Ingeniería del Software. 68 Futuras líneas de actuación Este proyecto nace como una solución inicial al problema de la carga de trabajo de organizar torneos de pádel. Una vez cumplidos los objetivos contemplados en la fase inicial, se contemplan una serie de líneas de actuación futura que se procederán a comentar a continuación: Mejora del algoritmo de autogeneración de horarios Actualmente el algoritmo de autogeneración de horarios que se encarga de facilitar la tarea de planificar las jornadas se basa en buscar aquellas parejas con mayores restricciones de horarios y ordenarlas por orden de restricción en base a sus preferencias y la disponibilidad de los recursos. Este algoritmo podría mejorarse para evitar de una manera más eficaz los conflictos que pudieran surgir. Ampliar a otros deportes o tipos de competición La aplicación, como se declaró en los objetivos principales, ahora mismo se centra en ligas de pádel, cumpliendo todas las necesidades de este tipo de competición. Una posible mejora sería ampliar a otro tipo de competiciones tales como torneos eliminatorios o incluso ampliarla a otro tipo de deportes que pudieran beneficiarse de las características que la aplicación ofrece. Añadir un sistema de puntuación a las competiciones/organizadores Otro de los puntos en los que se podría ampliar la aplicación sería en añadir un sistema de méritos o puntuaciones a los organizadores de las competiciones, así pues, los participantes, una vez finalizada la competición, podrían puntuar la organización de la competición y así darle prioridad en la aplicación a mostrar competiciones organizadas por usuarios con mayores méritos. Desarrollar una aplicación móvil más ligera Actualmente la aplicación web funciona desde cualquier navegador web, y al ser desarrollada desde un punto de vista adaptativo, se adapta también a dispositivos con distintos tamaños de pantalla como puede ser móviles o tabletas. Aun así, la aplicación 69 podría contar con una “app” concreta a instalar en dispositivos móviles, mucho más ligera que la aplicación web en sí y que se beneficie de las ventajas que ello da, como puede ser el uso de notificaciones o una interfaz más intuitiva en este tipo de dispositivos. Dar la posibilidad de exportar el horario, una vez planificado, en versión PDF Otra funcionalidad destacable a añadir sería la posibilidad de una vez definido el horario para una jornada en concreto, dar la posibilidad al usuario u organizador de la competición su exportación a formato PDF, ofreciendo así una manera de almacenar dicho horario y que pueda ser usado y consultado por los usuarios de manera local. 70 Agradecimientos En primer lugar, me gustaría agradecer enormemente el apoyo de mi familia, durante todos los años de la carrera así como durante el desarrollo de este proyecto. Sin su apoyo y ayuda incondicional no hubiera sido posible sacar adelante este proyecto. En segundo lugar, agradecer todo el tiempo dedicado por parte de mi tutor de proyecto, D. Alexis Quesada Arencibia, que gracias a su dedicación y sus conocimientos ha sabido guiarme durante todo el desarrollo, sabiendo sacar lo mejor de mí. Gracias a su ayuda, paciencia y pasión contagiosa por la profesión, que gracias a ella ha sido posible la finalización de este trabajo. También me gustaría agradecer a mis compañeros durante toda la carrera, Laia Pérez y Jorge Rodríguez, por saber hacer el camino más ameno y mantenerse ahí en los malos y en los buenos momentos, y por convertirse día a día en un ejemplo de superación y de esfuerzo con su trabajo. Finalmente agradecer a todas las personas que me han apoyado y me han animado a terminar este proyecto, a mis amigos por alegrarme, sacarme de dudas, exigirme y apoyarme en la finalización de este proyecto. 71 Bibliografía [1] Comunidad Wikipedia. [En línea]. Disponible: https://es.wikipedia.org/wiki/Desarrollo_en_espiral [2] Grady Booch, James Rumbaugh, Ivar Jacobson. (2006). El lenguaje unificado de modelado. (2ª Edición) [3] Comunidad Wikipedia. [En línea]. Disponible: https://es.wikipedia.org/wiki/Lenguaje_unificado_de_modelado [4] Comunidad NetBeans [En línea]. Disponible: https://netbeans.org/ [5] Comunidad Sublime Text [En línea]. Disponible: https://www.sublimetext.com/ [6] Comunidad GIMP [En línea]. Disponible: http://www.gimp.org.es/ [7] Comunidad Apache Friends [En línea]. Disponible: https://www.apachefriends.org/es/index.html [8] Comunidad MySQL [En línea]. Disponible: https://www.mysql.com/products/workbench/ [9] Comunidad Wikipedia [En línea]. Disponible: https://es.wikipedia.org/wiki/Git [10] Comunidad Atlassian [En línea]. Disponible: https://bitbucket.org/ [11] Comunidad SourceTree [En línea]. Disponible: https://www.sourcetreeapp.com/ [12] Comunidad Wikipedia [En línea]. Disponible: https://es.wikipedia.org/wiki/HTML [13] Comunidad Wikipedia [En línea]. Disponible: https://es.wikipedia.org/wiki/Hoja_de_estilos_en_cascada [14] Comunidad Bootstrap [En línea]. Disponible: http://getbootstrap.com/ [15] Comunidad ThemeForest [En línea]. Disponible: https://themeforest.net/item/canvas-the-multipurpose-html5-template/9228123 72 [16] Comunidad SensioLabs [En línea]. Disponible: https://twig.sensiolabs.org/ [17] Comunidad Wikipedia [En línea]. Disponible: https://es.wikipedia.org/wiki/PHP [18] Comunidad Symfony [En línea]. Disponible: http://symfony.com/ [19] Comunidad Wikipedia [En línea]. Disponible: https://en.wikipedia.org/wiki/Composer_(software) [20] Comunidad Wikipedia [En línea]. Disponible: https://es.wikipedia.org/wiki/MySQL [21] Comunidad Doctrine [En línea]. Disponible: http://www.doctrine-project.org/ [22] Comunidad Wikipedia [En línea]. Disponible: https://es.wikipedia.org/wiki/Mapeo_objeto-relacional [23] Comunidad Wikipedia [En línea]. Disponible: https://es.wikipedia.org/wiki/JavaScript [24] Comunidad Wikipedia [En línea]. Disponible: https://es.wikipedia.org/wiki/JQuery [25] Roger S. Pressman. (2010). Ingeniería del software. Un enfoque práctico (7ª Edición. [26] Comunidad Wikipedia [En línea]. Disponible: https://es.wikipedia.org/wiki/Modelo%E2%80%93vista%E2%80%93controlador [27] Comunidad Wikipedia [En línea]. Disponible: https://es.wikipedia.org/wiki/Pruebas_de_caja_blanca [28] Comunidad Wikipedia [En línea]. Disponible: https://es.wikipedia.org/wiki/Caja_negra_%28sistemas%29 [29] Comunidad Wikipedia [En línea]. Disponible: https://es.wikipedia.org/wiki/Pruebas_de_rendimiento_del_software [30] Comunidad W3Schools [En línea]. Disponible: https://www.w3schools.com/ [31] Comunidad Symfony [En línea]. Symfony cookbook 2.7. Disponible: https://symfony.com/pdf/Symfony_cookbook_2.7.pdf 73 [32] Comunidad Symfony [En línea]. Symfony book 2.7. Disponible: https://symfony.com/pdf/Symfony_book_2.7.pdf 80 mensaje entrante no leído aparecerá el número de mensajes no leídos como aviso en la interfaz: Ilustración 46 - Menú de usuario registrado en la aplicación A continuación se mostrará el buzón de entrada, que será un listado de los mensajes que el usuario ha recibido, así como un botón para mandar un nuevo mensaje a otros usuarios de la aplicación. Ilustración 47 - Interfaz de buzón de entrada En esta interfaz el usuario podrá buscar mensajes en su buzón, eliminar mensajes entrantes o acceder a un mensaje recibido en concreto. Si se hace clic sobre un mensaje en concreto se mostrará dicho mensaje, pudiendo eliminarse, contestarse, o volver al buzón de entrada sin realizar ninguna acción: 81 Ilustración 48 - Interfaz de visualización de mensaje En cambio, si desde el buzón de entrada se decide por mandar un nuevo mensaje, aparecerá un formulario para rellenar los campos necesarios para el envío del nuevo mensaje. Un campo en el que se podrán poner uno o varios usuarios a los que estará destinado el mensaje, así como la cabecera y el cuerpo del mensaje: Ilustración 49 - Interfaz de nuevo mensaje Una vez rellenados los campos, se podrá pulsar el botón de “Enviar mensaje” para realizar su envío a todos los destinatarios. Si se accede a esta interfaz a través de la opción de contestar un mensaje entrante, el destinatario se rellenará automáticamente con el remitente del mensaje entrante. Sistema de notificaciones Otro método de comunicación sobre las novedades de la aplicación es el sistema de notificaciones, que será utilizado, por ejemplo, para ayudar a los usuarios a la asignación de los resultados de los distintos partidos. Estas notificaciones serán lanzadas de forma automática y podrán ser consultadas por los usuarios en el menú desplegable como se muestra a continuación: 82 Ilustración 50 - Menú desplegable Una vez se accede al listado de notificaciones, se mostrarán las mismas y se podrá acceder a ellas haciendo click sobre las mismas: Ilustración 51 - Interfaz de listado de notificaciones Al acceder a la notificación, se mostrará la información referente a la misma y las vías de actuación pertinentes dependiendo de la notificación: Ilustración 52 - Interfaz de visualización de notificación Inscribirse en competiciones ya creadas Una vez se accede a la interfaz de información detallada de la competición y el usuario se encuentra dado de alta en la aplicación, podrá inscribirse en una competición ya creada. Para ello, deberá acceder a la interfaz de información detallada de la 83 competición y pulsar sobre el botón que se muestra a la derecha para ello, en el caso de que la inscripción aún no haya dado comienzo: Ilustración 53 - Método de inscripción en una competición Crear competición nueva Cualquier usuario que se encuentre dado de alta en la aplicación podrá crear una nueva competición pulsando el botón que aparece en el menú superior “Crear competición” Ilustración 54 - Menú superior de la aplicación Una vez pulsado se mostrará el formulario que se deberá rellenar para crear una nueva competición en el sistema: Ilustración 55 - Interfaz de creación de nueva competición 84 Se trata de la información básica necesaria, una vez rellenada se pulsará el botón “Crear competición”, se enviará el formulario para su comprobación y se creará la nueva competición en el sistema. Editar competición Añadir nuevo recurso a la competición Para añadir un nuevo recurso a la competición, desde la interfaz de vista detallada de la competición se pulsará sobre la pestaña “Normas, ajustes y recursos”. En la interfaz que se muestra a continuación se clicará sobre el botón “Añadir recurso a la competición” Ilustración 56 - Pestaña de normas, ajustes y recursos de la aplicación Al hacerlo, se mostrará una nueva interfaz de selección de horario y con ciertos campos a rellenar. Una vez seleccionado el horario de disponibilidad semanal del recurso y rellenada la información se podrá enviar la información para almacenar el nuevo recurso en la competición. 85 Ilustración 57 - Interfaz para añadir nuevo recurso a la competición Cambiar el estado de la competición La nueva competición se creará como competición “cerrada” y sólo será visible para su creador. Una vez el creador complete toda la información necesaria, tal como añadir recursos, podrá pulsar sobre el botón “Publicar competición” para cambiar su estado a “Abierta” y que así se encuentre disponible para que el resto de usuarios de la aplicación se inscriban como participantes. Ilustración 58 - Pestaña de información general de la competición Modificar información general de la competición El administrador de la competición también podrá modificar la información de la competición siempre y cuando esta no haya sido publicada aún, para ello accederá a la 86 pestaña de “Normas, ajustes y recursos” y pulsará el botón “Modificar información de la competición”: Ilustración 59 - Interfaz de la pestaña de "Normas, ajustes y recursos" de la competición Al pulsar sobre dicho botón, se mostrará la interfaz para la edición de la competición, en la que se podrán cambiar los campos para, una vez finalizada, modificarlos definitivamente: Ilustración 60 - Interfaz de modificación de información de una competición Generación de jornadas Cuando ya se han inscrito suficientes participantes en la competición, el organizador podrá cerrar las nuevas inscripciones y generar los cruces entre las parejas, obteniendo así los partidos para cada jornada. Para ello se accederá desde la interfaz de 87 información de la competición a la pestaña de “Clasificación”, y una vez se muestre se pulsará sobre el botón “Generar cuadrante” Ilustración 61 - Pestaña de clasificación de la competición Generar cruces de las distintas jornadas Una vez la competición se encuentre publicada y tenga participantes inscritos el administrador de la competición podrá generar las distintas jornadas, cerrando así el proceso de inscripción. Para ello, se accederá a la pestaña de “Clasificación” de la competición y se pulsará el botón de “Generar cuadrante” Ilustración 62 - Generación del cuadrante Organización de partidos de la jornada Una vez ya se haya generado el cuadrante con todos los partidos de la competición el siguiente paso será asignarle una fechas a dichos partidos. Para ello se accede a la pestaña de “Clasificación” en la interfaz de información de la competición, y una vez en ella se pulsará sobre el botón “Generar fechas”: Ilustración 63 - Pestaña de clasificación de la competición una vez generado el cuadrante 88 Al pulsar sobre dicho botón se le pedirá al usuario que indique sobre que fechas deben encontrarse los partidos de la próxima jornada a generar, por lo que el usuario deberá seleccionar un rango de fechas: Ilustración 64 - Interfaz para introducir las fechas del planificador de jornadas Una vez seleccionado el rango de fechas y al hacer clic sobre el botón “Generar fechas”, será la aplicación la encargada de generar automáticamente la nueva jornada, colocando los partidos en fechas donde los recursos se encuentren disponibles y además, teniendo en cuenta la disponibilidad de las parejas. Al terminar la asignación automática de partidos se mostrará la interfaz de organización de la jornada, mostrando el resultado de la ordenación de partidos y permitiendo al usuario su modificación si así lo desea, o resolver conflictos que el algoritmo no haya podido resolver: Ilustración 65 - Interfaz del planificador de jornadas A través de la interfaz se mostrará el calendario general, a la izquierda, mostrando en verde los rangos horarios con todos los recursos libres, en amarillo aquellos en los que hay algún partido asignado pero aún hay recursos libres y en rojo aquellos rangos 89 horarios que ya no tenga recursos libres. Si queremos cambiar o colocar un partido, se deberá seleccionar sobre qué día queremos colocarlo, y se mostrará a la derecha su vista detallada, mostrando la disponibilidad de cada recurso dentro del día seleccionado. A continuación, en la lista de la derecha, se clicará sobre un partido de la lista, y manteniendo el botón pulsado se arrastrará el partido hasta el rango horario dentro de la vista detallada donde queremos colocar el partido. Si todo se realiza correctamente, el partido quedará asignado al nuevo rango horario dentro del recurso y día seleccionado. Al finalizar la asignación de fecha y hora a los partidos, se almacenará la información pulsando en el botón “Guardar calendario” que aparece en la parte superior de la interfaz. Modificar resultado de partidos Una vez se ha jugado un partido, tanto el administrador como los usuarios que han jugado el partido podrán modificar el resultado de dicho partido, para ello, desde la interfaz de información detallada de la competición se accederá a la pestaña de “Clasificación” y se seleccionará la jornada del partido sobre el que queremos modificar el resultado. En caso de ser el administrador de la competición, o uno de los usuarios que ha jugado el partido, aparecerá a la derecha del partido en cuestión un botón para modificar el resultado: Ilustración 66 - Interfaz de información del partido, con botón de modificación de resultado Al pulsar sobre dicho botón, se accederá a la interfaz en la que se podrá asignar el resultado al partido, indicando la puntuación de cada pareja en cada set. Una vez terminada la asignación, se pulsará el botón “Guardar resultado” para almacenar la nueva información: 96 Anexo III – Casos de uso detallados Casos de uso de forma detallada A continuación procederemos a detallar cada uno de los casos de uso anteriormente nombrados. Para ello usaremos una tabla para cada uno de ellos que contendrá los siguientes campos detallados:  Nombre Nombre del caso de uso.  Identificador Número identificativo del caso de uso.  Actor Principal Se trata del actor que accederá de manera recurrente a los servicios del sistema para cumplir un objetivo.  Personal involucrado o intereses Para cada actor que interviene en el caso de uso, indica cuáles son sus intereses o que obtiene a través del caso de uso. De esta manera se delimitan los objetivos del sistema.  Descripción Descripción resumida de las razones y resultados del caso de uso.  Trigger Identifica el evento que inicializa el caso de uso, pudiendo ser un evento externo o un evento generado por el propio sistema.  Precondición 97 Establece lo que siempre debe cumplirse antes de comenzar el escenario del caso de uso. Estas condiciones se asumen como ciertas antes de comenzar el caso de uso, no siendo necesario comprobarlas durante la ejecución.  Postcondición Establece lo que debe de cumplirse una vez el caso de uso ha finalizado con éxito, describiendo el estado del sistema una vez finalizada su ejecución  Flujo normal Describe el camino que satisface los intereses del personal involucrado, proveyendo una descripción detallada de las acciones del usuario y las respuestas del sistema.  Flujo alternativo Indican todos los escenarios o bifurcaciones, tanto de éxito como de fracaso. En combinación con el flujo normal debería cubrir todos los caminos posibles de ejecución del caso de uso.  Excepción Describe cualquier condición de error que pueda ocurrir durante la ejecución del caso de uso, definiendo también como responde el sistema ante estas situaciones.  Includes Describe cualquier otro caso de uso que esté incluido por este caso de uso.  Requisitos especiales Requisito no funcional, es decir, atributo de calidad o restricción asociado al caso de uso en concreto.  Notas Cualquier comentario adicional al caso de uso. 98 Casos de uso: Usuario no registrado Nombre: Registrarse en la aplicación Identificador: 1.1 Actor Principal Usuario no registrado Personal involucrado o intereses Usuario no registrado: Registrarse en la aplicación como nuevo usuario Descripción Cualquier visitante de la aplicación podrá registrarse rellenando un formulario con la información básica para así posteriormente poder darse de alta en el sistema Trigger Precondición El nombre usuario y correo electrónico deben ser válidos y únicos en la aplicación Postcondición El usuario se creará en la base de datos del sistema Flujo Normal 1. El usuario visitará la página de la aplicación 2. Seleccionará la opción Registrarse en la aplicación 3. Se mostrará el formulario de registro de la aplicación 4. El usuario rellenará toda la información 5. Se confirmará el envío del formulario 6. Se comprobará que la información introducida es válida 7. Se enviará un correo de confirmación al correo electrónico indicado por el usuario 8. El usuario accederá al correo para confirmar el registro 9. El registro quedará confirmado Flujo alternativo 6a. Si alguno de los campos no es válido se indicará al usuario para que los modifique antes de enviar el formulario Excepción Includes Requisitos especiales Notas Nombre: Buscar competición Identificador: 1.2 Actor Principal Usuario no registrado Personal involucrado o intereses 99 Usuario no registrado: Realizar una búsqueda entre todas las competiciones creadas en la aplicación Descripción El usuario no registrado podrá realizar una búsqueda entre todas las competiciones del sistema, mostrándole posteriormente todas las competiciones que satisfagan los criterios de búsqueda. Trigger Precondición Postcondición Se mostrará una nueva vista donde se muestre un listado de competiciones que cumplan con el criterio de búsqueda. Flujo Normal 1.- El usuario hará clic en el botón de “Buscar competición” 2.- Rellenará los criterios de búsqueda que desee 3.- Se mostrará una nueva vista con el listado de competiciones que cumplan los criterios de búsqueda Flujo alternativo 2a.1-Si ninguna competición cumple con los criterios de búsqueda se informará al usuario Excepción Includes Requisitos especiales Notas Nombre: Acceder a información de competición Identificador: 1.3 Actor Principal Usuario no registrado Personal involucrado o intereses Usuario no registrado: Acceder a información más precisa de una competición seleccionada Descripción El visitante podrá seleccionar una competición y acceder a información de la misma, tales como la descripción, fechas, cuadrante, jugadores, etc. Trigger Precondición Postcondición El visitante accederá a la vista donde se muestra la información general de la competición, siendo ésta 100 el nombre y una descripción general de la misma. Flujo Normal 1. El usuario seleccionará el nombre de una competición 2. Se mostrará la información general de la competición por pantalla. Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre: Consultar cuadrante y resultados Identificador: 1.4 Actor Principal Usuario no registrado Personal involucrado o intereses Usuario no registrado: Podrá consultar el cuadrante de la competición y los resultados de los partidos jugados Descripción Una vez se ha accedido a la información general de la competición el usuario podrá seleccionar la pestaña de cuadrante de la competición, donde se mostrará una vista con todos los horarios de la competición así como los resultados de los partidos ya jugados. Trigger Precondición Postcondición Se mostrará la vista que muestra el cuadrante y los resultados de la competición que se está visitando Flujo Normal 1. Se hará uso del caso de uso 1.2 para acceder a la vista de información general de la competición 2. El usuario seleccionará la pestaña de “Cuadrante” 3. Se mostrará al usuario la información de horario de partidos y resultados de los mismos. Flujo alternativo Excepción Includes Se deberá acceder previamente a la información general de la competición a través del caso de uso 1.2 101 Requisitos especiales Notas Nombre: Consultar listado de usuarios inscritos Identificador: 1.5 Actor Principal Usuario no registrado Personal involucrado o intereses Usuario no registrado: Podrá comprobar todos los participantes de la competición que se esté visitando en ese momento Descripción El usuario no registrado podrá acceder a un listado de todas las parejas participantes en la competición que se esté visitando en ese momento. Trigger Precondición Postcondición Se mostrará en pantalla la vista donde se muestran todas las parejas participantes en la competición. Flujo Normal 1. Se hará uso del caso de uso 1.2 para acceder a la vista de información general de la competición 2. El usuario seleccionará la pestaña de “Cuadrante” 3. Se mostrará al usuario una nueva vista con la información de las parejas participantes en la competición Flujo alternativo Excepción Includes Se deberá acceder previamente a la información general de la competición a través del caso de uso 1.2 Requisitos especiales Notas Nombre: Consultar reglamento y configuración Identificador: 1.6 Actor Principal 102 Usuario no registrado Personal involucrado o intereses Usuario no registrado: Podrá comprobar el reglamento y configuración de la competición Descripción El usuario no registrado podrá acceder a la información acerca del reglamento y de la configuración que se encuentre visitando en ese momento Trigger Precondición Postcondición Se mostrará en pantalla la vista donde se muestra el reglamento y configuración de la competición Flujo Normal 1. Se hará uso del caso de uso 1.2 para acceder a la vista de información general de la competición 2. El usuario seleccionará la pestaña de “Reglamento” 3. Se mostrará al usuario una nueva vista con el reglamento y la configuración de la competición Flujo alternativo Excepción Includes Se deberá acceder previamente a la información general de la competición a través del caso de uso 1.2 Requisitos especiales Notas Nombre: Buscar usuario Identificador: 1.7 Actor Principal Usuario no registrado Personal involucrado o intereses Usuario no registrado: Podrá buscar a cualquier usuario inscrito en la aplicación a través del nombre. Descripción El usuario no registrado podrá realizar una búsqueda a través del nombre de cualquier usuario de la aplicación para, posteriormente, poder acceder a la información básica del mismo Trigger Precondición Postcondición Se mostrará un listado con todos los usuarios que cumplan el criterio de búsqueda Flujo Normal 103 1. El usuario pulsará el botón de “Buscar usuario” 2. Se introducirán los criterios de búsqueda que el usuario considere necesarios 3. Se realizará la búsqueda entre todos los usuarios dados de alta en la aplicación 4. Se mostrará un listado de todos los usuarios que cumplan con los criterios de búsqueda Flujo alternativo 3a. En caso de que ningún usuario dado de alta cumpla con los criterios de búsqueda se mostrará un mensaje informando que no ha sido posible mostrar ningún resultado Excepción Includes Requisitos especiales Notas Nombre: Visitar usuario Identificador: 1.8 Actor Principal Usuario no registrado Personal involucrado o intereses Usuario no registrado: acceder a la información básica de otro usuario registrado en la aplicación Descripción El usuario podrá acceder al perfil de otro usuario, viendo la información del mismo tal como la foto de perfil, descripción, competiciones en las que se encuentra inscrito, etc. Trigger Precondición Postcondición Se mostrará el perfil del usuario seleccionado Flujo Normal 1. El usuario hará clic sobre el nombre de algún usuario 2. Se mostrará una vista con el perfil de usuario, conteniendo éste toda la información básica del mismo. Flujo alternativo Excepción Includes Requisitos especiales Notas 104 Se podrá acceder al perfil de usuario a través de la lista que se muestra al hacer uso del caso de uso 1.6 o a través del listado de participantes de la competición, al que se accede a través del caso de uso 1.4 105 Casos de uso: Usuario registrado Nombre: Iniciar sesión Identificador: 2.1 Actor Principal Usuario registrado. Personal involucrado o intereses Usuario registrado: iniciar sesión en la aplicación para acceder a todas las funcionalidades. Descripción Una vez realizado el registro, y estando presente la entrada del usuario en la base de datos, este podrá acceder al sistema introduciendo su usuario y contraseña en el formulario de acceso. Trigger Precondición El usuario debe haberse registrado anteriormente en el sistema. Postcondición El usuario quedará identificado en el sistema durante la sesión Flujo Normal 1.- El usuario introducirá su usuario y contraseña 2.- Pulsará el botón de “Iniciar sesión”. 3.- El sistema comprobará que la información es correcta. 4.- El usuario quedará identificado. Flujo alternativo Excepción 3a. La información introducida no es correcta. 3a.1. Se notifica el error y no se permite el acceso al usuario, pidiendo que se vuelva a introducir la información. Includes Requisitos especiales Notas Nombre: Cerrar sesión Identificador: 2.2 Actor Principal Usuario registrado. Personal involucrado o intereses Usuario registrado: cerrar sesión, saliendo así del sistema 112 Nombre: Leer mensaje privado Identificador: 2.10 Actor Principal Usuario registrado Personal involucrado o intereses Usuario registrado: Leer mensajes entrantes de su buzón de correo Descripción El usuario registrado podrá acceder al contenido de los mensajes de los que él es destinatario, presentes en su buzón de correo. Trigger Precondición El usuario debe estar identificado previamente en el sistema Postcondición Se mostrará el contenido del mensaje seleccionado y éste será marcado como leído Flujo Normal 1. Se accederá al buzón de mensajes a través del caso de uso 2.8 2. Se pulsará sobre el mensaje al que se desea acceder 3. Se mostrará en pantalla el contenido del mensaje Flujo alternativo Excepción Includes Para acceder previamente al buzón de mensajes se hará uso del caso de uso 2.8 Requisitos especiales Notas Nombre: Eliminar mensaje privado Identificador: 2.11 Actor Principal Usuario registrado Personal involucrado o intereses Usuario registrado: Podrá eliminar un mensaje presente en su buzón de correo Descripción El usuario podrá eliminar cualquier mensaje entrante presente en su buzón de correo de la aplicación Trigger 113 Precondición El usuario debe estar identificado previamente en el sistema Postcondición Se eliminará el mensaje de la base de datos del sistema y, por lo tanto, del buzón del usuario Flujo Normal 1. Se accederá al buzón de mensajes a través del caso de uso 2.8 2. Se pulsará sobre el botón de “eliminar” asociado al mensaje que se desea eliminar. 3. El mensaje será borrado de la base de datos. Flujo alternativo Excepción 3a. En caso de fallo de conexión con la base de datos se mostrará un mensaje de error indicando que no se ha podido realizar la operación y se volverá a la vista del buzón de mensajes. Includes Para acceder previamente al buzón de mensajes se hará uso del caso de uso 2.8 Requisitos especiales Notas Nombre: Consultar notificaciones Identificador: 2.12 Actor Principal Usuario registrado Personal involucrado o intereses Usuario registrado: Consultar las notificaciones Descripción El usuario podrá consultar las notificaciones entrantes, avisos del sistema de varios eventos que afectan al usuario registrado. Trigger Precondición El usuario debe estar identificado previamente en el sistema Postcondición Se mostrarán las notificaciones entrantes que tenga el usuario Flujo Normal 1. El usuario pulsará sobre el botón de “Notificaciones” 2. Se mostrará una lista de las notificaciones que tenga el usuario en ese momento. Flujo alternativo Excepción Includes 114 Requisitos especiales Notas Nombre: Acceder a notificación Identificador: 2.13 Actor Principal Usuario registrado Personal involucrado o intereses Usuario registrado: Acceder a la notificaciones entrantes Descripción El usuario podrá acceder a una notificación en concreto una vez ha accedido al listado de notificaciones entrantes, obteniendo así una información detallada de la misma Trigger Precondición El usuario debe estar identificado previamente en el sistema Postcondición Se mostrará la información detallada de la notificación seleccionada Flujo Normal 1. El usuario hará uso del caso de uso 2.12 para consultar las notificaciones recibidas 2. Hará clic sobre la notificación a la que desea acceder 3. Se mostrará un dialogo de texto con la información detallada de la notificación Flujo alternativo Excepción Includes Para acceder al listado de notificaciones se hará uso del caso de uso 2.12 Requisitos especiales Notas 115 116 Casos de uso: Administrador del sistema Nombre: Seleccionar usuario Identificador: 3.1 Actor Principal Administrador del sistema Personal involucrado o intereses Administrador del sistema: Seleccionar un usuario entre todos los registrados en el sistema Descripción El administrador podrá seleccionar un usuario de entre todos los registrados en el sistema para posteriormente modificarlo o eliminarlo Trigger Precondición El administrador debe haberse dado de alta en el sistema Postcondición El usuario quedará seleccionado para su posterior modificación Flujo Normal 1. El administrador seleccionará 1 usuario de entre el listado de todos los usuarios registrados en el sistema 2. El usuario quedará marcado y pendiente de modificación Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre: Añadir usuario Identificador: 3.2 Actor Principal Administrador del sistema Personal involucrado o intereses Administrador del sistema: Añadir un nuevo usuario de forma manual a la base de datos de la aplicación Descripción El administrador podrá introducir la información de forma manual de un nuevo usuario en el sistema, guardando así el nuevo usuario en la base de datos 117 Trigger Precondición El administrador debe haberse dado de alta en el sistema Postcondición El nuevo usuario quedará creado en la base de datos del sistema Flujo Normal 1. El administrador pulsará el botón de “Crear nuevo usuario” 2. Se mostrará un formulario a rellenar con toda la información básica de un usuario 3. El administrador rellenará toda la información necesaria 4. El administrador pulsará el botón de “Aceptar” 5. Se comprobará que la información en el formulario es correcta 6. Se creará un nuevo usuario en la base de datos del sistema Flujo alternativo Excepción 5a. En caso de que alguno de los campos no sea válido, se notificará al administrador para que proceda a su modificación 6a. En caso de que la comunicación con la base de datos no pueda llevarse a cabo, se comunicará al administrador del error. Includes Requisitos especiales Notas Nombre: Eliminar usuario Identificador: 3.3 Actor Principal Administrador del sistema Personal involucrado o intereses Administrador del sistema: Podrá eliminar cualquier usuario presente en la aplicación Descripción El administrador del sistema tendrá completo control sobre la misma, pudiendo borrar de la base de datos cualquier usuario presente en la aplicación Trigger Precondición El administrador debe haberse dado de alta en el sistema Postcondición El usuario quedará eliminado de la base de datos del sistema Flujo Normal 118 1. Se hará uso del caso de uso 3.1 para seleccionar un usuario 2. Se pulsará el botón de eliminar usuario 3. Se pedirá una confirmación a través de un mensaje emergente para realizar la operación. 4. El administrador confirmará la operación 5. El usuario quedará borrado de la base de datos del sistema Flujo alternativo 4a. En caso de que el administrador no confirme la operación, ésta se cancelará y no se producirá la eliminación del usuario. Excepción 5a. En caso de que no se pueda comunicar con la base de datos en ese momento, se informará al administrador del error. Includes Se hará uso del caso de uso 3.1 para seleccionar el usuario a eliminar Requisitos especiales Notas Nombre: Modificar usuario Identificador: 3.4 Actor Principal Administrador del sistema Personal involucrado o intereses Administrador del sistema: Podrá modificar la información de perfil de cualquier usuario presente en la aplicación Descripción El administrador de la aplicación podrá modificar la información de cualquier usuario que se encuentre registrado en la aplicación Trigger Precondición El administrador debe haberse dado de alta en el sistema Postcondición La información del usuario quedará modificada en la base de datos Flujo Normal 1. Se hará uso del caso de uso 3.1 para seleccionar un usuario 2. Se pulsará el botón de “Modificar usuario” 3. Se mostrará toda la información del usuario 4. El administrador modificará los campos de información del usuario 5. Pulsará el botón de “Guardar” 6. Se pedirá confirmación por parte del administrador para realizar los cambios 7. El administrador confirmará los cambios 8. Se guardarán los cambios en la base de datos del sistema Flujo alternativo 7a. En caso de que el administrador no confirme los cambios no se guardarán los mismos en la base de 119 datos del sistema Excepción 5a. En caso de que alguno de los campos al modificarse no sean válidos, se informará al administrador para que proceda a su modificación 8a. Si no es posible comunicarse con la base de datos en ese momento se informará al administrador que no ha sido posible la modificación en la base de datos. Includes Requisitos especiales Notas Nombre: Seleccionar competición Identificador: 3.5 Actor Principal Administrador del sistema Personal involucrado o intereses Administrador del sistema: Seleccionar una competición de entre todas las registradas en el sistema Descripción El administrador podrá seleccionar una competición de entre todas las registradas en el sistema para posteriormente modificarla o eliminarla Trigger Precondición El administrador debe haberse dado de alta en el sistema Postcondición La competición quedará seleccionada para su posterior modificación Flujo Normal 1. El administrador seleccionará 1 competición de entre el listado de todas las competiciones registradas en el sistema 2. La competición quedará marcado y pendiente de modificación Flujo alternativo Excepción Includes Requisitos especiales Notas 120 Nombre: Eliminar competición Identificador: 3.6 Actor Principal Administrador del sistema Personal involucrado o intereses Administrador del sistema: Podrá eliminar cualquier competición presente en la aplicación Descripción El administrador del sistema tendrá completo control sobre la misma, pudiendo borrar de la base de datos cualquier competición presente en la aplicación Trigger Precondición El administrador debe haberse dado de alta en el sistema Postcondición La competición quedará eliminada de la base de datos del sistema Flujo Normal 1. Se hará uso del caso de uso 3.5 para seleccionar un usuario 2. Se pulsará el botón de eliminar competición 3. Se pedirá una confirmación a través de un mensaje emergente para realizar la operación. 4. El administrador confirmará la operación 5. La competición quedará borrado de la base de datos del sistema Flujo alternativo 4a. En caso de que el administrador no confirme la operación, ésta se cancelará y no se producirá la eliminación de la competición. Excepción 5a. En caso de que no se pueda comunicar con la base de datos en ese momento, se informará al administrador del error. Includes Se hará uso del caso de uso 3.5 para seleccionar el usuario a eliminar Requisitos especiales Notas Nombre: Modificar competición Identificador: 3.7 Actor Principal Administrador del sistema Personal involucrado o intereses Administrador del sistema: Podrá modificar la información de cualquier competición presente en la 121 aplicación Descripción El administrador de la aplicación podrá modificar la información de cualquier competición que se encuentre registrada en la aplicación Trigger Precondición El administrador debe haberse dado de alta en el sistema Postcondición La información de la competición quedará modificada en la base de datos Flujo Normal 1. Se hará uso del caso de uso 3.5 para seleccionar una competición 2. Se pulsará el botón de “Modificar competición” 3. Se mostrará toda la información de la competición 4. El administrador modificará los campos de información de la competición 5. Pulsará el botón de “Guardar” 6. Se pedirá confirmación por parte del administrador para realizar los cambios 7. El administrador confirmará los cambios 8. Se guardarán los cambios en la base de datos del sistema Flujo alternativo 7a. En caso de que el administrador no confirme los cambios no se guardarán los mismos en la base de datos del sistema Excepción 5a. En caso de que alguno de los campos al modificarse no sean válidos, se informará al administrador para que proceda a su modificación 8a. Si no es posible comunicarse con la base de datos en ese momento se informará al administrador que no ha sido posible la modificación en la base de datos. Includes Requisitos especiales Notas Nombre: Validar nueva competición Identificador: 3.8 Actor Principal Administrador del sistema Personal involucrado o intereses Administrador del sistema: El administrador validará cualquier competición que se cree en el sistema antes de que se publique Descripción Cualquier competición creada en el sistema debe ser validada por el administrador del sistema, una vez validada ésta se mostrará públicamente al resto de usuarios y podrá comenzar a trabajar en ella 128 6. El lugar e partido se eliminará de la lista de recursos de la competición que se está modificando Flujo alternativo 5a. El administrador puede decidir no eliminar el recurso, con lo que pulsará el botón “Rechazar” y el recurso no se eliminará Excepción 6a. Si no es posible comunicarse con la base de datos en ese momento se informará al administrador que no ha sido posible la modificación en la base de datos. Includes Requisitos especiales Notas Nombre: Definir normas de puntuación Identificador: 4.7 Actor Principal Administrador de la competición Personal involucrado o intereses Administrador de la competición: Modificar las normas de puntuación de los partidos Descripción El administrador de la competición podrá modificar la forma de puntuar un empate, victoria o perdida durante la competición Trigger Precondición El usuario debe haberse dado de alta en el sistema La competición a modificar no debe ser pública aún en el momento de la modificación Postcondición Las normas de puntuación quedarán fijadas para el torneo. Flujo Normal 1. El administrador accederá a la información de los recursos de la competición 2. Al ser administrador, se mostrará la vista de recursos de competición como un formulario modificable 3. El administrador de la competición modificará la puntuación que se recibirá al perder, empatar o ganar un partido 4. Pulsará el botón de “Guardar cambios” 5. Los cambios serán guardados en la base de datos Flujo alternativo Excepción 5a. Si no es posible comunicarse con la base de datos en ese momento se informará al administrador que no ha sido posible la modificación en la base de datos. Includes 129 Requisitos especiales Notas Nombre: Designar a otro usuario como administrador Identificador: 4.8 Actor Principal Administrador de la competición Personal involucrado o intereses Administrador de la competición: Designar a otro usuario como administrador de la competición, otorgándole los permisos que ello conlleva. Descripción El administrador de la competición podrá añadir más administradores para facilitar la tarea de organizar la competición Trigger Precondición El usuario debe haberse dado de alta en el sistema Postcondición Flujo Normal 1. El administrador accederá a la vista de información general de la competición 2. Pulsará el botón de “Añadir administrador a la competición” 3. Se mostrará una vista para que se realice la búsqueda del usuario que va a añadir como administrador 4. Introducirá los criterios de búsqueda 5. Seleccionará al usuario que desea nombrar como administrador 5. Confirmará la operación 6. El usuario indicado quedará marcado como administrador de la competición en la base de datos del sistema. Flujo alternativo Excepción Includes Requisitos especiales Notas 130 Nombre: Permitir inscripción vía web Identificador: 4.9 Actor Principal Administrador de la competición Personal involucrado o intereses Administrador de la competición: Abrir la inscripción para que los usuarios de la aplicación puedan pedir la inscripción a la competición Descripción El administrador podrá elegir si la inscripción se realizará solamente mediante invitación o si se permite la inscripción vía web del resto de usuarios de la aplicación Trigger Precondición El usuario debe haberse dado de alta en el sistema Postcondición Flujo Normal 1. El administrador accederá a la vista de listado de usuarios inscritos en la aplicación 2. Marcará la casilla que permitirá la inscripción vía web 3. Hará clic en el botón para guardar cambios 4. El tipo de inscripción quedará modificado para la competición Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre: Invitar a la competición por correo electrónico Identificador: 4.10 Actor Principal Administrador de la competición Personal involucrado o intereses Administrador de la competición: Enviará un correo electrónico con un link permitiendo la inscripción en la competición Descripción 131 El administrador podrá seleccionar a que usuarios invitar a la competición introduciendo un listado de correos electrónicos con un link para poder realizar la inscripción Trigger Precondición El usuario debe haberse dado de alta en la aplicación Postcondición Se mandará un email a toda la lista de correos indicada por el administrador Flujo Normal 1. El administrador accederá a la vista de listado de usuarios inscritos en la aplicación 2. Pulsará el botón para invitar a otros usuarios a la competición 3. Indicará todos aquellos correos electrónicos a los que se desea mandar la invitación 4. Pulsará el botón para confirmar el envío de invitaciones 5. Se mandará el correo electrónico con la invitación a todas las direcciones indicadas Flujo alternativo 4a. Al pulsar el botón se realizará la comprobación de los correos electrónicos, en caso de que alguno no sea válido se informará al administrador para que lo modifique o lo elimine antes de proceder al envío Excepción Includes Requisitos especiales Notas Al realizar el envío de correos electrónicos se comprobará si el usuario ya se ha registrado en la aplicación, en cuyo caso también se enviará un mensaje al usuario registrado a través del buzón interno de la aplicación Nombre: Confirmar petición de inscripción Identificador: 4.11 Actor Principal Administrador de la competición Personal involucrado o intereses Administrador de la competición: Confirmar la inscripción vía web por parte de un usuario Descripción Si el administrador ha abierto la inscripción vía web, cualquier usuario que intente registrarse en la competición deberá ser validado posteriormente por parte del administrador Trigger Precondición 132 El usuario debe haberse dado de alta en la aplicación Postcondición El usuario quedará definitivamente inscrito en la aplicación Flujo Normal 1. El administrador accederá a la vista de listado de usuarios inscritos en la aplicación, en este listado podrá comprobar los usuarios que se encuentran inscritos sin confirmación 2. El administrador pulsará el botón para confirmar la inscripción del usuario en la competición 3. Se mostrará un mensaje pidiendo confirmación de la operación 4. El administrador de la competición confirmará la operación 5. El usuario quedará finalmente inscrito en la competición Flujo alternativo 4a. El administrador podrá no confirmar la operación si así lo desea Excepción Includes Requisitos especiales Notas Nombre: Eliminar participante Identificador: 4.12 Actor Principal Administrador de la competición Personal involucrado o intereses Administrador de la competición: Eliminar un participante de la competición Descripción El administrador podrá eliminar cualquier participante de la competición. Trigger Precondición El usuario debe haberse dado de alta en el sistema Postcondición El usuario quedará eliminado como participante de la competición Flujo Normal 1. El administrador accederá a la vista de usuarios inscritos en la aplicación 2. El administrador pulsará el botón asociado a un determinado usuario para eliminar a dicho participante. 3. Se pedirá confirmación de la operación al administrador 4. El administrador de la competición validará la operación 5. El usuario quedará eliminado de la competición Flujo alternativo 4a. El administrador de la competición puede cancelar la operación si así lo desea Excepción 133 Includes Requisitos especiales Notas En caso de que la competición aún no haya dado comienzo, el participante será eliminado de la competición sin más repercusiones. En caso de que la competición ya se encuentre disputando, se marcarán como partidos perdidos todos los partidos en que dicho participante se encontrara. Nombre: Publicar competición Identificador: 4.13 Actor Principal Administrador de la competición Personal involucrado o intereses Administrador de la competición: Hacer pública una competición en la aplicación Descripción El administrador de la competición podrá crear la competición y revisarla hasta que decida publicarla, en el momento en el que la haga pública podrán empezar a inscribirse participantes para posteriormente comenzar a jugarla Trigger Precondición El usuario debe haberse dado de alta en el sistema Toda la información básica de la competición debe haberse rellenado por parte del administrador Postcondición La competición quedará publicada en la aplicación Flujo Normal 1. El administrador de la competición accederá a la vista general de la competición 2. Pulsará el botón para publicar la competición 3. Se pedirá confirmación de la operación, indicando que posteriormente habrá información de la competición que no podrá modificarse 4. El administrador de la competición confirmará la operación 5. Se marcará la competición como pública en la base de datos, indicando que podrá verse por el resto de usuarios de la aplicación Flujo alternativo 2a. Si falta información de la competición, se indicará al administrador que aún no es posible la publicación de la competición 4a. El administrador podrá cancelar la operación si así lo desea Excepción Includes 134 Requisitos especiales Notas Nombre: Seleccionar duración de fase o jornada Identificador: 4.14 Actor Principal Administrador de la competición Personal involucrado o intereses Administrador de la competición: Seleccionar la duración en tiempo de una fase o jornada de la competición Descripción El administrador de la competición debe seleccionar la duración en tiempo de las fases de la competición para que posteriormente el sistema pueda organizar el horario de los distintos partidos de cada jornada Trigger Precondición El usuario debe haberse dado de alta en el sistema Postcondición La duración de las jornadas para esta competición quedará señalada Flujo Normal 1. El administrador accederá a la vista de configuración de la competición 2. La vista será mostrada como un formulario modificable ya que es administrador de la aplicación 3. El administrador pulsará el botón de modificar duración de las jornadas 4. Seleccionará un plazo de tiempo para cada jornada 5. Pulsará el botón de guardar cambios 6. Se mostrará un aviso indicando si desea confirmar los cambios 7. El administrador confirmará los cambios 8. La duración de la jornada para esta aplicación será guardada en la base de datos de la aplicación Flujo alternativo 7a. El administrador podrá cancelar el cambio si así lo desea Excepción Includes Requisitos especiales Notas Modificar para que no haga falta confirmación 135 Nombre: Generar emparejamientos Identificador: 4.15 Actor Principal Administrador de la competición Personal involucrado o intereses Administrador de la competición: Generar automáticamente los emparejamientos Descripción Una vez ya se encuentren todos los usuarios inscritos en la competición, y el administrador haya fijado la duración de las jornadas, podrá generar de manera automática los emparejamientos entre las distintas parejas. Trigger Precondición El usuario debe haberse dado de alta en el sistema Postcondición Los emparejamientos quedarán creados y almacenados en el sistema Flujo Normal 1. El administrador accederá al cuadrante de la competición 2. Pulsará el botón de generar emparejamientos de forma automática 3. El sistema realizará los emparejamientos y serán mostrados en el cuadrante 4. El administrador podrá modificar algún emparejamiento si así lo desea 5. Pulsará el botón para guardar los cambios 6. Se pedirá confirmación por parte del administrador de la competición 7. El administrador confirmará la creación 8. Los emparejamientos se almacenarán en la base de datos de la aplicación Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre: Generar fechas de cada fase o jornada Identificador: 4.16 Actor Principal Administrador de la competición Personal involucrado o intereses Administrador de la competición: Generar automáticamente las fechas de cada partido Descripción El administrador, una vez se haya definido la duración de cada fase y creado los emparejamientos, podrá generar 136 de forma automática los horarios de los partidos teniendo en cuenta las restricciones de cada participante. Trigger Precondición El usuario debe haberse dado de alta en el sistema La duración de la jornada y los emparejamientos deben haberse definido anteriormente Postcondición Se generará el horario de las fases o jornadas seleccionadas Flujo Normal 1. El administrador accederá a la vista donde se muestra el cuadrante de la competición 2. El administrador indicará la franja límite para cuadrar los partidos 3. Pulsará el botón de generación automática del horario 4. La aplicación generará el horario de la forma más eficiente posible, teniendo en cuenta las restricciones de cada pareja jugadora 5. El administrador podrá ver el horario creado para las jornadas que ha decidido 6. El administrador pulsará el botón de guardar horario 7. Las fechas de los partidos quedarán almacenadas en el sistema Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre: Modificar fecha de encuentro Identificador: 4.17 Actor Principal Administrador de la competición Personal involucrado o intereses Administrador de la competición: Modificar la fecha de algún encuentro ya generado Descripción El administrador podrá modificar alguna fecha de encuentro una vez se haya usado el caso de uso 4.16 para generarlas Trigger Precondición El usuario debe haberse dado de alta en el sistema Las fechas deben haberse generado a través del caso de uso 4.16 Postcondición 137 Flujo Normal 1. El administrador usará el caso de uso 4.16 para generar el horario para ciertas jornadas 2. Una vez generado el horario, el administrador podrá modificar cualquier fecha que considere necesario 3. El administrador pulsará el botón para guardar los cambios 4. Se pedirá confirmación para realizar la operación 5. El administrador validará la operación 6. El cambio en el horario se guardará en el sistema Flujo alternativo 5a. El administrador podrá cancelar la operación si así lo desea Excepción Includes Requisitos especiales Notas Nombre: Modificar lugar de encuentro Identificador: 4.18 Actor Principal Administrador de la competición Personal involucrado o intereses Administrador de la competición: Modificar el lugar de algún encuentro ya generado Descripción El administrador podrá modificar el lugar de algún encuentro una vez se haya usado el caso de uso 4.16 para generarlas Trigger Precondición El usuario debe haberse dado de alta en el sistema Las fechas deben haberse generado a través del caso de uso 4.16 Postcondición Flujo Normal 1. El administrador usará el caso de uso 4.16 para generar el horario para ciertas jornadas 2. Una vez generado el horario, el administrador podrá modificar cualquier emplazamiento que considere necesario 3. El administrador pulsará el botón para guardar los cambios 4. Se pedirá confirmación para realizar la operación 5. El administrador validará la operación 6. El cambio en el horario se guardará en el sistema Flujo alternativo 5a. El administrador podrá cancelar la operación si así lo desea Excepción 144 Postcondición Se producirá el cambio validado en el encuentro de la competición Flujo Normal 1. El usuario accederá a la notificación de cambio de partido recibida 2. El usuario comprobará que el cambio ofrecido es satisfactorio 3. Pulsará el botón de “Aceptar cambio” 3. Se modificará la fecha y hora del encuentro sujeto al cambio Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre: Rechazar cambio en partido Identificador: 5.4 Actor Principal Participante en la competición Personal involucrado o intereses Participante en la competición: Rechazar un cambio solicitado por un contrincante en la competición Descripción El usuario podrá rechazar un cambio ofrecido por una pareja contrincante durante la competición Trigger Precondición El usuario debe haberse dado de alta en el sistema Postcondición Se eliminará la petición de cambio y no se producirá la modificación. Se enviará un mensaje al usuario que ha pedido el cambio informándole de la situación Flujo Normal 1. El usuario accederá a la notificación de cambio de partido recibida 2. El usuario comprobará la información del cambio ofrecido 3. El usuario pulsará el botón de “Rechazar cambio” 4. Se eliminará la petición de cambio y se enviará un mensaje al usuario que lo ha pedido. Flujo alternativo Excepción Includes 145 Requisitos especiales Notas Nombre: Solicitar asignación de resultado Identificador: 5.6 Actor Principal Participante en la competición Personal involucrado o intereses Participante en la competición: Solicitar la asignación de un resultado a un encuentro Descripción El participante podrá solicitar la asignación de un resultado de un partido ya celebrado, quedando esta asignación pendiente de ser validada. Trigger Precondición El usuario debe haberse dado de alta en el sistema Postcondición Se mandará una solicitud de asignación de resultado a la pareja afectada por el cambio Flujo Normal 1. El usuario accederá a la vista de cuadrante y horarios de la competición 2. Seleccionará el partido sobre el que desea realizar la asignación 3. Introducirá el resultado del encuentro 4. Pulsará el botón de “Solicitar asignación” 5. Se pedirá confirmación del envío al usuario 6. El usuario aceptará el envío 7. Se mandará una notificación a los usuarios afectados por el cambio Flujo alternativo 6a. El usuario puede cancelar el envío si así lo desea Excepción Includes Requisitos especiales Notas Nombre: Validar asignación de resultado Identificador: 5.7 146 Actor Principal Participante en la competición Personal involucrado o intereses Participante en la competición: Validar una asignación de resultado solicitada por un contrincante en la competición Descripción El usuario podrá confirmar la asignación de resultado, haciéndola definitiva y procediéndose así a guardar el resultado y a ser mostrado en el cuadrante de la competición Trigger Precondición El usuario debe haberse dado de alta en el sistema Postcondición Se validará el resultado y quedará público en la competición Flujo Normal 1. El usuario accederá a la notificación de asignación de resultado que reciba 2. El usuario comprobará que el cambio ofrecido es satisfactorio 3. Pulsará el botón de “Aceptar cambio” 3. Se modificará la fecha y hora del encuentro sujeto al cambio Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre: Rechazar asignación de resultado Identificador: 5.8 Actor Principal Participante en la competición Personal involucrado o intereses Participante en la competición: Rechazar una asignación de resultado enviada por un contrincante en la competición Descripción El usuario podrá rechazar una asignación de resultado enviada por un usuario perteneciente a la pareja contrincante durante la competición Trigger 147 Precondición El usuario debe haberse dado de alta en el sistema Postcondición Se eliminará la petición de asignación de resultado y no se producirá la modificación. Se enviará un mensaje al usuario que ha pedido el cambio informándole de la situación Flujo Normal 1. El usuario accederá a la notificación de asignación de resultado recibida 2. El usuario comprobará la información acerca del resultado 3. El usuario pulsará el botón de “Rechazar cambio” 4. Se eliminará la petición de cambio y se enviará un mensaje al usuario que lo ha pedido. Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre: Abandonar competición Identificador: 5.7 Actor Principal Participante en la competición Personal involucrado o intereses Participante en la competición: Abandonar la competición a la que ya se ha inscrito Descripción El usuario que ya se ha inscrito en alguna competición podrá abandonarla en cualquier momento Trigger Precondición El usuario debe haberse dado de alta en el sistema Postcondición El usuario abandonará la competición Flujo Normal 1. El usuario accederá a la vista principal de la competición que desea abandonar 2. Pulsará sobre el botón “Abandonar competición” 3. Se pedirá confirmación, indicando las consecuencias que esta acción tendrá en la competición 4. El usuario confirmará la operación 5. Se eliminará al usuario de la competición Flujo alternativo 4a. El usuario puede cancelar la operación si así lo desea 5a. Si la competición aún no ha sido iniciada, se eliminará al usuario y a su pareja de los participantes en la competición 148 5b. Si la competición ya se ha iniciado, se hará un barrido por todos los partidos en los que se encontraba dicho usuario, marcándolos como partidos perdidos para la pareja del usuario que abandona. Excepción Includes Requisitos especiales Notas