Desarrollo de un sistema de gestión de campeonatos y generación de calendarios de pádel

!! SISTEMA DE GESTIÓN DE CAMPEONATOS Y GENERACIÓN DE CALENDARIO DE PÁDEL Josué Caballero López Las Palmas de Gran Canaria, 06 de Junio de 2017 Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!1! Proyecto fin de carrera de la Facultad de Informática de la Universidad de Las Palmas de Gran Canaria presentado por el alumno: JOSUÉ CABALLERO LÓPEZ Título del Proyecto: Desarrollo de un sistema de gestión de campeonatos y generación de calendario de pádel. Tutor: D. Alexis Quesada Arencibia Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!2! Índice'de'Contenidos' Índice!de!Contenidos!.........................................................................................................................!2! Índice!de!ilustraciones!......................................................................................................................!5! Índice!de!tablas!....................................................................................................................................!6! !Introducción!................................................................................................................................!7!1. !Objetivos!.......................................................................................................................................!7!2. 2.1.!De!la!aplicación!..................................................................................................................!7! 2.2.!Del!desarrollo!......................................................................................................................!8! !Estructura!del!documento!.....................................................................................................!8!3. !Estado!del!arte!............................................................................................................................!9!4. 4.1.!Complejidad!del!problema!............................................................................................!9! 4.2.!Técnicas!de!resolución!empleadas!.........................................................................!10! 4.3.!Estudio!de!herramientas!.............................................................................................!10! 4.3.1.!TodoTorneos.com!......................................................................................................!10! 4.3.2.!Xporty!.............................................................................................................................!11! 4.3.3.!Pádel!manager!............................................................................................................!13! 4.4.!Conclusiones!del!estudio!de!herramientas!.........................................................!14! !Metodología!..............................................................................................................................!14!5. 5.1.!Modelo!de!proceso!de!software!...............................................................................!14! 5.2.!Lenguaje!de!modelado!.................................................................................................!18! 5.3.!Metodología!aplicada!....................................................................................................!18! 5.4.!Planificación!.....................................................................................................................!18! !Recursos!necesarios!..............................................................................................................!19!6. 6.1.!Recursos!hardware!.......................................................................................................!19! 6.1.1.!Servidor!web!................................................................................................................!19! 6.2.!Recursos!software!.........................................................................................................!19! 6.2.1.!Servicio!Hypnotoad!...................................................................................................!19! 6.2.2.!Servicio!PostgreSQL!9!o!superior!.......................................................................!19! 6.2.3.!Mojolicious!...................................................................................................................!19! 6.2.4.!Putty!................................................................................................................................!19! 6.2.5.!Git!.....................................................................................................................................!20! 6.2.6.!Vim!...................................................................................................................................!20! 6.2.7.!Psql!...................................................................................................................................!20! 6.2.8.!pgAdmin!........................................................................................................................!20! 6.2.9.!Sistema!operativo!Windows!10!...........................................................................!20! Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!3! 6.2.10.!Microsoft!Word!2010!..........................................................................................!21! 6.2.11.!StarUML!.....................................................................................................................!21! 6.3.!Tecnologías!utilizadas!..................................................................................................!21! 6.3.1.!Perl!...................................................................................................................................!21! 6.3.2.!PostgreSQL!...................................................................................................................!21! 6.3.3.!HTML!...............................................................................................................................!22! 6.3.4.!JavaScript!......................................................................................................................!22! 6.3.5.!jQuery!.............................................................................................................................!22! 6.3.6.!CSS!....................................................................................................................................!22! 6.3.7.!AJAX!.................................................................................................................................!23! 6.3.8.!Bootstrap!.......................................................................................................................!23! 6.3.9.!DataTables!....................................................................................................................!23! 6.3.10.!ApiRest!.......................................................................................................................!24! 6.3.11.!Curl!..............................................................................................................................!24! 6.3.12.!CPAN!...........................................................................................................................!25! !Análisis!........................................................................................................................................!25!7. 7.1.!Introducción!.....................................................................................................................!25! 7.2.!Requisitos!del!software!...............................................................................................!25! 7.2.1.!Introducción!.................................................................................................................!25! 7.2.2.!Modelo!conceptual!....................................................................................................!26! 7.2.3.!Identificación!de!actores!........................................................................................!27! 7.2.4.!Diccionario!de!conceptos!.......................................................................................!27! 7.2.5.!Actores/Objetivos!.....................................................................................................!28! 7.2.6.!Listado!resumen!de!los!casos!de!uso!................................................................!29! 7.2.7.!Diagramas!de!casos!de!uso!....................................................................................!30! 7.2.8.!Casos!de!uso!completos!..........................................................................................!31! 7.3.!Prototipos!de!validación!.............................................................................................!34! !Diseño!..........................................................................................................................................!38!8. 8.1.!Introducción!.....................................................................................................................!38! 8.2.!Arquitectura!ClientebServidor!..................................................................................!38! 8.3.!Patrón!MVC!(Modelo!Vista!Controlador)!.............................................................!39! 8.4.!Diseño!arquitectónico!..................................................................................................!39! 8.5.!Base!de!datos!...................................................................................................................!41! 8.5.1.!Tablas!..............................................................................................................................!42! 8.6.!Estructura!de!la!aplicación!.........................................................................................!45! 8.7.!Interfaz!................................................................................................................................!46! Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!4! 8.7.1.!Importancia!de!la!interfaz!......................................................................................!46! 8.7.2.!Estructura!y!diseño!...................................................................................................!46! 8.8.!Diagrama!de!clases!........................................................................................................!47! 8.9.!Diagramas!de!secuencia!..............................................................................................!49! 8.9.1.!Sistema!de!gestión!.....................................................................................................!49! !Desarrollo!..................................................................................................................................!51!9. 9.1.!Detalles!de!implementación!......................................................................................!51! 9.1.1.!Introducción!.................................................................................................................!51! 9.1.2.!Estructura!interna!del!sistema!............................................................................!52! 9.1.3.!Generar!competiciones!...........................................................................................!52! 9.1.4.!Heurística!para!la!asignación!de!pistas!............................................................!53! 9.2.!Librerías!externas!..........................................................................................................!54! 9.2.1.!DataTables!....................................................................................................................!54! 9.2.2.!Bootstrap!.......................................................................................................................!55! !Pruebas!del!sistema!..............................................................................................................!55!10. !Resultados!y!conclusiones!..................................................................................................!57!11. 11.1.!Resultados!.....................................................................................................................!57! 11.1.1.!Interfaz!.......................................................................................................................!57! 11.1.2.!Gestión!de!torneos!................................................................................................!58! 11.1.3.!Generación!de!torneos!........................................................................................!58! 11.1.4.!Asignación!de!pistas!.............................................................................................!58! 11.1.5.!Base!de!Datos!..........................................................................................................!58! 11.1.6.!Accesibilidad!y!optimización!............................................................................!59! 11.1.7.!Aportaciones!en!el!contexto!de!herramientas!de!gestión!de! competiciones!de!pádel!............................................................................................................!59! 11.2.!Conclusiones!................................................................................................................!59! !Trabajo!futuro!..........................................................................................................................!60!12. !Bibliografía!................................................................................................................................!61!13. 13.1.!Libros.!.............................................................................................................................!61! 13.2.!Web!..................................................................................................................................!61! !Anexos!.........................................................................................................................................!62!14. 14.1.!ANEXO!A:!Manual!de!usuario!...............................................................................!62! 14.2.!Anexo!B:!Guía!de!instalación!.................................................................................!64! 14.3.!Anexo!C:!Plantilla!de!casos!de!uso!......................................................................!65! 14.4.!Anexo!D:!Base!de!datos!...........................................................................................!73! ! Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!5! Índice'de'ilustraciones' Ilustración!1.!Paradigma!de!construcción!de!prototipos!................................................!15! Ilustración!2.!Ciclo!del!paradigma!de!construcción!de!prototipos!.............................!16! Ilustración!3.!Modelo!en!espiral!................................................................................................!17! Ilustración!4.!Casos!de!uso!del!usuario!anónimo!...............................................................!30! Ilustración!5.!Casos!de!uso!del!usuario!registrado!............................................................!31! Ilustración!6.!Casos!de!uso!del!usuario!administrador!...................................................!31! Ilustración!7.!Gestión!de!horarios!de!los!jugadores!..........................................................!35! Ilustración!8.!Listado!de!jugadores!..........................................................................................!35! Ilustración!9.!Configurador!de!competiciones!....................................................................!36! Ilustración!10.!Calendario!de!asignación!de!pistas!...........................................................!37! Ilustración!11.!Edición!de!pistas!................................................................................................!37! Ilustración!12.!Modelo!vista!controlador!..............................................................................!39! Ilustración!13.!Diseño!arquitectónico!.....................................................................................!40! Ilustración!14.!Ejemplo!de!registro!de!un!usuario!............................................................!41! Ilustración!15.!Esquema!de!la!base!de!datos!.......................................................................!42! Ilustración!16.!Detalle!de!almacenamiento!de!equipos!...................................................!42! Ilustración!17.!Detalle!de!almacenamiento!de!pistas!.......................................................!43! Ilustración!18.!Detalle!de!competiciones,!categorías!y!partidos!.................................!43! Ilustración!19.!Tabla!de!almacenamiento!de!!disponibilidad!.......................................!44! Ilustración!20.!Estructura!de!la!aplicación!...........................................................................!45! Ilustración!21.Ejemplo!de!diseño!de!la!aplicación!............................................................!47! Ilustración!22.!Modelo!vista!controlador!..............................................................................!48! Ilustración!23.!Estructura!de!Mojolicious!.............................................................................!48! Ilustración!24.!Diagrama!de!clases!...........................................................................................!49! Ilustración!25.!Diagrama!del!sistema!de!gestión................................................................!50! Ilustración!26.!Menú!superior!de!la!aplicación!...................................................................!52! Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!6! Índice'de'tablas' Tabla!1.!Identificación!de!actores!.............................................................................................!27! Tabla!2.!Tabla!de!jerarquías!........................................................................................................!27! Tabla!3.!Lista!actorbobjetivo!........................................................................................................!29! Tabla!4.!Resumen!de!los!casos!de!uso!.....................................................................................!30! Tabla!5.!Protocolo!RestFull!..........................................................................................................!50! Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!7! Introducción#1. A través de la experiencia en la organización de diversos torneos de pádel, se ha podido observar que la organización de estos eventos conlleva un gran gasto de tiempo, tendiendo éste a crecer en gran medida si se hace un especial énfasis en la organización del horario de forma que este se adecúe a las necesidades de todos los participantes del mismo. Con este proyecto se propone desarrollar una herramienta capaz de gestionar cualquier competición de pádel, así como la generación de las jornadas dependiendo de la disponibilidad de cada jugador. También abarca la gestión de los cambios de las jornadas y la gestión de los resultados obtenidos. El proyecto se plantea como un sistema integral de gestión para torneos de pádel. Pretende ser un lugar de encuentro entre jugadores, organizadores de torneos y clubes de pádel, facilitando en gran medida la gestión de cada uno de los actores. Este proyecto sirve igualmente para conocer todo el proceso necesario para aprender cómo gestionar y desarrollar un proyecto, desde la idea hasta su ejecución final, superando los obstáculos que se presentan durante el trayecto. Objetivos'2. Dentro de los objetivos del proyecto fin de carrera diferenciaremos dos. Los objetivos que queremos conseguir con el software y los objetivos relacionados con la adquisición de competencias con algunas herramientas que se emplean durante el desarrollo. 2.1. De'la'aplicación' El objetivo principal de este proyecto es el desarrollo de una aplicación web que permita la gestión de torneos de pádel. El proceso facilitará la gestión de cada uno de los roles participantes en el torneo. Por un lado a los organizadores del torneo se les facilita la generación de competiciones, permitiendo añadir las diferentes categorías y el formato de competición de cada una de ellas. Así mismo se facilita la selección de fechas de inscripción y del número máximo de inscritos. Por otro lado los jugadores tendrán una herramienta donde poder indicar su disponibilidad horaria para facilitar la generación de jornadas. Así mismo tendrán un lugar donde poder inscribirse en el torneo, introducir los resultados de los partidos y seguir la clasificación de las competiciones donde estén inscritos. Los objetivos del proyecto serían, por lo tanto: • Facilitar la inscripción de las parejas integrantes al torneo. Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!8! • Permitir a las parejas seleccionar su horario de disponibilidad para disputar los partidos. • Generar las jornadas basándose en los horarios definidos por las parejas y la disponibilidad del recinto de juego. • Permitir gestionar los cambios en las jornadas, pudiendo cambiar los horarios de los partidos. • Permitir añadir y validar los resultados de los partidos. • Generar automáticamente la clasificación. 2.2. Del'desarrollo' Existen una serie de objetivos para el desarrollo de la aplicación, entre los que destacan los siguientes • Uso de software libre. • Instalación y uso de un Servidor Web Hypnotoad. • Instalación y uso de servicios Rest sobre Hypnotoad. • Uso de frameworks de desarrollo basados en Perl (mojolicious). • Sistema de gestión de BBDD postgresql. • Uso de dbdesigner. • Plataformas de modelado, StarUml y ArgoUml. • Plataformas de desarrollo, Vim. Con el uso de software libre se persiguen dos objetivos. Disminuir los costes, debido al ahorro de uso de licencias de propietario y sacar ventaja de la comunidad de desarrolladores de proyectos de software libre. También hay que destacar que las herramientas que su uso están bastante contrastadas por su larga trayectoria como método de desarrollo de aplicaciones Web. Estructura'del'documento'3. Con el objetivo de facilitar la lectura del presente documento, se presenta en este apartado la estructura general del mismo. Tras haber realizado la introducción del proyecto y después de haber definido los objetivos del mismo, se explicarán cada una de las fases por las que ha pasado el proyecto. En primer lugar se presenta el estudio sobre el Estado del Arte y las herramientas existentes antes de comenzar el proyecto. A continuación, se explica la metodología utilizada durante la elaboración de la aplicación así como los recursos utilizados. En los siguientes apartados se detallan las fases de análisis, diseño y desarrollo del proyecto. Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!15! Lo ideal sería que el prototipo sirva como un mecanismo para identificar los requisitos del software. ' ! Ilustración,1.,Paradigma,de,construcción,de,prototipos! # # La construcción de prototipos nos aporta ciertas ventajas al tipo de proyecto que se está desarrollando: • El cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. • También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humanomáquina. # Aunque pueden surgir problemas, la construcción de prototipos ha demostrado ser un paradigma efectivo para la ingeniería del software. La clave es definir las reglas al comienzo, es decir, cliente y desarrollador se deben poner de acuerdo en las fases a seguir. La ilustración 2 muestra un ciclo normal para este paradigma.# # Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!16! ! Ilustración,2.,Ciclo,del,paradigma,de,construcción,de,prototipos! Dentro de cada fase se recogen los siguientes aspectos: # • Recolección y refinamiento de requisitos: requerimientos del usuario y software. • Diseño rápido: usa un modelo de desarrollo lineal y secuencial. • Construcción de prototipos: se implementa un prototipo y se hacen baterías de pruebas para comprobar el funcionamiento. • Evaluación del prototipo por el cliente: el cliente comprueba la evolución del proyecto para asegurarse que toma el camino adecuado. • Refinamiento del prototipo: con la información obtenida en las reuniones con el cliente realizamos los cambios pertinentes. • Producto de ingeniería: es el producto final, resultado del primer prototipo, del segundo, y así sucesivamente. ' El modelo en espiral, propuesto originalmente por Boehm [BOE88], es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema diseñado. La ilustración 3 muestra un modelo en espiral que contiene seis regiones de tareas: Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!17! ! Ilustración,3.,Modelo,en,espiral! ' ' • Comunicación con el cliente: se trata de las tareas requeridas para establecer comunicación entre el desarrollador y el cliente. • Planificación: las tareas requeridas para definir recursos, el tiempo y otra información relacionadas con el proyecto. • Análisis de riesgos: evaluación de riesgos técnicos y de gestión. • Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación. • Construcción y acción: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario, como documentación y práctica. • Evaluación del cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación. # El modelo en espiral utiliza la construcción de prototipos como mecanismo de reducción de riesgos, pero, lo que es más importante, permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del proyecto. Mantiene el enfoque sistemático de los pasos sugeridos por el ciclo de vida clásico, pero lo incorpora al marco de trabajo iterativo que refleja de forma más realista el mundo real [PRE03]. Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!18! El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software a gran escala. Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor antes los riesgos en cada uno de los niveles evolutivos. ' 5.2. Lenguaje'de'modelado' ' El lenguaje de modelado utilizado a lo largo del proyecto será UML o Lenguaje Unificado de Modelado. Permite expresar un modelo de análisis utilizando una notación de modelado con unas reglas sintácticas, semánticas y prácticas. Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un modelo del sistema, incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, además de aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables. Se emplea para definir un sistema, para detallar los artefactos en el mismo, para documentar y construir. UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, sólo se diagrama la realidad de una utilización en un requerimiento. La programación estructurada es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos es un complemento de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas. ' ' ' 5.3. Metodología'aplicada## ' El proyecto descrito en este documento se desarrollará en base a los modelos de proceso de software y el lenguaje de modelo indicado en los apartados precedentes. Para analizar y diseñar el sistema, se utilizarán los diagramas estándar establecidos por el Lenguaje Unificado de Modelado (UML). Entre estos diagramas destacan la identificación de actores, casos de uso, diagramas de clase y de secuencia. El desarrollo del software se llevará a cabo utilizando un Modelo de Proceso en Espiral apoyado en prototipos, es decir, éstos se desarrollarán como método de validación después de cada una de las fases descritas en el modelo, especialmente en análisis, diseño e implementación. 5.4. Planificación' La planificación que se realizó al comienzo del proyecto se muestra en la siguiente tabla: Fase Horas Análisis#de#requisitos 120 Análisis 200 Diseño#e#Implementación 490 Pruebas 135 Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!19! TOTAL 900 Se puede observar que en dicha planificación se estimó que aproximadamente un 35% del tiempo se emplearía en el análisis, más de la mitad en el desarrollo y aproximadamente un 15% en las pruebas. Sin embargo, el compatibilizar el desarrollo del proyecto con la jornada laboral del autor del trabajo, ha complicado la medición exacta de las horas dedicadas a cada una de las fases. A pesar de ello podemos afirmar que, en general, la estimación realizada se ha ajustado bastante a la realidad con dos salvedades: el tiempo dedicado a la fase de análisis ha sido superior al indicado mientras que el tiempo dedicado al desarrollo, debido a la experiencia del autor con el framework de desarrollo, ha sido menor. Recursos'necesarios''6. 6.1. Recursos'hardware' 6.1.1. Servidor#web# # Un servidor web no es más que un programa que se ejecuta de forma continua en un ordenador (también se utiliza el término para referirse al ordenador que lo ejecuta), manteniéndose a la espera de peticiones por parte de un cliente (un navegador de internet) y que contesta a estas peticiones de forma adecuada. Al tratarse de un servicio basado en Web, será primordial el tiempo de respuesta de la máquina a la hora de responder a las múltiples peticiones por parte de los usuarios del sistema. El servidor indicado deberá poseer al menos las siguientes características: # • Sistema de virtualización, deseable VirtualBox 5.1.14+. • Acceso a internet. 6.2. Recursos'software' 6.2.1. #Servicio#Hypnotoad# El servidor Hypnotoad es un servidor HTTP y WebSocket, preparado para la ejecución multihilos no bloqueantes, optimizado para equipos UNIX. Es el servidor de viene integrado en mojolicious y optimizado para Perl. 6.2.2. #Servicio#PostgreSQL#9#o#superior# Sistema de gestión de bases de datos relacional orientado a objetos y libre, publicado bajo licencia PostgreSQL, similar a las BSD o la MIT. 6.2.3. Mojolicious# Framework web en tiempo real basado en PERL que permite desarrollar aplicaciones web con estructura MVC de una manera sencilla. 6.2.4. Putty# Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!20! Cliente Telnet SSH. Es el cliente para la conexión desde Windows al servidor donde está alojada la aplicación. 6.2.5. Git# Git es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente. Al principio, Git se pensó como un motor de bajo nivel sobre el cual otros pudieran escribir la interfaz de usuario o front end como Cogito o StGIT. 3 Sin embargo, Git se ha convertido desde entonces en un sistema de control de versiones con funcionalidad plena. 6.2.6. Vim# Vi es un programa que entra en la categoría de los editores de texto, pues a diferencia de un procesador de texto no ofrece herramientas para determinar visualmente cómo quedará el documento impreso. Por esto carece de opciones como centrado o justificación de párrafos, pero permite mover, copiar, eliminar o insertar caracteres con mucha versatilidad. Este tipo de programas es frecuentemente utilizado por programadores para escribir código fuente de software. Vim es una versión mejorada del editor de texto vi, presente en todos los sistemas UNIX. Su autor, Bram Moolenaar, presentó la primera versión en 1991, fecha desde la que ha experimentado muchas mejoras. La principal característica tanto de Vim como de Vi consiste en que disponen de diferentes modos entre los que se alterna para realizar ciertas operaciones, lo que los diferencia de la mayoría de editores comunes, que tienen un solo modo en el que se introducen las órdenes mediante combinaciones de teclas o interfaces gráficas. 6.2.7. Psql# Es un programa de línea de órdenes para la administración de la base de datos PostgreSQL. Permite introducir queries SQL directamente, o ejecutarlas desde un fichero. Posee una serie de metaórdenes y varias características tipo Shell para facilitar escribir scripts y automatizar tareas. 6.2.8. pgAdmin# PgAdmin es una herramienta multilenguaje de administración PostgreSQL con interfaz gráfica. PgAdmin está escrito en C++ y puede ser ejecutado en los principales sistemas operativos. La herramienta incluye un lenguaje llamado pgScript para soporte administrativo y herramientas de desarrollo. 6.2.9. Sistema#operativo#Windows#10# Debido a la naturaleza del proyecto – aplicación web – se puede optar por cualquier sistema operativo. Sin embargo, debido a las aplicaciones y editores que se van a utilizar en el desarrollo se ha decidido utilizar un sistema operativo Windows, concretamente Windows 10 Professional. Windows 10 es la versión más reciente de Microsoft Windows, línea de sistemas operativos producida por Microsoft Corporation. Esta versión está diseñada para uso en PC, incluyendo equipos de escritorio en hogares y oficinas, equipos portátiles, tablet PC, Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!21! netbooks y equipos media center. El desarrollo de Windows 10 se completó el 29 de julio de 2015. Uno de los aspectos más importantes de Windows 10 es el enfoque en la armonización de experiencias de usuario y funcionalidad entre diferentes tipos de dispositivos, además de abordar las deficiencias en la interfaz de usuario de Windows que se introdujo por primera vez en Windows 8.# 6.2.10. Microsoft#Word#2010# Procesador de texto para la escritura de la memoria. Para la realización de la documentación se ha preferido el Microsoft Word 2010 en detrimento del procesador Latex, ya que éste se hace especialmente eficiente en la creación de libros técnicos donde abunden las expresiones matemáticas. No es el caso que nos ocupa y por tanto se ha seleccionado la opción de Microsoft. Microsoft Office 2010 es una versión de la suite ofimática Microsoft Office de Microsoft y sucesora de Microsoft Office 2007. Office 2010 incluye compatibilidad extendida para diversos formatos de archivos, actualizaciones de la interfaz de usuario y una experiencia de usuario refinada. Por primera vez y con la introducción de Office 2010, la suite está disponible en una compilación para arquitecturas de 64 bits. # 6.2.11. StarUML# La gran mayoría de los diagramas elaborados a lo largo de las diferentes fases del proyecto serán elaborados en el Lenguaje Unificado de Modelado UML, por lo que será necesario utilizar alguna herramienta de edición que permita trabajar de forma sencilla y rápida con este lenguaje. En concreto, se ha utilizado el software 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. 6.3. Tecnologías'utilizadas' 6.3.1. Perl# Perl es un lenguaje de programación diseñado por Larry Wall en 1987. Perl toma características del lenguaje C, del lenguaje interpretado bourne shell (sh), AWK, sed, Lisp y, en un grado inferior, de muchos otros lenguajes de programación. Estructuralmente, Perl está basado en un estilo de bloques como los del C o AWK, y fue ampliamente adoptado por su destreza en el procesado de texto y no tener ninguna de las limitaciones de los otros lenguajes de script. Perl es un lenguaje imperativo, con variables, expresiones, asignaciones, bloques de código delimitados por llaves, estructuras de control y subrutinas.# 6.3.2. PostgreSQL# Sistema de gestión de bases de datos relacional orientado a objetos y libre, publicado bajo licencia PostgreSQL, similar a las BSD (Berkeley Software Distribution) o la MIT (Massachusetts Institute of Technology). Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!22! Sus principales características son: alta concurrencia, amplia variedad de tipos nativos, posibilidad de crear tipos de datos propios, claves ajenas, triggers, vistas, integridad transaccional, herencia de tablas, tipos de datos y operaciones geométricas, soporte para transacciones distribuidas, funciones. Sus principales ventajas son: seguridad en términos generales, integridad en Base de datos: restricciones en el dominio, integridad referencial, afirmaciones (Assertions), disparadores (Triggers), autorizaciones, conexión a DBMS (DataBase Management System), transacciones y respaldos. 6.3.3. HTML# HTML (HyperText Markup Language) es el lenguaje de marcado predominante para la elaboración de páginas web. Es usado para describir la estructura y el contenido de un sitio web en forma de texto, así como para complementar el texto con objetos tales como imágenes. Además, puede describir la apariencia de un documento e incluir scripts como Javascript o elementos de maquetado como CSS. Este lenguaje será el utilizado para presentar los contenidos y herramientas al usuario en cada uno de los apartados que componen el sistema desarrollado.# 6.3.4. JavaScript# JavaScript es un lenguaje de programación interpretado, dialecto del estándar ECMAScript. Se define como orientado a objetos, basado en prototipos, imperativo, débilmente tipado y dinámico. Se utiliza principalmente en su forma del lado del cliente (client-side). En la fase de análisis y diseño, así como en los objetivos planteados, se ha recalcado la importancia de una interfaz tecnológicamente puntera que facilite al usuario trabajar con gran cantidad de datos en pantalla. Por tanto, es necesaria la utilización de un lenguaje de programación que se ejecutará en el cliente para que éstos tengan la responsabilidad de gestionar su propia interfaz. Por esta razón, se ha utilizado JavaScript para modificar “en caliente” el aspecto de la interfaz de usuario. 6.3.5. jQuery# jQuery es una biblioteca o framework de JavaScript, creada inicialmente por John Resig, 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. Fue presentada el 14 de enero de 2006 en el BarCamp NYC. jQuery es software libre y de código abierto, posee un doble licenciamiento bajo la Licencia MIT y la Licencia Pública General de GNU v2, permitiendo su uso en proyectos libres y privativos. jQuery, al igual que otras bibliotecas, ofrece una serie de funcionalidades basadas en JavaScript que de otra manera requerirían de mucho más código, es decir, con las funciones propias de esta biblioteca se logran grandes resultados en menos tiempo y espacio. Se han utilizado algunas librerías Jquery que han permitido conseguir grandes efectos (incluidos algunos fundamentales en la consecución de los objetivos) y que serán comentadas debidamente en el apartado de desarrollo de la memoria. 6.3.6. CSS# Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!23! CSS, del inglés Cascading Style Sheets, es un lenguaje usado para definir la presentación de un documento estructurado escrito en HTML, XML o XHTML. La idea principal que se encuentra detrás del desarrollo de CSS es separar la estructura de un documento de su presentación. De esta manera, se ha utilizado CSS para dar formato a cada uno de los documentos HTML desarrollados a través de sus etiquetas. Mediante esta tecnología, se facilita la presentación de contenidos y se ofrece una interfaz de usuario más accesible y clara. 6.3.7. AJAX# AJAX, acrónimo de Asynchronous JavaScript And XML, es una técnica de desarrollo web para crear aplicaciones interactivas. Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma, es posible realizar cambios sobre las páginas sin necesidad de recargarlas, lo que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones. En la aplicación que se ha desarrollado, se presenta en numerosas ocasiones la posibilidad de mostrar contenidos al usuario sin la necesidad de recargar la página al completo. De esta manera, se ha utilizado la tecnología AJAX para ofrecer servicios más interactivos y presentar información al usuario sin interrupciones. 6.3.8. Bootstrap# Bootstrap es un framework o conjunto de herramientas de código abierto para diseño de sitios y aplicaciones web. Contiene 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, extensiones de JavaScript opcionales adicionales. Bootstrap tiene un soporte relativamente completo para HTML5 y CSS 3, y es compatible con la mayoría de los navegadores web. La información básica de compatibilidad de sitios web o aplicaciones está disponible para todos los dispositivos y navegadores. Existe un concepto de compatibilidad parcial que hace disponible la información básica de un sitio web para todos los dispositivos y navegadores. Por ejemplo, las propiedades introducidas en CSS3 para las esquinas redondeadas, gradientes y sombras son usadas por Bootstrap a pesar de la falta de soporte de navegadores antiguos. Esto extiende la funcionalidad de la herramienta, pero no es requerida para su uso. Desde la versión 2.0 también soporta diseños sensibles. Esto significa que el diseño gráfico de la página se ajusta dinámicamente, tomando en cuenta las características del dispositivo usado (computadoras, tabletas, teléfonos móviles). Bootstrap es de código abierto y está disponible en GitHub. 6.3.9. DataTables# DataTables es un librería de la biblioteca jQuery – JavaScript. Es una herramienta muy flexible para el control de tablas HTML. De todas las características que ofrece, se destacan las siguientes:# • Paginación de longitud variable. • Ordenación por múltiples columnas. • Manejo inteligente de los anchos de columnas. • Totalmente personalizable. • Buscador dinámico. Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!24! 6.3.10. ApiRest# ApiRest es un estilo de arquitectura del software para sistemas WWW. Si bien el término REST se refería originalmente a un conjunto de principios de arquitectura — descritos más abajo—, en la actualidad se usa en el sentido más amplio para describir cualquier interfaz entre sistemas que utilice directamente HTTP para obtener datos o indicar la ejecución de operaciones sobre los datos, en cualquier formato (XML, JSON, etc) sin las abstracciones adicionales de los protocolos basados en patrones de intercambio de mensajes, como por ejemplo SOAP. Es posible diseñar sistemas de servicios web de acuerdo con el estilo arquitectónico REST de Fielding y también es posible diseñar interfaces XMLHTTP de acuerdo con el estilo de llamada a procedimiento remoto (RPC), pero sin usar SOAP. Estos dos usos diferentes del término REST causan cierta confusión en las discusiones técnicas, aunque RPC no es un ejemplo de REST. Los sistemas que siguen los principios REST se llaman con frecuencia RESTful. REST afirma que la web ha disfrutado de escalabilidad como resultado de una serie de diseños fundamentales clave: • Un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene toda la información necesaria para comprender la petición. Como resultado, ni el cliente ni el servidor necesitan recordar ningún estado de las comunicaciones entre mensajes. Sin embargo, en la práctica, muchas aplicaciones basadas en HTTP utilizan cookies y otros mecanismos para mantener el estado de la sesión (algunas de estas prácticas, como la reescritura de URLs, no son permitidas por REST) • Un conjunto de operaciones bien definidas que se aplican a todos los recursos de información: HTTP en sí define un conjunto pequeño de operaciones, las más importantes son POST, GET, PUT y DELETE. Con frecuencia estas operaciones se equiparan a las operaciones CRUD en bases de datos (CLAB en castellano: crear, leer, actualizar, borrar) que se requieren para la persistencia de datos, aunque POST no encaja exactamente en este esquema. • Una sintaxis universal para identificar los recursos. En un sistema REST, cada recurso es direccionable únicamente a través de su URI. • El uso de hipermedios, tanto para la información de la aplicación como para las transiciones de estado de la aplicación: la representación de este estado en un sistema REST son típicamente HTML o XML. Como resultado de esto, es posible navegar de un recurso REST a muchos otros, simplemente siguiendo enlaces sin requerir el uso de registros u otra infraestructura adicional. 6.3.11. Curl# cURL es un proyecto de software consistente en una biblioteca (libcurl) y un intérprete de órdenes (curl) orientado a la transferencia de archivos. Soporta los protocolos FTP, FTPS, HTTP, HTTPS, TFTP, SCP, SFTP, Telnet, DICT, FILE y LDAP, entre otros. La primera versión se publicó en 1997. cURL soporta certificados HTTPS, HTTP POST, HTTP PUT, subidas FTP, Kerberos, subidas mediante formulario HTTP, proxies, cookies, autenticación mediante usuario y contraseña (Basic, DIgest, NTLM y Negotiate para HTTP y kerberos 4 para FTP), continuación de transferencia de archivos, tunneling de proxy HTTP y otras prestaciones. cURL es Open Source, software libre distribuido bajo la Licencia MIT. El principal propósito y uso para cURL es automatizar transferencias de archivos o secuencias de operaciones no supervisadas. Es por ejemplo, una herramienta válida para simular las acciones de usuarios en un navegador web. Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!31! ! Ilustración,5.,Casos,de,uso,del,usuario,registrado! # Administrador La ilustración 6 muestra las opciones del sistema para el usuario administrador: # ! Ilustración,6.,Casos,de,uso,del,usuario,administrador! 7.2.8. Casos#de#uso#completos## Ya se han identificado los actores y definido mediante diagramas los casos de uso. Los diagramas dan una representación rápida del sistema, pero no aportan toda la Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!32! información sobre el caso de uso. Jacobson [JAC92] sugiere varias preguntas que se deberían contestar mediante un caso de uso. Estas preguntas se han extendido para proporcionar una visión más completa del contenido del caso de uso: • ¿Quién(es) es (son) el(los) actor(es) primario(s)? • ¿Cuáles son las metas del actor? • ¿Cuáles son las condiciones previas que deben existir antes de comenzar la historia? • ¿Cuáles son las tareas o funciones principales que realiza el actor? • ¿Qué excepciones podrían considerarse mientras se describe la historia? Para dar respuesta a todas estas cuestiones relativas a los casos de uso se utilizará una plantilla que se explica a continuación. ' Nombre APUNTARSE A UN CAMPEONATO ID 01 Creado por Josué Caballero López Fecha Modif. por Fecha Modif Actor Principal ANÓNIMO Personal involucrado Anónimo: Selecciona un campeonato y se apunta a él Administrador: Ve un nuevo jugador apuntado a su campeonato Descripción Un nuevo jugador se apunta a un campeonato Trigger Precondición Postcondición El jugador aparece en la lista de inscritos Flujo Normal 1. Rellena el formulario de los datos personales 2. El jugador se añade a la lista de inscritos Flujo alternativo Excepción El jugador ya está inscrito Se ha superado el número máximo de inscritos Includes Requisitos especiales Notas ' ID Dar a cada caso de uso un entero secuencial único identificativo. Alternativamente, se puede usar la forma jerárquica X.Y. Casos relacionados pueden agruparse jerárquicamente. Nombre Selecciona un nombre que sea lo más explicativo posible. Este ha de reflejar por sí mismo la tarea que el usuario necesita realizar. Creado por Identifica a la persona que ha creado el caso de uso. Fecha Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!33! Muestra la fecha de creación del caso de uso. Modificado por Identifica a la persona que ha modificado el caso de uso. Fecha modificación Muestra la fecha de modificación del caso de uso. Actor principal Especifica el actor principal que recurre a los servicios del sistema para cumplir un objetivo. Personal involucrado o intereses Esta lista es más importante y práctica de lo que podría parecer a primera vista. Sugiere y delimita qué es lo que debe hacer el sistema. Descripción Especifica una descripción resumida de las razones y el resultado del caso de uso. Trigger Identifica al evento que inicializo el caso de uso. Esto puede ser un evento externo o un evento del generado por el propio sistema, también puede ser el primer paso del flujo normal. Precondiciones Las precondiciones establecen lo que siempre debe cumplirse antes de comenzar un escenario de caso de uso. Las precondiciones no se prueban en el caso de uso, sino que son condiciones que se asumen que son verdad. Normalmente, una precondición implica un escenario de otro caso de uso que se ha completado con éxito. Por lo tanto, hay que listar cualquier actividad que debe tener lugar, o cualquier condición que debe ser cierta, antes de que el caso de uso pueda comenzar. Postcondiciones Las postcondiciones o garantías de éxito establecen qué debe cumplirse cuando el caso de uso se completa con éxito. La garantía debería satisfacer a todo el personal involucrado. Por lo tanto, las postcondiciones describen el estado del sistema tras la conclusión del caso de uso. Flujo normal Describe el camino de éxito típico que satisface los intereses del personal involucrado. Provee una descripción detallada de las acciones de usuario y las respuestas del sistema que tendrán lugar durante la ejecución normal del caso de uso. Esta secuencia llevará a la Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!34! consecución del caso de uso, alcanzando el objetivo deseado. La descripción se puede escribir como una respuesta a la hipotética pregunta, “¿Cómo hago para conseguir la tarea especificada en el caso de uso en cuestión?” Esto se consigue mejor mediante una lista de acciones realizadas por el actor, alternativamente con las respuestas ofrecidas por el sistema. Flujo alternativo o extensiones Las extensiones son muy importantes. Indican todos los otros escenarios o bifurcaciones, tanto de éxito como de fracaso. Por lo tanto, la combinación del flujo normal y del flujo alternativo deberían satisfacer “casi” todos los intereses del personal involucrado (de los usuarios). Excepciones Describe cualquier condición de error que pueda ocurrir durante la ejecución del caso de uso, y define como el sistema responde en estas situaciones. También describe como el sistema responde si la ejecución del caso de uso falla por alguna situación no controlada. Se ha de especificar si tras un error de este tipo se ha de realizar una vuelta atrás de las modificaciones que se estaban realizando, si finaliza parcialmente con un estado conocido, o si se deja en un estado indeterminado como resultado de la excepción. Includes Lista cualquier otro caso de uso que este incluido (“llamado”) por este caso de uso. Si aparece una funcionalidad común en múltiples casos de uso, esta puede convertirse en un caso de uso el cual pueda ser incluido por aquellos casos de uso que necesiten esa funcionalidad. Requisitos especiales Si un requisito no funcional, atributo de calidad o restricción se relaciona de manera específica con un caso de uso, se recoge en el caso de uso. Esto incluye cualidades tales como rendimiento, fiabilidad y facilidad de uso, y restricciones de diseño (a menudo, en dispositivos de entrada/salida) que son obligados o se consideran probables. Notas Lista cualquier comentario adicional sobre el caso de uso. Los casos de uso completos se encuentran de forma detallada en el anexo C de éste documento.' 7.3. Prototipos'de'validación' La realización de prototipos ayuda a identificar los requisitos y objetivos globales del software. Además, es la primera representación de la interfaz, lo que facilita la tarea de diseño. Por otra parte, ayuda al desarrollador a entender la interacción hombre-máquina, obteniendo así un mejor enfoque. El prototipo se pone a punto para satisfacer las Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!35! necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer. Con el fin de validar los actores y casos de uso, se han realizado una serie de prototipos de la aplicación antes de continuar con la siguiente fase del proyecto. En la ilustración 7 se muestra la gestión de horarios de los jugadores. Es similar en cuanto a su diseño a la gestión de horarios de pistas de pádel. ! Ilustración,7.,Gestión,de,horarios,de,los,jugadores La ilustración 8 muestra el listado de jugadores/usuarios registrados. Es la base común para mostrar listas de datos. ' ! Ilustración,8.,Listado,de,jugadores La ilustración 9 muestra la configuración de competiciones. Es el formato definido para insertar datos en el sistema mediante formularios. Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!36! # ! Ilustración,9.,Configurador,de,competiciones ' La ilustración 10 muestra el calendario para la asignación de pistas. # Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!37! ! Ilustración,10.,Calendario,de,asignación,de,pistas ' La ilustración 11 muestra el formulario de edición de pistas. ' ! Ilustración,11.,Edición,de,pistas, Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!38! Diseño''8. 8.1. Introducción' El diseño del software se encuentra en el núcleo técnico de la ingeniería del software y se aplica independientemente del modelo de diseño del software que se utilice. Una vez que se analizan y especifican los requisitos del software, el diseño es la primera de las tres actividades técnicas – diseño, generación de código y pruebas – que se requieren para construir y verificar el software. Cada actividad transforma la información de manera que dé lugar, por último, a un software validado. [PRE03]. En general, la actividad del diseño se refiere al establecimiento de las estructuras de datos, la arquitectura general del software, representaciones de la interfaz y algoritmos. Por tanto, el diseño debe contemplar todos los requisitos explícitos obtenidos en la fase de análisis, debe ser una guía que puedan leer y entender los que construyen el código y los que prueban y mantienen el software, debe proporcionar una idea completa de lo que es el software. El sistema desarrollado es una aplicación tipo web y la arquitectura será clienteservidor. Además, para diseñar dicha arquitectura se ha seleccionado el patrón MVC (Modelo, Vista, Controlador). 8.2. Arquitectura'ClienteUServidor'' ' La arquitectura cliente-servidor es un modelo para el desarrollo de sistemas de información en el que las transacciones se dividen en procesos independientes que cooperan entre sí para intercambiar información, servicios o recursos. Se denomina cliente al proceso que inicia el diálogo o solicita los recursos y servidor al proceso que responde a las solicitudes. En este modelo las aplicaciones se dividen de forma que el servidor contiene la parte que debe ser compartida por varios usuarios y en el cliente permanece sólo lo particular de cada usuario. Los clientes realizan funciones como: # • Manejar la interfaz de usuario. • Capturar y validar datos de entrada. • Generar consultas e informes sobre la base de datos. # El servidor realiza, entre otras, las siguientes funciones:# # • Controlar accesos concurrentes a bases de datos compartidas. • Enlaces de comunicaciones con otras redes de área local o extensa. # Entre las principales características de esta arquitectura se pueden destacar las siguientes: • El servidor presenta a todos sus clientes una interfaz única. • El cliente no necesita conocer la lógica del servidor, sólo su interfaz externa. Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!39! • El cliente no depende de la ubicación física del servidor, ni del tipo de equipo físico en el que se encuentra, ni de su sistema operativo. • Los cambios en el servidor implican pocos o ningún cambio en el cliente. # 8.3. Patrón'MVC'(Modelo'Vista'Controlador)'' Modelo Vista Controlador (MVC)- ilustración 12es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario y la lógica de control en tres componentes distintos: • Modelo: datos. • Vista: muestra la información del modelo al usuario. • Controlador: gestiona las entradas del usuario e implementa la lógica de la aplicación. # ! Ilustración,12.,Modelo,vista,controlador! # La Vista se presentará en un formato adecuado para que el usuario pueda interactuar con la misma. La interfaz de usuario, principalmente desarrollada en HTML, se encargará de presentar los contenidos de manera clara y accesible, obtenidos del Modelo. Cuando el usuario interactúa con la Vista haciendo clic en algún botón o realizando alguna acción, el Controlador recibirá la petición solicitada. Tras procesar la acción requerida, éste será el encargado de invocar peticiones al Modelo e incluso a la Vista. El Controlador está desarrollado en Perl, con lo que le permite comunicarse con la Vista y el Modelo, para modificarlos o actualizarlos. El Modelo es la representación específica de la información con la que opera el sistema. Consiste, principalmente, en las bases de datos en PostgreSQL que almacena toda la información de la aplicación. A ellas accede el Controlador para realizar modificaciones y actualizaciones y la Vista para obtener la información a presentar. 8.4. Diseño'arquitectónico' Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!40! El diseño arquitectónico consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario para guiar la construcción del software para un sistema de información. Para la realización del diseño arquitectónico se ha seguido el patrón Modelo-VistaControlador, junto con la arquitectura Cliente-Servidor que nos proporciona Mojolicious, ambas explicadas anteriormente. La ilustración 13 muestra el diseño arquitectónico general del proyecto. # Capa#de#presentación# Capa#de#negocio# Capa#de#datos# Ilustración,13.,Diseño,arquitectónico! La capa de presentación representa la interfaz de usuario, a través de la cual se interactúa con la aplicación. Contiene el código HTML de la página y se encuentra enlazado a las librerías JavaScript y a las hojas de estilo (CSS). Esta capa presenta el sistema al usuario, le comunica información y también la captura para poder transmitirla a la capa de negocio. La capa de negocio es donde residen los programas que se ejecutan. Se reciben peticiones del usuario y se envían respuestas tras el proceso. Se denomina capa de negocio porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación para recibir las solicitudes y presentar los resultados; y con la capa de datos para ejecutar programas y solicitar al gestor de la base de datos almacenar o recuperar información. Vista! HTML! Javascript! CSS! Controlador! Perl! PostgreSQL! Modelo! Perl! Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!47! ! Ilustración,21.Ejemplo,de,diseño,de,la,aplicación! En la parte superior se ha creado un menú con diferentes opciones según los roles del usuario. En función de los permisos podrá acceder a diferentes pantallas de la aplicación. Al ser una aplicación web, se ha añadido al menú la opción home, que será la pantalla principal de la aplicación para cualquier usuario que acceda a la web. Se ha categorizado los diferentes apartados de la aplicación en grupos y cada una de las opciones dentro de los grupos con un menú desplegable en pestañas. El diseño que se ha elegido permite mucha flexibilidad, ya que añadir nueva funcionalidad a la aplicación se realiza de una manera sencilla, insertando nuevos elementos en el menú superior. 8.8. Diagrama'de'clases' # Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Tal y como se ha indicado en anteriores apartados, se utilizará el patrón Modelo Vista Controlador. Para poder soportar la separación de la interfaz de usuario (Vista) de la lógica del programa (Controlador), se ha diseñado un diagrama de clases que permita abstraer la programación interna de Perl de los documentos de maquetación HTML. Además, deberá existir una serie de librerías separadas por módulos que permitan realizar acciones sobre la base de datos PostgreSQL (modelo). Éste esquema se muestra en la ilustración 22 # Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!48! ! Ilustración,22.,Modelo,vista,controlador! # Mojolicious posee una estructura de clases como se puede observar en la siguiente imagen: # ! Ilustración,23.,Estructura,de,Mojolicious! # Al crear una aplicación Mojolicious estos módulos son instalados automáticamente. La aplicación de pádel usa los varios plugins de la librería CPAN de Mojolicious. Entre ellos destacan el plugin de autorización y el de autenticación de la aplicación. También usa el módulo de acceso a la base de datos, de escritura en el Log y de rutas. El diagrama de clases queda como se ve a continuación: # Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!49! ! Ilustración,24.,Diagrama,de,clases! # Existen algunas clases que son usadas directamente por la aplicación para su uso base y que son heredadas por las demás clases. Un ejemplo claro es la librería PG, que es la que realiza la conexión a la base de datos. Esa clase es usada por la clase base Mojolicious, y por todas las demás que heredan de la clase base. La clase Routes es la encargada de determinar a qué controlador apunta cada una de las rutas del sistema. Dentro de la clase plugins se han utilizado el de autorización y el de autenticación. Autorización permite acceder a ciertas rutas según el rol del usuario, el de autenticación permite entrar o no a la aplicación. La aplicación define las clases propias dentro de la clase controller. Cuando se realiza la llamada al controlador, éste determina a que método de que clase está llamando.# 8.9. Diagramas'de'secuencia'' # Los diagramas de secuencia UML ofrecen una representación abreviada de la forma en la cual las acciones del usuario (los elementos dinámicos de un sistema que definen los casos de uso) colaboran con las clases de análisis (los elementos estructurales de un sistema que definen los diagramas de clases). [PRE03]. Para facilitar la comprensión del sistema, se muestra a continuación un ejemplo de diagrama de secuencia de la aplicación. 8.9.1. Sistema#de#gestión# ' La base de datos ha sido diseñada de forma que la gestión de los diferentes elementos se realice de manera similar. La gestión de usuarios, pistas, horarios, categorías y torneos sigue una estructura y lógica interna similar. Por esta razón, se presenta a continuación un diagrama de secuencia que representa el sistema de gestión. ' Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!50! ! Ilustración,25.,Diagrama,del,sistema,de,gestión! ' El usuario principal de la aplicación es el encargado de gestionar el torneo. El usuario interactúa con el sistema mediante el navegador web, aunque el framework permite la abstracción del cliente que use el usuario, permitiendo así que la aplicación sea multiplataforma. El navegador (FrontEnd) que está desarrollado en HTML, Bootstrap y Jquery solicita al backend mediante peticiones AJAX la información para poder mostrarla al usuario. Para las rutas se ha optado por un protocolo RestFull, cómo se muestra en la tabla 5. # ! Tabla,5.,Protocolo,RestFull! Así al realizar una llamada a la URL del objeto al que queremos acceder y según el verbo HTTP que usemos, el enrutador llamará al método del controlador que corresponda. En el caso concreto que mostramos en la ilustración 25 al llamar a la ruta con el verbo GET, llamaremos al método list, que es similar al index que se muestra en la tabla 5. El controlador hace la llamada al modelo, que realiza la consulta a la base de datos para obtener los elementos, estos elementos son devueltos al modelo, que después Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!51! de tratarlos, los entrega al controlador, que los envía al navegador en el formato solicitado. En la edición de los datos se pueden dar varios casos. Puede ocurrir que el navegador (cliente) tenga todos los datos para poder editar. En éste caso no hará falta realizar una llamada para mostrar el formulario al backend, será el código del frontend el que se encargue de realizar esa función. En otros casos es necesario obtener información del modelo de datos, por lo que se realizará la llamada AJAX correspondiente. Según como se ha definido en la tabla superior con el API REST, se realiza un llamada GET con el id del elemento que deseamos editar y añadimos /edit al final de la url. Para la actualización de datos se sigue el mismo procedimiento, pero en este caso con el verbo PUT y el id del elemento que se va a actualizar. El proceso para cada una de las acciones es bastante directo. Cuándo se desea añadir una acción sobre la aplicación, se debe tener en cuenta a que ruta de que controlador llamar, y respetar el protocolo RESt que se ha diseñado. Desarrollo'9. # En esta sección se procede a explicar la fase de implementación realizada para el proyecto. Se detallarán los aspectos más importantes de la interfaz, las clases externas utilizadas así como aquellas partes más importantes de las clases propias, tecnologías utilizadas, etc. La opción elegida para desarrollar la interfaz descrita en la fase de Diseño ha sido la utilización de una plantilla de bootstrap, a la que se ha añadido la funcionalidad necesaria para cubrir los requisitos expuestos en la fase de análisis. A esto se le ha añadido la librería jquery ya que facilita la implementación de la funcionalidad del DOM, y las llamadas al backend de la aplicación. La aplicación a desarrollar posee numerosa funcionalidad, y mucha dependencia de los requisitos de los usuarios. La aplicación debe ser flexible para ajustarse a los cambios de normativas. Por eso se ha optado por el uso de un framework, que mantenga la estructura de la aplicación, y que permita un mantenimiento sencillo. También facilita el desarrollo al poseer muchas herramientas ya incluidas en el propio framework, y aquellas que no están pueden añadirse a través de plugins de mojolicious, o perl. # El código fuente al completo se puede encontrar en el CD adjunto a la memoria. ' 9.1. Detalles'de'implementación'' 9.1.1. Introducción## # En este apartado se indican los aspectos más relevantes de la implementación. Se ha intentado separar en todo momento el modelo de la vista y el controlador, intentado que cada apartado sea independiente, permitiendo así una mayor flexibilidad en la aplicación. Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!52! 9.1.2. Estructura#interna#del#sistema# # Uno de los aspectos fundamentales de la aplicación es la organización de todas sus pantallas. Con el fin de agilizar todos los desarrollos de códigos, todas las herramientas siguen una misma estructura interna para cubrir las funcionalidades. La mayoría de la información puede presentarse de manera ordenada en forma de tabla siguiendo el patrón MVC. Las pantallas de equipos, usuarios, categorías, competiciones, disponibilidad de horario, etc., siguen la misma filosofía gracias a la organización de la base de datos. El sistema está organizado en controladores, plantillas (HTML), archivos estáticos (Javascript, Bootstrap), enrutador, controladores, modelos y tablas en la base de datos. Para conocer la relación entre ellos se muestra a continuación la lógica de la aplicación ante una petición de un listado de usuarios. En el menú superior el usuario solicita dentro de Admin, gestionar usuarios. # ! Ilustración,26.,Menú,superior,de,la,aplicación! # Al seleccionar la opción, se realiza una solicitud al enrutador a la ruta /users con un GET. # my $r_auth = $r->under->to('authentication#check')->name('authentication_check'); $r_auth->get('/users')->to('users#list'); # El fichero enrutador busca la ruta solicitada y comprueba que está dentro de las rutas que solicitan estar autenticado. Si el usuario ha realizado el login y tiene permiso, el enrutador llama al controlador users, y al método list. El controlador list realiza una llamada al modelo para obtener la lista de usuarios. El modelo realiza la consulta a la base de datos y responde al controlador. El controlador según el tipo MIME de la petición devolverá la respuesta en el formato solicitado:# # $self->respond_to( html => { user_document => (defined($self->session->{authenticated_user}))?$self->session->{authenticated_user}- >{document}:'', msg => 'List Users', users => \@users, }, json =>{json=> \@users} ); # Si el tipo mime solicitado es html se enviará junto con la lista de usuarios, el template (html) que se haya definido en el subdirectorio de templates correspondiente, en caso de que el tipo mime se json, se enviará la lista de usuario dentro de un objeto JSON. 9.1.3. Generar#competiciones# # Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!53! La generación de competiciones permite la generación del calendario de partidos de cada competición. Para llegar a ese punto se debía desarrollar mucha funcionalidad alrededor. Era necesaria una gestión de jugadores, de equipos, de competiciones, de categorías, de clubes y de pistas. Una vez se finalizó el desarrollo de la gestión de estos ítems, se debía generar los enfrentamientos entre los equipos, esto es, generar el calendario de partidos según el tipo de competición solicitada. Para la generación de competiciones existen dos algoritmos según sea round-robin o por eliminatoria. Uno de los algoritmos más usados para generar competiciones tipo liga, esto es, round-robin, es marcar un equipo como fijo, y pivotar el resto alrededor de él. De esta manera para generar un calendario de una competición round robin quedaría: Se crean un pivote y dos vectores de equipos, v1 y v2. Se genera la primera jornada: function primeraJornada(){ pivote = equipos[0]; for (i=1;i<equipos.length;i++){ if(i%2==0) v1.push(equipos[i]); else v2.push(equipos[i]); } }//primeraJornada Se rotan los equipos: function rotarEquipos(){ v2.unshift(v1.shift()); v1.push(v2.pop()); }//rotarEquipos # Y finalmente se generan el resto de las jornadas: function generarJornada(jornada){ pivote – v2[0] for( var i=1;i<v2.length;i++){ v1[i-1] vs v2[i] } }//generarJornada Una vez generadas todas las jornadas de la competición se permite al administrador que genere nuevas jornadas, hasta que estas quedan definitivas. 9.1.4. Heurística#para#la#asignación#de#pistas# # La asignación de pistas presentaba el mayor desafío del proyecto. Se debe tener en cuenta la disponibilidad de cada uno de los jugadores de cada equipo, de cada partido y la disponibilidad de pistas de cada club. Para ello la aplicación debe primero conocer cuál es la disponibilidad de cada jugador. Jugador 1 del equipo 1: lunes a viernes de 16:00 a 21:00 Jugador 2 del equipo 1: lunes a viernes de 18:00 a 21:00 Jugador 1 del equipo 2: martes a sábado de 16:00 a 21:00 Jugador 1 del equipo 2: lunes a domingo de 15:00 a 22:00 Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!54! Una vez conocida realiza una unión con la disponibilidad de sus compañeros de equipo, generando un vector de disponibilidades del equipo, con los jugadores más restrictivos. Equipo 1: lunes a viernes de 18:00 a 21:00 Equipo 2: martes a sábado de 16:00 a 21:00 Conocida la disponibilidad de cada equipo, debemos conocer la disponibilidad de cada partido y ver si es viable asignar una pista automáticamente, o se debe notificar a los jugadores que deben adaptarse. Partido 1: martes a viernes de 18:00 a 21:00 Una vez conocemos las disponibilidades de cada partido de la jornada, se ordenan de más restrictiva a menos restrictiva, y se busca la disponibilidad de pistas para ese equipo, asignando la hora en la que existan más pistas disponibles, si es posible. Pista 1: Martes de 19:30 a 21:00 Pista 2: martes de 18:00 a 21:00 Partido 1: Martes 19:30 en pista 1 Una vez finalizado la generación de la asignación, se informa al gestor del campeonato para que lo valide y publique el resultado. 9.2. Librerías'externas## 9.2.1. DataTables## DataTables es un librería de la biblioteca jQuery – JavaScript. Es una herramienta muy flexible para el control de tablas HTML. De todas las características que ofrece, se destacan las siguientes: # • Paginación de longitud variable. • Ordenación por múltiples columnas. • Manejo inteligente de los anchos de columnas. • Totalmente personalizable. • Buscador dinámico. # Para que este paquete funcione correctamente se necesita una serie de librerías y hojas de estilo. Las librerías se sitúan en la vista general de la aplicación. # <link#href="/css/jquery.dataTables.css"#rel="stylesheet"># <script#src="/js/jquery.js"></script># <script#src="/js/jquery.dataTables.min.js"></scrip># <script#src="/js/dataTables.tableTools.min.js"></script># <script#src="/js/jquery.dataTables.editable.js"></script># <script#src="/js/jquery.jeditable.js"></script># # Con las librerías incluidas adecuadamente, el siguiente paso es indicar a qué tabla del código HTML se le atribuye las características de la librería datatable: Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!55! $('#table_users').DataTable({# ######"data":data,# ######"columns":[# #########{title:#'Activo',#data:"active",#render:#function#(data){return#(data==1)?'<span# class="glyphicon#glyphiconsok"#ariashidden="true"></span>':'<span#class="glyphicon# glyphiconsremove"#ariashidden="true"></span>'}},# #########{title:#'Nombre',#data:"name"},# #########{title:#'Apellidos',#data:"surname"},# #########{title:#'DNI',#data:"document"},# #########{title:#'Email',#data:"email"},# #########{title:#'Tlf#1',#data:"phone"},# #########{title:#'Tlf#2',#data:"mobile"},# #########{title:#'Enviar#Email',#data:"user_id",#render:#function#(data){return#'<input# type="button"#value="Enviar#email"#onclick="validateUser(\''+data+'\')">'}},# ######],# ###});# # Datatable permite indicar en que variable vendrán los datos y cómo se define cada columna. Las columnas se pueden renderizar directamente, dónde data responde al campo del objeto JSON que se ha indicado en la tabla, o bien renderizar mediante una función específica.## 9.2.2. Bootstrap# # Bootstrap es un framework de desarrollo HTML, CSS y JS para el desarrollo de proyectos responsive en la web. # Para usarlo se debe añadir los ficheros css y javascript en el layout principal de la aplicación: # <link#href="/css/bootstrap.min.css"#rel="stylesheet"># <link#href="/css/fontsawesome.min.css"#rel="stylesheet"># <link#href="/css/prettyPhoto.css"#rel="stylesheet"># <link#href="/css/animate.css"#rel="stylesheet"># # <script#src="/js/bootstrap.min.js"></script># <script#src="/js/jquery.prettyPhoto.js"></script># # La inclusión de bootstrap al proyecto permite que el diseño de la aplicación sea común. Crea un formato general con una librería de componentes que resuelven gran parte del diseño de la aplicación. Pruebas'del'sistema'10. ! La realización de pruebas del sistema es una parte importante para la comprobación de que los requisitos están cubiertos. Para realizar las pruebas se ha solicitado a un gestor de torneos un listado de jugadores y disponibilidad de canchas para una liga que está organizando. En la temporada 2016/2017, en dicha liga hay un total de 2 grupos y 12 equipos por grupo. En las pruebas del sistema se han omitido los nombres por protección de datos. La disponibilidad de canchas queda como sigue: Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!56! Lunes: 1 cancha a las 17:00, otra a las 18:30 y una a las 21:00 Martes: 1 cancha a las 18:30, otra a las 20:00 y una a las 21:00 Miércoles: 1 cancha a las 18:30, otra a las 20:00 y una a las 21:00 Jueves: 1 cancha a las 17:00, otra a las 18:30 y una a las 21:00 Viernes: 1 cancha a las 17:00, otra a las 18:30, 2 a las 20:00 y una a las 21:00 La disponibilidad de los jugadores queda resumida en la siguiente tabla, donde cada fila se corresponde con las preferencias horarias de cada una de las parejas participantes: Preferencia'horarios' 1 Martes y jueves a partir de las 20:00. Viernes a partir de las 18:30. 2 Lunes a viernes a partir de las 19:00. 3 Lunes a viernes a partir de las 18:30. 4 Todos los días a partir de las 20:00 y sábados por la mañana 5 Lunes y miércoles desde las 18:30 hasta las 21:30 (hora max finalización del partido). Martes y viernes desde 16:00 hasta las 21:30 y fines de semana a partir de las 11:00. También por las mañanas. 6 Lunes a viernes a partir de las 18:00. 7 Lunes a viernes a partir de las 19:30. 8 Lunes a viernes a partir de las 19:30 9 Lunes a viernes a partir de las 17:00 y la última hora a la que pueden jugar es las 20:00. 10 Lunes a viernes a partir de las 20:00. 11 Lunes a viernes a partir de las 18:30. 12 Lunes a viernes a partir de las 20:30 y sábados a partir de las 14:00. 13 14 Lunes a viernes a partir de las 19:00 y sábados por la mañana. 15 Lunes a viernes a partir de las 16:00. 16 Lunes, miércoles y viernes a partir de las 19:00. 17 Trabaja en turno de tarde. 18 Lunes a viernes a partir de las 16:30. 19 Lunes a viernes a partir de las 18:00. 20 Lunes a viernes a partir de las 18:00 y algún fin de semana. 21 Miércoles y viernes a partir de las 18:00. Jueves a las 20:00. 22 Trabajan por turnos. Los viernes pueden a cualquier hora. Turno día: a partir de las 20:30. Turno noche: pueden terminar como muy tarde a las 20:30. 23 De lunes a viernes a partir de las 18:00. 24 Lunes a jueves a últimas hora de la tarde y los sábados por la mañana. Los resultados del algoritmo de generación automática de horarios se muestra a continuación: Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!63! Disponibilidad: Cada usuario puede gestionar su horario de disponibilidad. Se pueden tener más de un horario disponible. Administrar usuarios Los usuarios administradores tienen la opción de gestionar los usuarios desde el menú Admin. Gestión de instalaciones Los usuarios administradores tienen la opción de gestionar las instalaciones desde el menú Admin. Desde aquí se pueden añadir nuevos clubes, pistas e indicar la disponibilidad. Gestión de competiciones Desde el menú de campeonato se permite gestionar las competiciones. Es necesario añadir una fecha de inicio y de fin de la competición. Gestión de categorías Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!64! Desde el menú de campeonato se permite gestionar las categorías de cada competición. Es necesario añadir una fecha de inicio y de fin de la categoría. Configurar competiciones En el menú de campeonatos se permite configurar las competiciones. Aquí se determina cuantos puntos se da al ganador y cuantos al perdedor según el resultado de la competición. También se determina que tiene más valor en caso de empate. Ver inscritos Permite ver los inscritos en las diferentes categorías. Generar jornadas Una vez que la inscripción ha finalizado, el administrador del campeonato puede generar todas las jornadas de la misma. ! Generar horario Una vez generadas las jornadas, en el menú de jornadas se permite generar los horarios de cada partido y la asignación de canchas en caso de que sea posible. En este apartado es dónde los jugadores insertan los resultados al finalizar el partido. 14.2. Anexo'B:'Guía'de'instalación'' En el repositorio digital se encuentra el código del proyecto y una imagen de la máquina virtual donde se ha desarrollado. La manera más sencilla de instalación es usar una herramienta de virtualización como "VirtualBox" y cargar la imagen del proyecto, ya que están instalados todos los módulos necesarios de la máquina. En otro caso es necesaria una distribución linux para la instalación del proyecto. El primer paso es instalar el Framework Mojolicious con esta línea: $"sudo"'s"'curl"'L"cpanmin.us"|"perl"'"Mojolicious' Una vez que se haya instalado Mojolicious en el sistema, empezamos un nuevo proyecto: $"mojo"generate"Padel Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!65! En la carpeta Padel encontrará la estructura de directorios con la aplicación preconfigurada. Se cambian los ficheros existentes por el código que está en el repositorio general y ya tenemos la aplicación funcionando. El Framework mojolicious está bien documentado en: http://mojolicious.org/perldoc/Mojolicious ! 14.3. Anexo'C:'Plantilla'de'casos'de'uso'' Nombre APUNTARSE A UN CAMPEONATO ID 01 Creado por Josué Caballero López Fecha Modif. por Fecha Modif Actor Principal ANÓNIMO Personal involucrado Anónimo: Selecciona un campeonato y se apunta a él Administrador: Ve un nuevo jugador apuntado a su campeonato Descripción Un nuevo jugador se apunta a un campeonato Trigger Precondición Postcondición El jugador aparece en la lista de inscritos Flujo Normal 3. Rellena el formulario de los datos personales 4. El jugador se añade a la lista de inscritos Flujo alternativo Excepción El jugador ya está inscrito Se ha superado el número máximo de inscritos Includes Requisitos especiales Notas Nombre CREAR CAMPEONATOS ID 02 Creado por Josué Caballero López Fecha Modif. por Fecha Modif Actor Principal ADMINISTRADOR Personal involucrado Administrador: Crea un nuevo campeonato en el sistema Anónimo: Ve un nuevo campeonato en la lista Descripción Se genera un nuevo campeonato en el sistema Trigger Precondición Postcondición Se crea un nuevo campeonato Flujo Normal 1. El administrador inserta los datos del campeonato 2. El campeonato es visible para los usuarios Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre DAR DE ALTA CLUBES ID 03 Creado por Josué Caballero López Fecha 14/02/13 Modif. por Fecha Modif Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!66! Actor Principal ADMINISTRADOR Personal involucrado Administrador: Inserta un nuevo club en sistema Descripción Se añade un nuevo club para un administrador. Se insertan los detalles del club. Dirección, teléfono, correo, etc Trigger Precondición Postcondición Sobre el club creado se insertan los recursos de los que dispone cada campeonato Flujo Normal 1. El administrador inserta los datos del club Flujo alternativo 2. El administrador inserta el número de pistas que tiene disponible en el club Excepción Includes Requisitos especiales Notas Nombre DARSE DE BAJA DE UN CAMPEONATO ID 04 Creado por Josué Caballero López Fecha 14/02/13 Modif. por Fecha Modif Actor Principal USUARIO REGISTRADO Personal involucrado Usuario registrado: Se da de baja de un campeonato Descripción El usuario registrado deja de participar en un campeonato Trigger Precondición El campeonato no ha comenzado Postcondición Hay un hueco libre en la generación del calendario Flujo Normal 1. El usuario selecciona el campeonato en el que está inscrito 2. Indica que se quiere dar de baja del mismo Flujo alternativo 3. Indica la razón de baja del campeonato 4. Se informa al administrador de la baja y el motivo Excepción Includes Requisitos especiales Notas Nombre GENERAR HORARIOS ID 05 Creado por Josué Caballero López Fecha Modif. por Fecha Modif Actor Principal ADMINISTRADOR Personal involucrado Administrador: El Administrador da la orden de generación de los horarios. Anónimo: Ve los horarios de la siguiente jornada Descripción Se generan los horarios de una jornada en concreto Trigger Precondición Se ha generado el calendario del campeonato Postcondición Aparecen la jornada siguiente con su horario Flujo Normal 1. Se selecciona la jornada Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!67! 2. Se da la orden de generar el horario 3. Aparece el horario con sus incidencias Flujo alternativo Excepción No se puede generar el horario completo por falta de recursos o incompatibilidades entre equipos Includes Requisitos especiales Notas Nombre GENERAR INCIDENCIAS ID 06 Creado por Josué Caballero López Fecha 14/02/13 Modif. por Fecha Modif Actor Principal USUARIO REGISTRADO Personal involucrado Usuario registrado: Inserta una incidencia en el sistema Administrador: Gestiona la incidencia para dar una respuesta Descripción El usuario registrado desea indicar una incidencia como falta de cancha, incompatibilidad de horario, etc Trigger Precondición Postcondición Se muestra una incidencia en el listado del administrador Flujo Normal 5. Se selecciona el tipo de incidencia 6. Se envía 7. El administrador es notificado de la misma Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre GESTIONAR CAMBIOS EN EL CALENDARIO ID 07 Creado por Josué Caballero López Fecha 06/12/12 Modif. por Fecha Modif Actor Principal USUARIO REGISTRADO Personal involucrado Usuario registrado: El usuario puede modificar los fecha de su partido según la disponibilidad Usuario registrado: El resto de los usuarios implicado en el partido ve las modificaciones propuestas y actúan en consecuencia Descripción El usuario puede modificar su partido durante un periodo de tiempo antes del mimo Trigger Precondición Se ha generado el calendario provisional y está en periodo de cambios Postcondición Se informa a los participantes del cambio propuesto Flujo Normal 1. Se seleccionan el partido a modificar 2. Se observa la disponibilidad de pistas 3. Se selecciona una de las pistas vacías para jugar Flujo alternativo 3b. Se propone el nuevo horario 3c. Se indica en las observaciones donde se disputaría el partido Excepción Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!68! Includes Requisitos especiales Notas Nombre GESTIONAR INCIDENCIAS ID 08 Creado por Josué Caballero López Fecha 06/12/12 Modif. por Fecha Modif Actor Principal ADMINISTRADOR Personal involucrado Administrador: Ve el listado de incidencias y actua sobre las mismas Usuario registrado: Se notifica la respuesta del administrador Descripción El administrador da respuesta a la incidencia Trigger Precondición Postcondición La incidencia ha sido gestionada Flujo Normal 4. Se seleccionan la incidencia sobre la lista 5. Se envía una respuesta a la misma Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre INSERTAR RECURSOS ID 09 Creado por Josué Caballero López Fecha Modif. por Fecha Modif Actor Principal ADMINISTRADOR Personal involucrado Administrador: Inserta recursos al sistema (pistas). Descripción Se insertan y gestionan recursos de un campeonato Trigger Precondición Postcondición El campeonato tiene nuevos recursos Flujo Normal 1. Se selecciona el listado de recursos del campeonato 2. Se añade o modifica los recursos del campeonato 3. El sistema tiene en cuenta este cambio para asignación de horarios Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre INSERTAR Y EDITAR PREFERENCIAS DE HORARIO ID 10 Creado por Josué Caballero López Fecha Modif. por Fecha Modif Actor Principal USUARIO REGISTRADO Personal involucrado Usuario registrado: Puede modificar sus preferencias de horario Administrador: Ver las modificaciones y las tiene en cuenta para la Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!69! generación de horarios Descripción Se modifica las preferencias de horarios Trigger Precondición Postcondición Las preferencias de horarios han sido modificadas. El sistema las tiene en cuenta para la generación del horario. Flujo Normal 1. Se selecciona el horario actual 2. Se modifica a las nuevas preferencias Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre INTRODUCIR LOS RESULTADOS DE LA JORNADA ID 11 Creado por Josué Caballero López Fecha Modif. por Fecha Modif Actor Principal ADMINISTRADOR Personal involucrado Administrador: Modifica los resultados de la jornada Anónimo: Ve el resulta de cada jornada Descripción Se inserta los resultados de la jornada Trigger Precondición Postcondición Los resultados se almacenan en el sistema. Se calcula la nueva clasificación. Flujo Normal 1. Selecciona la jornada 2. Seleccionar el partido 3. Introducir marcador Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre INTRODUCIR RESULTADOS ID 12 Creado por Josué Caballero López Fecha Modif. por Fecha Modif Actor Principal USUARIO REGISTRADO Personal involucrado Usuario registrado: Introduce los resultado del partido que ha jugado Descripción Se muestra el resultado del partido Trigger Precondición El partido ha finalizado Postcondición Se abre un periodo de modificación y aceptación de resultado Flujo Normal 1. Se selecciona el partido disputado 2. Se introduce el resultado del mismo 3. El sistema informa al resto de los jugadores del partido del resultado introducido Flujo alternativo Excepción Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!70! Includes Requisitos especiales Notas Nombre LISTAR CAMPEONATOS Y FILTRARLOS ID 13 Creado por Josué Caballero López Fecha Modif. por Fecha Modif Actor Principal ANÓNIMO Personal involucrado Anónimo: Ve el listado de los campeonatos que han sido creados en el sistema Descripción Se muestran los campeonatos del sistema filtrados según condiciones Trigger Precondición Postcondición El sistema lista los campeonatos Flujo Normal 4. Se selecciona la lista de campeonatos 5. Se muestran los campeonatos filtrados por condiciones de los mismos Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre MODIFICAR HORARIOS ID 14 Creado por Josué Caballero López Fecha 06/12/12 Modif. por Fecha Modif Actor Principal ADMINISTRADOR Personal involucrado Administrador: Modifica los horarios generados por el sistema Anónimo: Ve la jornada con los horarios modificados Descripción Se modifican los horarios generados Trigger Precondición El horario ha sido generado Postcondición Se muestra el nuevo horario de la jornada Flujo Normal 1. Se selecciona la jornada 2. Se muestra el horario seleccionado 3. Se realizan las modificaciones 4. Se almacena el nuevo horario de la jornada Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre REGISTRARSE EN EL SISTEMA ID 15 Creado por Josué Caballero López Fecha 06/12/12 Modif. por Fecha Modif Actor Principal ANÓNIMO Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!71! Personal involucrado Anónimo: Inserta sus datos personales, preferencias horarias y categoría Descripción El usuario se registra en el sistema Trigger Precondición Postcondición El usuario está registrado. Puede entrar en su área personal Flujo Normal 1. Se selecciona registrarse 2. Se introduce sus datos personales y categoría 3. Se introduce sus preferencias horarias Flujo alternativo 1a. Se inscribe en un campeonato Excepción Includes Requisitos especiales Notas Nombre VALIDAR RESULTADOS ID 16 Creado por Josué Caballero López Fecha 06/12/12 Modif. por Fecha Modif Actor Principal USUARIO REGISTRADO Personal involucrado Usuario registrado: Valida el resultado del partido Descripción El usuario valida el resultado del partido introducido por otro jugador Trigger Precondición El resultado del partido disputado ha sido introducido Postcondición El resultado se da por válido y cerrado Flujo Normal 1. Se selecciona el partido jugado 2. Se valida el resultado introducido Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre VER CALENDARIO DE UN CAMPEONATO ID 17 Creado por Josué Caballero López Fecha 06/12/12 Modif. por Fecha Modif Actor Principal ANÓNIMO Personal involucrado Anónimo: Ve el calendario del campeonato jornada por jornada y lugar Descripción Se muestra el calendario y lugar de los partidos de un campeonato Trigger Precondición Postcondición Flujo Normal 1. Selecciona el campeonato que desea ver 2. Se muestra el detalle por jornada Flujo alternativo Excepción Includes Requisitos especiales Universidad!de!Las!Palmas!de!Gran!Canaria! ! ! !Josué!Caballero!López!!!!!72! Notas Nombre VER CALENDARIO DE LOS CAMPEONATOS EN LOS QUE PARTICIPA ID 18 Creado por Josué Caballero López Fecha 06/12/12 Modif. por Fecha Modif Actor Principal USUARIO REGISTRADO Personal involucrado Usuario registrado: Lista sus campeonatos Descripción Ve los campeonatos en los que participa filtrados Trigger Precondición Postcondición Flujo Normal 1. Se introduce en su área personal 2. Muestra sus campeonatos activos y finalizados Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre VER NOTICIAS ID 19 Creado por Josué Caballero López Fecha 06/12/12 Modif. por Fecha Modif Actor Principal ANÓNIMO Personal involucrado Anónimo: Ve noticias genéricas sobre la aplicación y sobre campeonatos Descripción Se muestran noticias en la welcome page de la aplicación Trigger Precondición Postcondición Flujo Normal 1. Entra en la página de la aplicación 2. Ve noticias sobre la aplicación o sobre campeonatos específicos Flujo alternativo Excepción Includes Requisitos especiales Notas Nombre VER RESULTADOS POR JORNADA ID 20 Creado por Josué Caballero López Fecha Modif. por Fecha Modif Actor Principal ANÓNIMO Personal involucrado Anónimo: Ve resultados por jornada Descripción El anónimo puede ver resultados actuales y pasados de un campeonato jornada a jornada Trigger Precondición