INDICE 1 LA EMPRESA 1.1 ESTUDIO DEL CLIENTE 1.2 PROGRAMA DE NECESIDADES 2 PLANIFICACIÓN 2.1 METODOLOGIA DE TRABAJO 2.2 PLANING Y FASES DE DESARROLLO 3 ESTUDIO Y ANALISIS FUNCIONAL 3.1 ANALISIS DE TAREAS 4 ARQUITECTURA DE LA APLICACIÓN 4.1 MVC 4.2 SERVIDOR Y CONEXIONES 4.3 ESTRUCTURA DE LA APLICACIÓN 5 MODELO 5.1 CONSULTA DE DATOS 5.2 BASE DE DATOS 6 VISTA 6.1 FRONT-END PUBLICA 6.2 FRONT-END PRIVADA 7 CONTROLADOR 8 BIBLIOGRAFIA Y MATERIAL GRÁFICO
1 LA EMPRESA 1.1 Estudio del cliente Se trata de una aplicación para la gestión integral de la liga de f7 del Rayo Majadahonda CF que se celebra anualmente en las instalaciones municipales de la oliva (Majadahonda) y que cuenta con más de 1.000 participantes repartidos en 72 equipos. El campeonato cuenta con 4 divisiones y 6 grupos en total. El campeonato dura 10 meses durante los cuales se celebran 3 torneos diferentes, Apertura, Clausura y Copa. Al final de cada campeonato se realizan ascensos y descensos entre los diferentes grupos. Todo esto se acompaña con 2 torneos más adicionales por temporada, uno a nivel colectivo denominado Trofeo a la Deportividad y otro a nivel individual que es el Trofeo Pichichi. Al finalizar el torneo Clausura se disputa el campeonato de copa en el cual los 72 equipos son repartidos en 3 grupos y disputan partidos a eliminatoria directa hasta que solo queden 3 campeones. Cada uno recibe un trofeo al final del torneo y son invitados a un torneo nacional que se celebra cada año en San Sebastián al que acuden equipos de toda España. 1.2 Programa de necesidades Actualmente todo el control se realiza a través de una hoja programada de Excel y la idea de la aplicación es crear una plataforma unificada para la gestión de la liga y consulta de los datos actualizados por parte de los participantes de la liga. La gestión de este torneo requiere de una compleja aplicación para gestionar todas las situaciones habituales que suceden en la competición: control de goleadores, sanciones, amonestaciones, clasificaciones Aparte debe poder ser consultada de manera rápida y clara por una gran cantidad de usuarios de diferentes niveles de conocimientos informáticos. Las principales funciones deben ser: 1. Mostrar clasificaciones de cada grupo actualizadas a la ultima jornada disputada. 2. Posibilidad de visualizar el ranking de goleadores divididos por grupos 3. Mostrar los jugadores sancionados para la jornada siguiente. 4. Ranking en el torneo a la deportividad. 5. Un panel de administración desde el cual se pueda gestionar todos los datos necesarios para el correcto funcionamiento de la liga.
2 PLANIFICACIÓN 2.1. Metodología de trabajo la metodología que empleada para el desarrollo del proyecto es el diseño centrado en el usuario (DCU). El diseño centrado en el Usuario DCU es una metodología de trabajo de diseño de interfaces basadas en la investigación y participación de quienes serán los usuarios finales de la aplicación. El DCU no solo evalúa las soluciones de diseño a partir de usuarios para que las interfaces se adapten a ellos, sino que también analiza el valor del producto que se pretende crear, y su capacidad para resolver necesidades reales. Que es el diseño centrado en el usuario? El diseño centrado en el usuario es una aproximación al diseño de productos y aplicaciones que sitúa al usuario en el centro de todo el proceso. Así podemos entender el DCU como una filosofía cuya premisa es que, para garantizar el éxito de un producto, hay que tener en cuenta al usuario en todas las fases del diseño. Además, también podemos entender el DCU como metodología de desarrollo: una forma de planificar los proyectos y un conjunto de métodos que se pueden utilizar en cada una de las principales fases del desarrollo de la aplicación. 2.2 Planing y fases de desarrollo. Se plantea el desarrollo de la aplicación en dos fases. La primera fase englobaría el despliegue de la aplicación publica de consulta de datos por parte de los participantes del campeonato, así como su gestión desde el panel de administración de los datos. Y un segunda fase en la que se actualizaría la aplicación publica con la posibilidad de realizar las inscripciones de nuevos jugadores y la posibilidad de visualizar la web desde dispositivos móviles (Responsive Design). Este proyecto corresponde al despliegue de la primera fase descrita en el párrafo anterior.
3 ESTUDIO Y ANALISIS FUNCIONAL 3.1 análisis de tareas El objetivo es definir de una forma clara y sencilla las tareas que se van a realizar, y los factores necesarios para llevarlas a cabo. Las principales tareas que debe realizar la aplicación son los siguientes: Carga de resultados de los 36 partidos de cada una de las 11 jornadas que conforman cada uno de los torneos que se celebran (Apertura y Clausura). (privada) Asignación de puntos conforme a los resultados almacenados. (privada) Pintado de las clasificaciones actualizadas conforme a los resultados introducidos. (publica) Introducción de goleadores por cada partido disputado. (privada) Pintado de los ranking de goleadores. (publica) Asignación de sancionados de cada jornada. (privada) Pintado de las sanciones individuales o colectivas (publica) Introducción de puntos por equipos para el torneo a la deportividad. Pintado del ranking del trofeo a la deportividad (publica) Explicaciones de las diferentes tareas. Tarea1: Desde el panel de administración se solicita mediante un formulario sencillo la búsqueda de los partidos para un torneo y jornada determinada. Por medio de AJAX recibimos la respuesta del servlet encargado de atacar la BD con la consulta. Este mismo servlet responde pintando el listado en la misma pagina que realiza la consulta sin volver a recargar toda la web. Tarea2: Esta tarea arranca a petición del servlet encargado de guardar los resultados introducidos en el apartado anterior. Esta función evalúa el resultado introducido en cada partido y asigna puntuaciones a los diferentes equipos siguiendo las instrucciones dadas (Reglamento Deportivo). Tarea3: Esta tarea es cargada en el momento que el usuario accede a la aplicación web. Mediante un archivo JSP se realiza una búsqueda en la base de datos y se muestra el resultado ordenado por grupos, puntos, diferencial de goles y goles a favor. Esta función es automática y no requiere de acción por el usuario. Se accede desde la parte publica de la web aplication. Tarea4: Esta tarea es accesible desde el panel de administración. El funcionamiento es similar al de la introducción de resultados descrita en la primera tarea. Mediante un formulario
sencillo se cargan los resultados de una jornada en concreto. Una vez cargados es posible ir añadiendo los goleadores correspondientes a cada partido. La estructura de esta función si es más compleja. Cada vez que se asigna un goleador se realiza un búsqueda de los jugadores que componen el equipo para mostrar un desplegable donde poder hacer la selección del jugador en cuestión. Disponemos de un espacio para apuntar la cantidad de goles de ese jugador. Todo el sistema de agregar goleadores está implementado con JavaScript y AJAX. Una vez concluida la introducción de datos un servlet procesa la información y almacena los datos en un tabla correspondiente. Tarea5: Esta tarea se ejecuta de manera automática a la hora de acceder a la parte publica. Se realiza una búsqueda en la base de datos y se muestran los resultados por medio de un JSP. Estos resultados se muestran ordenados por grupos y por cantidad de goles. Tarea6: Esta función de la parte privada de la web tiene acceso desde el panel de administración. Mediante un formulario sencillo usando AJAX se introducen los datos solicitados y se procesa una petición de inserción en la base de datos correspondiente sin necesidad de refrescar la pagina de entrada de datos. Tarea7: Al igual que el resto de funciones de la web publica, esta tarea se ejecuta automáticamente al acceder a la parte publica de la aplicación y muestra separada por grupos todas las sanciones individuales. Es un simple JSP que realiza un búsqueda en la base de datos y pinta un tabla en la que se muestran los jugadores pendientes de cumplir una sanción. Tarea8: Esta tarea permite la introducción de puntos por equipos para realizar el ranking de deportividad. El funcionamiento es el mismo que la tarea de introducción de resultados descrito en la primera tarea con la excepción que el servlet encargado de recibir los datos procesa y almacena los resultados en su tabla correspondiente dentro de la base de datos. Tarea9: Esta función, al igual que el resto de las tareas de la web publica se inicia de manera autónoma una vez que el usuario accede mediante su navegador a la aplicación web. El funcionamiento es simple, muestra el resultado de una petición de búsqueda realzada a la base de datos donde muestra un ranking general y los tres primeros clasificados de manera destacada.
4 ARQUITECTURA DE LA APLICACION 4.1 MVC (Modelo Vista Controlador) El patrón de arquitectura MVC (modelo) es un patrón que define la organización independiente del Modelo (datos de la aplicación), la Vista (interfaz con el usuario) y el Controlador (la lógica de control de la aplicación) El patrón que utilizado para el desarrollo de esta aplicación es de de MVC. Ya que este patrón de arquitectura de software separa los datos y la lógica de una aplicación, de la interfaz de usuario. Como he citado anteriormente este patrón nos propone la creación de 3 componentes distintos con sus funciones muy marcadas: el modelo (los datos), la vista (el Front-End o interfaz) y el controlador (la capa negocio o lógica de la aplicación). De esta forma este patrón se basa en las ideas de reutilización de código y la separación de conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento. Para entender como funciona este patrón, se debe entender la división a través del conjunto de estos tres elementos y como estos componentes se comunican entre si, los unos con los otros y con otros externos al modulo principal. Por tanto es necesario saber que el controlados interpreta las entradas que el usuario manda mediante la introducción enviando ejecución de una acción al modelo y a la vista para que procedan a realizar los cambios oportunos. 4.2 Servidor y conexiones. La aplicación esta montada sobre un servidor que permite tecnología J2EE. El servidor de web que monta es Apache TomCat 8. El fichero raíz de la app es un index.jsp el cual es el encargado de iniciar la aplicación. Las conexiones necesarias para la aplicación se ejecutan desde archivos JSP incluidos dentro del archivo raíz y mediante servlets incluidos dentro del mapeado de la aplicación (web.xml). todas estas conexiones se comunican con una base de datos MySQL alojada en el mismo servidor que contiene todos los datos de la app. 4.3 Estructura de la aplicación La estructura de la aplicación consta de dos partes diferenciadas: PUBLICA: dispone de una página JSP diseñada como un SIMPLE WEB APLICATION donde se muestra toda la información ofrecida al usuario de la app. Carga una única vez toda la información y navegamos por ella sin necesidad de refrescar la url. Nos apoyamos en el uso de librerías propias JSP que alivian la carga de código dentro del archivo index.jsp PRIVADA: compuesta por varias paginas jsp, cada una con sus funciones correspondientes y vinculadas con la lógica de la aplicación.
5 MODELO el modelo es la representación de la información con la cual el sistema opera, por tanto gestiona todos los accesos a dicha información, tanto consultas como actualizaciones, implementando también los privilegios de acceso que se hayan descrito en las especificaciones de la aplicación(datos de la app). Envía a la vista aquella parte de la información que en cada momento se le solicita para que sea mostrada (típicamente a un usuario). Las peticiones de acceso o manipulación llegan al modelo a través de el controlador. 5.1. Consulta de los datos Todas las consultas de datos se realizan mediante ficheros JSP y SERVLETS que atacan la base de datos MySQL obteniendo los datos necesarios. Una vez tenemos los datos, los propios archivos JSP y Servlets pintan en la vista la información solicitada. 5.2 Base de datos Estructura de la Base de Datos:
6 VISTA Presenta el modelo (información y datos de la app) en un formato adecuado para interactuar, por tanto requiere de dicho modelo la información que debe representar como salida. Es decir, es la presentación del modelo. Puede acceder al modelo pero nunca cambiar su estado. 6.1 FRONT-END pública (interfaz pública)
6.2 FRONT-END privada (interfaz privada)
7 CONTROLADOR Responde a eventos (usualmente acciones del usuario) e invoca al modelo cuando se hace alguna solicitud sobre la información (por ejemplo, editar un documento o un registro en una base de datos). También puede enviar comando a su vista asociada si se solicita un cambio en la forma en que se presenta su modelo, por tanto se podría decir que el controlador hace de intermediario entre la vista y el modelo. 8.1 tecnologías utilizadas las tecnologías utilizadas en este proyecto son: HTML5, CSS3, y javascript Librería jquery MySQL AJAX JAVA EE JSP y Servlets HTML5, CSS3 y JAVASCRIPT HTML: utilizado para toda la estructura de la aplicación CSS3: toda la apariencia de la aplicación JavaScript: motor secundario de la aplicación. Solicita acciones a los servlet o ejecuta funciones propias de la librería jquery y AJAX. MySQL: base de datos de la aplicación, libre, segura y soportada por el servidor donde se hospeda la aplicación. JAVA EE: es el lenguaje utilizado por toda la aplicación. Soportado por el servidor de aplicaciones y el servidor web que monta el Server donde se hospeda la aplicación. JSP y Servlets: es la tecnología utilizada que gestiona la dinámica de la aplicación. Es el encargado de hacer todas las peticiones a la base de datos de la aplicación, trabajando en la parte del servidor, maneja y controla todas las funciones de la aplicación.
8 BIBLIOGRAFIA Y MATERIAL GRÁFICO El escudo utilizado es propiedad del Rayo Majadahonda Club de Futbol y tengo permiso expreso del presidente de la entidad D. Enrique Vedia Pesquera para utilizarlo en este proyecto. Los datos facilitados en la base de datos pertenecen a personas reales que participan en la competición. No se incluye ningún dato más amparándose en la Ley de Protección de Datos. Todo el material gráfico es de libre uso con propósitos no comerciales. Como el proyecto tratado es un proyecto docente y no existe animo de lucro no encuentro impedimento. Para el front-end público se ha utilizado un plugin gratuito basado en jquery llamado hero-slider propiedad de Claudia Romano (https://codyhouse.co/gem/hero-slider) Referencias de procedencia de las imágenes utilizadas: http://insider.ticketmaster.com http://fifa.com http://w3schools.com http://jquery.com http://kuler.adobe.com/es/create/color-wheel http://f7majadahonda.org http://tomcat.apache.org https://docs.oracle.com/javase/7/docs/api https://commons.apache.org