Analisis Arquitectonico Informacion Mesa 2013

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
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.

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
Nota de aceptación
__________________________
__________________________
__________________________
__________________________
__________________________
__________________________
__________________________
Firma del jurado
__________________________
Firma del jurado
Medellín, 11de enero de 2013

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.
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.
Contenido
1. JUSTIFICACION. ............................................................................................................. 11
2. PLANTEAMIENTO DEL PROBLEMA. .......................................................................... 12
3. OBJETIVO GENERAL..................................................................................................... 13
4. OBJETIVOS ESPECIFICOS .......................................................................................... 13
5. MARCO REFERENCIAL................................................................................................. 14
5.1 MARCO TEORICO .................................................................................................. 14
5.1.1 METOLOGIAS DE DESARROLLO DE SOFTWARE. ...................................... 14
5.1.2UML ........................................................................................................................... 15
5.1.3Diagramas UML. ...................................................................................................... 15
5.1.4Proceso de desarrollo. ............................................................................................ 16
5.1.5Diseño de base de datos, modelización conceptual de datos ......................... 17
5.1.6Funciones básicas de un torneo de futbol ........................................................... 18
5.1.7Caracterización de la información manejada por un torneo de futbol............. 19
5.1.8Caracterización de usuarios .................................................................................. 21
5.2 Estado del arte. .............................................................................................................. 21
6. DISEÑO METODOLOGICO PRELIMINAR.................................................................. 24
7. CRONOGRAMA. .............................................................................................................. 26
8. PRESUPUESTO. ............................................................................................................. 28
9. ANALISIS Y MODELO ARQUITECTONICO DE DATOS PARA SISTEMA DE
INFORMACION DE TORNEOS DE FUTBOL. .................................................................... 28
9.1 REQUERIMIENTOS (Descripción de necesidades para desarrollo de proyecto).
28
9.2 ANALISIS (Transformación de requisitos en un diseño del sistema) ............. 29
9.2.1 Definición módulos de desarrollo (clasificación de requisitos por módulo de
desarrollo).......................................................................................................................... 29
9.2.2 Requisitos de información (Funcional, no funcional). ................................. 33
9.2.3 Definición de Actores ............................................................................................ 75
9.2.3 Matriz de rastreabilidad objetivos- requisitos de información. .................. 76
9.3 Definición de diagramas UML (Un diagrama es la representación gráfica de un
conjunto de elementos con sus relaciones)................................................................... 78
9.3.2 Diagrama de casos de uso (representación de casos de uso, esto está
diciendo lo que tiene que hacer un sistema y como). ................................................ 78
9.3.3 Diagrama de Clases y objetos (muestra un conjunto de clases, interfaces y
relaciones). ........................................................................................................................ 80
9.3.4 Diagramas de Secuencia (comportamiento dinámico del sistema ........... 81
9.3.6 Diagramas de Estados (comportamiento dinámico del sistema). .......... 103
9.3.7 Diagrama de Paquetes (comportamiento dinámico del sistema). .......... 108
9.3.8 Diagrama de Componentes (implementación del sistema). .................... 108
9.3.9 Diagrama Despliegue ................................................................................... 109
9.4 Diseño conceptual Base de datos (Describir la información de la base de datos).
110
9.4.1 Definición de Entidades....................................................................................... 110
9.4.2 Definición de Atributos por Entidad: .................................................................. 111
9.4.3 Descripción de Entidades y Atributos: .............................................................. 114
9.5 Diseño lógico Base de Datos. .............................................................................. 118
9.5.1Definición de relaciones: ...................................................................................... 118
9.5.2 Modelo Entidad- Relación. ............................................................................ 122
9.5.3 Modelo Relacional. ......................................................................................... 123
9.5.4 Revisión Modelo Relacional. ....................................................................... 124
9.6 Diseño físico Base de datos (consiste en la implementación del modelo de
datos (diseño lógico)) ........................................................................................................ 131
9.6.1 Creación documento SQL implementación de Base de Datos. .................... 131
9.6.2 Implementación en motor de base de datos. ............................................. 138
9.6.3 Pruebas base de Datos. ................................................................................ 139
9.6.3.1Pruebas Implementación Base De Datos ...................................................... 139
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). ....................................................................................................................... 145
9.7.1 Diseño gráfico de interfaces. ............................................................................. 145
9.7.2 Descripción Prototipo. ........................................................................................ 151
10. CONCLUCIONES. ..................................................................................................... 151
11. BIBLIOGRAFIA. .......................................................................................................... 152
LISTA DE ANEXOS. ....................................................................¡Error! Marcador no definido.
LISTA DE IMÁGENES. ...............................................................¡Error! Marcador no definido.
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.
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.
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.
5. MARCO REFERENCIAL.
5.1 MARCO TEORICO
5.1.1 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.
 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.
5.1.2UML.
Este lenguaje se centra en la representación gráfica de un sistema.

Los objetivos de UML son muchos, pero se pueden sintetizar sus
funciones:
 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.
5.1.3Diagramas 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
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
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
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.”
5.1.6Funciones 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
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.
5.1.7Caracterizació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.
 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)
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:www.ligapostobon.com.co 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
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
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”
www.fedefutbolant.com donde se administran torneos, Posiciones de equipos,
resultados de partidos, programación, escuelas.
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).

 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.
 Revisión final del prototipo on-line.
7. CRONOGRAMA.
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
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)
9.2.1 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 Gestionar Torneo

El sistema deberá gestionar los torneos con
la información pertinente a él.
Descripción
Las Operaciones de Gestionar Torneo son:
crear, eliminar, modificar, visualizar.
Estabilidad Alta
Todo usuario con acceso al sistema de
información podrá visualizar la información de
Comentarios
los torneos de futbol registrados en el
sistema.
OBJ-02 Gestionar Equipo
El sistema deberá gestionar los equipos
Descripción participantes en un torneo de futbol registrado
en el sistema de información.
Las Operaciones de Gestionar equipo son:
crear, eliminar, visualizar.
Estabilidad Alta
Todo usuario con acceso al sistema de
Comentarios información podrá visualizar la información de
los torneos de futbol registrados en el sistema.
OBJ-03 Gestionar Participante.

El sistema deberá gestionar los participantes
de un torneo de futbol registrado en el sistema
Descripción de información.
Las Operaciones de Gestionar participante
son: crear, eliminar, modificar, visualizar.
Estabilidad Alta
Los participantes serán jugadores,
Comentarios entrenadores, miembros de equipos (ejemplo:
ayudante, médicos), árbitros.
OBJ-04 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
Descripción
información
Las Operaciones de Gestionar goleador son:
Estabilidad Alta
Tener registro de los goles anotados por
Comentarios
equipos, jugadores en los torneos de futbol.
OBJ-05 Gestionar Programar fecha
El sistema deberá gestionar la programación
de los partidos que se desarrollan en un torneo
Descripción de futbol.
Las Operaciones de Gestionar Programación
fecha son: crear, modificar, visualizar.
Estabilidad Alta
La programación de fechas será la
Comentarios
programación de fechas, partidos y lugares.
OBJ-06 Gestionar Ubicación

El sistema deberá gestionar los lugares donde
se realizaran los partidos programados para un
Descripción torneo de futbol.
Las Operaciones de Gestionar Ubicación son:
Estabilidad Alta
Manejar la información de los lugares con
Comentarios
dirección e imagen.
OBJ-07 Gestionar Posición

El sistema deberá gestionar la tabla de
posiciones de cada torneo de futbol registrado
Descripción en el sistema de información.
Las Operaciones de Gestionar estudiante son:
Estabilidad Alta
Mostrar toda la información que administra una
Comentarios tabla de posiciones como partidos, puntos o
posiciones.
OBJ-08 Gestionar Galería

El sistema deberá gestionar la galería de
multimedia que se maneja en el sistema de
Descripción información.
Estabilidad Alta
Comentarios Todos los archivos multimedia video.
OBJ-09 Gestionar Usuario
El sistema deberá gestionar los usuarios que
interactuaran con el sistema de información.
Descripción
crear, eliminar, modificar, login.
Estabilidad Alta
El usuario administrador será el único
Comentarios permitido para realizar la acción de crear,
eliminar o modificar cada objetivo del sistema.
OBJ-10 Gestionar Seguridad del Sistema

El sistema deberá gestionar la seguridad de
Descripción todas las operaciones disponibles en el
sistema para todos los usuarios, sin excepción.
Estabilidad Alta
Comentarios N/A
9.2.2 Requisitos de información (Funcional, no funcional).
9.2.2.1 Requisitos de Información.
RI-01-01 Información Torneo
OBJ – 01 Gestionar Torneo
OBJ –02 Gestionar equipo
OBJ – 03 Gestionar
participante
OBJ – 04 Gestionar goleo
Objetivos Asociados
programación fecha
OBJ – 06 Gestionar ubicación
OBJ – 07 Gestionar Posición
OBJ – 08 Gestionar Galería
Seguridad del Sistema
RF – 1-01, RF – 1-02, RF – 1-
Requisitos Asociados
03, RF – 1-04
El Sistema deberá almacenar la
Descripción información pertinente a los
torneos.
Id_torneo, nombre_ torneo,
Datos Específicos
fecha_inicio, comentario.
Intervalo Presente
Estabilidad Alta
Comentarios N/A
RI-01-02 Información Equipo
OBJ – 02 Gestionar Equipo
OBJ – 03 Gestionar Participante

Objetivos Asociados
OBJ – 04 Gestionar Goleo
OBJ – 010 Gestionar Seguridad del

Sistema
Requisitos Asociados RF – 2-01,RF – 2-02,RF – 2-03

Descripción
información pertinente a los Equipos.
Datos Específicos Id_Equipo, nombre, comentario.
Intervalo Presente
Estabilidad Alta
Comentarios N/A
Id_torneo, nombre_ torneo, fecha_inicio,
Datos Específicos
comentario.
Intervalo Presente
Estabilidad Alta
Comentarios N/A
RI-01-03 Información Participante

Objetivos Asociados

Sistema
RF – 3-01,RF – 3-02,RF – 3-03,RF – 3-
04
Descripción información pertinente a los
Participantes.
Id_participante, nombre, apellido,
Datos Específicos
posición_juego_torneo .
Intervalo Presente
Estabilidad Alta
Comentarios N/A
Id_torneo, nombre_ torneo, fecha_inicio,
Datos Específicos
comentario.
Intervalo Presente
Estabilidad Alta
Comentarios N/A
RI-01-04 Información Goleo


Objetivos Asociados
OBJ – 05 Gestionar programación fecha

Sistema
RF – 4-01,RF – 4-02,,RF – 4-03RF – 4-
04
Descripción información pertinente a los Participantes
anotadores de goles.
Datos Específicos Id_goleo, cantidad_goles, comentario.
Intervalo Presente
Estabilidad Alta
Comentarios N/A
RI-01-05 Información Programación fecha

Objetivos Asociados
OBJ – 05 Gestionar programación fecha

OBJ – 07 Gestionar posición
OBJ – 010 Gestionar Seguridad del Sistema
Requisitos
RF – 5-01,RF – 5-02,RF – 5-03,RF – 5-04
Asociados
El Sistema deberá almacenar la información

Descripción
pertinente a los Participantes.
Id_programacion_fecha, fecha, hora,

Datos Específicos marador_1, marcador_2, ganador, perdedor,
empate, estado.
Intervalo Presente
Estabilidad Alta
Comentarios N/A
RI-01-06 Información Ubicación

OBJ – 05 Gestionar Programación fecha
Objetivos Asociados
Requisitos
RF – 6-01,RF – 6-02,RF – 6-03
Asociados
Descripción pertinente a la ubicación de desarrollo de un
torneo.
Id_ubicacion, nombre, dirección, teléfono,
Datos Específicos
comentario.
Intervalo Presente
Estabilidad Alta
RI-01-07 Información Posición

OBJ – 05 Gestionar Programación fecha
Objetivos Asociados
OBJ – 07 Gestionar posición
Requisitos
RF – 7-01,RF – 7-02,RF – 7-03,RF – 7-04
Asociados

Descripción
pertinente a la tabla de posiciones de un torneo.
Id_posicion, partidos_jugados, cantidad_puntos,

partidos_ganados, partidos_ perdidos,
Datos Específicos
partidos_empatados, goles_anotados,
goles_encontra, diferencia_goles, posicion.
Intervalo Presente
RI-01-08 Información Galería
BOJ – 08 Gestionar galería
Objetivos Asociados
Requisitos
RF – 8-01,RF – 8-02,RF – 8-03
Asociados

Descripción
pertinente a videos tomados en un torneo.
Id_Galeria, nombre, dirección_url,
Datos Específicos
comentario,fecha_creacion.
Intervalo Presente
RI-01-09 Información usuario

OBJ –02 Gestionar equipo
OBJ – 03 Gestionar participante
Objetivos Asociados OBJ – 05 Gestionar programación fecha

OBJ – 07 Gestionar Posición

OBJ – 09 Gestionar usuario
Requisitos
RF – 9-01,RF – 9-02,RF – 9-03,RF - 9 – 04
Asociados
Descripción
pertinente a los usuarios.
Datos Específicos Nombre_ usuario, contraseña, perfil.
Intervalo Presente
Estabilidad Alta
Comentarios N/A
9.2.2.2 Requerimientos Funcionales.
RF – 1-01 Crear torneo

Objetivos Asociados
Requisitos Asociados RI-01-01 Información Torneo
El sistema deberá comportarse tal como se

describe en el siguiente caso de uso: Cuando el
Descripción
administrador solicite la creación de un Torneo
al aplicativo web
El Torneo no debe estar registrado en el
Precondición
sistema.
Secuencia Normal PASO ACCION
El administrador
solicita al sistema
la creación de
1
torneos para el
despliegue del
formulario
El sistema
despliega
2
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
Postcondición
administrar en el sistema de información.
PASO ACCION
Si el sistema
detecta que el
Excepciones
5 Torno ya existe,
este caso de uso
aborta.
LAPSO DE
PASO
TIEMPO
Rendimiento
3 3 segundos
4 3 segundo
Frecuencia 2 por semestre
Estabilidad Alta
Comentarios N/A
RF – 1-02 Modificar torneo
Objetivos Asociados
Requisitos Asociados RI-01-01 Información Torneo
El sistema deberá comportarse tal como se

describe en el siguiente caso de uso: Cuando el
Descripción
administrador solicite modificar un Torneo al
aplicativo web
Precondición El Torneo debe estar creado.
PASO ACCION
El Administrador
solicita al sistema
modificar los
1
Torneos para el
despliegue del
formulario
El sistema
despliega la
2
información del
Secuencia Normal torneo.
El usuario modifica
3 los campos válidos
para modificar.
El sistema verifica
si los requisitos de
4 campos de
formulario son
válidos.
El sistema modifica
5
el registro del
torneo.
El sistema genera
6 una respuesta para
el usuario
La información del torneo queda modificada

Postcondición
exitosamente.
PASO ACCION
Excepciones
LAPSO DE
PASO
TIEMPO
Rendimiento
3 3 segundos
4 3 segundo
Estabilidad Alta
Comentarios N/A
RF – 1-03 Eliminar torneo

Objetivos
Asociados
Requisitos
Asociados
El sistema deberá comportarse tal como se describe en

Descripción el siguiente caso de uso: Cuando el administrador solicite
eliminar un Torneo al aplicativo web
Secuencia PASO ACCION

Normal
El Administrador solicita al sistema
1
eliminar Torneo
El sistema eliminar todo requisito

2
asociado al torneo.
El sistema genera una respuesta al

3
usuario.
Postcondición La información del torneo queda eliminada exitosamente.
PASO ACCION
Excepciones
PASO LAPSO DE TIEMPO

Rendimiento
2 5 segundos
Estabilidad Alta
Comentarios N/A
RF – 1-04 visualizar torneo

Objetivos
Asociados
Requisitos
Asociados

Descripción el siguiente caso de uso: Cuando un usuario solicite ver
la información de un Torneo al aplicativo web
PASO ACCION
Un usuario solicita al sistema mostrar

1
Secuencia la información de un torneo
Normal
El sistema despliega la información
2
del torneo.
Postcondición La información del torneo queda visible exitosamente.
Excepciones PASO ACCION

Rendimiento
2 3 segundos

Estabilidad Alta
Comentarios N/A
RF – 2-01 Crear equipo

OBJ-02 Gestionar equipo
Objetivos
Asociados
Requisitos
RI-01-02 Información equipo
Asociados
El sistema deberá comportarse tal como se describe en el

Descripción siguiente caso de uso: Cuando el administrador solicite la
creación de un equipo al aplicativo web
Precondición El Torneo no debe estar registrado en el sistema.
PASO ACCION
El administrador solicita al sistema la
1 creación de equipos para el despliegue
del formulario
El sistema despliega formulario para la

2
creación de equipo
El sistema verifica si los requisitos de

3
campos de formularios son válidos.
Secuencia
Normal
El sistema valida la existencia del

4
equipo a crear
5 El sistema crea el equipo.

6
usuario
PASO ACCION
Excepciones Si el sistema detecta que el equipo ya
5
existe, este caso de uso aborta.
RF – 2-02 Eliminar equipo

Objetivos
Asociados
Requisitos
Asociados

Descripción el siguiente caso de uso: Cuando el administrador solicite
eliminar un equipo al aplicativo web
Precondición El equipo debe estar creado.
PASO ACCION

1
eliminar equipo
Secuencia
Normal El sistema eliminar todo requisito
2
asociado al equipo.

3
usuario.
Postcondición La información del equipo queda eliminada exitosamente.
PASO ACCION
Excepciones

Rendimiento
2 5 segundos
Estabilidad Alta
Comentarios N/A
RF – 2-03 visualizar equipo

Objetivos
Asociados
Requisitos
Asociados

la información de un equipo al aplicativo web
PASO ACCION

1
Secuencia la información de un equipo
Normal
2
del equipo.
Postcondición La información del equipo es visible exitosamente.

Rendimiento
2 3 segundos

Estabilidad Alta
Comentarios N/A
RF – 3-01 Crear Participante

Objetivos
OBJ-03 Gestionar Participante
Asociados
Requisitos
Asociados
el siguiente caso de uso: Cuando el administrador solicite
Descripción
la creación de un Participante de un torneo al aplicativo
web
Precondición El participante no debe estar registrado en el sistema.

PASO ACCION

1 creación de participantes para el
despliegue del formulario

2
Secuencia creación de participante
Normal
3
5 El sistema crea el Participante.

6
usuario
El participante queda registrado como participante de un

Postcondición
torneo para administrar en el sistema de información.
PASO ACCION
Excepciones Si el sistema detecta que el
5 Participante ya existe, este caso de
uso aborta.
RF – 3-02 Modificar Participante

Objetivos
Asociados
Requisitos
Asociados
El sistema deberá comportarse tal como se describe

en el siguiente caso de uso: Cuando el administrador
Descripción
solicite modificar un participante de un Torneo al
aplicativo web
Precondición El Participante debe estar creado.
PASO ACCION
modificar los Participantes de un
1
torneo para el despliegue del
formulario
2
de un participante.
Secuencia El usuario modifica los campos
3
Normal válidos para modificar.
4
campos de formulario son válidos.
El sistema modifica el registro del
5
Participante.
El sistema genera una respuesta
6
para el usuario
La información del Participante queda modificada

Postcondición
exitosamente.

Rendimiento
3 3 segundos
RF – 3-04 visualizar Participante
Objetivos
Asociados
Requisitos
RI-01-03 Información participante
Asociados
la información de un Participante al aplicativo web
Precondición El Participante debe estar creado.

PASO ACCION
Un usuario solicita al sistema
1 mostrar la información de un
Secuencia Participante
Normal
El sistema despliega la
2
información del Participante.
Postcondición La información del Participante es visible exitosamente.

Rendimiento
2 3 segundos
Estabilidad Alta
Comentarios N/A
RF – 4-01 Crear Goleo

Objetivos
Asociados
Requisitos
RI-01-04 Información goleo
Asociados
creación de un goleador de un torneo al aplicativo web
Precondición El goleador no debe estar registrado en el sistema.
PASO ACCION
1 creación de registro de goleo para el
2
creación de registro de goleo

3
Secuencia
Normal
El sistema valida la existencia del goleo
4
a crear
5 El sistema crea el equipo.

6
usuario
PASO ACCION
Excepciones Si el sistema detecta que el registro de
5 goleo ya existe, este caso de uso
aborta.
RF – 4-02 Modificar goleo
Objetivos
OBJ-04 Gestionar Goleo
Asociados
Requisitos
Asociados
El sistema deberá comportarse tal como se describe
en el siguiente caso de uso: Cuando el administrador
Descripción
solicite modificar un registro de goleo de un Torneo
al aplicativo web
Precondición El registro de goleo debe estar creado.
PASO ACCION
modificar los registros de goleo de un
1
torneo para el despliegue del
formulario

2
de un registro de goleo.
Secuencia El usuario modifica los campos
Normal 3
válidos para modificar.
4
5
goleo.
El sistema genera una respuesta para
6
el usuario
La información de goleo queda modificada

Postcondición
exitosamente.

Rendimiento
3 3 segundos
RF – 4-03 Eliminar goleo

Objetivos
OBJ-04 Gestionar Goleo
Asociados
Requisitos
Asociados

Descripción siguiente caso de uso: Cuando el administrador solicite
eliminar un registro de goleo de un torneo al aplicativo web
PASO ACCION

1
eliminar Goleo
Secuencia
2
asociado al goleo.

3
usuario.
Postcondición La información de goleo queda eliminada exitosamente.
PASO ACCION
Excepciones

Rendimiento
2 5 segundos
RF – 4-04 visualizar Goleo

Objetivos
Asociados
Requisitos
Asociados

siguiente caso de uso: Cuando un usuario solicite ver la
Descripción
información de un registro de goleo de un torneo al
aplicativo web
Precondición El Torneo y registro de goleo debe estar creado.
PASO ACCION
Secuencia 1
la información de un registro de goleo
Normal
El sistema despliega la información de
2
goleo.
Postcondición La información de goleo es visible exitosamente.

Rendimiento
2 3 segundos
Estabilidad Alta
Comentarios N/A
RF – 5-01 Crear Programación fecha
Objetivos OBJ-05 Gestionar Programar fecha

Asociados
Requisitos
RI-01-05 Información Programar fecha
Asociados
siguiente caso de uso: Cuando el administrador solicite la
Descripción
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

Precondición
registrada en el sistema.
PASO ACCION
1 creación de registro de programación de
fecha para el despliegue del formulario

2 creación de registro de programación
fecha

3
Secuencia
Normal
El sistema valida la existencia de la

4
programación a crear
5 El sistema crea la fecha de los partidos.

6
usuario
PASO ACCION
Excepciones Si el sistema detecta que el registro de
5 programación fecha para partido ya
RF – 5-02 Modificar Programación fecha

Objetivos
Asociados
Requisitos
Asociados
siguiente caso de uso: Cuando el administrador solicite
Descripción
modificar un registro de programación departido de un
Torneo al aplicativo web
Precondición El registro de programación debe estar creado.
PASO ACCION

modificar los registros de programar
1
fecha de partido de un torneo para el
2
un registro de programación fecha.
Secuencia El usuario modifica los campos válidos
Normal 3
para modificar.

4

5
programación fecha.
El sistema genera una respuesta para el
6
usuario
La información de programación fecha queda modificada

Postcondición
exitosamente.
Rendimiento PASO LAPSO DE TIEMPO

3 3 segundos
RF – 5-03 Eliminar Programar fecha

Objetivos
Asociados
Requisitos
Asociados

Descripción
eliminar un registro de programación fecha de un torneo o
eliminar un torneo al aplicativo web
PASO ACCION
El Administrador solicita al sistema eliminar

1
Programación de fecha o eliminar torneo
Secuencia
Normal El sistema eliminar todo requisito asociado a la
2
programación de fecha.
3 El sistema genera una respuesta al usuario.
La información de programar fecha queda eliminada

Postcondición
exitosamente.
PASO ACCION
Excepciones

Rendimiento
2 5 segundos
RF – 5-04 visualizar Programar fecha
OBJ-05 Gestionar programar fecha

Objetivos
Asociados
Requisitos
Asociados

Descripción
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
Precondición
creado.
PASO ACCION
Un usuario solicita al sistema mostrar la
1 información de un registro de
Secuencia
programación fecha
Normal
2
programación.
La información de Programación fecha de partidos por

Postcondición
torneo es visible exitosamente.

Rendimiento
2 3 segundos

Estabilidad Alta
Comentarios N/A
RF – 6-01 Crear Ubicación

Objetivos
Asociados
Requisitos
Asociados

Descripción
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

Precondición
estar creada.
PASO ACCION
creación de ubicación para el desarrollo
1
de partidos de un torneo para el

2
creación de ubicación.

Secuencia 3
Normal

4
ubicación a crear
El sistema crea la ubicación de

5
desarrollo e partidos.
6
usuario
PASO ACCION
Excepciones
5 Si el sistema detecta que la ubicación
ya existe, este caso de uso aborta.
RF – 6-02 Eliminar Ubicación
OBJ-06 Gestionar ubicación

Objetivos
Asociados
Requisitos
RI-01-06 Información ubicación
Asociados

eliminar un torneo o una ubicación al aplicativo web
Precondición El torneo o la ubicación deben estar creado.
PASO ACCION
1
eliminar ubicación
Secuencia
2
asociado a la ubicación.

3
usuario.
La información de la ubicación queda eliminada

Postcondición
exitosamente.
PASO ACCION
Excepciones

Rendimiento
2 5 segundos
RF – 6-03 visualizar Ubicación

Objetivos
Asociados
Requisitos
Asociados

Descripción
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
Un usuario solicita al sistema mostrar la

1 información de un registro de
programación fecha
Secuencia
Normal

2
programación.
La información de Programación fecha de partidos por

Postcondición
torneo es visible exitosamente.

Rendimiento
2 3 segundos
Estabilidad Alta
Comentarios N/A
RF – 7-01 Crear Posición
Objetivos OBJ-07 Gestionar Posición

Asociados
Requisitos
Asociados
Descripción
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
Precondición
estar creada.
PASO ACCION

creación de una posición para un equipo
1
de un torneo para el despliegue del
formulario
2
creación de una posición para un equipo.
3
Secuencia
Normal

4
ubicación a crear del equipo
5 El sistema crea la posición de un equipo.

6
usuario
PASO ACCION
5 tiene una posición creada ya existe,
este caso de uso aborta.
RF – 7-02 Eliminar Posición

Objetivos
Asociados
Requisitos
Asociados
Descripción
eliminar un torneo o una posición de un equipo al
aplicativo web
Precondición El torneo o la ubicación debe estar creado.
PASO ACCION
1
eliminar un torneo
Secuencia
2
asociado a la torneo.
3
usuario.
Postcondición La información del torneo queda eliminada exitosamente.
PASO ACCION
Excepciones

Rendimiento
2 5 segundos
RF – 7-03 visualizar Posición

Objetivos
Asociados
Requisitos
Asociados
Descripción
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
Precondición
creado.
PASO ACCION
Secuencia Un usuario solicita al sistema mostrar

Normal 1 la información de un registro de
posición de un equipo en un torneo

2
posición.
La información de Posición de equipos por torneo es

Postcondición
visible exitosamente.

Rendimiento
2 3 segundos

Estabilidad Alta
Comentarios N/A
RF – 7-04 Modificar posición

OBJ-07 Gestionar posición
Objetivos
Asociados
Requisitos
RI-01-07 Información posición
Asociados
Descripción
modificar una posición de un equipo en un Torneo al
aplicativo web
Precondición El Torneo, el equipo y la posición deben estar creado.
PASO ACCION

1 modificar la posición de un equipo por un
torneo para el despliegue del formulario
Secuencia 2
Posición.
Normal El usuario modifica los campos válidos
3
para modificar.
4
5
Posición.
6
usuario
La información del torneo con respecto a la tabla de

Postcondición
posiciones queda modificada exitosamente.
PASO ACCION
Excepciones
RF – 8-01 Crear galería

OBJ-08 Gestionar galería
Objetivos
Asociados
Requisitos
RI-01-08 Información galería
Asociados
Descripción
creación de una registro de galería ( video) de un torneo al
aplicativo web
Precondición El registro de galería no debe estar creada.
PASO ACCION

1 creación de un registro de galería para el

2
creación de galería.

3
Secuencia
Normal
El sistema valida la existencia del registro

4
de la galeria
5 El sistema crea la posición de un equipo.

6
usuario
PASO ACCION
5 tiene un registro de galería ya creada
idénticamente, este caso de uso aborta.
RF – 8-02 visualizar galería

Objetivos
Asociados
Requisitos
RI-01-078Información Galería.
Asociados

Descripción
información de una imagen o video de un equipo en un
torneo al aplicativo web
Precondición El registro de galería por torneo debe estar creado.
PASO ACCION
Secuencia 1 la información de un registro de galería
Normal (imagen o video) de un torneo
2
Galería.
Postcondición La información de Registro galería es visible exitosamente.

Rendimiento
2 3 segundos
Estabilidad Alta
Comentarios N/A
RF – 8-03 Eliminar galería

Objetivos
Asociados
Requisitos
RI-01-08 Información Galería
Asociados

eliminar un registro de galería al aplicativo web
Precondición El registro de galería debe estar creado.
PASO ACCION

1
eliminar un torneo o registro de galería
Secuencia El sistema eliminar todo requisito

Normal 2
asociado a la torneo o a la galería.

3
usuario.
La información del torneo o dela galería queda eliminada

Postcondición
exitosamente.
PASO ACCION
Excepciones

Rendimiento
2 5 segundos
RF – 9-01 Crear usuario

Objetivos
OBJ-09 Gestionar usuario
Asociados
Requisitos
Asociados

creación de un usuario que administrara al aplicativo web
Precondición El usuario no debe estar creado.
PASO ACCION

1 creación de un usuario para el despliegue
del formulario
2
creación de usuario.

3
Secuencia
Normal
El sistema valida la existencia del registro

4
de la usuario
El sistema crea un nuevo usuario

5
administrador.

6
usuario
PASO ACCION
Excepciones Si el sistema detecta que el usuario ya
5
RF – 9-02 Modificar contraseña usuario.
OBJ-09 Gestionar usuario

Objetivos
Asociados
Requisitos
Asociados

modificar su contraseña de usuario aplicativo web
Precondición El usuario debe estar creado.
PASO ACCION

1 modificar su contraseña para el

2
usuario.
Secuencia
El usuario modifica los campos válidos
Normal 3
para modificar.

4
5
contraseña de usuario.
6
usuario
La información del usuario queda modificada

Postcondición
exitosamente.
RF – 9-03 Eliminar usuario

Objetivos
Asociados
Requisitos
RI-01-09 Información Usuario
Asociados

eliminar un usuario al aplicativo web
PASO ACCION
1
eliminar un usuario
Secuencia
El sistema eliminar todo requisito
Normal 2
asociado a un usuario.

3
usuario.
Postcondición La información del usuario queda eliminada exitosamente.
PASO ACCION
Excepciones

Rendimiento
2 5 segundos
RF – 9-04 Login usuario

Objetivos
Asociados
Requisitos
RI-01-09 Información Usuario
Asociados
Descripción siguiente caso de uso: Cuando el usuario administrador
solicite ingresar al aplicativo web administrador

PASO ACCION
El Administrador solicita al sistema hacer
1
login usuario y contraseña
El sistema despliega el formulario de

2
Secuencia login de usuario.
Normal
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
Postcondición
exitosamente.
PASO ACCION
Excepciones El usuario o contraseña no existen, este
4
caso de uso aborta
9.2.2.3 Requerimientos no Funcionales.
RNF-01 Copias de seguridad
Objetivos
N/A.
asociados:
Requisitos
N/A.
asociados:
El sistema deberá crear cada cierto lapso de tiempo,
Descripción:
la realización de una copia de seguridad.
Aun no se ha definido con el cliente el tiempo y

Comentarios:
forma para la realización de la copia de seguridad.
RNF-02 Hosting (Dominio)

OBJ-01 Gestionar Estudiante
OBJ- 02 Gestionar Documento

Objetivos
asociados:
OBJ – 03 Gestionar Docente
RI-01-01 Información Estudiante

Requisitos
RI-01-02 Información Docente
asociados:
RI -02 Información Documento
El sistema necesitara de un espacio de alojamiento

Descripción:
web.
El sistema requiere que su hosting sea de gran

Comentarios: almacenamiento, a su vez que permitir la interacción
con bases de datos de MySQL.
RNF-03 Servidor de base de datos

Objetivos
N/A.
asociados:
Requisitos
N/A.
asociados:
El sistema requerirá un almacenamiento de datos para
Descripción:
la información del aplicativo.
La base de datos deberá tener compatibilidad con el

Comentarios: servidor web (hosting) para garantizar el rendimiento
deseado.
RNF-04 Web application Sever
Objetivos
N/A.
asociados:
Requisitos
N/A.
asociados:
El sistema requerirá un servidor para poder correr los

Descripción:
servicios que se tienen en el aplicativo.
El web server debe tener compatibilidad con la base de

Comentarios:
datos y fácil manejo con el hosting
RNF-05 Ancho de Banda
Objetivos
N/A.
asociados:
Requisitos
N/A.
asociados:
El sistema requerirá un ancho de banda como mínimo

Descripción:
de 500 kb/s
Comentarios: N/A
RNF-06 Versión de Navegador

Objetivos
N/A.
asociados:
Requisitos
N/A.
asociados:
El sistema estará diseñado para ejecutarse
Descripción:
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.
9.2.3 Definición de Actores.
ACT-01 Web Máster
Descripción Este Actor representa la persona encargada de controlar

la seguridad del sistema.
Comentarios Un web máster debe velar por la disponibilidad,

funcionamiento, y posibles cambios en la aplicación.
ACT-02 Administrador
Descripción 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
torneo, gestión de usuario.
ACT-03 Visitante
Descripción 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.
9.2.3 Matriz de rastreabilidad objetivos- requisitos de información.
MATRIZ DE RASTREABILIDAD
OBJ- OBJ- OBJ- OBJ- OBJ- OBJ- OBJ- OBJ- OBJ- OBJ-
01 02 03 04 05 06 07 08 09 10
RI-01-01
RI-01-02
RI-01-03
RI-01-04
RI-01-05
RI-01-06
RI-01-07
RI-01-08
RI-01-09
RF – 1-01
RF – 1-02
RF – 1-03
RF – 1-04
RF – 2-01
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 - 9 –
04
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
9.3 Definición de diagramas UML (Un diagrama es la representación
gráfica de un conjunto de elementos con sus relaciones).
9.3.1 Subsistema General (descripción del sistema en la unificación de la

definición de módulos de desarrollo).
Figura 2: Subsistema general
9.3.2 Diagrama de casos de uso(representación de casos de uso, esto

está diciendo lo que tiene que hacer un sistema y como).
9.3.2.1 Diagrama Caso de Uso Administrador.
Figura 3: Diagrama caso de uso administrador
9.3.2.2 Diagrama Caso de Uso Visitante.
Figura 4: Diagrama caso de uso Visitante

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

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

9.3.3.1 Diagrama Secuencia Torneo.
Figura 7: Diagrama secuencia torneo
9.3.3.2 Diagrama Secuencia Equipo.

Figura 8: Diagrama Secuencia Equipo.
9.3.3.3 Diagrama Secuencia Participante.
Figura 9: Diagrama secuencia participante.
9.3.3.4 Diagrama Secuencia Ubicación.

Figura 10: Diagrama secuencia ubicación.
9.3.3.5 Diagrama Secuencia Programación Fecha.
Figura 11: Diagrama secuencia programación fecha.
9.3.3.6 Diagrama secuencia Goleo.

Figura 12: Diagrama secuencia goleo.
9.3.3.7 Diagrama Secuencia Posición.
Figura 13: Diagrama secuencia posicion.
9.3.3.8 Diagrama Secuencia Galería.

Figura 14: Diagrama secuencia galeria.
9.3.3.9 Diagrama Secuencia Usuario.
Figura 15 : Diagrama secuencia usuario.
9.3.4 Diagramas de Colaboración (comportamiento dinámico del
sistema)
9.3.4.1 Diagrama Colaboración Crear Torneo.
Figura 16: Diagrama colaboración crear torneo.
9.3.4.2 Diagrama Colaboración Modificar Torneo.

Figura 17: Diagrama colaboración modificar torneo.
9.3.4.3 Diagrama Colaboración Eliminar Torneo.
Figura 18: Diagrama colaboración eliminar torneo.
9.3.4.4 Diagrama Colaboración Visualizar Torneo.
Figura 19: Diagrama colaboración visualizar torneo.
9.3.4.5 Diagrama Colaboración Crear Equipo.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.3.6.1 Diagrama de Estado Torneo.
Figura 49: Diagrama estado torneo.
9.3.5.2 Diagrama Estado Equipo.

Figura 50: Diagrama colaboración estado equipo.
9.3.5.3 Diagrama Estado Participante.

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

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

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

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

Figura 59: Diagrama componentes.
9.3.8 Diagrama Despliegue
Figura 60: Diagrama despliegue.

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.
9.4.1 Definición de Entidades.
“las entidades se registran de cosas que pueden representarse

mediante una tabla.”(.Kroenke., 2003.).
 Torneo.
 Equipo.
 Participante.
 Goleo.
 Posicion_Juego.
 Programacion_Fecha.
 Estado.
 Ubicación.
 Posicion.
 Galeria.
 Multimedia.
 Usuario.
 Tipo_usuario.
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.
 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.
 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:
 ID_Usuario.
 Nombre_Usuario.
 Contraseña.
 Tipo_Usuario:
 ID_Tipo
 Descripcion.
9.4.3 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.
 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.

 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.

 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.
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)

 ID_Posicion_Juego(relación entidad posición_juego)
 Goleo.
 ID_Goleo.
 Cantidad_Goles.
 Comentario.
 ID_Participante(relación entidad participante)
 Posicion_Juego.
 ID_Posicion_Juego.
 Descripcion.
 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_Estado(relación entidad estado)

 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_Equipo(relación entidad equipo)

 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.
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

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.
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.

Figura 63: modelo relacional.
La representación de las relaciones modeladas en este diseño es definida
de la siguiente manera:
Usuario
Tipo_Usuario
PK ID_Usuario
PK ID_Tipo
Nombre_Usuario
Contraseña Descripcion
FK1 ID_Tipo
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
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
ID_Tipo_Usuario 1
Descripcion Administrador
Usuario
Tipo_Usuario
PK ID_Usuario
PK ID_Tipo
Nombre_Usuario
Contraseña Descripcion
FK1 ID_Tipo
La definición de las entidades y atributos con tipos de datos queda definida

como:
ENTIDAD ATRIBUTO TIPO DE DATO
 Torneo:
o ID_Torneo . (numérico)
o Nombre_Torneo . (alfanumérico)
o Fecha_Inicio . (Fecha)
o Fecha_Finalizacion (Fecha)
o Comentario. (alfanumérico)
 Equipo:
o ID_Equipo . (numérico)
o Nombre_Equipo (alfanumérico)
o Comentario . (alfanumérico)
 Participante:
o ID_Participante . (numérico)
o Nombre . (texto)
o Apellidos . (texto)
o ID_Posicion_Juego (numérico)
Torneo_Equipo_Participante:
o ID_CombinacionUno
. (numérico)
o ID_Torneo (numérico)
o ID_Equipo (numérico)
o ID_Participante (numérico)
 Goleo.
o ID_Goleo . (numérico)
o Cantidad_Goles . (numérico)
o ID_CombinacionUno (numérico)
 Posicion_Juego.
o ID_Posicion_Juego . (numérico)
o Descripcion . (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_Estado (numérico)
 Estado:
o ID_Estado . (numérico)
o Descripcion . (texto)
 Ubicación.
o ID_Ubicacion . (numérico)
o Nombre_Ubicacion . (alfanumérico)
o Direccion . (alfanumérico)
o Telefono . (alfanumérico)
 Posicion.
o ID_Posicion (numérico)
o Posición_Torneo . (alfanumérico)
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)
 Galeria:
o ID_Galeria . (numérico)
o Nombre . (alfanumérico)
o Direccion_URL (alfanumérico)
o ID_Multimedia (numérico)
o ID_Ubicacion (numérico)
 Posicion_Equipo_Torneo:
o ID_CombinacionDos
. (numérico)
o ID_Equipo (numérico)
o ID_Posicion (numérico)
 Multimedia:
o ID_Multimedia . (numérico)
o Descripcion . (alfanumérico)
 Usuario:
o ID_Usuario . (numérico)
o Nombre_Usuario . (alfanumérico)
o Contraseña . (alfanumérico)
o ID_Tipo (numérico)
 Tipo_Usuario:
o ID_Tipo (numérico)
o Descripcion . (alfanumérico)
9.6 Diseño físico Base de datos (consiste en la implementación del
modelo de datos (diseño lógico))
9.6.1 Creación documento SQL implementación de Base de Datos.
Estructura de tabla para la tabla torneo.
CREATE TABLE IF NOT EXISTS `torneo`

(
ÌD_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 (ÌD_Torneo`),
KEY `Fecha_Inicio` (`Fecha_Inicio`, `Fecha_Finalizacion`)
)
Estructura de tabla para la tabla equipo.
CREATE TABLE IF NOT EXISTS èquipo`
ÌD_Equipo` int(11) NOT NULL AUTO_INCREMENT,
`Nombre_Equipo` char(15) NOT NULL,
`Comentario` char(20) DEFAULT NULL,
PRIMARY KEY (ÌD_Equipo`)
)
Estructura de tabla para la tabla participante.
CREATE TABLE IF NOT EXISTS `participante`
ÌD_Participante` int(11) NOT NULL AUTO_INCREMENT,
`Nombre` char(20) NOT NULL,
Àpellidos` char(20) NOT NULL,
ÌD_Posicion_Juego` int(11) NOT NULL,
PRIMARY KEY (ÌD_Participante`),
KEY `participanteFK1` (ÌD_Posicion_Juego`)
Estructura de tabla para la tabla posicion_juego.
CREATE TABLE IF NOT EXISTS `posicion_juego`
ÌD_Posicion_Juego` int(11) NOT NULL AUTO_INCREMENT,
`Descripcion` char(30) NOT NULL,
PRIMARY KEY (ÌD_Posicion_Juego`)
Estructura de tabla para la tabla ubicacion.
CREATE TABLE IF NOT EXISTS ùbicacion`
(
ÌD_Ubicacion` int(11) NOT NULL AUTO_INCREMENT,
„Nombre_Ubicacion` char(14) NOT NULL,
`Direccion` char(20) NOT NULL,
`Telefono` char(15) DEFAULT NULL,
PRIMARY KEY (ÌD_Ubicacion`)
Estructura de tabla para la tabla torneo_equipo_participante.
CREATE TABLE IF NOT EXISTS `torneo_equipo_participante`
ÌD_combinacionUno` int(11) NOT NULL AUTO_INCREMENT,
ÌD_Equipo` int(11) NOT NULL,
ÌD_Torneo` int(11) NOT NULL,
ÌD_Participante` int(11) NOT NULL,
PRIMARY KEY (ÌD_combinacionUno`),
KEY `torneo_equipo_participanteFK1` (ÌD_Torneo`),
KEY `torneo_equipo_participanteFK2` (ÌD_Equipo`),
KEY `torneo_equipo_participanteFK3` (ÌD_Participante`)
Estructura de tabla para la tabla èstado`.
CREATE TABLE IF NOT EXISTS èstado`
(
ÌD_Estado` int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (ÌD_Estado`)
Estructura de tabla para la tabla programar_fecha.
CREATE TABLE IF NOT EXISTS `programar_fecha`
ÌD_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,
Èquipo_Ganador` int(11) DEFAULT NULL,
Èquipo_Perdedor` int(11) DEFAULT NULL,
ÌD_Equipo1` int(11) NOT NULL,
ÌD_Equipo2` int(11) NOT NULL,
ÌD_Ubicacion` int(11) NOT NULL,
ÌD_Estado` int(11) NOT NULL,
PRIMARY KEY (ÌD_Programar_Fecha`),
KEY `programarFK1` (ÌD_Torneo`),
KEY `programarFK2` (ÌD_Equipo1`),

KEY `programarFK3` (ÌD_Equipo2`),
KEY `programarFK4` (ÌD_Ubicacion`),
KEY `programarFK5` (ÌD_Estado`)
Estructura de tabla para la tabla `multimedia`.
CREATE TABLE IF NOT EXISTS `multimedia`
ÌD_Multimedia` int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (ÌD_Multimedia`)
Estructura de tabla para la tabla `galeria`.
CREATE TABLE IF NOT EXISTS `galeria`
ÌD_Galeria` int(11) NOT NULL AUTO_INCREMENT,
`Nombre` char(15) NOT NULL,
`Direccion_URL` varchar(150) NOT NULL,
ÌD_Multimedia` int (11) NOT NULL,
ÌD_Ubicacion` int (11) NOT NULL,

PRIMARY KEY (ÌD_Galeria`),
KEY `galeriaFK1` (ÌD_Ubicacion`),
KEY `multimediaFK1` (ÌD_Multimedia`)
Estructura de tabla para la tabla `goleo`.
CREATE TABLE IF NOT EXISTS `goleo`
ÌD_Goleo` int(11) NOT NULL AUTO_INCREMENT,
`Cantidad_Goles` int(11) NOT NULL,
ÌD_Combinacionuno` int(11) NOT NULL,
PRIMARY KEY (ÌD_Goleo`),
KEY `goleoFK1` (ÌD_Combinacionuno`)
Estructura de tabla para la tabla `posicion_equipo_torneo`.
CREATE TABLE IF NOT EXISTS `posicion_equipo_torneo`
ÌD_CombinacionDos` int(11) NOT NULL AUTO_INCREMENT,
ÌD_Equipo` int(11) NOT NULL,
PRIMARY KEY (ÌD_CombinacionDos`),

KEY `posequi1` (ÌD_Torneo`),
KEY `posequi2` (ÌD_Equipo`)
Estructura de tabla para la tabla `posicion`.
CREATE TABLE IF NOT EXISTS `posicion`
ÌD_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,
ÌD_CombinacionDos` int(11) NOT NULL,
PRIMARY KEY (ÌD_Posicion`),
KEY `posequi3` (ÌD_CombinacionDos`)
)
Estructura de tabla para la tabla `tipo_usuario`.
CREATE TABLE IF NOT EXISTS `tipo_usuario`
ÌD_Tipo` int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (ÌD_Tipo`)
9.6.2 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.
9.6.3 Pruebas base de Datos.
9.6.3.1Pruebas 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.
INSERT INTO `torneitos`. `torneo_equipo_participante`
(ÌD_combinacionUno`, ÌD_Equipo`, ÌD_Torneo`, ÌD_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` (ÌD_CombinacionDos`,

ÌD_Torneo`, ÌD_Equipo`) VALUES (NULL, '1', '1');
Prueba integridad entidad Torneo, Equipo, ubicación, estado con

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

INSERT INTO `torneitos`.`programar_fecha` (ÌD_Programar_Fecha`,
`Fecha_Programada`, `Hora_Programada`, `MarcadorUno`,
`MacradorDOs`, Èquipo_Ganador`, Èquipo_Perdedor`, ÌD_Equipo1`,
ÌD_Equipo2`, ÌD_Ubicacion`, ÌD_Torneo`, ÌD_Estado`) VALUES (NULL,
'2012-10-06', '8:00', NULL, NULL, NULL, NULL, '1', '2', '1', '1', '2');
9.3.6.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`
(ÌD_Torneo`,`Nombre_Torneo`,`Fecha_Inicio`,
`Fecha_Finalizacion`,`Comentario`)VALUES (NULL,'La Paz','2012-08-
08','2012-12-08','torneo de sanlorenzo');
Resultado INSERT:
Insertar registro en la entidad Equipo.
INSERT INTO `torneitos`. èquipo` (ÌD_Equipo`, `Nombre_Equipo`,
`Comentario`, ÌD_Torneo`) VALUES (NULL,'Barrigol','Campeones','1');
Resultado INSERT:
Insertar registro en la entidad participante.
INSERT INTO `torneitos`.`participante`(ÌD_Participante`, `Nombre`,

Àpellidos`, ÌD_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.

Registro sin modificar:
Registro modificado:
UPDATE`torneitos`. ùbicacion` SET` Direccion`='clla38 'WHERE

ùbicacion`. ÌD_Ubicacion`=1;
Modificar registro de la entidad multimedia.
UPDATE`torneitos`.`multimedia` SET` Descripcion`='imagen' WHERE`

multimedia`. ÌD_Multimedia`=1;
Modificar registro de la entidad Estado.

UPDATE`torneitos`.èstado` SET` Descripcion` ='Cancelado' WHERE`

estado`.ÌD_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).
9.7.1 Diseño gráfico de interfaces.

9.7.1.1 Interface login.
Figura 65: Interface login.

9.7.1.2 interface nuevo usuario.
Figura 66: Interface nuevo usuario.
9.7.1.3 Interface Nuevo torneo.

Figura 67: Interface nuevo torneo.
9.7.1.4 Interface Nuevo Equipo.
Figura 68: Interface nuevo equipo.

9.7.1.5 Interface nuevo Participante.
Figura 69: Interface nuevo participante.
9.7.1.6 Interface Nuevo Ubicación.

Figura 70: Interface nueva ubicacion.
9.7.1.7interface Nueva Fecha.

Figura 71: Interface nueva fecha.
9.7.1.8 Interface nueva Galería.
Figura 72: interface nueva galeria.
9.7.1.9 interface Ingresar Goleador.

Figura 73: Interface ingresar goleador.
9.7.1.10 interface Visualizar torneo.

Figura 74: Interface visualizar torneo.
9.7.1.10 Interface Visualizar Equipo.
Figura 75: Interface visualizar equipo.
9.7.1.11 Interface Visualizar Ubicación.

Figura 76: Interface visualizar ubicacion.
9.7.1.12 Interface Visualizar Galería.

Figura 77: Interface visualizar galeria.
9.7.1.13 Interface Visualizar Posición.
Figura 78: Interface visualizar posicion.
9.7.1.14 Interface Visualizar Goleo.

Figura 79: Interface visualizar gole.
9.7.1.15 Interface Cambiar Contraseña.

Figura 80: Interface cambiar contraseña.
9.7.2 Descripción Prototipo.
El prototipo está desarrollado para demostrar el funcionamiento del análisis y modelado

arquitectónico de datos desarrollado durante todo el proyecto.
El prototipo funcional está desarrollado en bajo leguaje PHP y estructurado en

aplicaciones de almacenamiento MYSQL.
El funcionamiento del prototipo es correcto en un ambiente de navegación otorgado por

google chrome.
El prototipo fue probado durante su desarrollo en un ambiente real con el desarrollo del
torneo egresados liceo francisco Restrepo molina administrado por el señor Samuel
vasco.
Ingresando a la siguiente dirección URLhttp://184.173.252.159/~torneito/index.php o

http://184.173.252.159/~torneito/ podemos ingresar al sistema de información web
Torneitos.com, con el usuario 123456789 y clave igual 123456789
10 CONCLUSIONES.
 Los conocimientos de base de la ingeniería de sistemas fueron

implementados en este proyecto de graso. Conocimientos como
levantamiento de requerimientos, análisis de datos, diseño de base de
datos y programación de aplicaciones web.
 Un modelado arquitectónico de datos requiere en dar claridad de
desarrollo, desde las necesidades de usuario hasta culminar las fases de
base datos.
 La metodología UML es un análisis de programación orientada a objetos y
se enfatiza en desarrollo web
 Al levantar los requerimientos se tiene claridad de las ideas, necesidades y
solicitudes del usuario.
 El diseño de diagramas UML debe ser en rutados a solucionar todas las
necesidades de un usuario.
 Teniendo bases de análisis de datos y diagramas UML que están
diseñados para definir un desarrollo de aplicaciones óptimas.
 El diseño de la base de datos está dividido en tres fases de diseño
conocidas como fase conceptual, fase lógica y fase física.
 La base de datos se establece para almacenar la información de las
aplicaciones desarrolladas bajo ese ambiente de almacenamiento. En este
caso de ambiente se tiene el motor de base de datos MYSQL.
 Al momento de crear una idea de aplicación web se tiene que tener claridad
de las necesidades no tan llegadas al usuario. la razón es llegando a las
necesidades de mercado y sociedad.
11 BIBLIOGRAFIA.
.Kroenke., D. M. (2003.). Procesameinto de base de datos: fundamentos, diseño e implementacion.

Mexico: Pearson Educations .
Alarcon, V. F. (2006). Desarrollo de sistemas de informacion: una metodologia basada en el

modelado. Barcelona: Editorial UPC.
C.J.Date. (2001). introduccion a los sistemas de bases de datos. Pearson Educations.
coronel, C. (2003). Sistemas de bases de datos: diseño, implementacion y administracion. Mexico:

Cengage learning editores.
Dean D, S. T. (2010). Captar el verdadero valor del cloud computing. Harvard Deusto bussines
Review.
Dimayor. (s.f.). Recuperado el 10 de 08 de 2012, de Dimayor:

http://dimayor.com/medios/docu/reglamentacion_liga_postobon_2012.pdf
Es.Scribd. (s.f.). Recuperado el 07 de 10 de 2012, de Es.Scribd:

http://es.scribd.com/doc/40031583/49/METODOLOGIA-DE-DISENO-DE-BASES-DE-DATOS
Jacobson, I. (1999). el lenguaje unificado de modelado.Madrid: Addison Wesley.
Jacobson. I, G. B. (2004). El proceso Unificado de Desarrollo de Software. Addison Wesley.
Jose Angel Taboada, J. m. (2005). Sistema de informacion medioambiental. Netbiblo.

Orallo, E. H. (s.f.). Disca. Recuperado el 06 de 10 de 2012, de Disca:
http://www.disca.upv.es/enheror/pdf/ActaUML.PDF
Rob, C. c. (2003). Sistemas de bases de datos: diseño, implementacion y administracion. Mexico:

Cengage learning editores.
Sommerville, L. (2005). Ingenieria del software. Madrid: Pearson Educations SA.
Weitzenfeld, A. (2005). Ingenieria de software oriendata a objetos con uml, java e internet.
Madrid: Thomsom.
Yera, A. C. (2007). Diseño y Programacion de Bases de Datos. Madrid: Vision Libros.
Yera, A. C. (s.f.). Diseño y Programacion de Bases de Datos. Madrid: Vision Libros.
LISTA DE ANEXOS.
CODIGO DESCRIPCION
0001 Documento 0001 Manual Administrador.
0002 Documento 0002 Manual Visitante.
0003 Planilla prueba casos de uso de software.
0004 Acuerdo de Entendimiento.PG_ILMAO-0001.
Estos archivos son anexos como complemento de información de tesis.
CODIGO NOMBRE
Grafica de representación de procesos de desarrollo.

Figura 1
Figura 2 Subsistema general
Figura 3 Caso de uso administrador
Figura 4 Caso de uso visitante
Figura 5 Diagrama de clase
Figura 6 Diagrama de objetos
Figura 7 Secuencia de torneo
Figura 8 Secuencia de equipo
Figura 9 Secuencia participante
Figura 10 Secuencia ubicación
Figura 11 Secuencia programación de fecha
Figura 12 Secuencia goleo
Figura 13 secuencia posición
Figura 14 Secuencia de galería
Figura 15 Secuencia de usuario
Figura 16 Colaboración crear torneo
Figura 17 Colaboración modificar torneo
Figura 18 Colaboración eliminar torneo
Figura 19 Colaboración visualizar torneo
Figura 20 Colaboración crear equipo
Figura 21 Colaboración eliminar equipo
Figura 22 Colaboración visualizar equipo
Figura 23 Colaboración crear participante
Figura 24 Colaboración modificar participante
Figura 25 Colaboración eliminar participante
Figura 26 Colaboración visualizar participante
Figura 27 Colaboración crear ubicación
Figura 28 Colaboración eliminar ubicación
Figura 29 Colaboración visualizar ubicación
Figura 30 Colaboración crear programar fecha
Figura 31 Colaboración eliminar programar fecha
Figura 32 Colaboración modificar programar fecha
Figura 33 Colaboración visualizar programar fecha
Figura 34 Colaboración crear goleo
Figura 35 Colaboración modificar goleo
Figura 36 Colaboración eliminar goleo
Figura 37 Colaboración visualizar goleo
Figura 38 Colaboración crear posición
Figura 39 Colaboración modificar posición
Figura 40 Colaboración eliminar posición
Figura 41 Colaboración visualizar posición
Figura 42 Colaboración crear galería
Figura 43 Colaboración eliminar galería
Figura 44 Colaboración visualizar galería
Figura 45 Colaboración crear usuario
Figura 46 Colaboración modificar usuario
Figura 47 Colaboración eliminar usuario
Figura 48 Colaboración login usuario
Figura 49 Estado de torneo
Figura 50 Estado de equipo
Figura 51 Estado participante
Figura 52 Estado programar fecha
Figura 53 Estado ubicación
Figura 54 Estado goleo
Figura 55 Estado posición
Figura 56 Estado galería
Figura 57 Estado usuario
Figura 58 Diagrama de paquetes
Figura 59 Diagrama de componentes
Figura 60 Diagrama de despliegue
Figura 61 Diagrama modelo entidad relación
Figura 62 Diagrama relacional
Figura 63 Diagrama revisión modelo relacional
Figura 64 Implementación
Figura 65 Interface login
Figura 66 Interface nuevo usuario
Figura 67 Interface nuevo torneo
Figura 68 Interface nuevo equipo
Figura 69 Interface nuevo participante
Figura 70 Interface nueva ubicación
Figura 71 Interface nueva fecha
Figura 72 Interface nueva galería
Figura 73 Interface ingresar goleador
Figura 74 Interface visualizar torneo
Figura 75 Interface visualizar equipo
Figura 76 Interface visualizar ubicación
Figura 77 Interface visualizar galería
Figura 78 Interface visualizar posición
Figura 79 Interface visualizar goleo
Figura 80 Interface cambiar contraseña

Analisis Arquitectonico Informacion Mesa 2013

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Analisis Arquitectonico Informacion Mesa 2013

Cargado por

Copyright:

Formatos disponibles

ANALISIS Y MODELO ARQUITECTONICO DE DATOS PARA UN SISTEMA DE

INFORMACION DE TORNEOS DE FUTBOL

JUAN DIEGO MESA PAREJA

UNIVERSIDAD DE SAN BUENAVENTURA SECCIONAL MEDELLÍN

El siguiente trabajo plantea la manera de desarrollar un análisis de datos para una

Se presenta toda una arquitectura de datos basada en metodología UML

Sistemas de información, Análisis de requerimientos, arquitectura de datos, diseño

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.

JUAN DIEGO MESA PAREJA

Proyecto presentado para optar al título de ingeniero de sistemas

UNIVERSIDAD DE SAN BUENAVENTURA SECCIONAL MEDELLÍN

Firma del jurado

Firma del jurado

Medellín, 11de enero de 2013

Dedicatoria a todas aquellas personas que velaron por el aprendizaje en todo el

Agradezco a todos los trabajadores administrativos de la universidad de san

Agradezco a mi familia por su apoyo en todo momento y sabiendo que con su

La información que se maneja en un torneo de fútbol o una actividad deportiva no

El proyecto se enfoca hacia la realización de un modelado y estructurado de

La denominación del sistema será enmarcada en un administrador de torneos que

La gestión de información de los torneos no es fácil de adquirir ya que se

Los participantes de un torneo se encentran con el efecto de cambiar las

Este problema se origina por la falta de medios de publicación acerca de un

Se plantea el análisis, modelo, estructura e implementación de un sistema que

Realizar el análisis y modelado arquitectónico de datos para un sistema de

 Realizar el levantamiento de requisitos para enmarcar la ruta de desarrollo

 Implementar la metodología de desarrollo de software bajo técnicas UML y

 Desarrollar un prototipo donde se demuestre e implementen la estructura

5.1 MARCO TEORICO

5.1.1 METOLOGIAS DE DESARROLLO DE SOFTWARE.

Existe gran cantidad de metodologías de desarrollo que pueden ser

 UML (Unified Modeling Language “Lenguaje Unificado de Modelado”).

 El número de personas en el proyecto, y

 DSDM (Dynamic Systems Developmemt Method): Es un proceso

Este lenguaje se centra en la representación gráfica de un sistema.

 Visualizar: UML permite expresar de una forma gráfica un sistema de

Un diagrama es la representación gráfica de un conjunto de elementos

Según el autor Enrique Hernández Orallo, el planteamiento de desarrollo

Figura 1: Grafica de representación de procesos de desarrollo.(Jacobson. I,

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

El diseño de base de datos se descompone en diseño conceptual, lógico y

“El diseño lógico consiste en transformar el modelo conceptual obtenido

“El modelo físico se parte del esquema lógico y da como resultado el

5.1.6Funciones básicas de un torneo de futbol.

a. Todos contra todos

a. Todos contra todos

La modalidad será de liga que se establecen partidos todos contra todos y

5.1.7Caracterización de la información manejada por un torneo de

Tabla de posiciones: presentar la tabla de posiciones de forma entendible

Información de amonestaciones en cada partido: manejar la información de

Las normativas de tarjetas solo son perjudiciales para los jugadores o

Estadística: recopilación de toda la información de una fecha de

Presentar la descripción de los usuarios que interactuaran con el sistema

A. Administrador de sistema de información: persona encargada del

B. Jugadores: integrantes de equipos participantes de un torneo de

C. Entrenadores: encargados de dirigir y formar equipos participantes

D. Espectadores: personas interesada en un torneo de futbol. Pero que

E. Familiares: personas perteneciente a un grupo familiar que registra

5.2 Estado del arte.