ANALISIS Y MODELO ARQUITECTONICO DE DATOS PARA UN SISTEMA DE INFORMACION DE TORNEOS DE FUTBOL JUAN DIEGO MESA PAREJA

Transcripción

1 ANALISIS Y MODELO ARQUITECTONICO DE DATOS PARA UN SISTEMA DE INFORMACION DE TORNEOS DE FUTBOL JUAN DIEGO MESA PAREJA Asesor: Ingeniero Wilder Perdomo Charry Magister en Gestión Tecnológica, Ingeniero de sistemas UNIVERSIDAD DE SAN BUENAVENTURA SECCIONAL MEDELLÍN FACULTAD DE INGENIERÍAS INGENIERIA SISTEMAS MEDELLIN 2012

2 RESUMEN: El siguiente trabajo plantea la manera de desarrollar un análisis de datos para una arquitectura estructurada y modelo de datos para realizar desarrollos sin la necesidad de crear modelados nuevos o realizar nuevos análisis de requerimientos. Se presenta toda una arquitectura de datos basada en metodología UML presentado diseño de base de datos MYSQL y prototipo desarrollado en leguaje PHP para demostrar el funcionamiento de todo el análisis y modelado arquitectónico de datos implementado en este trabajo PALABRAS CLAVES: Sistemas de información, Análisis de requerimientos, arquitectura de datos, diseño base de datos. GRUPO INVESTIGACION: Ingeniería de Software. LINEA INVESTIGACION: Ingeniería de Software. AREA: Análisis, modelado, diseño e implementación de software. TEMA:Análisis y modelo arquitectónico de datos para un sistema de información.

3 ANALISIS Y MODELO ARQUITECTONICO DE DATOS PARA SISTEMA DE INFORMACION DE TORNEOS DE FUTBOL JUAN DIEGO MESA PAREJA Proyecto presentado para optar al título de ingeniero de sistemas Asesor: Ingeniero Wilder Perdomo Charry Magister en Gestión Tecnológica, Ingeniero de sistemas UNIVERSIDAD DE SAN BUENAVENTURA SECCIONAL MEDELLÍN FACULTAD DE INGENIERÍAS INGENIERIA DE SISTEMAS MEDELLIN 2012

4 Nota de aceptación

5 Firma del jurado Firma del jurado Medellín, 11de enero de 2013

6 DEDICATORIA Dedicatoria a todas aquellas personas que velaron por el aprendizaje en todo el transcurso de mi carrera, como lo fueron profesores, compañeros de estudio, familiares y personas de la universidad de san buenaventura seccional Medellín por el apoyo en momentos de dudas y equivocaciones personales.

7 AGRADECIMIENTOS Agradezco ala universidad de son buenaventura como institución por enseñar los valores y temáticas aprendidas durante este periodo académico. Agradezco a los profesores que se encargaron de enseñar y luchar por que fuera cada día mejor como persona y como ingeniero de sistemas. Agradezco a todos los trabajadores administrativos de la universidad de san buenaventura por ayudarme a resolver dudas en los momentos de inquietudes durante todo el periodo de estudio. Agradezco a mi familia por su apoyo en todo momento y sabiendo que con su esfuerzo y dedicación ayudarían a que fuera un excelenteingeniero de sistemas.

8 Contenido 1. JUSTIFICACION PLANTEAMIENTO DEL PROBLEMA OBJETIVO GENERAL OBJETIVOS ESPECIFICOS MARCO REFERENCIAL MARCO TEORICO METOLOGIAS DE DESARROLLO DE SOFTWARE UML Diagramas UML Proceso de desarrollo Diseño de base de datos, modelización conceptual de datos Funciones básicas de un torneo de futbol Caracterización de la información manejada por un torneo de futbol Caracterización de usuarios Estado del arte DISEÑO METODOLOGICO PRELIMINAR CRONOGRAMA PRESUPUESTO ANALISIS Y MODELO ARQUITECTONICO DE DATOS PARA SISTEMA DE INFORMACION DE TORNEOS DE FUTBOL REQUERIMIENTOS (Descripción de necesidades para desarrollo de proyecto) ANALISIS (Transformación de requisitos en un diseño del sistema) Definición módulos de desarrollo (clasificación de requisitos por módulo de desarrollo) Requisitos de información (Funcional, no funcional) Definición de Actores Matriz de rastreabilidad objetivos- requisitos de información

9 9.3 Definición de diagramas UML (Un diagrama es la representación gráfica de un conjunto de elementos con sus relaciones) Diagrama de casos de uso (representación de casos de uso, esto está diciendo lo que tiene que hacer un sistema y como) Diagrama de Clases y objetos (muestra un conjunto de clases, interfaces y relaciones) Diagramas de Secuencia (comportamiento dinámico del sistema Diagramas de Estados (comportamiento dinámico del sistema) Diagrama de Paquetes (comportamiento dinámico del sistema) Diagrama de Componentes (implementación del sistema) Diagrama Despliegue Diseño conceptual Base de datos (Describir la información de la base de datos) Definición de Entidades Definición de Atributos por Entidad: Descripción de Entidades y Atributos: Diseño lógico Base de Datos Definición de relaciones: Modelo Entidad- Relación Modelo Relacional Revisión Modelo Relacional Diseño físico Base de datos (consiste en la implementación del modelo de datos (diseño lógico)) Creación documento SQL implementación de Base de Datos Implementación en motor de base de datos Pruebas base de Datos Pruebas Implementación Base De Datos Desarrollo prototipo (mostrar un valor agregado del proyecto para integrar el análisis y modelo arquitectónico de datos con un prototipo de un sistema de información) Diseño gráfico de interfaces Descripción Prototipo

10 10. CONCLUCIONES BIBLIOGRAFIA LISTA DE ANEXOS.... Error! Marcador no definido. LISTA DE IMÁGENES.... Error! Marcador no definido.

11 1. JUSTIFICACION. La información que se maneja en un torneo de fútbol o una actividad deportiva no es llevada a las personas de una manera óptima, el acceso a la información es muy limitado ya que las personas con el conocimiento de los torneos son actoresmínimos para la distribución de la información al resto de interesados (equipos: entrenadores, jugadores; desarrollo de torneo: administradores de torneo, árbitros; espectadores: familia, amigos, etc.). El proyecto se enfoca hacia la realización de un modelado y estructurado de datos para el desarrollo de un sistema de información web para torneos de futbol en el sector de Envigado del área metropolitana de Medellín, buscando recopilar datos e información de torneos no formales disputados en comunidades del sector. La denominación del sistema será enmarcada en un administrador de torneos que incluirá los siguiente ítems: programación, ubicación de torneos, notificación en cuanto a cambio de posiciones, seguimiento de goleadores, información de equipos (entrenadores y jugadores), videos e imágenes, todo lo anterior ligado al interés de un participante en conocer lo sucedido durante las jornadas de cada torneo. El sistema de información se dispondrá al público en general a través de internet.

12 2. PLANTEAMIENTO DEL PROBLEMA. La gestión de información de los torneos no es fácil de adquirir ya que se presentan hechos que interrumpen el acceso a datos. Hechos tales como tiempo, desplazamiento o medios de publicación. Los participantes de un torneo se encentran con el efecto de cambiar las actividades planeadas para un día. Por causa a la forma de distribución de la información del torneo (información de manera tardía o divulgada por medios no comunes para el participante). Este problema se origina por la falta de medios de publicación acerca de un torneo, los medios de publicación son muy básicos (carteles, llamadas telefónicas, lugares de desarrollo de torneo, el manejo redes sociales) y con accesos limitados para muchas personas. Todo esto conlleva a la cancelación de partidos, menor interés de las personas por participar en los torneos, falta de conocimiento en información perteneciente a un participante, finalización del torneo antes de lo previsto, no desarrollo de torneos futuros. Se plantea el análisis, modelo, estructura e implementación de un sistema que permita ofrecer la información de manera constante y actualizada a las personas interesadas en un torneo. Será una solución óptima para resolver los inconvenientes que se pueden presentar al no evidenciar los medios de publicación suficientes a cerca de la gestión de la información de torneos de fútbol en el Dorado, sector del Municipio de Envigado.

13 3. OBJETIVO GENERAL Realizar el análisis y modelado arquitectónico de datos para un sistema de información que administre los torneos de futbol del sector el Dorado, del municipio de Envigado. 4. OBJETIVOS ESPECIFICOS. Realizar el levantamiento de requisitos para enmarcar la ruta de desarrollo del software. Implementar la metodología de desarrollo de software bajo técnicas UML y diseño de Base de Datos. Desarrollar un prototipo donde se demuestre e implementen la estructura de modelado y diseño de datos para un sistema de información que administre los torneos de futbol.

14 5. MARCO REFERENCIAL. 5.1 MARCO TEORICO METOLOGIAS DE DESARROLLO DE SOFTWARE. Existe gran cantidad de metodologías de desarrollo que pueden ser utilizadas por cualquier personal. A continuación se definirán las principales metodologías orientadas al desarrollo de software: UML (Unified Modeling Language Lenguaje Unificado de Modelado ). XP (Extreme Programming): Desarrollo iterativo e incremental, Programación en parejas, Hacer entregas frecuentes, Refactorización del código, Simplicidad en el código. Scrum: El desarrollo de software se realiza mediante iteraciones, denominadas sprints o carreras cortas, con una duración de 30 días, La reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración. Crystal Clear: Las metodologías de Crystal se basan en el principio de que tipos diferentes de proyectos requieren tipos diferentes de metodologías. La metodología escogida debe depender de dos factores: El número de personas en el proyecto, y Las consecuencias de los errores. DSDM (Dynamic Systems Developmemt Method): Es un proceso iterativo e incremental, el equipo de desarrollo y el usuario trabajan juntos. El ciclo de vida contempla de esta metodología a partir de cinco fases: Estudio viabilidad, Estudio del negocio, Modelado funcional, Diseño y Construcción e implementación. FDD (Feature Driven Development). El FDD cuenta con cinco procesos: Desarrollar un modelo Global. Construcción de la lista de funcionalidades.

15 Plan de versiones en base a funcionalidades a implementar. Diseñar en base a las funcionalidades. Implementar en base a las funcionalidades ASD (Adaptive Software Development).Sus principales características son: Iterativo Orientado a los componentes software más que a las tareas Tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: Especulación. Se inicia el proyecto y se planifican las características del software. Colaboración. Se desarrollan las características. Aprendizaje. Se revisa su calidad, y se entrega al cliente. La revisión de los componentes sirve para prender de los errores y volver a iniciar el ciclo de desarrollo UML. Este lenguaje se centra en la representación gráfica de un sistema. Los objetivos de UML son muchos, pero se pueden sintetizar funciones: sus Visualizar: UML permite expresar de una forma gráfica un sistema de forma que otro lo puede entender. Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción. Construir: A partir de los modelos especificados se puede construir los sistemas diseñados. Documentar: Los propios elementos gráficos sirven como documentación del sistema desarrollado que puede servir para su futura revisión Diagramas UML. Un diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. En concreto, un diagrama ofrece una vista del sistema a

16 modelar. Para poder representar correctamente un sistema. UML incluye los siguientes diagramas: Diagrama de caso de uso. Diagrama de clases. Diagrama de objetos. Diagrama de secuencia. Diagrama de colaboración. Diagrama de estado. Diagrama de actividades. Diagrama de componentes. Diagrama de despliegue. Los más interesante y más usados son los de caso de uso, clase y secuencia. Diagrama de caso de uso: es la representación gráfica de los casos de uso, se define un caso de uso como cada interacción supuesta con el sistema a desarrollar. Esto está diciendo lo que tiene que hacer un sistema y como. Diagrama de clase: muestra un conjunto de clases, interfaces y relaciones. Diagrama de secuencia: se muestra la interacción de los objetos que componen un sistema de forma temporal. El resto de diagramas muestran distintos aspectos del sistema a modelar, para modelar el comportamiento dinámico del sistema están los de colaboración, estado y actividades. Los diagramas de componentes y despliegue están enfocada ala implementación del sistema.(jacobson, 1999) 5.1.4Proceso de desarrollo. Según el autor Enrique Hernández Orallo, el planteamiento de desarrollo para metodología UML se define de la siguiente forma: Todo sistema informático complejo supone un gran esfuerzo que puede durar desde varios meses hasta años. Por lo tanto, lo más práctico es dividir un proyecto en varias fases. Actualmente se suele hablar de ciclos de vida en los que se realizan varios recorridos por todas las fases. Cada recorrido por las fases se denomina iteración en el proyecto en el que se va a realizar varios tipos de trabajo (denominados flujos) además cada

17 iteración parte de lo anterior incrementado o revisando la funcionalidad implementada. Figura 1: Grafica de representación de procesos de desarrollo.(jacobson. I, 2004) 5.1.5Diseño de base de datos, modelización conceptual de datos. Según la literatura identificada, el diseño y modelado de bases de datos se realiza con la siguiente estructura: El diseño de base de datos se descompone en diseño conceptual, lógico y físico. En el diseño conceptual se parte de las especificaciones de usuario y se consigue una representación del mundo real, esta imagen del mundo real se denomina modelo conceptual. En el que se describen las entidades y sus propiedades, además de las relaciones entre ellos. (Yera, Diseño y Programacion de Bases de Datos, 2007) El diseño lógico consiste en transformar el modelo conceptual obtenido en otro esquema que se puede procesar (relacional, jerárquico, red). Ejemplo (modelo entidad relación, modelo de datos). (Yera, Diseño y Programacion de Bases de Datos, 2007) El modelo físico se parte del esquema lógico y da como resultado el esquema físico. Consiste en la implementación del modelo de datos, dando

18 lugar a estructuras de datos de almacenamiento en uno o varios soportes físicos. (Yera, Diseño y Programacion de Bases de Datos, 2007) Para el Instituto Superior Privado Peruano de Sistemas SISE en su artículo titulado: MODELAMIENTO Y DISEÑO DE BASE DE DATOS EL diseño de una base de datos se puede denominar de la siguiente manera: Diseño Conceptual, Diseño Lógico y diseño Físico el objetivo del diseño conceptual es describir el contenido de la información de la base de datos. Y no las estructuras de almacenamiento que se necesitaran para manejar esta información. Un esquema lógico es una descripción de la estructura de la base de datos. el modelo físico de datos, las entidades son consideradas tablas, los atributos viene hacer los campos de las tablas Funciones básicas de un torneo de futbol. Según la presentación del acta reglamento de liga postobón por la Dimayor En cada uno de los partidos de dicho torneo se adjudicaran tres (3) puntos por partido ganado, un (1) punto por partido empatado y cero (0) puntos por partido perdido. a) El torneo se desarrollara con la participación de los clubes inscritos para participar en el torneo. b) Un torneo se establece de las siguientes formas. a. Todos contra todos b. Enfrentamientos directos, eliminación directa c. Cuadrangulares, fase de grupos. d. Finales. c) Un ejemplo de desarrollo de torneo es El torneo futbol profesional colombiano donde se implementan varias formas de establecer un torneo como son: a. Todos contra todos b. Cuadrangulares finales c. Final de torneo La modalidad será de liga que se establecen partidos todos contra todos y llegando al final de esta fase hasta convertirse en un torneo de fase de

19 grupos como los grandes torneos organizados por la FIFA (Federación Internacional de Futbol Asociados). Lo anterior nos da a entender que la estructura de desarrollo de un torneo no está definida únicamente por una forma de desarrollo. Una vez finalizada la fase de todos contra todos se ejecutara la sumatoria general de los puntos obtenidos en esta fase y se hará la tabla de posiciones desde el puesto número 1 hasta el último puesto de la tabla. Si se realizaran cuadrangulares o fase de grupos los 8 primeros equipos de la tabla de posiciones podrán participar en la fase de grupos de 4 integrantes cada uno. Si no se realiza el cuadrangular, el campeón del torneo será el equipo que más puntos obtengan en la sumatoria de puntos reales del torneo. En caso de empate en la tabla de posiciones se realizará la aplicación de normas establecidas por los organizadores del torneo. En el torneo de futbol profesional colombiano se tiene como referencia las siguientes normativas para un desempate: Mayor diferencia de total de goles a favor y total de goles en contra. Mayor número de goles a favor. Mayor número de goles a favor como visitantes. Menor número de goles en contra como visitantes. Por sorteo Caracterización de la información manejada por un torneo de futbol. Programación de partidos: presentar de forma óptima la programación de cada partido que se desarrollara en un torneo de futbol, esta programación de partidos consta de la siguiente información: Fecha de partidos. Equipos que participaran en el partido. Horario del partido. Lugar del partido. Tabla de posiciones: presentar la tabla de posiciones de forma entendible para cada resultado obtenido según la programación de partidos. Toma de resultados en cada partido ganado por programación. Toma de resultado en cada partido empatado por programación.

20 Toma de resultado en cada partido perdido por programación. Establecer posiciones de equipos. Información de amonestaciones en cada partido: manejar la información de incumplimiento de normas en cada partido desarrollado. Cantidad de faltas cometidas por equipo. Cantidad de tarjetas amarillas. Cantidad de tarjetas rojas. Las normativas de tarjetas solo son perjudiciales para los jugadores o entrenadores. Como: Una cantidad de tarjetas amarillas establecidas en la estructura del torneo dan suspensión a jugadores por fechas de juego del torneo. Una tarjeta roja da suspensión a jugadores o entrenadores por fechas de juego del torneo. Estadística: recopilación de toda la información de una fecha de programación para el desarrollo estadístico del torneo en simulaciones futuras en puntuación o resultados. (Elaboración propia)

21 5.1.8Caracterización de usuarios: Presentar la descripción de los usuarios que interactuaran con el sistema de información de torneos de futbol, usuarios definidos por: A. Administrador de sistema de información: persona encargada del manejo de la información que será publicada en el sistema de información de torneos de futbol. B. Jugadores: integrantes de equipos participantes de un torneo de futbol. C. Entrenadores: encargados de dirigir y formar equipos participantes de un torneo de futbol. D. Espectadores: personas interesada en un torneo de futbol. Pero que no son integrantes de un equipo. E. Familiares: personas perteneciente a un grupo familiar que registra algún interés en la participación de un miembro de la familia en un torneo de futbol. 5.2 Estado del arte. Las plataformas de Administración de torneos de futbol son implementaciones de sistemas de información en la web que tienen facetas informativas y administrativas. Como ejemplos de estos tipos de sistemas de información se pueden tomar las siguientes aplicaciones: o es.fifa.com. De una forma técnica se llega a la producción de un sistema de información web como los mencionados anteriormente teniendo como base los siguientes puntos desarrollo, metodologías, implementación y resultados. El desarrollo de gestores de información o Sistemas de información se plantea según ideas, inquietudes o necesidades de usuario. Para desarrollar un sistema de información se debe tener claridad su definición y objetivo principal

22 para identificar que su desarrollo es una solución acorde a las necesidades del sector. Siendo consecuentes con lo anteriormente mencionado, tomamos como referente las definiciones o conceptos de los siguientes autores: Según Alarcón, los sistemas de información son considerados como un conjunto de componentes interrelacionados que recolectan (o recuperan), procesan, almacenan y distribuyen información Los sistemas de información se comportan de manera estratégica para la toma de decisión del usuario, adicionalmente éstos han tenido avances significativos que pueden hacer que las decisiones sean acordes a los tiempos y necesidades actuales. Dichos avances se pueden considerar como sistemas de información en la nube, que consisten en mejorar al acceso a la información con menor cantidad de recursos físicos todo por medio del internet. Para entender el concepto Técnico de Qué es la Nube? Se hace referencia a literatura Tecnológica que defina la nube como: lo podemos definir como un servicio a través de la web y de otras redes de comunicación de toda una seria de recursos relacionados con las TIC. Estos recursos, como la potencia de procesamiento de información, el almacenamiento, plataformas informáticas y aplicaciones, etc. Se encuentran en una situación remota al usuario, y se paga por ellos solo según el uso que se haga de los mismos (Dean D, 2010) Teniendo conocido lo que son los SI o SI en la nube y cuál es su objetivo, se pueden definir en cómo se va a desarrollar. Para desarrollar un SI o cualquier software se pueden implementar el conjunto de conocimiento para la creación, perfección e implementación de desarrollo de software también llamada ingeniería de software, que consiste en el manejo de metodologías de desarrollo, Herramientas de desarrollo y toma de decisiones para el desarrollo de software. Comúnmente se habla de ingeniería de software como la apropiación de una metodología para encaminar y estructurar la vía de creación de un aplicativo. la ingeniería de software se refiere a los problemas prácticos de producir software (Sommerville, 2005) Las metodologías de desarrollo existentes en ingeniería de Software son de tipos y estilos que acordes con el personal designado para el desarrollo de la

23 aplicación plantean cual es la mejor opción metodológica para implementar. Para este caso en particular, se listan: UML (Unified Modeling Language Lenguaje Unificado de Modelado ). XP (Extreme Programming) Scrum. Crystal Clear DSDM (Dynamic Systems Development Method) FDD (Feature Driven Development ASD (Adaptive Software Development) Teniendo una metodología definida y un modelo estructurado (en este caso de metodología UML) basado en una estructura de interacción con el usuario en la relación de flujos de trabajo (requerimientos, análisis, diseño, implementación y prueba). Donde el usuario tiene conocimiento total del desarrollo del sistema de esta forma tomando un papel no directo con el grupo de trabajo en el cargo de prueba de satisfacción de sus propias necesidades. Una relación de usuario con metodología UML establece que un usuario final verifica el sistema o su aplicación como tal, se toma el punto de vista del usuario final y los casos de uso de pruebas ejecutan acciones típicas del usuario (Weitzenfeld, 2005) Al finalizar todas las etapas de desarrollo de un SI desde que surge una idea o necesidad hasta que se implementa la totalidad de una metodología se tiene como resultado una plataforma de gestión de información de alguna razón social específica. Dando un ejemplo de sistemas de información desarrollados e implementados con una razón social específica se puede mencionar a la plataforma de administración de torneos de futbol liga antioqueña de futbol donde se administran torneos, Posiciones de equipos, resultados de partidos, programación, escuelas.

24 6. DISEÑO METODOLOGICO PRELIMINAR. Se hará referencia a los flujos de trabajo que se tendrán en cuenta para el análisis y modelado del proyecto basados en referencias UML y metodología de diseño de base de datos. REQUERIMIENTOS (Descripción de necesidades para desarrollo de proyecto): Levantamiento de requerimientos ANALISIS (Transformación de requisitos en un diseño del sistema): Definición módulos de desarrollo (clasificación de requisitos por módulo de desarrollo). Requisitos de información (Funcional, no funcional). Descripción Actores de interacción. Matriz de rastreabilidad objetivos- requisitos de información. Definición de diagramas UML (Un diagrama es la representación gráfica de un conjunto de elementos con sus relaciones): Subsistema General (descripción del sistema en la unificación de la definición de módulos de desarrollo). Diagrama de casos de uso (representación de casos de uso, hace referencia al cómo se debe ejecutar el desarrollo o cada tarea) Diagrama de Clases y objetos (muestra un conjunto de clases, interfaces y relaciones). Diagramas de Secuencia (muestra la iteración de los objetos que componen un sistema). Diagramas de Colaboración (comportamiento dinámico del sistema).

25 Diagramas de Estados (comportamiento dinámico del sistema). Diagrama de Paquetes (comportamiento dinámico del sistema). Diagrama de Componentes (implementación del sistema). Diagrama de Despliegue (implementación del sistema) Diseño conceptual Base de datos (Describir la información de la base de datos): Definición de entidades. Definición de atributos. Descripción de entidades. Descripción de atributos. Diseño lógico Base de datos (descripción de la estructura de base de datos): Definición de relaciones. Modelo entidad- relación (participación). Modelo relacional (entidad.- atributos). Pruebas de escritorio modelo relacional. Revisión de modelo relacional. Pruebas de escritorio modelo relacional. Diseño físico Base de datos (consiste en la implementación del modelo de datos (diseño lógico)): Creación documento SQL implementación de Base de Datos. Implementación en motor de base de datos. Pruebas relaciones de entidades. Pruebas objetos de manejo y optimización de base de datos. Desarrollo prototipo(integrar el análisis y modelado arquitectónico de datos con un prototipo de sistema de información, como valor agregado del proyecto): Diseño gráfico de interfaces. Desarrollo prototipo en lenguaje PHP y MYSQL para módulos de desarrollo en flujo de trabajo análisis. Revisión material de publicación (texto, imagen, video). Pruebas de rendimiento con interacción de usuario. Montaje en HOSTING y asignación de dominio del proyecto.

26 Revisión final del prototipo on-line. 7. CRONOGRAMA.

27

28 8. PRESUPUESTO. 9. ANALISIS Y MODELO ARQUITECTONICO DE DATOS PARA SISTEMA DE INFORMACION DE TORNEOS DE FUTBOL. 9.1 REQUERIMIENTOS (Descripción de necesidades para desarrollo de proyecto). Se desea fomentar el desarrollo de una estructura de datos donde se describa los procesos de creación e implementación de un sistema de información que maneje la información perteneciente a torneos de futbol donde se satisfagan las siguientes necesidades: Información general del torneo como una descripción (objetivo del torneo). Programación de partidos con fecha, hora y lugar Los lugares pertenecen a las canchas donde se realiza el torneo que están descritas por nombre, dirección y teléfono si tiene. Tabla de posiciones de cada torneo con nombre de equipos, posición en la cual se encuentra cada equipo, cantidad de puntos durante el torneo por equipo, número de goles a favor, número de goles en contra y diferencia de

29 goles por cada equipo (diferencia entre goles a favor y en contra), número de tarjetas amarillas y rojas. Se manejara una tabla de posiciones de goleadores por cada torneo. Manejar la información de cada equipo con datos de jugadores, entrenadores y directivas si las posee. Manejar la información de los jugadores pertenecientes a un equipo con nombre, apellido, edad, número de goles anotados, posición de juego. Se tendrá una galería de imágenes y videos donde se refleje lo ocurrido en una fecha de programación de cada torneo. Galería de imágenes por torneos, lugares de desarrollo de torneo. 9.2 ANALISIS (Transformación de requisitos en un diseño del sistema) Definición módulos de desarrollo (clasificación de requisitos por módulo de desarrollo). Requisitos de información (Funcional, no funcional). Módulos objetivos del sistema. OBJ-01 Descripción Estabilidad Comentarios Gestionar Torneo El sistema deberá gestionar los torneos con la información pertinente a él. Las Operaciones de Gestionar Torneo son: crear, eliminar, modificar, visualizar. Alta Todo usuario con acceso al sistema de información podrá visualizar la información de los torneos de futbol registrados en el sistema.

30 OBJ-02 Descripción Estabilidad Comentarios Gestionar Equipo El sistema deberá gestionar los equipos participantes en un torneo de futbol registrado en el sistema de información. Las Operaciones de Gestionar equipo son: crear, eliminar, visualizar. Alta Todo usuario con acceso al sistema de información podrá visualizar la información de los torneos de futbol registrados en el sistema. OBJ-03 Descripción Estabilidad Comentarios OBJ-04 Descripción Estabilidad Comentarios Gestionar Participante. El sistema deberá gestionar los participantes de un torneo de futbol registrado en el sistema de información. Las Operaciones de Gestionar participante son: crear, eliminar, modificar, visualizar. Alta Los participantes serán jugadores, entrenadores, miembros de equipos (ejemplo: ayudante, médicos), árbitros. Gestionar goleo El sistema deberá gestionar los jugadores que anoten un gol en un partido desarrollado en torneos de futbol registrados en el sistema de información Las Operaciones de Gestionar goleador son: crear, eliminar, modificar, visualizar. Alta Tener registro de los goles anotados por equipos, jugadores en los torneos de futbol.

31 OBJ-05 Descripción Estabilidad Comentarios OBJ-06 Descripción Estabilidad Comentarios OBJ-07 Descripción Estabilidad Comentarios OBJ-08 Descripción Estabilidad Comentarios Gestionar Programar fecha El sistema deberá gestionar la programación de los partidos que se desarrollan en un torneo de futbol. Las Operaciones de Gestionar Programación fecha son: crear, modificar, visualizar. Alta La programación de fechas será la programación de fechas, partidos y lugares. Gestionar Ubicación El sistema deberá gestionar los lugares donde se realizaran los partidos programados para un torneo de futbol. Las Operaciones de Gestionar Ubicación son: crear, eliminar, visualizar. Alta Manejar la información de los lugares con dirección e imagen. Gestionar Posición El sistema deberá gestionar la tabla de posiciones de cada torneo de futbol registrado en el sistema de información. Las Operaciones de Gestionar estudiante son: crear, eliminar, modificar, visualizar. Alta Mostrar toda la información que administra una tabla de posiciones como partidos, puntos o posiciones. Gestionar Galería El sistema deberá gestionar la galería de multimedia que se maneja en el sistema de información. Las Operaciones de Gestionar estudiante son: crear, eliminar, visualizar. Alta Todos los archivos multimedia video.

32 OBJ-09 Descripción Estabilidad Comentarios OBJ-10 Descripción Gestionar Usuario El sistema deberá gestionar los usuarios que interactuaran con el sistema de información. Las Operaciones de Gestionar estudiante son: crear, eliminar, modificar, login. Alta El usuario administrador será el único permitido para realizar la acción de crear, eliminar o modificar cada objetivo del sistema. Gestionar Seguridad del Sistema El sistema deberá gestionar la seguridad de todas las operaciones disponibles en el sistema para todos los usuarios, sin excepción. Estabilidad Alta Comentarios N/A

33 9.2.2 Requisitos de información (Funcional, no funcional) Requisitos de Información. RI Objetivos Asociados Requisitos Asociados Descripción Datos Específicos Intervalo Estabilidad Comentarios Información Torneo OBJ 01 Gestionar Torneo OBJ 02 Gestionar equipo OBJ 03 Gestionar participante OBJ 04 Gestionar goleo OBJ 05 Gestionar programación fecha OBJ 06 Gestionar ubicación OBJ 07 Gestionar Posición OBJ 08 Gestionar Galería OBJ 010 Gestionar Seguridad del Sistema RF 1-01, RF 1-02, RF 1-03, RF 1-04 El Sistema deberá almacenar la información pertinente a los torneos. Id_torneo, nombre_ torneo, fecha_inicio, comentario. Presente Alta N/A RI Información Equipo OBJ 01 Gestionar Torneo OBJ 02 Gestionar Equipo Objetivos Asociados OBJ 03 Gestionar Participante OBJ 04 Gestionar Goleo OBJ 010 Gestionar Seguridad del Sistema Requisitos Asociados RF 2-01,RF 2-02,RF 2-03

34 Descripción Datos Específicos Intervalo Estabilidad Comentarios Datos Específicos Intervalo Estabilidad Comentarios El Sistema deberá almacenar la información pertinente a los Equipos. Id_Equipo, nombre, comentario. Presente Alta N/A Id_torneo, nombre_ torneo, fecha_inicio, comentario. Presente Alta N/A RI Información Participante OBJ 01 Gestionar Torneo OBJ 02 Gestionar Equipo Objetivos Asociados OBJ 03 Gestionar Participante OBJ 04 Gestionar goleo Requisitos Asociados Descripción Datos Específicos Intervalo Estabilidad Comentarios OBJ 010 Gestionar Seguridad del Sistema RF 3-01,RF 3-02,RF 3-03,RF 3-04 El Sistema deberá almacenar la información pertinente a los Participantes. Id_participante, nombre, apellido, posición_juego_torneo. Presente Alta N/A

35 Datos Específicos Intervalo Estabilidad Comentarios Id_torneo, nombre_ torneo, fecha_inicio, comentario. Presente Alta N/A RI Información Goleo OBJ 01 Gestionar Torneo OBJ 02 Gestionar Equipo Objetivos Asociados OBJ 03 Gestionar Participante OBJ 04 Gestionar goleo OBJ 05 Gestionar programación fecha OBJ 010 Gestionar Seguridad del Sistema Requisitos Asociados Descripción Datos Específicos Intervalo Estabilidad Comentarios RF 4-01,RF 4-02,,RF 4-03RF 4-04 El Sistema deberá almacenar la información pertinente a los Participantes anotadores de goles. Id_goleo, cantidad_goles, comentario. Presente Alta N/A RI Objetivos Asociados Información Programación fecha OBJ 01 Gestionar Torneo OBJ 02 Gestionar Equipo

36 OBJ 03 Gestionar Participante OBJ 05 Gestionar programación fecha OBJ 06 Gestionar ubicación OBJ 07 Gestionar posición OBJ 010 Gestionar Seguridad del Sistema Requisitos Asociados RF 5-01,RF 5-02,RF 5-03,RF 5-04 Descripción El Sistema deberá almacenar la información pertinente a los Participantes. Datos Específicos Intervalo Estabilidad Comentarios Id_programacion_fecha, fecha, hora, marador_1, marcador_2, ganador, perdedor, empate, estado. Presente Alta N/A RI Información Ubicación OBJ 05 Gestionar Programación fecha OBJ 06 Gestionar ubicación Objetivos Asociados OBJ 08 Gestionar Galería OBJ 010 Gestionar Seguridad del Sistema Requisitos Asociados RF 6-01,RF 6-02,RF 6-03

37 Descripción Datos Específicos Intervalo Estabilidad El Sistema deberá almacenar la información pertinente a la ubicación de desarrollo de un torneo. Id_ubicacion, nombre, dirección, teléfono, comentario. Presente Alta RI Información Posición OBJ 01 Gestionar Torneo OBJ 02 Gestionar Equipo OBJ 05 Gestionar Programación fecha Objetivos Asociados OBJ 07 Gestionar posición OBJ 010 Gestionar Seguridad del Sistema Requisitos Asociados Descripción Datos Específicos Intervalo RF 7-01,RF 7-02,RF 7-03,RF 7-04 El Sistema deberá almacenar la información pertinente a la tabla de posiciones de un torneo. Id_posicion, partidos_jugados, cantidad_puntos, partidos_ganados, partidos_ perdidos, partidos_empatados, goles_anotados, goles_encontra, diferencia_goles, posicion. Presente

38 RI Información Galería OBJ 01 Gestionar Torneo OBJ 06 Gestionar ubicación Objetivos Asociados BOJ 08 Gestionar galería OBJ 010 Gestionar Seguridad del Sistema Requisitos Asociados RF 8-01,RF 8-02,RF 8-03 Descripción Datos Específicos Intervalo El Sistema deberá almacenar la información pertinente a videos tomados en un torneo. Id_Galeria, nombre, dirección_url, comentario,fecha_creacion. Presente RI Información usuario OBJ 01 Gestionar Torneo OBJ 02 Gestionar equipo OBJ 03 Gestionar participante OBJ 04 Gestionar goleo Objetivos Asociados OBJ 05 Gestionar programación fecha OBJ 06 Gestionar ubicación OBJ 07 Gestionar Posición OBJ 08 Gestionar Galería OBJ 09 Gestionar usuario

39 OBJ 010 Gestionar Seguridad del Sistema Requisitos Asociados Descripción Datos Específicos Intervalo Estabilidad Comentarios RF 9-01,RF 9-02,RF 9-03,RF El Sistema deberá almacenar la información pertinente a los usuarios. Nombre_ usuario, contraseña, perfil. Presente Alta N/A Requerimientos Funcionales. RF 1-01 Objetivos Asociados Crear torneo OBJ-01 Gestionar Torneo OBJ-10 Gestionar Seguridad del Sistema Requisitos Asociados RI Información Torneo Descripción Precondición El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite la creación de un Torneo al aplicativo web El Torneo no debe estar registrado en el sistema. Secuencia Normal PASO ACCION

40 Postcondición Excepciones Rendimiento Frecuencia Estabilidad Comentarios 1 2 El administrador solicita al sistema la creación de torneos para el despliegue del formulario El sistema despliega formulario para la creación de torneo El sistema verifica si los requisitos de 3 campos de formularios son válidos. El sistema valida la 4 existencia del torneo a crear El sistema crea el 5 torneo. El sistema genera 6 una respuesta al usuario El torneo queda registrado como torneo para administrar en el sistema de información. PASO ACCION 5 Si el sistema detecta que el Torno ya existe, este caso de uso aborta. LAPSO DE PASO TIEMPO 3 3 segundos 4 3 segundo 2 por semestre Alta N/A

41 RF 1-02 Objetivos Asociados Modificar torneo OBJ-01 Gestionar Torneo OBJ-10 Gestionar Seguridad del Sistema Requisitos Asociados RI Información Torneo Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite modificar un Torneo al aplicativo web Precondición El Torneo debe estar creado. Secuencia Normal PASO ACCION El Administrador solicita al sistema modificar los Torneos para el despliegue del formulario El sistema despliega la información del torneo. El usuario modifica los campos válidos para modificar. El sistema verifica si los requisitos de campos de formulario son válidos. El sistema modifica el registro del

42 6 torneo. El sistema genera una respuesta para el usuario Postcondición La información del torneo queda modificada exitosamente. Excepciones PASO ACCION Rendimiento Frecuencia Estabilidad Comentarios LAPSO DE PASO TIEMPO 3 3 segundos 4 3 segundo 2 por semestre Alta N/A RF 1-03 Objetivos Asociados Eliminar torneo OBJ-01 Gestionar Torneo OBJ-10 Gestionar Seguridad del Sistema Requisitos Asociados RI Información Torneo Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite eliminar un Torneo al aplicativo web Precondición El Torneo debe estar creado. Secuencia PASO ACCION

43 Normal 1 El Administrador solicita al sistema eliminar Torneo 2 3 El sistema eliminar todo requisito asociado al torneo. El sistema genera una respuesta al usuario. Postcondición La información del torneo queda eliminada exitosamente. Excepciones PASO ACCION Rendimiento Frecuencia Estabilidad Comentarios PASO LAPSO DE TIEMPO 2 5 segundos 2 por semestre Alta N/A RF 1-04 Objetivos Asociados Requisitos Asociados visualizar torneo OBJ-01 Gestionar Torneo OBJ-10 Gestionar Seguridad del Sistema RI Información Torneo Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando un usuario solicite ver la información de un Torneo al aplicativo web

44 Precondición El Torneo debe estar creado. Secuencia Normal PASO 1 2 ACCION Un usuario solicita al sistema mostrar la información de un torneo El sistema despliega la información del torneo. Postcondición La información del torneo queda visible exitosamente. Excepciones PASO ACCION PASO LAPSO DE TIEMPO Rendimiento 2 3 segundos Frecuencia Estabilidad Comentarios 150 por semestre Alta N/A RF 2-01 Objetivos Asociados Requisitos Asociados Descripción Crear equipo OBJ-02 Gestionar equipo OBJ-10 Gestionar Seguridad del Sistema RI Información equipo El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite la creación de un equipo al aplicativo web

45 Precondición El Torneo no debe estar registrado en el sistema. PASO 1 ACCION El administrador solicita al sistema la creación de equipos para el despliegue del formulario 2 El sistema despliega formulario para la creación de equipo Secuencia Normal 3 4 El sistema verifica si los requisitos de campos de formularios son válidos. El sistema valida la existencia del equipo a crear 5 El sistema crea el equipo. Excepciones 6 PASO 5 El sistema genera una respuesta al usuario ACCION Si el sistema detecta que el equipo ya existe, este caso de uso aborta. RF 2-02 Objetivos Asociados Eliminar equipo OBJ-02 Gestionar equipo

46 OBJ-10 Gestionar Seguridad del Sistema Requisitos Asociados RI Información equipo Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite eliminar un equipo al aplicativo web Precondición El equipo debe estar creado. Secuencia Normal PASO 1 2 ACCION El Administrador solicita al sistema eliminar equipo El sistema eliminar todo requisito asociado al equipo. 3 El sistema genera una respuesta al usuario. Postcondición La información del equipo queda eliminada exitosamente. Excepciones PASO ACCION Rendimiento Frecuencia Estabilidad Comentarios PASO LAPSO DE TIEMPO 2 5 segundos 2 por semestre Alta N/A RF 2-03 visualizar equipo

47 Objetivos Asociados Requisitos Asociados Descripción OBJ-02 Gestionar equipo OBJ-10 Gestionar Seguridad del Sistema RI Información equipo El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando un usuario solicite ver la información de un equipo al aplicativo web Precondición El Torneo debe estar creado. Secuencia Normal PASO 1 2 ACCION Un usuario solicita al sistema mostrar la información de un equipo El sistema despliega la información del equipo. Postcondición La información del equipo es visible exitosamente. Excepciones PASO ACCION Rendimiento Frecuencia Estabilidad Comentarios PASO LAPSO DE TIEMPO 2 3 segundos 150 por semestre Alta N/A RF 3-01 Objetivos Asociados Crear Participante OBJ-03 Gestionar Participante

48 OBJ-10 Gestionar Seguridad del Sistema Requisitos Asociados Descripción Precondición RI Información Participante El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite la creación de un Participante de un torneo al aplicativo web El participante no debe estar registrado en el sistema. PASO ACCION 1 El administrador solicita al sistema la creación de participantes para el despliegue del formulario Secuencia Normal 2 3 El sistema despliega formulario para la creación de participante El sistema verifica si los requisitos de campos de formularios son válidos. 5 El sistema crea el Participante. 6 El sistema genera una respuesta al usuario Postcondición El participante queda registrado como participante de un torneo para administrar en el sistema de información. Excepciones PASO 5 ACCION Si el sistema detecta que el Participante ya existe, este caso de uso aborta. RF 3-02 Objetivos Asociados Modificar Participante OBJ-03 Gestionar Participante

49 OBJ-10 Gestionar Seguridad del Sistema Requisitos Asociados Descripción RI Información Participante El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite modificar un participante de un Torneo al aplicativo web Precondición El Participante debe estar creado. Secuencia Normal PASO ACCION El Administrador solicita al sistema modificar los Participantes de un torneo para el despliegue del formulario El sistema despliega la información de un participante. El usuario modifica los campos válidos para modificar. El sistema verifica si los requisitos de campos de formulario son válidos. El sistema modifica el registro del Participante. El sistema genera una respuesta para el usuario Postcondición Rendimiento RF 3-04 Objetivos Asociados La información del Participante queda modificada exitosamente. PASO LAPSO DE TIEMPO 3 3 segundos visualizar Participante OBJ-03 Gestionar Participante OBJ-10 Gestionar Seguridad del Sistema

50 Requisitos Asociados Descripción Precondición Secuencia Normal RI Información participante El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando un usuario solicite ver la información de un Participante al aplicativo web PASO 1 2 El Participante debe estar creado. ACCION Un usuario solicita al sistema mostrar la información de un Participante El sistema despliega la información del Participante. Postcondición La información del Participante es visible exitosamente. Excepciones PASO ACCION PASO LAPSO DE TIEMPO Rendimiento 2 3 segundos Frecuencia Estabilidad Comentarios 250 por semestre Alta N/A RF 4-01 Objetivos Asociados Crear Goleo OBJ-04 Gestionar goleo OBJ-10 Gestionar Seguridad del Sistema Requisitos Asociados RI Información goleo

51 Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite la creación de un goleador de un torneo al aplicativo web Precondición El goleador no debe estar registrado en el sistema. Secuencia Normal PASO ACCION El administrador solicita al sistema la creación de registro de goleo para el despliegue del formulario El sistema despliega formulario para la creación de registro de goleo El sistema verifica si los requisitos de campos de formularios son válidos. El sistema valida la existencia del goleo a crear 5 El sistema crea el equipo. Excepciones RF 4-02 Objetivos Asociados 6 PASO 5 El sistema genera una respuesta al usuario ACCION Si el sistema detecta que el registro de goleo ya existe, este caso de uso aborta. Modificar goleo OBJ-04 Gestionar Goleo

52 OBJ-10 Gestionar Seguridad del Sistema Requisitos Asociados Descripción Precondición RI Información Goleo El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite modificar un registro de goleo de un Torneo al aplicativo web El registro de goleo debe estar creado. Secuencia Normal PASO ACCION El Administrador solicita al sistema modificar los registros de goleo de un torneo para el despliegue del formulario El sistema despliega la información de un registro de goleo. El usuario modifica los campos válidos para modificar. El sistema verifica si los requisitos de campos de formulario son válidos. El sistema modifica el registro del goleo. El sistema genera una respuesta para el usuario Postcondición Rendimiento La información de goleo queda modificada exitosamente. PASO LAPSO DE TIEMPO 3 3 segundos RF 4-03 Objetivos Asociados Eliminar goleo OBJ-04 Gestionar Goleo

53 OBJ-10 Gestionar Seguridad del Sistema Requisitos Asociados RI Información Goleo Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite eliminar un registro de goleo de un torneo al aplicativo web Precondición El registro de goleo debe estar creado. Secuencia Normal PASO ACCION El Administrador solicita al sistema eliminar Goleo El sistema eliminar todo requisito asociado al goleo. El sistema genera una respuesta al usuario. Postcondición La información de goleo queda eliminada exitosamente. Excepciones PASO ACCION Rendimiento Frecuencia PASO LAPSO DE TIEMPO 2 5 segundos 10 por semestre RF 4-04 Objetivos Asociados visualizar Goleo OBJ-04 Gestionar goleo

54 OBJ-10 Gestionar Seguridad del Sistema Requisitos Asociados RI Información Goleo Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando un usuario solicite ver la información de un registro de goleo de un torneo al aplicativo web Precondición Secuencia Normal Postcondición El Torneo y registro de goleo debe estar creado. PASO 1 2 ACCION Un usuario solicita al sistema mostrar la información de un registro de goleo El sistema despliega la información de goleo. La información de goleo es visible exitosamente. Excepciones PASO ACCION PASO LAPSO DE TIEMPO Rendimiento 2 3 segundos Frecuencia 150 por semestre Estabilidad Comentarios Alta N/A RF 5-01 Objetivos Crear Programación fecha OBJ-05 Gestionar Programar fecha

55 Asociados Requisitos Asociados Descripción Precondición OBJ-10 Gestionar Seguridad del Sistema RI Información Programar fecha El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite la programación de una fecha de partido de un torneo al aplicativo web La programación de la fecha de un partido no debe estar registrada en el sistema. Secuencia Normal PASO ACCION El administrador solicita al sistema la creación de registro de programación de fecha para el despliegue del formulario El sistema despliega formulario para la creación de registro de programación fecha El sistema verifica si los requisitos de campos de formularios son válidos. 4 El sistema valida la existencia de la programación a crear 5 El sistema crea la fecha de los partidos. Excepciones 6 PASO 5 El sistema genera una respuesta al usuario ACCION Si el sistema detecta que el registro de programación fecha para partido ya existe, este caso de uso aborta.

56 RF 5-02 Objetivos Asociados Requisitos Asociados Descripción Precondición Modificar Programación fecha OBJ-05 Gestionar Programar fecha OBJ-10 Gestionar Seguridad del Sistema RI Información Programar fecha El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite modificar un registro de programación departido de un Torneo al aplicativo web El registro de programación debe estar creado. Secuencia Normal PASO ACCION El Administrador solicita al sistema modificar los registros de programar fecha de partido de un torneo para el despliegue del formulario El sistema despliega la información de un registro de programación fecha. El usuario modifica los campos válidos para modificar. El sistema verifica si los requisitos de campos de formulario son válidos. El sistema modifica el registro del programación fecha. El sistema genera una respuesta para el usuario Postcondición La información de programación fecha queda modificada exitosamente. Rendimiento PASO LAPSO DE TIEMPO

57 3 3 segundos RF 5-03 Objetivos Asociados Eliminar Programar fecha OBJ-05 Gestionar Programar fecha OBJ-10 Gestionar Seguridad del Sistema Requisitos Asociados RI Información Programar fecha Descripción Precondición El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite eliminar un registro de programación fecha de un torneo o eliminar un torneo al aplicativo web El registro de goleo debe estar creado. Secuencia Normal PASO 1 2 ACCION El Administrador solicita al sistema eliminar Programación de fecha o eliminar torneo El sistema eliminar todo requisito asociado a la programación de fecha. 3 El sistema genera una respuesta al usuario. Postcondición Excepciones Rendimiento Frecuencia La información de programar fecha queda eliminada exitosamente. PASO ACCION PASO LAPSO DE TIEMPO 2 5 segundos 10 por semestre

58 RF 5-04 Objetivos Asociados visualizar Programar fecha OBJ-05 Gestionar programar fecha OBJ-10 Gestionar Seguridad del Sistema Requisitos Asociados Descripción Precondición Secuencia Normal Postcondición RI Información Programar fecha El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando un usuario solicite ver la información de un registro de programación de partido de un torneo al aplicativo web El registro de programación fecha por torneo debe estar creado. PASO 1 2 ACCION Un usuario solicita al sistema mostrar la información de un registro de programación fecha El sistema despliega la información de programación. La información de Programación fecha de partidos por torneo es visible exitosamente. Excepciones PASO ACCION PASO LAPSO DE TIEMPO Rendimiento 2 3 segundos Frecuencia Estabilidad Comentarios 150 por semestre Alta N/A RF 6-01 Crear Ubicación

59 Objetivos Asociados OBJ-06 Gestionar Ubicación OBJ-10 Gestionar Seguridad del Sistema Requisitos Asociados RI Información Ubicación Descripción Precondición El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite la creación de una ubicación para el desarrollo de un torneo al aplicativo web El Torneo debe estar creado pero la ubicación no debe estar creada. PASO 1 ACCION El administrador solicita al sistema la creación de ubicación para el desarrollo de partidos de un torneo para el despliegue del formulario 2 El sistema despliega formulario para la creación de ubicación. Secuencia Normal 3 El sistema verifica si los requisitos de campos de formularios son válidos. 4 El sistema valida la existencia de la ubicación a crear Excepciones El sistema crea la ubicación de 5 desarrollo e partidos. El sistema genera una respuesta al 6 usuario PASO ACCION 5 Si el sistema detecta que la ubicación

60 ya existe, este caso de uso aborta. RF 6-02 Objetivos Asociados Requisitos Asociados Descripción Eliminar Ubicación OBJ-06 Gestionar ubicación OBJ-10 Gestionar Seguridad del Sistema RI Información ubicación El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite eliminar un torneo o una ubicación al aplicativo web Precondición El torneo o la ubicación deben estar creado. Secuencia Normal PASO ACCION El Administrador solicita al sistema eliminar ubicación El sistema eliminar todo requisito asociado a la ubicación. El sistema genera una respuesta al usuario. Postcondición Excepciones Rendimiento Frecuencia La información de la ubicación queda eliminada exitosamente. PASO PASO ACCION LAPSO DE TIEMPO 2 5 segundos 2 por semestre

61 RF 6-03 Objetivos Asociados Requisitos Asociados Descripción visualizar Ubicación OBJ-06 Gestionar Ubicación OBJ-10 Gestionar Seguridad del Sistema RI Información Ubicación El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando un usuario solicite ver la información de un registro de ubicación de desarrollo de un partido de un torneo al aplicativo web Precondición El registro de ubicación por torneo debe estar creado. PASO ACCION 1 Un usuario solicita al sistema mostrar la información de un registro de programación fecha Secuencia Normal 2 El sistema despliega la información de programación. Postcondición La información de Programación fecha de partidos por torneo es visible exitosamente. Excepciones PASO ACCION Rendimiento Frecuencia Estabilidad PASO LAPSO DE TIEMPO 2 3 segundos 150 por semestre Alta

62 Comentarios N/A RF 7-01 Objetivos Asociados Requisitos Asociados Descripción Precondición Crear Posición OBJ-07 Gestionar Posición OBJ-10 Gestionar Seguridad del Sistema RI Información Posición El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite la creación de una Posición de un equipo según un torneo para el desarrollo de un torneo al aplicativo web El Torneo debe estar creado pero la ubicación no debe estar creada. Secuencia Normal PASO ACCION El administrador solicita al sistema la creación de una posición para un equipo de un torneo para el despliegue del formulario El sistema despliega formulario para la creación de una posición para un equipo. El sistema verifica si los requisitos de campos de formularios son válidos. El sistema valida la existencia de la ubicación a crear del equipo 5 El sistema crea la posición de un equipo. 6 El sistema genera una respuesta al usuario

63 Excepciones PASO 5 ACCION Si el sistema detecta que el equipo ya tiene una posición creada ya existe, este caso de uso aborta. RF 7-02 Eliminar Posición Objetivos Asociados Requisitos Asociados Descripción OBJ-07 Gestionar Posición OBJ-10 Gestionar Seguridad del Sistema RI Información Posición El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite eliminar un torneo o una posición de un equipo al aplicativo web Precondición El torneo o la ubicación debe estar creado. Secuencia Normal PASO ACCION El Administrador solicita al sistema eliminar un torneo El sistema eliminar todo requisito asociado a la torneo. El sistema genera una respuesta al usuario. Postcondición La información del torneo queda eliminada exitosamente. Excepciones PASO ACCION Rendimiento Frecuencia PASO LAPSO DE TIEMPO 2 5 segundos 2 por semestre

64 RF 7-03 Objetivos Asociados Requisitos Asociados Descripción Precondición visualizar Posición OBJ-07 Gestionar Posición OBJ-10 Gestionar Seguridad del Sistema RI Información Posición El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando un usuario solicite ver la información de una posición de un equipo en un torneo al aplicativo web El registro de Posición por equipo y por torneo debe estar creado. PASO ACCION Secuencia Normal 1 2 Un usuario solicita al sistema mostrar la información de un registro de posición de un equipo en un torneo El sistema despliega la información de posición. Postcondición La información de Posición de equipos por torneo es visible exitosamente. Excepciones PASO ACCION Rendimiento Frecuencia Estabilidad Comentarios PASO LAPSO DE TIEMPO 2 3 segundos 150 por semestre Alta N/A RF 7-04 Modificar posición

65 Objetivos Asociados Requisitos Asociados Descripción Precondición OBJ-07 Gestionar posición OBJ-10 Gestionar Seguridad del Sistema RI Información posición El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite modificar una posición de un equipo en un Torneo al aplicativo web El Torneo, el equipo y la posición deben estar creado. PASO ACCION Secuencia Normal El Administrador solicita al sistema modificar la posición de un equipo por un torneo para el despliegue del formulario El sistema despliega la información de Posición. El usuario modifica los campos válidos para modificar. El sistema verifica si los requisitos de campos de formulario son válidos. El sistema modifica el registro del Posición. El sistema genera una respuesta para el usuario Postcondición Excepciones La información del torneo con respecto a la tabla de posiciones queda modificada exitosamente. PASO ACCION RF 8-01 Crear galería

66 Objetivos Asociados Requisitos Asociados Descripción Precondición OBJ-08 Gestionar galería OBJ-10 Gestionar Seguridad del Sistema RI Información galería El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite la creación de una registro de galería ( video) de un torneo al aplicativo web El registro de galería no debe estar creada. Secuencia Normal PASO ACCION El administrador solicita al sistema la creación de un registro de galería para el despliegue del formulario El sistema despliega formulario para la creación de galería. El sistema verifica si los requisitos de campos de formularios son válidos. El sistema valida la existencia del registro de la galeria 5 El sistema crea la posición de un equipo. Excepciones 6 PASO 5 El sistema genera una respuesta al usuario ACCION Si el sistema detecta que el equipo ya tiene un registro de galería ya creada idénticamente, este caso de uso aborta.

67 RF 8-02 Objetivos Asociados Requisitos Asociados Descripción Precondición visualizar galería OBJ-08 Gestionar Galería OBJ-10 Gestionar Seguridad del Sistema RI Información Galería. El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando un usuario solicite ver la información de una imagen o video de un equipo en un torneo al aplicativo web El registro de galería por torneo debe estar creado. Secuencia Normal PASO 1 2 ACCION Un usuario solicita al sistema mostrar la información de un registro de galería (imagen o video) de un torneo El sistema despliega la información de Galería. Postcondición La información de Registro galería es visible exitosamente. Excepciones PASO ACCION Rendimiento Frecuencia Estabilidad Comentarios PASO LAPSO DE TIEMPO 2 3 segundos 250 por semestre Alta N/A RF 8-03 Objetivos Asociados Eliminar galería OBJ-08 Gestionar Galería

68 OBJ-10 Gestionar Seguridad del Sistema Requisitos Asociados Descripción RI Información Galería El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite eliminar un registro de galería al aplicativo web Precondición El registro de galería debe estar creado. PASO 1 ACCION El Administrador solicita al sistema eliminar un torneo o registro de galería Secuencia Normal 2 El sistema eliminar todo requisito asociado a la torneo o a la galería. 3 El sistema genera una respuesta al usuario. Postcondición La información del torneo o dela galería queda eliminada exitosamente. Excepciones PASO ACCION Rendimiento Frecuencia PASO LAPSO DE TIEMPO 2 5 segundos 2 por semestre RF 9-01 Objetivos Asociados Crear usuario OBJ-09 Gestionar usuario

69 OBJ-10 Gestionar Seguridad del Sistema Requisitos Asociados Descripción RI Información usuario El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite la creación de un usuario que administrara al aplicativo web Precondición El usuario no debe estar creado. PASO ACCION El administrador solicita al sistema la creación de un usuario para el despliegue del formulario El sistema despliega formulario para la creación de usuario. El sistema verifica si los requisitos de campos de formularios son válidos. Secuencia Normal 4 El sistema valida la existencia del registro de la usuario Excepciones 5 6 PASO 5 El sistema crea un nuevo usuario administrador. El sistema genera una respuesta al usuario ACCION Si el sistema detecta que el usuario ya existe, este caso de uso aborta.

70 RF 9-02 Objetivos Asociados Requisitos Asociados Modificar contraseña usuario. OBJ-09 Gestionar usuario OBJ-10 Gestionar Seguridad del Sistema RI Información usuario Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite modificar su contraseña de usuario aplicativo web Precondición El usuario debe estar creado. PASO 1 ACCION El Administrador solicita al sistema modificar su contraseña para el despliegue del formulario Secuencia Normal El sistema despliega la información de usuario. El usuario modifica los campos válidos para modificar. El sistema verifica si los requisitos de campos de formulario son válidos. El sistema modifica el registro del contraseña de usuario. El sistema genera una respuesta para el usuario Postcondición La información del usuario queda modificada exitosamente. Excepciones PASO ACCION

71 RF 9-03 Objetivos Asociados Requisitos Asociados Descripción Eliminar usuario OBJ-09 Gestionar Usuario OBJ-10 Gestionar Seguridad del Sistema RI Información Usuario El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el administrador solicite eliminar un usuario al aplicativo web Precondición El usuario debe estar creado. Secuencia Normal PASO ACCION El Administrador solicita al sistema eliminar un usuario El sistema eliminar todo requisito asociado a un usuario. El sistema genera una respuesta al usuario. Postcondición La información del usuario queda eliminada exitosamente. Excepciones PASO ACCION Rendimiento Frecuencia PASO LAPSO DE TIEMPO 2 5 segundos 2 por semestre RF 9-04 Objetivos Asociados Login usuario OBJ-09 Gestionar Usuario

72 OBJ-10 Gestionar Seguridad del Sistema Requisitos Asociados Descripción RI Información Usuario El sistema deberá comportarse tal como se describe en el siguiente caso de uso: Cuando el usuario administrador solicite ingresar al aplicativo web administrador Precondición PASO 1 El usuario debe estar creado. ACCION El Administrador solicita al sistema hacer login usuario y contraseña Secuencia Normal Postcondición Excepciones 2 El sistema despliega el formulario de login de usuario. El usuario ingresa el nombre de usuario 3 y contraseña. El sistema valida la existencia de usuario 4 y contraseña 5 El usuario ingresa al sistema 6 Respuesta al usuario El usuario ingresa al sistema de administración exitosamente. PASO ACCION El usuario o contraseña no existen, este 4 caso de uso aborta Requerimientos no Funcionales. RNF-01 Objetivos asociados: Requisitos asociados: Copias de seguridad N/A. N/A.

73 Descripción: El sistema deberá crear cada cierto lapso de tiempo, la realización de una copia de seguridad. Comentarios: Aun no se ha definido con el cliente el tiempo y forma para la realización de la copia de seguridad. RNF-02 Hosting (Dominio) OBJ-01 Gestionar Estudiante Objetivos asociados: OBJ- 02 Gestionar Documento OBJ 03 Gestionar Docente OBJ-04 Gestionar Seguridad del Sistema RI Información Estudiante Requisitos asociados: RI Información Docente RI -02 Información Documento Descripción: El sistema necesitara de un espacio de alojamiento web. Comentarios: El sistema requiere que su hosting sea de gran almacenamiento, a su vez que permitir la interacción con bases de datos de MySQL. RNF-03 Servidor de base de datos

74 Objetivos asociados: Requisitos asociados: Descripción: N/A. N/A. El sistema requerirá un almacenamiento de datos para la información del aplicativo. Comentarios: La base de datos deberá tener compatibilidad con el servidor web (hosting) para garantizar el rendimiento deseado. RNF-04 Objetivos asociados: Requisitos asociados: Descripción: Web application Sever N/A. N/A. El sistema requerirá un servidor para poder correr los servicios que se tienen en el aplicativo. Comentarios: El web server debe tener compatibilidad con la base de datos y fácil manejo con el hosting RNF-05 Objetivos asociados: Requisitos asociados: Descripción: Ancho de Banda N/A. N/A. El sistema requerirá un ancho de banda como mínimo de 500 kb/s

75 Comentarios: N/A RNF-06 Versión de Navegador Objetivos asociados: Requisitos asociados: Descripción: N/A. N/A. El sistema estará diseñado para ejecutarse principalmente en el navegador de google Se debe asegurar que al ejecutarse en otros Comentarios: navegadores como mozilla e internet explorer disponible las opciones principales del aplicativo Definición de Actores. ACT-01 Descripción Comentarios Web Máster Este Actor representa la persona encargada de controlar la seguridad del sistema. Un web máster debe velar por la disponibilidad, funcionamiento, y posibles cambios en la aplicación. ACT-02 Descripción Administrador Este actor representa la persona encargada de controlar la información de la página correspondiente a los torneos de futbol. Comentarios Este Actor tiene la capacidad de agregar, modificar y/o eliminar la información perteneciente a un torneo de futbol como: equipos, partidos, fechas, lugares, galería (imágenes y videos), tabla de posiciones de cada

76 torneo, gestión de usuario. ACT-03 Descripción Visitante Este actor representa la persona que visita y visualiza la información que se encuentra en el sistema de información para torneos de futbol. Comentarios Este Actor tiene la posibilidad de visualizar toda la información manejada en el sistema. Información de torneo, equipos, imágenes, videos, posiciones, lugares Matriz de rastreabilidad objetivos- requisitos de información. MATRIZ DE RASTREABILIDAD OBJ- 01 OBJ- 02 OBJ- 03 OBJ- 04 OBJ- 05 OBJ- 06 OBJ- 07 OBJ- 08 OBJ- 09 OBJ- 10 RI RI RI RI RI RI RI RI RI RF 1-01 RF 1-02 RF 1-03 RF 1-04 RF 2-01

77 RF 2-02 RF 2-03 RF 3-01 RF 3-02 RF 3-03 RF 3-04 RF 4-01 RF 4-02 RF 4-03 RF 4-04 RF 5-01 RF 5-02 RF 5-03 RF 5-04 RF 6-01 RF 6-02 RF 6-03 RF 7-01 RF 7-02 RF 7-03 RF 7-04 RF 8-01 RF 8-02 RF 8-03 RF 9-01 RF 9-02 RF 9-03 RF RNF-01 RNF-02 RNF-03 RNF-04 RNF-05 RNF-06 La matriz de rastreabilidad muestra la relación que hay entre cada uno de los requisitos funcionales y no funcionales con los objetivos del sistema

78 9.3 Definición de diagramas UML (Un diagrama es la representación gráfica de un conjunto de elementos con sus relaciones) Subsistema General (descripción del sistema en la unificación de la definición de módulos de desarrollo). Figura 2: Subsistema general Diagrama de casos de uso(representación de casos de uso, esto está diciendo lo que tiene que hacer un sistema y como).

79 Diagrama Caso de Uso Administrador. Figura 3: Diagrama caso de uso administrador Diagrama Caso de Uso Visitante. Figura 4: Diagrama caso de uso Visitante

80 9.3.3 Diagrama de Clases y objetos (muestra un conjunto de clases, interfaces y relaciones) Diagrama de clases. Figura 5: Diagrama de clases

81 Diagrama de Objetos. Figura 6: Diagrama caso de objetos Diagramas de Secuencia (comportamiento dinámico del sistema

82 Diagrama Secuencia Torneo. Figura 7: Diagrama secuencia torneo Diagrama Secuencia Equipo. Figura 8: Diagrama Secuencia Equipo.

83 Diagrama Secuencia Participante. Figura 9: Diagrama secuencia participante Diagrama Secuencia Ubicación. Figura 10: Diagrama secuencia ubicación.

84 Diagrama Secuencia Programación Fecha. Figura 11: Diagrama secuencia programación fecha Diagrama secuencia Goleo. Figura 12: Diagrama secuencia goleo.

85 Diagrama Secuencia Posición. Figura 13: Diagrama secuencia posicion Diagrama Secuencia Galería. Figura 14: Diagrama secuencia galeria.

86 Diagrama Secuencia Usuario. Figura 15 : Diagrama secuencia usuario.

87 9.3.4 Diagramas de Colaboración (comportamiento dinámico del sistema) Diagrama Colaboración Crear Torneo. Figura 16: Diagrama colaboración crear torneo Diagrama Colaboración Modificar Torneo. Figura 17: Diagrama colaboración modificar torneo.

88 Diagrama Colaboración Eliminar Torneo. Figura 18: Diagrama colaboración eliminar torneo Diagrama Colaboración Visualizar Torneo. Figura 19: Diagrama colaboración visualizar torneo Diagrama Colaboración Crear Equipo.

89 Figura 20: Diagrama colaboración crear equipo Diagrama Colaboración Eliminar Equipo. Figura 21: Diagrama colaboración eliminar equipo Diagrama colaboración Visualizar Equipo.

90 Figura 22: Diagrama colaboración visualizar equipo Diagrama Colaboración Crear Participante. Figura 23: Diagrama colaboración crear participante.

91 Diagrama Colaboración Modificar Participante. Figura 24: Diagrama colaboración modificar participante Diagrama Colaboración Eliminar Participante. Figura 25: Diagrama colaboración eliminar participante Diagrama colaboración visualizar Participante.

92 Figura 26: Diagrama colaboración visualizar participante Diagrama Colaboración Crear Ubicación. Figura 27: Diagrama colaboración crear ubicacion Diagrama Colaboración Eliminar Ubicación.

93 Figura 28: Diagrama colaboración eliminar ubicacion Diagrama Colaboración Visualizar Ubicación. Figura 29: Diagrama colaboración visualizar ubicacion Diagrama Colaboración Crear Programar Fecha.

94 Figura 30: Diagrama colaboración crear programar fecha Diagrama Colaboración Eliminar Programar Fecha. Figura 31: Diagrama colaboración eliminar programar fecha Diagrama colaboración Modificar Programar Fecha. Figura 32: Diagrama colaboración modificar programar fecha.

95 Diagrama colaboración Visualizar Programar Fecha. Figura 33: Diagrama colaboración visualizar programar fecha Diagrama Colaboración Crear Goleo.

96 Figura 34: Diagrama colaboración crear goleo Diagrama Colaboración Modificar Goleo. Figura 35: Diagrama colaboración modificar goleo.

97 Diagrama colaboración Eliminar Goleo. Figura 36: Diagrama colaboración eliminar goleo Diagrama Colaboración Visualizar Goleo. Figura 37: Diagrama colaboración visualizar goleo.

98 Diagrama Colaboración Crear Posición. Figura 38: Diagrama colaboración crear posicion Diagrama colaboración Modificar Posición. Figura 39: Diagrama colaboración modificar posicion.

99 Diagrama Colaboración Eliminar Posición. Figura 40: Diagrama colaboración eliminar posicion Diagrama colaboración Visualizar Posición. Figura 41: Diagrama colaboración visualizar posicion.

100 Diagrama colaboración Crear Galería. Figura 42: Diagrama colaboración crear galeria Diagrama Colaboración Eliminar Galería. Figura 43: Diagrama colaboración eliminar galeria.

101 Diagrama colaboración Visualizar Galería. Figura 44: Diagrama colaboración visualizar galeria Diagrama colaboración Crear Usuario. Figura 45: Diagrama colaboración crear usuario.

102 Diagrama colaboración Modificar Usuario. Figura 46: Diagrama colaboración modificar usuario. Diagrama colaboración Eliminar Usuario. Figura 47: Diagrama colaboración eliminar usuario.

103 Diagrama colaboración Login Usuario. Figura 48: Diagrama colaboración login usuario Diagramas de Estados (comportamiento dinámico del sistema) Diagrama de Estado Torneo.

104 Figura 49: Diagrama estado torneo Diagrama Estado Equipo. Figura 50: Diagrama colaboración estado equipo Diagrama Estado Participante.

105 Figura 51: Diagrama estado participante Diagrama Estado Programar Fecha. Figura 52: Diagrama estado programar fecha Diagrama Estado Ubicación.

106 Figura 53: Diagrama estado ubicacion Diagrama Estado goleo. Figura 54: Diagrama estado goleo Diagrama Estado Posición. Figura 55: Diagrama estado posicion.

107 Diagrama Estado Galería. Figura 56: Diagrama estado galeria Diagrama Estado Usuario.

108 Figura 57: Diagrama colaboración estado ubicacion Diagrama de Paquetes (comportamiento dinámico del sistema). Figura 58: Diagrama de paquetes Diagrama de Componentes (implementación del sistema). Figura 59: Diagrama componentes.

109 9.3.8 Diagrama Despliegue Figura 60: Diagrama despliegue.

110 9.4 Diseño conceptual Base de datos (Describir la información de la base de datos). Este flujo de actividades describe la información que se administrara en la Base de Datos. La información se define como entidades que tienen características descriptivas llamadas atributos Definición de Entidades. las entidades se registran de cosas mediante una tabla. (.Kroenke., 2003.). que pueden representarse Torneo. Equipo. Participante. Goleo. Posicion_Juego. Programacion_Fecha. Estado. Ubicación. Posicion. Galeria. Multimedia. Usuario. Tipo_usuario.

111 9.4.2 Definición de Atributos por Entidad: una columna de una relación, también llamada columna, campo o elemento de datos. Una propiedad de una entidad (.Kroenke., 2003.) Torneo: ID_Torneo. Nombre_Torneo. Fecha_Inicio. Fecha_Finalizacion. Comentario. Equipo: ID_Equipo. Nombre_Equipo Comentario. Participante: ID_Participante. Nombre. Apellidos. Goleo. ID_Goleo. Cantidad_Goles. Comentario. Posicion_Juego.

112 ID_Posicion_Juego. Descripcion. Programar_Fecha. ID_Programar_Fecha. Fecha_Programada. Hora_Programada. MarcadorUno. MacradorDOs. Equipo_Ganador. Equipo_Perdedor. Estado: ID_Estado. Descripcion. Ubicación. ID_Ubicacion. Nombre_Ubicacion. Direccion. Telefono. Comentario. Posicion.

113 ID_Posicion Posición_Torneo. Partidos_Jugados Cantidad_Puntos Partidos_Ganados Partidos_Perdidos Partidos_Empatados Goles_Anotados Goles_Encontra Diferencia_Goles Galeria: ID_Galeria. Nombre. Direccion_URL Comentario. Multimedia: ID_Multimedia. Descripcion. Usuario:

114 ID_Usuario. Nombre_Usuario. Contraseña. Tipo_Usuario: ID_Tipo Descripcion Descripción de Entidades y Atributos: Torneo: Grupo de participación por equipos en el desarrollo de actividades deportivas durante una consecución de partidos de Futbol. ID_Torneo: Identificador de la entidad Torneo para el sistema Nombre_Torneo: Nombre con el cual se registra un Torneo Fecha_Inicio: Fecha de inicio para un torneo Fecha_Finalizacion: Fecha de finalización para un torneo Comentario: Texto Descriptivo del torneo. Equipo: Grupo de integrantes que participan en un torneo ID_Equipo: Identificador de la entidad Equipo para el sistema. Nombre_Equipo: Nombre de identificación de un equipo. Comentario: Texto descriptivo de un Equipo. Participante: integrante de un Equipo (jugador o entrenador), árbitros o administradores de torneos. ID_Participante: Identificador de la entidad de participantes para el sistema.

115 Nombre: Nombre identificador de un participante. Apellidos: Apellidos de familia de un participante Goleo: registro de participantes anotadores de goles en un partido de futbol. ID_Goleo: Identificador de la entidad Goleo para el sistema. Cantidad_Goles: cantidad de goles anotados por un participante (jugador). Comentario: Texto Descriptivo de un Goleador. Posicion_Juego: posiciones de participantes durante un partido de futbol. ID_Posicion_Juego: Identificador de la entidad posición_juego. Descripcion: tipos deposición de juego(jugador, entrenador, árbitros, administradores) Programar_Fecha: programación de una fecha para el desarrollo de partidos de futbol. ID_Programar_Fecha: identificador de la entidad programar_fecha. Fecha_Programada: fecha de desarrollo de un partido. Hora_Programada: hora de desarrollo de un partido. MarcadorUno: número de goles anotados por un equipo MarcadorDOS: Número de goles anotados por el equipo contrario. Equipo_Ganador: nombre del equipo ganador del partido. Equipo_Perdedor: Nombre del equipo Perdedor del partido. Estado: estado de un partido.

116 ID_Estado: Identificador de la entidad estado para el sistema. Descripcion: estados de tipo (empate, cancelado, desarrollado). Ubicación: lugar de desarrollo de los partidos de futbol de un torneo. ID_Ubicacion: identificador de la entidad ubicación para el sistema. Nombre_Ubicacion: nombre de la ubicación. Direccion: dirección urbana de lugar de partidos. Telefono: número telefónico de lugar de partidos. Comentario: Texto descriptivo de una ubicación. Posicion: ubicación de un equipo durante el desarrollo de un torneo. ID_Posicion: identificador de la entidad posición para el sistema Posición_Torneo: posición de un equipo para un torneo. Partidos_Jugados: número de partidos desarrollados por un equipo. Cantidad_Puntos: número de puntos obtenidos por un equipo durante el torneo. Partidos_Ganados: número de partidos ganados por un equipo. Partidos_Perdidos: número de partidos perdidos por un equipo. Partidos_Empatados: número de partidos empatados por un equipo. Goles_Anotados: cantidad de goles anotados por un equipo. Goles_Encontra: cantidad de goles recibidos por un equipo.

117 Diferencia_Goles: cantidad de goles en diferencia de un equipo. diferencia definida como goles_anotados - goles_encontra. Galeria: conjunto de archivos visuales referentes a torneos. ID_Galeria: identificador de la entidad galería para el sistema. Nombre: Nombre descriptivo de una galería. Direccion_URl: dirección de almacenamiento de un archivo galería. Comentario: Texto descriptivo de galería. Multimedia: tipo de archivo galería. ID_Multimedia: identificación de la entidad multimedia para el sistema. Descripcion: tipo de archivo multimedia para una galería. Multimedia como fotografía, video. Usuario: personal de administración del sistema de información. ID_Usuario: identificador de la entidad usuario para el sistema. Nombre_Usuario: nombre descriptivo de un usuario. Contraseña: clave de acceso al sistema de información. Tipo_Usuario: definición de usuarios. ID_Tipo: identificador de la entidad Tipo_usuario para el sistema. Descripcion: tipos de usuarios como administrador, usuario administrador.

118 9.5 Diseño lógico Base de Datos. El diseño lógico se utiliza para transformar el diseño conceptual en el modelo interno de un sistema de administración de base de datos. (Rob, 2003) 9.5.1Definición de relaciones: Torneo: ID_Torneo. Nombre_Torneo. Fecha_Inicio. Fecha_Finalizacion. Comentario. Equipo: ID_Equipo. Nombre_Equipo Comentario. ID_Torneo (relación entidad torneo) Participante: ID_Participante. Nombre. Apellidos. ID_Torneo(relación entidad torneo) ID_Equipo(relación entidad equipo)

119 ID_Posicion_Juego(relación entidad posición_juego) Goleo. ID_Goleo. Cantidad_Goles. Comentario. ID_Participante(relación entidad participante) ID_Torneo(relación entidad torneo) Posicion_Juego. ID_Posicion_Juego. Descripcion. Programar_Fecha. ID_Programar_Fecha. Fecha_Programada. Hora_Programada. MarcadorUno. MacradorDOs. Equipo_Ganador. Equipo_Perdedor. ID_Equipo1(relación entidad equipo) ID_Equipo2(relación entidad equipo) ID_Ubicacion(relación entidad ubicación) ID_Torneo(relación entidad torneo) ID_Estado(relación entidad estado)

120 Estado: ID_Estado. Descripcion. Ubicación. ID_Ubicacion. Nombre_Ubicacion. Direccion. Telefono. Comentario. Posicion. ID_Posicion Posición_Torneo. Partidos_Jugados Cantidad_Puntos Partidos_Ganados Partidos_Perdidos Partidos_Empatados Goles_Anotados Goles_Encontra Diferencia_Goles ID_Torneo(relación entidad torneo) ID_Equipo(relación entidad equipo)

121 Galeria: ID_Galeria. Nombre. Direccion_URL Comentario. ID_Multimedia(relación entidad multimedia) ID_Ubicacion(relación entidad ubicación) Multimedia: ID_Multimedia. Descripcion. Usuario: ID_Usuario. Nombre_Usuario. Contraseña. ID_Tipo(relación entidad tipo_usuario) Tipo_Usuario: ID_Tipo Descripcion.

122 9.5.2 Modelo Entidad- Relación. El modelo entidad relación se puede definir como: la asociación, vinculación o correspondencia entre entidades (Jose Angel Taboada, 2005) Figura 61: Modelo entidad relacion

123 9.5.3 Modelo Relacional. El modelo relacional se ocupa de tres aspectos principales de la información: la estructura de datos, la manipulación de datos, y la integridad de los datos. (C.J.Date, 2001) Figura 62: Modelo relacional. El modelo presentado es una mala práctica de relación. No representa ninguna relación existente entre las entidades, se debe tener claridad de las relaciones para poder asegurar una integridad de la información a almacenar. Este modelo presenta las relaciones de las entidades con la descripción de sus atributos.

124 9.5.4 Revisión Modelo Relacional. Al implementar el modelo relacional anterior se presentan errores por no aplicar normalización de entidades que conlleva a enfrentar un mal modelado de la estructura de base de datos. Para hacer una revisión de un modelo relacional es una buena práctica implementar las formas normales para el diseño de base de datos. Las formas normales se definen como: Primera forma normal: Una entidad está en 1FN si cada atributo que la constituye, y que no participa como identificador de ella, es dependiente fundamental de dicho indicador. Segunda forma normal: Una entidad está en 2FN si ya está en 1FN y además si todos los atributos que la constituyen, y que no participan como identificador, son dependientes fundamentales de la totalidad del indicador y no de una sola parte de este. Tercera forma normal: Una entidad está en 3FN si está en 2FN y si todos los atributos que la componen, y que no constituyen el identificador, son independientes fundamentales entre sí. Implementando lo anterior se construye el siguiente modelo relacional final.

125 Figura 63: modelo relacional.

126 La representación de las relaciones modeladas en este diseño es definida de la siguiente manera: PK FK1 Usuario ID_Usuario Nombre_Usuario Contraseña ID_Tipo Tipo_Usuario PK ID_Tipo Descripcion Una relación uno a muchos definida por el atributo PK de la entidad Tipo_Usuario referente al atributo FK1 de la entidad Usuario. Aplicando las formas normales mencionadas anteriormente se puede nombrar este modelo relacional como modelo relacional normalizado. Para expresar el resultado del modelo relacional normalizado se muestran los siguientes ejemplos: Primera forma normal: los atributos de la tabla deben contener un solo valor. No aplica la 1FN: Equipo ID_Equipo 1 Nombre_Equipo Barrigol;generación-90 Comentario Barrigol campeón último torneo Si aplica la 1FN: Equipo ID_Equipo 1 Nombre_Equipo Barrigol Comentario Barrigol campeón último torneo

127 Equipo ID_Equipo 2 Nombre_Equipo generación-90 Comentario Generación-90 subcampeón último torneo Segunda forma normal: una clave primaria no debe estar duplicada en una entidad. Tercera forma normal: definir claves primarias pero no hacer redundancia en los atributos de los registros. No aplica 3FN: Usuario ID_Usuario 1 Nombre_Usuario Diego Contraseña ***************** Tipo_Usuario Administrador ID_Tipo_Usuario 1 Si aplica 3FN: Usuario ID_Usuario 1 Nombre_Usuario Diego Contraseña ***************** ID_Tipo_Usuario 1 Tipo_Usuario

128 ID_Tipo_Usuario 1 Descripcion Administrador PK FK1 Usuario ID_Usuario Nombre_Usuario Contraseña ID_Tipo Tipo_Usuario PK ID_Tipo Descripcion La definición de las entidades y atributos con tipos de datos queda definida como: ENTIDAD ATRIBUTO TIPO DE DATO Torneo: Equipo: Participante: Torneo_Equipo_Participante: o ID_Torneo. (numérico) o Nombre_Torneo. (alfanumérico) o Fecha_Inicio. (Fecha) o Fecha_Finalizacion (Fecha) o Comentario. (alfanumérico) o ID_Equipo. (numérico) o Nombre_Equipo (alfanumérico) o Comentario. (alfanumérico) o ID_Participante. (numérico) o Nombre. (texto) o Apellidos. (texto) o ID_Posicion_Juego (numérico) o ID_CombinacionUno. (numérico) o ID_Torneo (numérico) o ID_Equipo (numérico)

129 o ID_Participante (numérico) Goleo. Posicion_Juego. Programar_Fecha. Estado: Ubicación. Posicion. o ID_Goleo. o Cantidad_Goles. o Comentario. o ID_CombinacionUno o ID_Posicion_Juego. o Descripcion. (numérico) (numérico) (alfanumérico) (numérico) (numérico) (texto) o ID_Programar_Fecha (Numérico). o Fecha_Programada. (fecha) o Hora_Programada. (hora) o MarcadorUno. (numérico) o MacradorDOs. (numérico) o Equipo_Ganador. (numérico) o Equipo_Perdedor. (numérico) o ID_Equipo1 (numérico) o ID_Equipo2 (numérico) o ID_Ubicacion (numérico) o ID_Torneo (numérico) o ID_Estado (numérico) o ID_Estado. o Descripcion. o ID_Ubicacion. o Nombre_Ubicacion. o Direccion. o Telefono. o Comentario. o ID_Posicion o Posición_Torneo. (numérico) (texto) (numérico) (alfanumérico) (alfanumérico) (alfanumérico) (alfanumérico) (numérico) (alfanumérico)

130 Galeria: Posicion_Equipo_Torneo: o Partidos_Jugados (numérico) o Cantidad_Puntos (numérico) o Partidos_Ganados (numérico) o Partidos_Perdidos (numérico) o Partidos_Empatados (numérico) o Goles_Anotados (numérico) o Goles_Encontra (numérico) o Diferencia_Goles (numérico) o ID_Galeria. o Nombre. o Direccion_URL o Comentario. o ID_Multimedia o ID_Ubicacion (numérico) (alfanumérico) (alfanumérico) (alfanumérico) (numérico) (numérico) o ID_CombinacionDos. (numérico) o ID_Torneo (numérico) o ID_Equipo (numérico) o ID_Posicion (numérico) Multimedia: o ID_Multimedia. o Descripcion. (numérico) (alfanumérico) Usuario: Tipo_Usuario: o ID_Usuario. o Nombre_Usuario. o Contraseña. o ID_Tipo o ID_Tipo o Descripcion. (numérico) (alfanumérico) (alfanumérico) (numérico) (numérico) (alfanumérico)

131 9.6 Diseño físico Base de datos (consiste en la implementación del modelo de datos (diseño lógico)) Creación documento SQL implementación de Base de Datos. Estructura de tabla para la tabla torneo. CREATE TABLE IF NOT EXISTS `torneo` ( `ID_Torneo` int (11) NOT NULL AUTO_INCREMENT, `Nombre_Torneo` char (15) NOT NULL, `Fecha_Inicio` date NOT NULL, `Fecha_Finalizacion` date NOT NULL, `Comentario` char (40) DEFAULT NULL, PRIMARY KEY (`ID_Torneo`), KEY `Fecha_Inicio` (`Fecha_Inicio`, `Fecha_Finalizacion`) ) Estructura de tabla para la tabla equipo. CREATE TABLE IF NOT EXISTS `equipo` ( `ID_Equipo` int(11) NOT NULL AUTO_INCREMENT, `Nombre_Equipo` char(15) NOT NULL, `Comentario` char(20) DEFAULT NULL, PRIMARY KEY (`ID_Equipo`) )

132 Estructura de tabla para la tabla participante. CREATE TABLE IF NOT EXISTS `participante` ( `ID_Participante` int(11) NOT NULL AUTO_INCREMENT, `Nombre` char(20) NOT NULL, `Apellidos` char(20) NOT NULL, `ID_Posicion_Juego` int(11) NOT NULL, PRIMARY KEY (`ID_Participante`), KEY `participantefk1` (`ID_Posicion_Juego`) ) Estructura de tabla para la tabla posicion_juego. CREATE TABLE IF NOT EXISTS `posicion_juego` ( `ID_Posicion_Juego` int(11) NOT NULL AUTO_INCREMENT, `Descripcion` char(30) NOT NULL, PRIMARY KEY (`ID_Posicion_Juego`) ) Estructura de tabla para la tabla ubicacion. CREATE TABLE IF NOT EXISTS `ubicacion` (

133 `ID_Ubicacion` int(11) NOT NULL AUTO_INCREMENT, Nombre_Ubicacion` char(14) NOT NULL, `Direccion` char(20) NOT NULL, `Telefono` char(15) DEFAULT NULL, `Comentario` char(20) DEFAULT NULL, PRIMARY KEY (`ID_Ubicacion`) ) Estructura de tabla para la tabla torneo_equipo_participante. CREATE TABLE IF NOT EXISTS `torneo_equipo_participante` ( `ID_combinacionUno` int(11) NOT NULL AUTO_INCREMENT, `ID_Equipo` int(11) NOT NULL, `ID_Torneo` int(11) NOT NULL, `ID_Participante` int(11) NOT NULL, PRIMARY KEY (`ID_combinacionUno`), KEY `torneo_equipo_participantefk1` (`ID_Torneo`), KEY `torneo_equipo_participantefk2` (`ID_Equipo`), KEY `torneo_equipo_participantefk3` (`ID_Participante`) ) Estructura de tabla para la tabla `estado`. CREATE TABLE IF NOT EXISTS `estado` (

134 `ID_Estado` int(11) NOT NULL AUTO_INCREMENT, `Descripcion` char(11) NOT NULL, PRIMARY KEY (`ID_Estado`) ) Estructura de tabla para la tabla programar_fecha. CREATE TABLE IF NOT EXISTS `programar_fecha` ( `ID_Programar_Fecha` int(11) NOT NULL AUTO_INCREMENT, `Fecha_Programada` date NOT NULL, `Hora_Programada` time NOT NULL, `MarcadorUno` int(11) DEFAULT NULL, `MacradorDOs` int(11) DEFAULT NULL, `Equipo_Ganador` int(11) DEFAULT NULL, `Equipo_Perdedor` int(11) DEFAULT NULL, `ID_Equipo1` int(11) NOT NULL, `ID_Equipo2` int(11) NOT NULL, `ID_Ubicacion` int(11) NOT NULL, `ID_Torneo` int(11) NOT NULL, `ID_Estado` int(11) NOT NULL, PRIMARY KEY (`ID_Programar_Fecha`), KEY `programarfk1` (`ID_Torneo`), KEY `programarfk2` (`ID_Equipo1`),

135 KEY `programarfk3` (`ID_Equipo2`), KEY `programarfk4` (`ID_Ubicacion`), KEY `programarfk5` (`ID_Estado`) ) Estructura de tabla para la tabla `multimedia`. CREATE TABLE IF NOT EXISTS `multimedia` ( `ID_Multimedia` int(11) NOT NULL AUTO_INCREMENT, `Descripcion` char(15) NOT NULL, PRIMARY KEY (`ID_Multimedia`) ) Estructura de tabla para la tabla `galeria`. CREATE TABLE IF NOT EXISTS `galeria` ( `ID_Galeria` int(11) NOT NULL AUTO_INCREMENT, `Nombre` char(15) NOT NULL, `Direccion_URL` varchar(150) NOT NULL, `Comentario` char(100) DEFAULT NULL, `ID_Multimedia` int (11) NOT NULL, `ID_Ubicacion` int (11) NOT NULL,

136 PRIMARY KEY (`ID_Galeria`), KEY `galeriafk1` (`ID_Ubicacion`), KEY `multimediafk1` (`ID_Multimedia`) ) Estructura de tabla para la tabla `goleo`. CREATE TABLE IF NOT EXISTS `goleo` ( `ID_Goleo` int(11) NOT NULL AUTO_INCREMENT, `Cantidad_Goles` int(11) NOT NULL, `Comentario` char(20) DEFAULT NULL, `ID_Combinacionuno` int(11) NOT NULL, PRIMARY KEY (`ID_Goleo`), KEY `goleofk1` (`ID_Combinacionuno`) ) Estructura de tabla para la tabla `posicion_equipo_torneo`. CREATE TABLE IF NOT EXISTS `posicion_equipo_torneo` ( `ID_CombinacionDos` int(11) NOT NULL AUTO_INCREMENT, `ID_Torneo` int(11) NOT NULL, `ID_Equipo` int(11) NOT NULL, PRIMARY KEY (`ID_CombinacionDos`),

137 KEY `posequi1` (`ID_Torneo`), KEY `posequi2` (`ID_Equipo`) ) Estructura de tabla para la tabla `posicion`. CREATE TABLE IF NOT EXISTS `posicion` ( `ID_Posicion` int(11) NOT NULL AUTO_INCREMENT, `Posición_Torneo` int(11) NOT NULL, `Partidos_Jugados` int(11) NOT NULL, `Cantidad_Puntos` int(11) NOT NULL, `Partidos_Ganados` int(11) NOT NULL, `Partidos_Perdidos` int(11) NOT NULL, `Partidos_Empatados` int(11) NOT NULL, `Goles_Anotados` int(11) NOT NULL, `Goles_Encontra` int(11) NOT NULL, `Diferencia_Goles` int(11) NOT NULL, `ID_CombinacionDos` int(11) NOT NULL, PRIMARY KEY (`ID_Posicion`), KEY `posequi3` (`ID_CombinacionDos`) )

138 Estructura de tabla para la tabla `tipo_usuario`. CREATE TABLE IF NOT EXISTS `tipo_usuario` ( `ID_Tipo` int(11) NOT NULL AUTO_INCREMENT, `Descripcion` char(15) NOT NULL, PRIMARY KEY (`ID_Tipo`) ) Implementación en motor de base de datos. Se implementa la estructura de la base de datos en el motor de base de datos MySQl por la conexión eficiente en servidor apache y programación en lenguaje web PHP. Figura 64: Implementación base de datos. En esta imagen se quiere representar la base de datos a utilizar en una implementación bajo la plataforma phpmyadmin y motor de base de datos MySQL.

139 9.6.3 Pruebas base de Datos Pruebas Implementación Base De Datos. cuando creamos una relación entre tablas podemos activar una característica denominada integridad referencial. Que garantiza que los datos introducidos en las tablas de relación sean correctos. La integridad referencial impide que se introduzca un valor en la tabla relacionada que no exista en la tabla principal. (coronel, 2003) Se realiza una secuencia de creación de registros entre entidades con llaves PK y entidades con FK. Revisando que la creación del registro es exitoso. Prueba integridad entidad Torneo con entidad Torneo_equipo_Participante. Para entender el resultado de la prueba de integridad se genera el siguiente ejemplo: Se puede ver que el torneo La paz esta creado en el registro con ID_Torneo=1. Ahora se crea un registro en la entidadtorneo_equipo_participante y al crear el registro se debe exigir que el Id_Torneo sea igual a 1.si al crear el registro se deja ingresar un ID_Torneo no existente (para el ejemplo diferente de 1).el modelo no cumple la regla de integridad referencial.

140 INSERT INTO `torneitos`. `torneo_equipo_participante` (`ID_combinacionUno`, `ID_Equipo`, `ID_Torneo`, `ID_Participante`) VALUES (NULL, '1', '1', '1'); Prueba integridad entidad Torneo, Equipo con entidad Posicion_equipo_torneo. Registros existentes de la entidad Torneo. Registros existentes de la entidad Equipo. Crear registro en la posicion_equipo_torneo. INSERT INTO `torneitos`.`posicion_equipo_torneo` (`ID_CombinacionDos`, `ID_Torneo`, `ID_Equipo`) VALUES (NULL, '1', '1'); Prueba integridad entidad Torneo, Equipo, ubicación, estado con entidad Programar_fecha.

141 Registros existentes entidad torneo. Registros existentes entidad equipo. Registros existentes entidad ubicación. Registros existentes entidad estado. Crear registro entidad Programar_fecha.

142 INSERT INTO `torneitos`.`programar_fecha` (`ID_Programar_Fecha`, `Fecha_Programada`, `Hora_Programada`, `MarcadorUno`, `MacradorDOs`, `Equipo_Ganador`, `Equipo_Perdedor`, `ID_Equipo1`, `ID_Equipo2`, `ID_Ubicacion`, `ID_Torneo`, `ID_Estado`) VALUES (NULL, ' ', '8:00', NULL, NULL, NULL, NULL, '1', '2', '1', '1', '2'); Pruebas de Rendimiento Base de Datos. las pruebas de rendimiento tiene que diseñarse para asegurar que el sistema pueda procesar su carga esperada. Se ocupan tanto de demostrar que el sistema satisface sus requerimientos. (.Kroenke., 2003.) Se realiza una secuencia de requerimientos funcionales comunes en el rendimiento de una base de datos. Requerimientos como: insertar, eliminar, modificar. Insertar: realizar un INSERT de un registro en una entidad. Sintaxis de INSERT: Insertar registro en la entidad Torneo. Insert into`torneitos`.`torneo` (`ID_Torneo`,`Nombre_Torneo`,`Fecha_Inicio`, `Fecha_Finalizacion`,`Comentario`)VALUES (NULL,'La Paz',' ',' ','torneo de sanlorenzo'); Resultado INSERT:

143 Insertar registro en la entidad Equipo. INSERT INTO `torneitos`. `equipo` (`ID_Equipo`, `Nombre_Equipo`, `Comentario`, `ID_Torneo`) VALUES (NULL,'Barrigol','Campeones','1'); Resultado INSERT: Insertar registro en la entidad participante. INSERT INTO `torneitos`.`participante`(`id_participante`, `Nombre`, `Apellidos`, `ID_Posicion_Juego`) VALUES (NULL,'Diego','Mesa','1'); Resultado INSERT: Modificar: realizar un UPDATE para cambiar el valor de un atributo en registro de una entidad. Sintaxis de UPDATE: Modificar registro de la entidad Ubicación.

144 Registro sin modificar: Registro modificado: UPDATE`torneitos`. `ubicacion` SET` Direccion`='clla38 'WHERE `ubicacion`. `ID_Ubicacion`=1; Modificar registro de la entidad multimedia. Registro sin modificar: Registro modificado: UPDATE`torneitos`.`multimedia` SET` Descripcion`='imagen' WHERE` multimedia`. `ID_Multimedia`=1; Modificar registro de la entidad Estado. Registro sin modificar:

145 Registro modificado: UPDATE`torneitos`.`estado` SET` Descripcion` ='Cancelado' WHERE` estado`.`id_estado`=2; Eliminar: Realizar un DELETE en los registros de una entidad. Sintaxis DELETE: Eliminar un registro de la entidad posición. Registro eliminado: DELETE FROM posicion. 9.7 Desarrollo prototipo (mostrar un valor agregado del proyecto para integrar el análisis y modelo arquitectónico de datos con un prototipo de un sistema de información) Diseño gráfico de interfaces Interface login. Figura 65: Interface login.

146 interface nuevo usuario. Figura 66: Interface nuevo usuario Interface Nuevo torneo. Figura 67: Interface nuevo torneo Interface Nuevo Equipo. Figura 68: Interface nuevo equipo.

147 Interface nuevo Participante. Figura 69: Interface nuevo participante Interface Nuevo Ubicación. Figura 70: Interface nueva ubicacion interface Nueva Fecha. Figura 71: Interface nueva fecha.

148 Interface nueva Galería. Figura 72: interface nueva galeria interface Ingresar Goleador. Figura 73: Interface ingresar goleador interface Visualizar torneo. Figura 74: Interface visualizar torneo.

149 Interface Visualizar Equipo. Figura 75: Interface visualizar equipo Interface Visualizar Ubicación. Figura 76: Interface visualizar ubicacion Interface Visualizar Galería. Figura 77: Interface visualizar galeria.

150 Interface Visualizar Posición. Figura 78: Interface visualizar posicion Interface Visualizar Goleo. Figura 79: Interface visualizar gole Interface Cambiar Contraseña. Figura 80: Interface cambiar contraseña.