Castillo Duarte, Pablo Fernando, Figueroa Robles, Lucia Margarita

Sistema Web de Gestión Deportiva
Pablo Castillo y Lucía Figueroa
UNIVERSIDAD NACIONAL DE LOJA
ÁREA DE LA ENERGÍA, LAS INDUSTRIAS Y LOS

RECURSOS NATURALES NO RENOVABLES
CARRERA DE INGENIERÍA EN SISTEMAS
“DISEÑO E IMPLANTACIÓN DE UN SISTEMA WEB

PARA LA GESTIÓN Y CONTROL DE CAMPEONATOS
DEPORTIVOS DE LAS DISCIPLINAS DE FÚTBOL Y
BÁSQUET, ORGANIZADOS POR FEDELIBAL,
UTILIZANDO UN MODELO MATEMÁTICO PARA LA
GENERACIÓN DEL CALENDARIO DE
ENFRENTAMIENTOS”
TESIS, PREVIA A LA
OBTENCIÓN DEL TÍTULO DE
INGENIERO EN SISTEMAS
AUTORES:
CASTILLO DUARTE PABLO FERNANDO

FIGUEROA ROBLES LUCÍA MARGARITA
DIRECTOR: ING. WILMAN PATRICIO CHAMBA ZARAGOCÍN
LOJA- ECUADOR
2011 1
CERTIFICACIÓN DEL DIRECTOR
Ing. Wilman Patricio Chamba Zaragocín,

CATEDRÁTICO DEL ÁREA DE LA ENERGÍA, LAS INDUSTRIAS Y LOS RECURSOS
NATURALES NO RENOVABLES DE LA UNIVERSIDAD NACIONAL DE LOJA
CERTIFICA:
Que la presente tesis de investigación previa la obtención del Título de Ingenieros en

Sistemas de la Universidad Nacional de Loja, titulada “DISEÑO E IMPLANTACIÓN
DE UN SISTEMA WEB PARA LA GESTIÓN Y CONTROL DE CAMPEONATOS
DEPORTIVOS DE LAS DISCIPLINAS DE FÚTBOL Y BÁSQUET, ORGANIZADOS
POR FEDELIBAL, UTILIZANDO UN MODELO MATEMÁTICO PARA LA
GENERACIÓN DEL CALENDARIO DE ENFRENTAMIENTOS”, cuya autoría
corresponde a los Señores Egresados Lucía Margarita Figueroa Robles y Pablo
Fernando Castillo Duarte, ha sido desarrollada bajo mi dirección y prolijamente
revisada por lo que autorizo su presentación y sustentación.
Es todo cuanto puedo certificar en honor a la verdad.
Loja, Octubre del 2011
Ing. Wilman Patricio Chamba Zaragocín

DIRECTOR DE TESIS
2
AUTORÍA
Las ideas, definiciones, análisis, conclusiones y demás elementos teóricos de la

presente tesis, son de exclusiva propiedad y responsabilidad de sus autores, y no
comprometen necesariamente, el criterio ideológico de la Universidad Nacional de
Loja.
Egda. Lucía Margarita Figueroa Robles Egdo. Pablo Fernando Castillo Duarte
C.I. 110433910-4 C.I. 110405448-9
3
AGRADECIMIENTO
Nuestros sentimientos de gratitud van expresados a las dignas autoridades y docentes

de la Universidad Nacional de Loja, del Área de la Energía, las Industrias y los
Recursos Naturales no Renovables, y de la Carrera de Ingeniería en Sistemas,
quienes han sabido contribuir adecuadamente en nuestra formación, con sólidos
fundamentos científicos, teórico – prácticos y axiológicos, nos han encaminado a la
utilización de la investigación como herramienta principal para la adquisición de
nuevos conocimientos, y a su vez nos han dado la posibilidad de interactuar con la
sociedad.
Así también nuestro sincero agradecimiento a la planta administrativa de la Federación

de Ligas Barriales de Loja (FEDELIBAL), quienes han sabido contribuir con valiosa
información, durante todo el proceso investigativo, ya que sin ellos, no habríamos
logrado nuestra meta propuesta.
Dejamos constancia de nuestra gratitud a todos los insignes maestros y brillantes

ingenieros que compartieron con nosotros sus vastos conocimientos en las aulas.
Para todos ellos nuestros mejores recuerdos.
Y de manera muy especial, agradecemos al Señor Ingeniero Wilman Chamba

Zaragocín, excelente catedrático, amigo sincero y ser humano ejemplar, quien dirigiera
la presente investigación de la manera más acertada posible.
Los Autores
4
DEDICATORIA
A mis padres Margarita y Estuardo,

paradigmas de perseverancia y lucha,
gracias por estar siempre apoyando mis
metas, e inculcar valores fundamentales en
mi vida. A mis abuelitas por su ejemplo de
tenacidad y amor. A mis hermanos y
amigos, compañeros de penas y alegrías,
gracias por compartir todas aquellas
inolvidables experiencias.
Lucía Figueroa
A mi madre y hermanos, puntales

fundamentales de mi formación, motivo de la
felicidad y fortaleza de mi vida, ejemplo de
amor y sacrificio.
A mi padre, faro luminoso y tesoro que

habita entre las estrellas radiantes, sus
destellos refulgentes aun me encaminan por
los surcos de la vida.
A la niña de mis ojos, fuente inagotable de

empeño y sacrificio. Fue el molino de viento
que impulsó este trabajo.
Pablo Castillo
5
CESIÓN DE DERECHOS
Nosotros Lucía Margarita Figueroa Robles y Pablo Fernando Castillo Duarte,

declaramos conocer que nuestro trabajo de investigación forma parte del patrimonio
de la Universidad Nacional de Loja, por lo tanto, autorizamos a la Universidad hacer
uso pertinente del mismo.
Egda. Lucía Margarita Figueroa Robles Egdo. Pablo Fernando Castillo Duarte
C.I. 110433910-4 C.I. 110405448-9
6
RESUMEN
La ciencia y tecnología avanzan continuamente, y las necesidades de automatizar

actividades dentro de las empresas o instituciones que todavía manejan los procesos
de forma tradicional, se conciben cada vez más imperiosas. Precisamente ante la
necesidad de administrar de una manera óptima las actividades realizadas en la
Federación Deportiva de Ligas Barriales de la ciudad de Loja
(FEDELIBAL),desarrollamos el presente Sistema Web para la gestión y control de
campeonatos deportivos de las disciplinas de fútbol y básquet, utilizando un modelo
matemático para la generación del calendario de enfrentamientos, con la finalidad de
que todos los procesos, se cumplan de forma rápida y confiable.
La metodología de desarrollo de software utilizada es la ICONIX, que es un proceso

de desenvolvimiento de Software que utiliza el lenguaje de Modelamiento UML y
posee una característica que nos permite verificar en todas las fases, si los requisitos
están siendo atendidos. Esta metodología consta de las siguientes tareas: Análisis de
Requisitos, Análisis y Diseño Preliminar, Diseño e Implementación basada en el
lenguaje de modelamiento UML.
El Sistema Web de gestión deportiva permite administrar los procesos que se

presentan en el desarrollo de los campeonatos de fútbol y básquet, almacenado de
forma confiable los datos de los árbitros, escenarios, canchas, equipos y jugadores,
agilitando las tareas como: inscripción de equipos y jugadores; sorteo y generación de
los partidos a disputarse; registro de los resultados de los partidos; determinar equipos
clasificados a la siguiente fase del campeonato; impresión de las actas de juegos;
impresión de los jugadores sancionados; creación e impresión de la tabla de
posiciones; creación e impresión de la tabla de los máximos anotadores, así como
también permite controlar que un jugador participe en un solo equipo.
En la generación automática del calendario de juegos (fixture),se utilizó un modelo

matemático, el mismo que cubrió con todos los requerimientos solicitados por
7
FEDELIBAL: que se pueda elegir una o más canchas para el desarrollo del
campeonato, que cada participante se enfrente por turno a los demás jugando el
mismo número de partidos, que exista el mismo tiempo de descanso entre partido y
partido, que se lo planifique para jugar únicamente los fines de semana, que
clasifiquen un numero x de equipos a la segunda fase del campeonato, que se aplique
un torneo de simple eliminación para de la segunda fase del campeonato. Para ello en
nuestro modelo matemático aplicamos uno de los esquemas más populares de turno
rotatorio, el algoritmo Round Robin para la primera fase del campeonato denominada
de eliminación, en donde un equipo se enfrenta por turno a los demás con lo demás, y,
para la segunda fase se aplicó un campeonato de simple eliminación con los equipos
que logren clasificar, en donde a la mitad de los equipos se los elimina del
campeonato después de disputarse la fecha.
El propósito del Sistema Web es lograr cubrir todas las actividades de la

administración de los campeonatos de futbol y básquet organizado por FEDELIBAL de
forma fácil y efectiva, permitiendo además poder otorgar comodidad a los miembros
de los equipos participantes, ya que a través del sistema podrán realizar consultas
rápidas como: campeonatos en desarrollo, equipos participantes, resultados de los
compromisos, la próxima fecha, tabla de posiciones y tabla de mayores anotadores.
8
SUMARY
Science and technology is continually advancing, and the need to computerize

activities within companies or institutions that still manage information manually, are
seen increasingly urgent. Just before the need to improve the management and
control of activities in the Federación Deportiva de Ligas Barriales of Loja city
(FEDELIBAL), we develop this Web Sistem for management and control of sports
championships in the disciplines of soccer and basketball, which are made in this
institution, using a mathematical model for the generation of schedule conflicts.
The software development methodology used is the ICONIX, based on UML modeling
language. Also we use as a technology for developing Web applications: the Java
programming language v 1.6.0_03, with the programming environment v JavaServer
Faces 1.1, System Operational Database MySQL v 5.0.19, and works on a Web
Server Apache Tomcat 6.0.14 v.
The Web System automates the processes that occur in the development of soccer
and basketball championships, such as: team and player registration; drawing and
generation of games to be played; printing of the minutes of the game, match result
file; players suspended reports; creation of the standings of the teams, creation of
tables of position of the top scorers and printing the standings, controllinng a player
that can only participate in a single team.
For the automatic generation of game schedule (fixture), our first step was to make a
mathematical representation of it, thus covering the following requirements requested
by FEDELIBAL: that the teams play the same number of games in the first phase
elimination, that each participant faces in turn to others, that in the matches exist the
same rest time between games, to rank a number x of team to the second round, to
use simply removing games from the second round and that the matches are played at
different times.
9
In the elimination phase of the championship, our mathematical model is applied one
of the most popular schemes in rotation, the Round Robin algorithm, while in the
second round was applied to a single elimination tournament, where half the teams
removed on each date.
The purpose of the Web System is making it easier and efficient the control and
management of the championships by that institution, in addition to providing comfort
to the user-participant in team, who through the system can query from the network,
such as: championships in development, the participating teams, the match results,
the table of the standings of the teams, scorers table, and the next matches.
10
ÍNDICE
CONTENIDOS: Pág.
PORTADA……………………………………..………………………………………..…... I
CERTIFICACIÓN…………………………………………………………………………… II
AUTORÍA…………………………….………….………………………………………..…. III
AGRADECIMIENTO……………………………………………………………………….. IV
DEDICATORIA…………..…………………………………………………………………. V
CESIÓN DE DERECHOS………………………………………………..…………..….... VI
RESUMEN……………………………………………………………….………………….. VII
SUMARY………………………………………………………………………….…………. IX
ÍNDICE………......………………………………………………………………………….. XI
INDICE DE TABLAS…………………..………………………………………………... XVII
INDICE DE FIGURAS……………………...…………………………………………... XXI
B. INTRODUCCIÓN.…………………………………………………………………. 1
C. METODOLOGÍA……...…………………………………………………….……... 4
C.1. METODOS…………………………………………………………..….......... 4
C.1.1. Método Deductivo…...………………………………………............. 4
C.1.2. Método Analítico – Crítico……………………………………........... 4
C.1.3. Método Descriptivo…...………….……………………...…………… 4
11
C.1.4. Metodología Iconix……………………………………...……………. 5
C.2. TECNICAS APLICADAS…………………………………….…….….... 6
C.2.1. Entrevista……..………………………...…………………. 6
C.2.2. Encuesta……….………………………………………….. 7
D. REVISIÓN DE LITERATURA…………....………………………………..…...... 8
CAPÍTULO I
1. FEDELIBAL Y SUS PRINCIPALES DISCIPLINAS
1.1. Historia………………………………………………………………………… 8
1.2. Metas………………………….………………………………………..…......... 10
1.3. Principales Disciplinas……….……………………………………………....... 10
1.3.1. Fútbol………………………………………………………………...…...... 10
1.3.2. Básquet………….…………………………………………………...…..... 16
CAPITULO II
2. GESTION DE CAMPEONATOS DEPORTIVOS
2.1. Introducción…………………………………………………………………...... 20
2.2. Campeonatos deportivos……………………………………………..…....... 21
2.2.1. Campeonatos por puntos………………………………………….…...... 21
2.2.2. Calendarios de juegos………………………………………………........ 22

2.2.2.1. Método rotativo para la confección de un calendario……. 22
2.2.2.2. Número de Partidos por Fechas………………………….... 23
2.2.2.3. Número de Fechas…………………………………...…....... 23
2.2.2.4. Número de Partidos…………………………………….….... 23
2.2.3. Campeonatos por Eliminación…………………………………..…......... 24
2.2.3.1. Campeonatos de Simple Eliminación……………….…...... 24
12
2.2.3.2. Determinación del Número de Partidos……………..…...... 25

2.2.3.3. Número de Fechas…………………………………...…....... 25
2.2.4. Organización del campeonato……………………………………..…..... 25
2.2.4.1. Lista de Control………………………………………..…...... 26
2.3. Características del armado de un Campeonato o Fixtures con el esquema
Round Robin………………………………………………….…...... 28
2.3.1. Descripción General………………………………………………..…...... 28
2.3.2. Programación Entera…………………………………………………....... 29
CAPITULO III
3. MODELOS MATEMÁTICOS
3.1. Introducción…………………………………………………………...…........ 30
3.2. Clasificación de modelos matemáticos……………………………..…........ 31
3.2.1. Modelos Heurísticos…………………………………………….…........ 32
3.3. Representación del modelo………………………………………..……......... 33
CAPITULO IV
4. TECNOLOGÍAS PARA EL DESARROLLO DE LA APLICACIÓN WEB
4.1. Servidores Web…………………………………………………….….…......... 34
4.2. Java Server Faces…………………………………………………….…......... 36
4.2.1. Objetivos….…………………………………………………………......... 37
4.2.2. Beneficios de JSF…………………………………….…...................... 38
4.2.3. Ciclo de vida de una página JSF…………………….…..................... 39
4.2.4. Escenarios de Procesamiento del Ciclo de Vida de una Petición...... 40
4.2.5. Ciclo de Vida Estándar de Procesamiento de Peticiones………....... 42
4.3. Sitio Web……………………………………………………………................. 42
4.3.1. Sitio Web estático…………………………………………................... 43
4.3.2. Sitio Web dinámico…………………………………….…................... 44
4.3.3. Tipos de Sitios Web………………………………………………………. 44
4.4. Modelo Vista Controlador…………………………………….……….…........ 47

13
4.4.1. Estructura MVC…………………………………………………..….......... 47

4.4.2. Ventajas del MVC………………………...…………………………......... 49
4.5. Arquitectura cliente – servidor………………………………………..…......... 49
4.5.1. Características del Cliente……………………………………….…........ 50
4.5.2. Características del Servidor…………………………………….….......... 50
4.5.3. Ventajas…………………………………………………………….…........ 51
4.5.4. Desventajas………………………………………………………………... 52
E. RESULTADOS………………………………………………………………………… 53
E.1. Desarrollo de la Propuesta Alternativa…………...…..…................................ 53
E.2. Valoración Técnico-Económica-Ambiental……………………………………. 57
F. DISCUSIÓN……………………………………………………………………………. 60
F.1. Modelado del Sistema…………………………………………..……………….. 60
F.1.1. Requerimientos Funcionales………………………..……………………… 60
F.1.2. Requerimientos No Funcionales……………………….………………….. 62
F.1.3. Glosario de Términos……………………………………………………….. 62
F.2. Modelo del Dominio……………………………………………...…....………… 64
F.3. Prototipado de Pantallas……………………………………………….......….. 65
F.4. Modelamiento de Casos de Uso……………………………………………….. 82
F.4.1. Identificación de Casos de Uso……………………………………………. 82
F.4.2. Descripción de Casos de Uso y Diagramas de Secuencia…................. 85
F.4.2.1. Caso de uso: Login Usuario…………………………………………… 85
F.4.2.2. Caso de uso: Ingresar al Sistema……………………………………. 88
F.4.2.3. Caso de uso: Crear Cuenta Usuario………………….……………… 90
14
F.4.2.4. Caso de uso: Eliminar Cuenta Usuario…………………………. 93
F.4.2.5. Caso de uso: Modificar Cuenta Usuario………………….......... 96
F.4.2.6. Caso de uso: Crear Jugador.……………………………………. 99
F.4.2.7. Caso de uso: Eliminar Jugador…………………………………… 102
F.4.2.8. Caso de uso: Modificar Jugador…………………………………. 105
F.4.2.9. Caso de uso: Crear Equipo.………………………………............. 108
F.4.2.10. Caso de uso: Eliminar Equipo…………………………………… 111
F.4.2.11. Caso de uso: Modificar Equipo…………………………………. 114
F.4.2.12. Caso de uso: Crear Arbitro...……………………………………… 117
F.4.2.13. Caso de uso: Eliminar Arbitro……………………………………. 120
F.4.2.14. Caso de uso: Modificar Arbitro………………………………….. 123
F.4.2.15. Caso de uso: Crear Escenario…………………………………… 126
F.4.2.16. Caso de uso: Eliminar Escenario………………………………. 129
F.4.2.17. Caso de uso: Modificar Escenario……………………………… 132
F.4.2.18. Caso de uso: Crear Cancha……..……………………………… 135
F.4.2.19. Caso de uso: Eliminar Cancha……………………………......... 138
F.4.2.20. Caso de uso: Modificar Cancha…..………………………......... 141
F.4.2.21. Caso de uso: Crear Campeonato………………………………… 144
F.4.2.22. Caso de uso: Eliminar Campeonato…………………………… 147
F.4.2.23.Caso de uso: Modificar Campeonato…………………………… 150
15
F.4.2.24. Caso de uso: Inscribir Equipo al Campeonato………………... 153
F.4.2.25. Caso de uso: Asignar Cancha al Campeonato…………………. 156
F.4.2.26. Caso de uso: Generar el Calendario del Campeonato………… 159
F.4.2.27. Caso de uso: Cambiar Cancha al Compromiso...……………..… 162
F.4.2.28. Caso de uso: Ingresar Resultados…….…………………………. 165
F.5. Diagrama de Clases Final………………………………………………........... 168
F.5.1. Diagrama de Paquetes……………………………………………………. 169
Dominio – DAO………………………………………………………….. 169
Negocio…………………………………………………………………… 169
Vistas……………………………………………………………………… 169
F.6. Diagrama de Componentes…………………………………………………….. 170
F.7. Diagrama de Despliegue………………………………………………………... 170
F.8. Pruebas de Validación…………………………………………………………... 171
F.8.1. Tipos de Prueba………………………………………………….............. 171
F.8.1.1. Prueba de Funcionalidad……………………………….................. 171
F.8.1.2. Prueba de Aceptación………………………………………………... 172
F.8.1.3. Prueba de Usabilidad………………………………………………… 172
F.8.2. Resultados de Validación…………………………………………………. 174
F.8.3. Control de Calidad en la Aplicación……………………………………… 177
G. CONCLUSIONES………………………………………………………………….. 182
16
H. RECOMENDACIONES……………………………….………………………...… 184
I. BIBLIOGRAFÍA Y REFERENCIAS……………………………………………... 185
J. ANEXOS………………………………………………………………………........ 187
17
INDICE DE TABLAS
CONTENIDOS: Pág.
Tabla 1 Evaluación del Objeto de Investigación….………………………..………….... 53
Tabla 2 Recursos Humanos…………………..…………………………………………... 57
Tabla 3 Recursos Materiales………………….………………………………………….. 57
Tabla 4 Servicios Básicos……………………………………………………..………….. 58
Tabla 5 Recursos Técnicos……………………………………………………………….. 58
Tabla 6 Recursos Económicos………………..………………………………………….. 59
Tabla 7 Requerimientos Funcionales………………………………………..…...…….... 60
Tabla 8 Requerimientos No Funcionales.…………………………………..…….……... 62
Tabla 9 Identificación de Casos de Uso...…………………………………..…....……... 82
Tabla 10 Descripción del Caso de Uso: Login usuario……………………..…..……... 85
Tabla 11 Validación del Caso de Uso: Login Usuario..…………………..…...…….... 86
Tabla 12 Descripción del Caso de Uso: Ingresar al Sistema..…………..…………... 88
Tabla 13 Validación del Caso de Uso: Ingresar al Sistema……………..…............... 88
Tabla 14 Descripción del Caso de Uso: Crear Cuenta Usuario…………….............. 90
Tabla 15 Validación del Caso de Uso: Crear Cuenta Usuario……………….............. 91
Tabla 16 Descripción del Caso de Uso: Eliminar Cuenta Usuario…..……………….. 93
Tabla 17 Validación del Caso de Uso: Eliminar Cuenta Usuario…………….............. 94
Tabla 18 Descripción del Caso de Uso: Modificar Cuenta Usuario…………………... 96
18
Tabla 19 Validación del Caso de Uso: Modificar Cuenta Usuario…………................ 97
Tabla 20 Descripción del Caso de Uso: Crear Jugador..…….……………….............. 99
Tabla 21 Validación del Caso de Uso: Crear Jugador……….……………….............. 100
Tabla 22 Descripción del Caso de Uso: Eliminar Jugador……….…..………………... 102
Tabla 23 Validación del Caso de Uso: Eliminar Jugador……….…………….............. 103
Tabla 24 Descripción del Caso de Uso: Modificar Jugador………………..………….. 105
Tabla 25 Validación del Caso de Uso: Modificar Jugador………..…………............... 106
Tabla 26 Descripción del Caso de Uso: Crear Equipo.……...………………............... 108
Tabla 27 Validación del Caso de Uso: Crear Equipo..……….……………….............. 109
Tabla 28 Descripción del Caso de Uso: Eliminar Equipo..……….…..……………….. 111
Tabla 29 Validación del Caso de Uso: Eliminar Equipo..……….…………….............. 112
Tabla 30 Descripción del Caso de Uso: Modificar Equipo.………………..…………... 114
Tabla 31 Validación del Caso de Uso: Modificar Equipo .………..…………............... 115
Tabla 32 Descripción del Caso de Uso: Crear Árbitro..……...……………….............. 117
Tabla 33Validación del Caso de Uso: Crear Árbitro...……….……………….............. 118
Tabla 34 Descripción del Caso de Uso: Eliminar Árbitro. .……….…..……………….. 120
Tabla 35 Validación del Caso de Uso: Eliminar Árbitro.……….……………............... 121
Tabla 36 Descripción del Caso de Uso: Modificar Árbitro..………………..………….. 123
Tabla 37 Validación del Caso de Uso: Modificar Árbitro.….…..…………................... 124
Tabla 38 Descripción del Caso de Uso: Crear Escenario…...……………….............. 126
Tabla 39 Validación del Caso de Uso: Crear Escenario.............…………….............. 127
19
Tabla 40 Descripción del Caso de Uso: Eliminar Escenario…….…..………………… 129
Tabla 41 Validación del Caso de Uso: Eliminar Escenario…….……………............... 130
Tabla 42 Descripción del Caso de Uso: Modificar Escenario……………..…………... 132
Tabla 43 Validación del Caso de Uso: Modificar Escenario....…..…………............... 133
Tabla 44 Descripción del Caso de Uso: Crear Cancha……...……………….............. 135
Tabla 45 Validación del Caso de Uso: Crear Cancha.……….……………….............. 136
Tabla 46 Descripción del Caso de Uso: Eliminar Cancha.……….…..………............. 138
Tabla 47 Validación del Caso de Uso: Eliminar Cancha……….……………............... 139
Tabla 48 Descripción del Caso de Uso: Modificar Cancha………………..…............. 141
Tabla 49 Validación del Caso de Uso: Modificar Cancha………..…………................ 142
Tabla 50 Descripción del Caso de Uso: Crear Campeonato..……………….............. 144
Tabla 51 Validación del Caso de Uso: Crear Campeonato….……………….............. 145
Tabla 52 Descripción del Caso de Uso: Eliminar Campeonato….…..………............ 147
Tabla 53 Validación del Caso de Uso: Eliminar Campeonato………………............... 148
Tabla 54 Descripción del Caso de Uso: Modificar Campeonato….…………............. 150
Tabla 55Validación del Caso de Uso: Modificar Campeonato……………................. 151
Tabla 56 Descripción del Caso de Uso: Inscribir Equipo al Campeonato……........... 153
Tabla 57 Validación del Caso de Uso: Inscribir Equipo al Campeonato.…................ 154
Tabla 58 Descripción del Caso de Uso: Asignar Cancha al Campeonato..............… 156
Tabla 59 Validación del Caso de Uso: Asignar Cancha al Campeonato.………….... 157
Tabla 60 Descripción del Caso de Uso: Generar el Calendario………………………. 159
20
Tabla 61 Validación del Caso de Uso: Generar el Calendario……...…...…............... 160
Tabla 62 Descripción del Caso de Uso: Asignar Fecha a la Jornada……..............… 162
Tabla 63 Validación del Caso de Uso: Asignar Fecha a la Jornada…….…............... 163
Tabla 64 Descripción del Caso de Uso: Ingresar Resultados……….……..............… 165
Tabla 65 Validación del Caso de Uso: Ingresar Resultados……….…….…............... 166
Tabla 66 Resultados de Validación rol Administrador – Secretario…………………... 175
Tabla 67 Resultados de Validación rol Usuario………………………………………… 176
Tabla 68 Control de Calidad………………………………………………………………. 178
21
INDICE DE FIGURAS
CONTENIDOS: Pág.
Fig. 1 Terreno de Juego……………..……………..………………………………..…... 11
Fig. 2 Terreno de Juego Detallado…………….………………………………………… 12
Fig. 3 Poste del banderín de Esquina ...………………………………..……………… 13
Fig. 4 Medidas del campo en metros.……………………………………………..…… 13
Fig. 5 Marcador Electrónico……………………………………………….…………..… 16
Fig. 6 Campo de Baloncesto…………………………………………………………….. 17
Fig. 7 Línea de Tiros Libres.…………………………………………………………..… 18
Fig. 8 Campo de Baloncesto Detallado..……………………………………………..… 18
Fig. 9 Canasta…………………………………………………………………………….. 20
Fig.10 Fixture usual de un campeonato de todos contra todos de 6 equipos………. 22
Fig. 11 Servidor………..…………………………………………………………………… 35
Fig. 12 Interfaz de Usuario…...…………………………………………………………… 38
Fig. 13 Pasos del ciclo de vida petición-respuesta JSF…..…………………………… 42
Fig. 14 Modelo - Vista - Controlador………………..…………………………………… 47
Fig. 15 Modelo del Dominio………...………………………..…………………………… 64
Fig. 16 Pantalla: Ingresar al Sistema………………………..…………………………… 65
Fig. 17 Pantalla: Principal…………………………….…………………………………… 65
Fig. 18 Pantalla: Buscar Usuario…...……...………………………………......………… 66
22
Fig. 19 Pantalla: Nuevo Usuario………………………………………..………………… 66
Fig. 20Pantalla: Editar Usuario………………………………………..………………… 67
Fig. 21Pantalla: Buscar Jugador......……..………………………………......…………. 67
Fig. 22 Pantalla: Nuevo Jugador...………………………………………………………. 68
Fig. 23 Pantalla: Editar Jugador.…………………………………………………………. 68
Fig. 24 Pantalla: Buscar Equipo.......………………………………………......………… 69
Fig. 25 Pantalla: Nuevo Equipo....……………………………..………………………… 69
Fig. 26 Pantalla: Editar Equipo..……………………………..………………………….. 70
Fig. 27 Pantalla: Buscar Arbitro........……...………………………………......………… 70
Fig. 28 Pantalla: Nuevo Arbitro.....………………………………………..……………… 71
Fig. 29 Pantalla: Editar Arbitro...…………………………….…………………………… 71
Fig. 30 Pantalla: Buscar Escenario...……...………………………………......………… 72
Fig. 31 Pantalla: Nuevo Escenario……..……………………..………………………… 72
Fig. 32 Pantalla: Editar Escenario………………………………………………………. 73
Fig. 33 Pantalla: Buscar Cancha......………………………………………......………… 73
Fig. 34 Pantalla: Nuevo Cancha...……………………………………………………….. 74
Fig. 35 Pantalla: Editar Cancha.………………………………………..………………… 74
Fig. 36 Pantalla: Buscar Campeonato…….………………………………......………… 75
Fig. 37 Pantalla: Nuevo Campeonato………………………….……………………….. 75
Fig. 38 Pantalla: Editar Campeonato………………………………….…………………. 76
23
Fig. 39 Pantalla: Inscripción de Equipos..…………..……………………......…………. 76
Fig. 40 Pantalla: Listado de Equipos del Campeonato………………..………………. 77
Fig. 41 Pantalla: Listado de Campeonatos por Iniciarse…………..………………….. 77
Fig. 42 Pantalla: Generación del Campeonato………………………….……………… 78
Fig. 43 Pantalla: Calendario del Campeonato………………..…………………………. 78
Fig. 44 Pantalla: Lista de Campeonatos Activos……….………………..…………….. 79
Fig. 45 Pantalla: Listado de Encuentro de la Fecha….………………..………………. 79
Fig. 46 Pantalla: Clasificación……………………………………………..……………… 80
Fig. 47 Pantalla: Jugadores Sancionados……………………………….……………… 80
Fig. 48 Pantalla:Cambiar Calendario…………………………………………………… 81
Fig. 49 Pantalla:Listado de Jornadas.…………………………………………………… 81
Fig. 50 Pantalla:Cambiar Cancha……..………………………………………………… 81
Fig. 51 Modelamiento de Casos de Uso……………………..………………………… 84
Fig. 52 Login Usuario……………………..……………………..………………………… 87
Fig. 53 Ingresar al Sistema………………………..………………………………………. 89
Fig. 54 Crear Cuenta Usuario…….……….……………………………………………… 92
Fig. 55 Eliminar Cuenta Usuario…...………………………………………......………… 95
Fig. 56 Modificar Cuenta Usuario………………………………………..………………. 98
Fig. 57 Crear Jugador......………………………………………………………........…… 101
Fig. 58 Eliminar Jugador..………………………………………..……………………….. 104
24
Fig. 59 Modificar Jugador.…….…………………………………..……………………… 107
Fig. 60 Crear Equipo…......…………………………………………………......………… 110
Fig. 61 Eliminar Equipo.....………………………………………..……………………… 113
Fig. 62 Modificar Equipo..………………………………………..……………………….. 116
Fig. 63 Crear Arbitro….......…………………………………………………......………… 119
Fig. 64 Eliminar Arbitro...………………………………………..……………………….. 122
Fig. 65 Modificar Arbitro...………………………………………..……………………….. 125
Fig. 66 Crear Escenario...…………………………………………………........………… 128
Fig. 67 Eliminar Escenario………………………………………..……………………….. 131
Fig. 68 Modificar Escenario……………………………………..………………………… 134
Fig. 69 Crear Cancha......…………………………………………………........…………. 137
Fig. 70 Eliminar Cancha...………………………………………..………………………. 140
Fig. 71 Modificar Cancha.………………………………………..………………………. 143
Fig. 72 Crear Campeonato…..……………………………………………........………… 146
Fig. 73 Eliminar Campeonato…………………………………..…………………………. 149
Fig. 74 Modificar Campeonato…………………………………..………………………... 152
Fig. 75 Inscribir Equipo al Campeonato..…………………………………......…………. 155
Fig. 76 Asignar Cancha al Campeonato………………..…………………..…………… 158
Fig. 77 Generar el Calendario del Campeonato……………………………………….. 161
Fig. 78 Cambiar Fecha a la Jornada…..…………..…………………………………….. 164
25
Fig. 79 Ingresar Resultados………………….………………..………………………….. 167
Fig. 80 Diagrama de Clases Final………….………………………………..…………… 168
Fig. 81 Diagrama de Paquetes…………….………………………………..…………… 169
Fig. 82 Diagrama de Componentes……….………………………………..……………. 170
Fig. 83 Diagrama de Despliegue………….………………………………..…………….. 170
26
B. INTRODUCCIÓN
El presente trabajo de investigación tiene el propósito de mejorar la gestión y

control de campeonatos de futbol y básquet de la Federación Deportiva de Ligas
Barriales de Loja (FEDELIBAL), ya que luego de realizar un análisis minucioso y
profundo surgió la necesidad imperante de mejorar los procesos de gestión
deportiva, pues al tener FEDELIBAL en sus campeonatos una gran acogida por
parte de los equipos barriales de la ciudad de Loja y al no disponer de un sistema
informático para la gestión de los mismos se tornaba extenuante poder llevar un
control adecuado, rápido y eficiente. Por ello es que hemos creído conveniente
desarrollar el proyecto titulado “DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA
WEB PARA LA GESTIÓN Y CONTROL DE CAMPEONATOS DEPORTIVOS DE
LAS DISCIPLINAS DE FÚTBOL Y BÁSQUET, ORGANIZADOS POR
FEDELIBAL, UTILIZANDO UN MODELO MATEMÁTICO PARA LA
GENERACIÓN DEL CALENDARIO DE ENFRENTAMIENTOS”, Software que
optimiza recursos para FEDELIBAL, y que nos permite poner en práctica todos los
conocimientos, técnicas y métodos aprendidos en la Universidad Nacional de Loja,
cumpliendo así la vinculación con la colectividad.
El Sistema Web de gestión y control está enmarcado en logar automatizarlos

procesos que se presentan en el desarrollo de los campeonatos de fútbol y
básquet, permite realizar de forma sencilla la inscripción de equipos y jugadores,
seleccionar las canchas en donde se desarrollarán los encuentros, sortear y
generar el calendario de juegos (fixture) utilizando un modelo matemático, registrar
los resultado de los partidos, la impresión de las actas de juego, la impresión de
los jugadores sancionados; la creación de la tabla de posiciones, la creación de las
tablas de los máximos anotadores, identificar los equipos que clasifican a la
segunda fase del campeonato, controlar que los jugadores no participen en
diferentes equipos. El sistema además permite a la ciudadanía realizar consultas
desde la red tales como: campeonatos en desarrollo, los equipos participantes, los
27
resultados de los compromisos, la tabla de posiciones, la tabla de máximos

anotadores y la próxima fecha del campeonato.
La Fundamentación teórica reúne toda la información relacionada con el presente

proyecto, que se la ha dividido en cuatro capítulos que se resumen a continuación:
El primer capítulo denominado “FEDELIBAL Y SUS PRINCIPALES

DISCIPLINAS”, contiene un resumen de las generalidades de Fedenaligas; su
crecimiento a nivel de las provincias, hasta llegar a FEDELIBAL; la Ley de Cultura
Física en su Artículo 12;una breve descripción de lo que es Fedelibal, junto a sus
metas; y en cuanto a las principales disciplinas y que requieren una mayor
organización en dicha institución deportiva, existen algunas observaciones de lo
que es el Fútbol, el Básquet y las reglas básicas para cada una de estas
disciplinas.
El segundo capítulo titulado “GESTIÓN DE CAMPEONATOS DEPORTIVOS”,

destaca una conceptualización de lo que son los campeonatos deportivos
reseñando de manera general una introducción, para posteriormente abordar los
campeonatos por puntos, los campeonatos por eliminación, la organización de
campeonatos y las características del armado de un campeonato o fixtures con el
esquema Round Robin.
El tercer capítulo denominado “MODELOS MATEMÁTICOS”, nos presenta todo lo

referente a estos modelos, desde un preámbulo general, para a continuación
referirnos a las clasificaciones de los Modelos Matemáticos, así como los
Modelos Heurísticos; y concluir con la Representación del Modelo.
El cuarto capítulo titulado “TECNOLOGÍAS PARA EL DESARROLLO DE LA

APLICACIÓN WEB”, describe los datos más importantes en lo referente a los
Servidores Web, Java Server Faces, los Sitios Web, el Modelo Vista Controlador y
la Arquitectura Cliente Servidor.
28
La Evaluación del Objeto de Investigación da a conocer la situación actual de la

Federación Deportiva de Ligas Barriales de Loja (FEDELIBAL).
El Desarrollo de la Propuesta Alternativa, detalla claramente la solución planteada,

todos los requerimientos básicos y necesarios que se utilizaron en el desarrollo de
la aplicación dentro del modelado del sistema, se muestra el modelo del dominio,
prototipado de pantallas, modelamiento de Casos de Uso, descripción de Casos
de Uso, diagramas de secuencia, diagrama de clases final, diagrama de
componentes, diagrama de despliegue, y las pruebas de validación, que hacen
referencia a la forma en la que se validó a la aplicación en su totalidad.
Finalmente luego de una Valoración Técnico – Económica – Ambiental del

proyecto, se establecen las Conclusiones y Recomendaciones, las cuales dan una
valoración del cumplimento de objetivos y consejos pertinentes que se establecen
una vez finalizado y socializado el presente sistema, el mismo que estuvo a
prueba en las instalaciones de FEDELIBAL.
29
C. METODOLOGÍA
Para la elaboración del Sistema de Gestión Deportiva fue necesario seguir un

esquema metodológico, basado en el uso de métodos y técnicas que nos
facilitaron la recolección de la información, y se convirtieron en guía de la
presente investigación.
C.1. MÉTODOS:
C.1.1. Método Deductivo
Su principal característica es partir de datos generales aceptados como

válidos, para llegar a una conclusión de tipo particular. Para el
desarrollo del Sistema Web, se utilizó este método, ya que nos
permitió determinar los inconvenientes que se suscitaban durante el
proceso de gestión y control de las actividades realizadas en la
Federación Deportiva de Ligas Barriales de la ciudad de Loja
(FEDELIBAL).
C.1.2 Método Analítico – Crítico
Se utilizó este método al momento de analizar y sintetizar los

conocimientos, basados en la sustentación de la bibliografía, para
posteriormente ser plasmados en los resultados del proyecto.
C.1.3. Método Descriptivo
Este método se utilizó al momento de describir las características de la

aplicación simultáneamente con sus interfaces gráficas, además se
realizó la explicación de cada función y procedimientos, utilizados
30
durante la realización de la aplicación, y por consiguiente el

cumplimiento del objetivo general en el que se basa el proyecto.
C.1.4. Metodología ICONIX
Es un Proceso de Desenvolvimiento de Software que utiliza el lenguaje

de Modelamiento UML y posee una característica que nos permite
verificar en todas las fases, si los requisitos están siendo atendidos.
Ésta metodología consta de las siguientes tareas:
 Análisis de Requisitos.
 Identificar objetos del dominio y relaciones de agregación

 Generalización
 Prototipo rápido
 Identificar casos de uso
 Organizar casos de uso en grupos (paquetes)
 Asignar requerimientos funcionales a casos de uso y objetos del
dominio
 META: revisión de requerimientos
 Análisis y Diseño Preliminar.
 Escribir descripciones de casos de uso

o cursos básico y alternos
 Análisis de robustez
o Identificar grupos de objetos que realizan escenario
o Actualizar diagramas de clases del dominio
 Finalizar diagramas de clases
 META: revisión del diseño preliminar
o De usuarios hacia sistema
o De datos hacia sistema
31
o Detallar a partir de modelos de alto nivel
 Diseño
 Asignar comportamiento
 Para cada caso de uso
o Identificar mensajes y métodos
o Dibujar diagramas de secuencia
o Actualizar clases
o (opcional) diagramas de colaboración
o (opcional) Diagramas de estados
 Terminar el modelo estático
 Verificar el cumplimiento de requerimientos
 META: revisión crítica del diseño
 Implementación
 Producir diagramas necesarios

o Despliegue
o Componentes
 Escribir el código
 Pruebas de unidad e integración
 Pruebas de sistema y aceptación basadas en casos de uso
 META: entrega del sistema
C.2. TÉCNICAS APLICADAS
C.2.1. Entrevista
Es la comunicación interpersonal establecida entre el investigador y el

sujeto de estudio a fin de obtener respuestas verbales a las
interrogantes planteadas sobre el tema propuesto. Como técnica de
32
recolección va desde la interrogación estandarizada hasta la

conversación libre, en ambos casos se recurre a una guía que puede
ser un formulario o esquema de cuestiones que han de orientar la
conversación. Para los propósitos de la presente investigación,
realizamos la entrevista, al principal encargado de la gestión y control
de las actividades realizadas en la Federación Deportiva de Ligas
Barriales de Loja (FEDELIBAL), quien nos indicó los inconvenientes
presentados durante dicho proceso (Ver Anexo 3).
C.2.2. Encuesta
Rodríguez, N. 1986, la caracteriza a ésta técnica “como el

procedimiento a través del cual el investigador busca llegar a la
obtención de una información de un grupo de individuos en base a un
conjunto de estímulos (preguntas), mediante las cuales se busca llegar
a dicha información (respuestas). Las cuales pueden ser aplicadas en
forma escrita (cuestionario)”1.
Esta técnica, fue realizada a los usuarios del Sistema Web con el objeto
de tener información relacionada al funcionamiento y validación del
sistema (Ver Anexo 4).
1
TÉCNICAS DE INVESTIGACIÓN. 2006-2010[en línea].Técnicas de Investigación.com
[http://www.rrppnet.com.ar/tecnicasdeinvestigacion.htm], [Consulta: 10 de Enero de 2010].
33
D. REVISIÓN DE LITERATURA
1. FEDELIBAL Y SUS PRINCIPALES DISCIPLINAS
1.1. Historia.
El Deporte Barrial así como el Parroquial, durante años ha venido

fomentando el desarrollo de diferentes actividades deportivas, y
especialmente en la disciplina de fútbol, con una visión de enaltecer el
espíritu y la conducta de niños, jóvenes y adultos, cada día prosperando
y ampliando su participación a tal punto que en la actualidad hombres y
mujeres se han incorporado a la práctica deportiva.
La Ley de Cultura Física, Deportes y Recreación del Ecuador establece

en su Art. 12 que el deporte barrial y parroquial será planificado dirigido
y desarrollado por la Federación Nacional de Ligas Deportivas Barriales
y Parroquiales del Ecuador (FEDENALIGAS), y se regirá por sus
estatutos legalmente aprobados, en coordinación con la Secretaría
Nacional de Cultura Física, Deportes y Recreación.
La Federación Nacional de Ligas Deportivas Barriales del Ecuador

(FEDENALIGAS), aglutina a las diferentes federaciones provinciales de
ligas barriales. Las federaciones provinciales de ligas barriales están
constituidas por las distintas federaciones cantonales de ligas
deportivas barriales y éstas a su vez por las ligas deportivas barriales
con personería jurídica2.
2
FEDENALIGAS, (2010) [en línea] Disponible en: http://fedenaligas.org/textocat.php, [Consulta: 22 de Febrero de
2010].
34
Las diferentes organizaciones afiliadas a FEDENALIGAS, bajo su

dirección, han ido incorporando diferentes disciplinas deportivas de
carácter obligatorio en su campeonato. Así se práctica el fútbol,
ecuavóley y básquetbol, para mujeres y hombres en diferentes
categorías que van desde niños (as) hasta adultos, categoría máster.
El Deporte Barrial y Parroquial, aglutina a ciudadanos de todos los

sectores del país, sin discriminación de ningún tipo, llegando en la
actualidad a tener alrededor del millón de deportistas en permanente
actividad, tornándose de esta forma en un verdadero semillero de
futuros atletas que se incorporan a las diversas disciplinas del deporte
de alto rendimiento y profesional. De ahí que tenemos futbolistas de
raigambre popular, que han nacido en las canteras del deporte barrial y
han llegado a lugares estelares tanto en la práctica de alto rendimiento
como en lo profesional, dando un orgullo al pueblo ecuatoriano
específicamente en la disciplina de fútbol, que constituye el deporte más
practicado en todos los rincones de nuestra patria.
Es necesario que el Estado y los organismos de régimen seccional

autónomo, Consejos Provinciales, Municipios brinden el apoyo
ineludible a las Ligas Barriales y Parroquiales a fin de que las mismas
coadyuven en beneficio de todos los deportistas. Y así mismo se deben
propiciar campañas permanentes que tiendan a calar en el pensamiento
de los ciudadanos y especialmente de los hinchas organizados, que el
deporte es una fiesta de unidad y de alegría, de compartimiento, de
pasiones sanas y no un simple pretexto para desencadenar en
acciones violentas.
FEDELIBAL o Federación de Ligas Barriales de Loja, fue fundada el 8

de diciembre de 1984, y sus estatutos, fueron aprobados el 30 de enero
de 1990, mediante Acuerdo Ministerial Nro. 372, como filial de
FEDENALIGAS. Las oficinas se encuentran ubicadas en exteriores del
35
Estadio Federativo Reina del Cisne, entre calles Macará y Mercadillo.

Su actual Presidente es el Ing. Edwin Guerrero y el secretario en Sr.
Jhon Jaramillo.
1.2. Metas
FEDELIBAL, con la finalidad de masificar, socializar, confraternizar y

elevar el nivel de competencia, organiza anualmente el campeonato
provincial de fútbol senior con la participación de sus filiales, y la
premisa de motivar a cada deportista, dirigente y público en general a
cumplir con el principio de “Juego Limpio” Fairplay. El Campeón y Vice-
campeón participarán en los Zonales de FEDENALIGAS3.
Tiene las siguientes metas:
1. PROCURAR: Un sano esparcimiento, el respeto mutuo entre

todos los participantes del campeonato y leal competencia entre
los clubes representantes de las matrices filiales a FEDELIBAL.
2. INCENTIVAR: En el deportista barrial la práctica del deporte como

expresión de acercamiento social y permitirle la aplicación de las
reglas universales del fútbol PROPENDER: Al descubrimiento de
nuevos valores y talentos en el campo netamente barrial y
posicionar al movimiento barrial como generador y semillero de
deportistas.
3
FEDENALIGAS, (2010) [en línea] Disponible en: http://fedenaligas.org/textocat.php, [Consulta: 22 de Febrero de
2010].
36
1.3. Principales Disciplinas Deportivas
1.3.1. Fútbol
Reglas Básicas
El terreno de juego debe ser de césped natural o artificial,

dependiendo del reglamento de la competición. El terreno deberá
ser rectangular, siendo su largo entre 90 y 120 m (100 y 110m para
partidos internacionales), y su ancho entre 45 y 90m (64 y 75m para
partidos internacionales). Todo el perímetro del terreno estará
rodeado por líneas de 12cm de ancho como máximo: las 2 más
largas tendrán el nombre de líneas de banda, mientras que las
demás serán las líneas de meta. Dentro del campo se traza una
línea paralela y equidistante a las líneas de meta, la cual será
llamada línea media. El punto medio de esta línea será el centro de
una circunferencia de radio igual a 9,15m4.
En cada intersección entre las líneas de meta y de banda (4 en

total) se colocará un banderín no puntiagudo de por lo menos 1,5m
de altura. Opcionalmente se pueden poner banderines exteriores al
terreno a 1m de distancia de la intersección entre las líneas de
banda y la línea media. Tomando como centro cada una de las
intersecciones, se deberá marcar una semicircunferencia de radio
1m que vaya desde la línea de banda hasta la línea de meta, por el
interior del terreno. Esta área recibe el nombre de área de esquina.
Opcionalmente se pueden hacer unas pequeñas marcas sobre las
líneas de meta a 9,15m de cada banderín.
4
EDUCACIÓN FÍSICA.DEPORTE. 2001 [en línea]. Reglas Básicas del Fútbol. RincondelVago.com [http://www.Reglas
básicas del fútbol.htm], [Consulta: 23 de Febrero de 2010].
37
Fig. 1 Terreno de Juego
Sobre las líneas de meta se colocarán dos postes verticales,

ambos equidistantes de los banderines, y unidos por un poste
horizontal (travesaño). La distancia entre la parte interior de los
postes verticales será de 7,32m, y la distancia entre la parte
inferior del travesaño y el suelo de 2,44m. Los postes deberán
tener el mismo ancho que las líneas de meta, y ser de color
blanco. Esta construcción se llama meta o portería y puede
poseer una red que la cubra, pero deberá estar entre la línea de
meta y la parte exterior del terreno. Los postes pueden ser de
forma cuadrada, rectangular, redonda o elíptica.
En la zona de las metas se trazarán las áreas que son dos

líneas perpendiculares a la línea de meta, ubicadas a 5,5m de la
parte interior de cada poste vertical. Dichas líneas se adentrarán
5,5m en el terreno de juego y se unirán con una línea paralela a
la línea de meta. El área delimitada por dichas líneas será el
área de meta.
La denominada área penal se traza igual que el área de meta,
pero con líneas de 16,5 m. Dentro de esta área, se marcará el
punto penal. Dicho punto estará ubicado a 11m de la línea de
meta y equidistante de los postes de la meta. En el exterior del
área penal se marcará un segmento de circunferencia con centro
en el punto penal y un radio igual a 9,15m.
38
Fig. 2 Terreno de juego detallado
Poste del banderín de esquina: El poste del banderín de

esquina es obligatorio.
Fig. 3 Poste del banderín de esquina
Medidas del campo en metros:
Fig. 4 Medidas del campo en metros
39
Número de jugadores.- Cada uno de los dos equipos que

disputan un partido podrán tener un máximo de 11 futbolistas dentro del
terreno, y no menos de 7,si se llega a este número de jugadores, se
terminara el partido dando como ganador a el equipo contrario, con un
marcador de dos a cero aunque este último número puede variar según
la competición.
En competiciones oficiales se podrán hacer hasta 3 cambios en un

mismo partido por equipo, y se podrán tener en el banco de 3 a 7
suplentes, dependiendo del reglamento de la competición. Para partidos
de selecciones internacionales "A", se podrán tener hasta 6 suplentes
en el banco.
Para realizar una sustitución entre un futbolista titular y un suplente se

deberá informar al árbitro de esto. El suplente o sustituto no podrá
ingresar al campo de juego hasta que el jugador reemplazado haya
abandonado por completo el campo de juego. La sustitución se
realizará sobre la línea de banda y sobre la mitad del campo durante
una interrupción del partido. El jugador reemplazado no podrá volver a
ingresar durante ese partido. Si el jugador a ingresar viola estas reglas,
será amonestado.
En cualquier momento del partido, incluso durante una tanda de

penales, un jugador de campo podrá cambiar de posición con el
guardameta si el árbitro ha sido informado, y esto se realiza durante una
interrupción. Si alguna de estas dos condiciones no se cumplen, ambos
jugadores serán amonestados. Si un jugador es expulsado antes del
comienzo del partido, podrá ser reemplazado por un suplente. Si un
suplente es expulsado antes del partido, no podrá jugar, ni ser
remplazado.
40
El árbitro.-Es quien tendrá la autoridad total para hacer cumplir las

reglas de juego en el partido para el que ha sido nombrado. Todas las
decisiones del árbitro son definitivas. Solo él puede modificar una
decisión, siempre que no haya reanudado el juego o el partido haya
finalizado.
El árbitro le mostrará tarjeta amarilla o roja a todo jugador que cometa

una infracción merecedora de la misma. En caso de que un jugador
cometa más de una infracción al mismo tiempo, el árbitro castigará la
más grave.
Además del árbitro principal hay dos árbitros asistentes, que son los
encargados de ayudar al árbitro en toma de decisiones particulares por
su ubicación en el campo. Los asistentes tiene la misión de indicar las
siguientes situaciones, decisión que podrá ser aceptada o no por el
árbitro principal.
 El balón ha traspasado los límites del terreno

 A qué equipo corresponde realizar un saque de esquina, de meta o
de banda
 Posición de fuera de juego
 Sustitución de jugadores
 Infracciones o incidentes fuera del campo visual del árbitro principal
 Infracciones o incidentes cercanos al asistente
 Si el guardameta se adelanta en un penal, o la pelota no ingresó a la
meta por completo
Duración del partido.-Cada partido se juega en dos periodos de

45 minutos cada uno, salvo que por mutuo acuerdo entre el árbitro y los
dos equipos participantes se convenga otra cosa. Los cambios de
duración de cada periodo deberán tomarse antes del inicio del partido y
41
conforme al reglamento de la competición. Entre ambos periodos se

realizará un descanso de 15 minutos como máximo.
Al final de cada periodo el árbitro deberá, según su criterio, jugar más

tiempo para recuperar el tiempo perdido. Los motivos para conformar
ese tiempo añadido son los siguientes:
 sustituciones
 evaluación de una lesión por parte del árbitro
 transporte de los jugadores fuera del terreno
 cualquier otro motivo de pérdida de tiempo
Fig. 5 Marcador electrónico
En caso de que se deba patear o volver a patear un penal con el tiempo

extra ya cumplido, se prolongará el tiempo hasta que se efectúe el
penal. El mismo se considera efectuado cuando es gol, es desviado
fuera del campo, toca al guardameta o toca cualquier parte de la meta.
Culminado el tiempo reglamentario (90 minutos), incluidas las adiciones,

puede ser necesario disputar una prórroga o tiempo extra, dependiendo
del reglamento de la competición. Dicha prórroga consta de dos
periodos de 15 minutos, pero puede verse culminada si se convierte un
gol de oro o de plata, si estos están permitidos por la competición.
También dependiendo del reglamento de la competición se pueden
42
ejecutar tiros penales después del tiempo reglamentario o tras la

prórroga.
1.3.2. Básquet
Reglas Básicas
La cancha.- Una pista de baloncesto tiene que ser una superficie

dura, plana, rectangular y libre de obstáculos, con 15 m de ancho y 28
m de longitud. El perímetro de la pista debe estar libre de obstáculos a
dos metros de distancia. La altura del primer obstáculo que se
encuentre verticalmente sobre la pista debe de estar como mínimo a 7
m de altura5.
El campo está dividido en dos mitades iguales separadas por la línea

denominada de medio campo y con un círculo que parte del centro de la
pista, el círculo central mide 3,6 m diámetro. Para cada equipo el medio
campo que contiene la canasta defendida se denomina medio campo
defensivo y el medio campo que contiene la canasta en la que se
pretende anotar se llama medio campo ofensivo. En los lados menores
se sitúan los aros que están a 3,05 m. de altura y se introducen 1,20 m.
dentro del rectángulo de juego, tienen que estar provistos de
basculantes homologados.
5
BALONCESTO. 2001 [en línea]. Reglas Básicas del Baloncesto. RincondelVago.com [http://www.Reglas básicas del
Baloncesto.htm], [Consulta: 23 de Febrero de 2010].
43
Fig. 6 Campo de Baloncesto
Paralela a la línea de fondo encontramos la línea de tiros libres, que se

encuentra a 5,80 m de la línea de fondo y a 4,60 m de la canasta. El
círculo donde se encuentra la línea de tiros libres tiene un diámetro de
3,6 m. Las líneas miden 6 cm. de ancho. La línea de tres puntos se
encuentra situada a 6,25 m. (FIBA) y a 7,25 m. (NBA) de distancia de la
canasta.
Fig. 7 Línea de tiros libres
44
Fig. 8 Campo de Baloncesto Detallado
Duración de un partido: En la FIBA6, según su reglamento el

partido está compuesto por cuatro períodos de 10 minutos cada uno. En
la NBA7 la duración de cada período es de 12 min, y en NCAA8 se
juegan dos períodos de 20 minutos cada uno. Si el partido finaliza con
empate entre los dos equipos, deberá jugarse una prórroga de 5 min
más. Y así sucesivamente hasta que un equipo gane el partido.
Jugadores: el equipo presentado al partido está formado por 12

jugadores como máximo. 5 formarán el quinteto inicial y los otros 7
serán los suplentes. El entrenador podrá cambiar a los jugadores tantas
veces como desee aprovechando interrupciones en el juego.
6
FIBA.-La Federación Internacional de Baloncesto, es el organismo que se dedica a regular las normas del baloncesto
mundialmente, así como de celebrar periódicamente competiciones y eventos en sus dos disciplinas.
7
NBA.-NationalBasketballAssociation (Asociación Nacional de Baloncesto) es la principal liga estadounidense de baloncesto
profesional.
8
NCAA.-Es una asociación compuesta de unas 1.200 instituciones, conferencias, organizaciones e individuos que organizan la
mayoría de los programas deportivos universitarios en los Estados Unidos de América. Su sede está actualmente situada en
Indianápolis, Indiana
45
Inicio del partido: debe colocarse un jugador de cada equipo

dentro del círculo central con un pie cerca de la línea que divide el
terreno de juego en dos mitades, situado cada uno de ellos en su
campo. Los demás jugadores deben estar fuera del círculo. El árbitro
lanza la pelota hacia arriba desde el centro del círculo y los dos
jugadores saltan verticalmente para intentar desviarla, sin cogerla, hacia
algún compañero de su equipo.
Árbitros: para la mayoría de competiciones suelen ser dos árbitros

los encargados de dirigir el encuentro. Aunque para muchas ligas
profesionales existan tres y para otras con muy bajo presupuesto uno.
Mesa de anotadores: la mesa de anotadores (anotador,

ayudante de anotador, cronometrador, operador de la regla de 24 s y, si
lo hubiera, comisario) controla todas las incidencias del partido (tanteo,
tiempos muertos, tiempo de juego, faltas, cambios, etc.) y elabora el
acta del partido.
Fig. 9 Canasta
46
2. GESTIÓN DE CAMPEONATOS DEPORTIVOS
2.1. Introducción.
La calidad se ha convertido en un aspecto ineludible en la gestión

deportiva. La necesidad de adaptarse de manera permanente a una
realidad cambiante ha obligado a una modernización tecnológica
necesaria por parte de las organizaciones deportivas para tratar de
alcanzar la máxima calidad posible en los servicios que prestan. La
obligatoria adecuación de las estructuras organizativas a la rápida
evolución del sector, es la clave para lograr ser más eficaces y poder
atender estas necesidades con garantías suficientes, en donde la oferta
que se realice se ajuste lo máximo posible a la demanda.
La gestión del deporte a través de la calidad es un elemento estratégico

y, por tanto, un compromiso para las organizaciones deportivas que
quieran caracterizarse por una buena gestión y tener la clave para que
se produzca una satisfacción conjunta de los grupos de interés.
2.2. Campeonatos deportivos
2.2.1. Campeonatos por puntos
El campeonato por "puntos" es, probablemente, el más equitativo de los

campeonatos, siempre que el tiempo e instalaciones disponibles lo
permitan, ya que cada jugador o equipo juega el mayor (e igual) número
de partidos. Se basa en que cada participante se enfrenta, por turno, a
todos los otros jugadores o equipos.
Vence el equipo que gana más partidos. Puede suceder un empate
47
entre dos o más participantes y ser entonces necesario recurrir a

partidos suplementarios para definir un ganador. Otros procedimientos
para esa definición pueden ser:
1. Coronar a quien ganó el partido entre ambos participantes.

2. Por "gol average".
Es un tipo de campeonato que se presta tanto para actividades

individuales como para las de equipo, y es conveniente para cualquier
tipo de institución, se presta muy bien cuando se proyecta un
campeonato que dure una temporada, ya que también puede jugarse a
varias ruedas. Además establece un campeonato de organización
relativamente fácil, ya que puede confeccionarse un calendario de
partidos fijos; sin embargo, hay que avisar con tiempo a los
participantes la fecha, lugar, hora y contrincante.
Lo mejor es dar a cada equipo el calendario de sus propios partidos. Al

plantear un campeonato por "puntos" hay que tomar en cuenta:
1. Cada equipo o jugador recibe un número, ya que es mucho más

fácil manejarse con éstos.
2. Los números se adjudican por sorteo entre los jugadores o
equipos.
3. Al realizar el calendario hay que tratar que los participantes
tengan el mismo tiempo de descanso entre partido y partido, que
jueguen el mismo número de partidos en cada cancha (si hay
varias) y también que jueguen a distintas horas (si hubiera
horario diverso).
48
2.2.2. Calendarios de juegos
2.2.2.1. Método rotativo para la confección de un

calendario
El método rotativo para la confección de un calendario es sin

lugar a dudas el más fácil de confeccionar. Se basa en que
un equipo queda estacionario y los otros de desplazan en el
sentido de las agujas del reloj.
1. Con número par de equipos (por ejemplo, con 8

equipos); el equipo estacionario es el 1 y los demás
corren un lugar en cada fecha.
Fig. 10 Fixture usual de un campeonato de todos contra todos de 6

equipos
2. Con número impar de equipos (por ejemplo, con 7 equipos); se

marcará en el sitio del equipo que queda fijo la palabra "bye"
(equipo que queda libre en dicha fecha). Se procede en la
misma forma que con los pares y el equipo que juega contra
"bye" está libre en dicha fecha.
49
Publicación del calendario
En el avisador del torneo debería figurar un calendario

departidos y/o distribuir una copia a cada participante para
comunicar y recordar las fechas de los partidos.
2.2.2.2. Número de Partidos por Fechas
1. Si el número de equipos es par, la cantidad de partidos por

fecha es la mitad de la cantidad de equipos. Por ejemplo, 8
equipos dan 4 partidos por fecha.
2. Si el número de equipos es impar, la cantidad de partidos es
la mitad del número de equipos menos uno. Por ejemplo, 7
equipos dan: 7 menos 1 dividido 2, igual a 3 partidos por
fecha.
2.2.2.3. Número de Fechas
El número de fechas en un campeonato por "puntos" es:

1. Cuando hay un número par de equipos, la cantidad de
fechas es igual al número de equipos menos uno.
2. Cuando el número de equipos es impar la cantidad de
fechas equivale al número de equipos.
2.2.2.4. Número de Partidos
Para determinar el número de partidos de un campeonato

por "puntos" se utiliza la siguiente fórmula:
Número de partidos = número de equipos x (número de
equipos-1)/2
o sea N x (N-1)/2
50
En un campeonato de ocho equipos sería: 8 x (8-1) = (8 x 7

DIVIDIDO 2)= 28 partidos9
2.2.3. Campeonatos por Eliminación
Este tipo de campeonato se basa en la eliminación de la mitad de

los participantes en cada fecha. Si los perdedores no tienen más
oportunidad de jugar se le llama de simple eliminación; si se integra
una rueda de perdedores (repechaje) se le llama de doble
eliminación. Se puede realizar también con ruedas consuelos: los
que han sido eliminados y han jugado solamente 1 o 2 partidos,
tienen una oportunidad de competir entre sí en otra rueda
eliminatoria, pero ya no dentro del campeonato original. La gran
ventaja de esta forma de campeonatos es la rapidez con que se
puede determinar un ganador.
Se adapta a todas las situaciones como serían las de centros
docentes, recreativos, campamentos, etc., y a cualquier tipo de
actividad tanto deportiva (individual o de equipo) como social.
Tienen un gran valor para dar interés a una actividad en forma
rápida.
2.2.3.1. Campeonatos de Simple Eliminación
El campeonato de "simple eliminación" es el método más

rápido y simple para determinar un ganador.
Los participantes que pierden en cada fecha quedan

eliminados, por lo tanto, en cada fecha quedan excluidos la
9
ASOCIACIÓN DEPORTE Y CIENCIA. 2004 [en línea]. Cómo organizar campeonatos deportivos.
DeporteyCiencia.com. [http://www.Deporteyciencia Cómo organizar campeonatos deportivos.htm], [Consulta: 05 de
Marzo de 2010].
51
mitad de los participantes. Este campeonato es muy valioso

cuando la cantidad de participantes es grande, se dispone
de poco tiempo y las instalaciones son insuficientes.
Su desventaja principal radica en que los participantes

menos capaces son eliminados rápidamente (siendo los que
necesitan más actividad) y por consecuencia los mejor
dotados son los que más intervienen.
Otra desventaja a tener presente es que un buen

participante puede ser eliminado por una actuación pobre y
entonces los resultados (orden de equipos) del campeonato
no serían reflejo fiel del valor de cada participante.
2.2.3.2. Determinación del Número de Partidos
El número de partidos es igual al de participantes menos 1.

Por ejemplo, para 17 participantes sería: 17-1.Si se desea
determinar el tercer puesto habrá un partido extra; en tal
caso el número de partidos será igual al de participantes.
2.2.3.3. Número de Fechas
Se determina el número de fechas elevando la potencia del

número "2" tantas veces como sea necesario para igualar o
sobrepasar el número de participantes. Por ejemplo, ocho
participantes es 23 , 2 x 2 x 2 = 8; o sea, 3 fechas.
2.2.4. Organización del campeonato
52
La organización de campeonatos no escapa al presupuesto que

establece como ineludible la adopción de previsiones frente a la
eventualidad de una realización. De ello se desprende la necesidad
de una adecuada planificación que abarque todas las circunstancias
“aún las de aparente escasa entidad” que son susceptibles de
acontecer incidiendo en mayor o menor grado en el éxito final del
evento. Similares razones promueven el establecimiento previo de
una reglamentación que será guía para el participante y respaldo
para el organizador.
En tal sentido los referidos elementos se establecen desde dos

puntos de vista complementarios: una "lista de control" y un
"esquema de reglamento".
La lista de control tiene una estructura emergente de la necesidad
de apreciar con la debida previsión los tres aspectos anotados en
columnas encabezadas, respectivamente: si, no y tiempo. Los dos
primeros casos son los correspondientes a la aprobación u omisión
de organización o previsión del aspecto de que se trate; el tercero
alude al tiempo de anticipación con que tal aspecto debe ser
encarado, en caso de anotación previa afirmativa.
En cuanto al esquema de reglamento no pretende ser más que una

guía general -y no un molde- que servirá al efecto de desarrollar el
reglamento propiamente dicho, con arreglo a las condicionantes
propias de toda actividad educativa y/o recreativa.
53
2.2.4.1. Lista de Control10
Comisión del Campeonato (responsabilidad total de la

competencia)
 Integración
 Marcar objetivos de la competencia
 Obtener aprobación (o permiso) para realizar el torneo
 Designar director del torneo
 Presentar informe a federación o instituto patrocinante.
Director (secretario ejecutivo de la Comisión de

Campeonato)
 Proyectar el reglamento de competencia
 Elevarlo a la Comisión de campeonato
 Programar el calendario de la competencia
 Mantener la rutina administrativa
 Notificar a los participantes
 Comunicar el reglamento
 Preparar y enviar invitaciones
 Evaluar el torneo
 Elevar informes a la Comisión de Campeonato
Comisión o encargado de premios

 Proyectar el presupuesto
 Elevarlo a la Comisión de Campeonato
 Seleccionar distinciones:
o Diplomas
o Medallas
10
ASOCIACIÓN DEPORTE Y CIENCIA. 2004 [en línea]. Cómo organizar campeonatos deportivos.
DeporteyCiencia.com. [http://www.Deporteyciencia Cómo organizar campeonatos deportivos.htm], [Consulta: 05 de
Marzo de 2010].
54
o Copas
o Plaquetas, etc.
 Planear grabado de copas y medallas.
 Planear exposición de premios.
 Planear entrega de premios.
Comisión o encargado de los árbitros

 Proyectar presupuesto.
 Elevarlo a la Comisión de Campeonato.
 Preparar lista de árbitros y ayudantes (entrevistarlos).
 Ratificar árbitros para determinados partidos. .
 Comisiones o encargados de relaciones
públicas y propaganda
 Proyectar presupuesto.
 Elevarlo a la Comisión de Campeonato.
 Promocionar la competencia entre los posibles
participantes.
 Establecer contactos con prensa (escrita, oral, televisiva).
 Preparar material impreso y fotografías.
 Imprimir programas y "afiches".
2.3. Características del armado de un Campeonato o

Fixtures con el esquema Round Robin.
2.3.1. Descripción general
En una competencia deportiva, n equipos deben jugar entre sí (1 o

más veces) en un período de tiempo siguiendo algún esquema. Uno
de los esquemas más populares es el denominado Round Robin
donde todo equipo e juega contra todos los demás una cierta
cantidad r de veces a lo largo de todo el torneo. Si r es 1, el
55
esquema se denomina Single Round Robin (SRR). Si res 2, se

denomina Doble Round Robin (partido y revancha). Por lo general,
un partido se juega en el estadio de uno de los dos equipos. Se dice
que un equipo juega de local cuando lo hace en su propio estadio, y
que juega de visitante en caso contrario.
A grandes rasgos, podemos clasificar los fixtures en dos grandes

tipos:
Fixtures Restringidos Temporalmente: Son aquellos

en los que todos los partidos se distribuyen de forma tal de
minimizar la cantidad de fechas o rondas requeridas.
Fixtures Relajados Temporalmente: Son aquellos en

los que los partidos pueden distribuirse libremente a lo largo de
todas las rondas que se deseen. Ejemplos típicos de esta clase de
fixtures son los de las grandes ligas de basquetbol (NBA) en EEUU,
o la de Hockey (NHL11)
Por ejemplo un torneo de 4 equipos que siga el esquema Round

Robin necesitaría al menos 3 rondas. Entonces, si se requiere
armar un fixture temporalmente restringido este debería tener
exactamente 3 rondas.
En general, un torneo simple con n equipos requeriría por lo menos

n − 1 rondas si n es par y por lo menos n en el caso de que sea
impar. Para simplificar las cosas, a lo largo de todo el trabajo
asumiremos que n(la cantidad de equipos), es par, ya que para
contemplar los casos en donde n es impar, sólo tendremos que
agregar un equipo “ficticio” o “comodín”. Entonces, cuando el fixture
11
NHL.-Es una organización deportiva compuesta de equipos de hockey sobre hielo de Canadá y los Estados Unidos.
56
resultante indique que un cierto equipo e debe jugar contra ese

equipo “ficticio” en la ronda r, diremos que e queda libre en la ronda
r.
2.3.2. Programación Entera
En base a un modelo de Programación Entera, también podemos

representar un fixture Single Round Robin (SRR) de n equipos
como se describe a continuación:
Sea 𝑋𝑖𝑗𝑟 una variable binaria que toma el valor 1 solo si el equipo i
juega contra el equipo j en la ronda r (podemos además asumir que
i juega de local y j de visitante) y 0 en otro caso. El problema,
entonces consiste en encontrar una matriz X[𝑋𝑖𝑗𝑟 ]de ceros y unos
que cumpla las siguientes condiciones:
a.
b.
a. Cada equipo juega exactamente una vez por ronda (ya sea de
local o visitante)
b. Cada equipo juega contra todos los demás exactamente una
vez.
Una solución factible para este conjunto de restricciones

constituye un fixture SSR. Para un problema dado, se puede
querer obtener sólo una solución cualquiera, todas las posibles,
o la mejor solución posible respecto de alguna función objetivo
que se quiera optimizar.
57
3. MODELOS MATEMÁTICOS
3.1. Introducción
En ciencias aplicadas un Modelo matemático es uno de los tipos de

modelos científicos, que emplea algún tipo de formulismo matemático
para expresar relaciones, proposiciones sustantivas de hechos,
variables, parámetros, entidades y relaciones entre variables y/o
entidades u operaciones, para estudiar comportamientos de sistemas
complejos ante situaciones difíciles de observar en la realidad.
El significado de Modelo matemático en matemáticas, sin embargo, es

algo diferente. En concreto en matemáticas se trabajan con modelos
formales. Un modelo formal para una cierta teoría matemática es un
conjunto sobre el que se han definido un conjunto de relaciones unarias,
binarias y ternarias, que satisface las proposiciones derivadas del
conjunto de axiomas de la teoría.
La rama de la matemática que se encarga de estudiar sistemáticamente

las propiedades de los modelos es la teoría de modelos.
El término de modelización matemática es utilizado también en diseño

gráfico cuando se habla de modelos de los objetos en 2D o 3D.
3.2. Clasificación de modelos matemáticos
Se podría decir que un modelo de las ciencias físicas es una traducción

de la realidad física para poder aplicar los instrumentos y técnicas de
las teorías matemáticas para estudiar el comportamiento de sistemas
complejos, y posteriormente hacer el camino inverso para traducir los
58
resultados numéricos a la realidad física. Generalmente se introducen

simplificaciones de realidad.
Los modelos matemáticos pueden clasificarse de la siguiente manera:
 Determinista. Se conoce de manera puntual la forma del

resultado ya que no hay incertidumbre. Además, los datos
utilizados para alimentar el modelo son completamente
conocidos y determinados.
 Estocástico. Probabilístico, que no se conoce el resultado
esperado, sino su probabilidad y existe por tanto
incertidumbre.
Además con respecto a la función del origen de la información utilizada

para construirlos los modelos pueden clasificarse de otras formas.
Podemos distinguir entre modelos heurísticos y modelos empíricos:
 Modelos heurísticos (del griego euriskein 'hallar, inventar').

Son los que están basados en las explicaciones sobre las
causas o mecanismos naturales que dan lugar al fenómeno
estudiado.
 Modelos empíricos (del griego empeirikos relativo a la
'experiencia'). Son los que utilizan las observaciones directas
o los resultados de experimentos del fenómeno estudiado.
Además los modelos matemáticos encuentran distintas denominaciones

en sus diversas aplicaciones. A continuación veremos algunos tipos en
los que se puede adecuar algún modelo matemático de interés. Según
su campo de aplicación los modelos:
59
 Modelos conceptuales. Son los que reproducen mediante fórmulas

y algoritmos matemáticos más o menos complejos los procesos
físicos que se producen en la naturaleza.
 Modelo matemático de optimización. Los modelos matemáticos
de optimización son ampliamente utilizados en diversas ramas de la
ingeniería para resolver problemas que por su naturaleza son
indeterminados, es decir presentan más de una solución posible.
3.2.1. Modelos Heurísticos
Son todos aquellos que se plantean a partir del comportamiento de

variables intertemporales o series de datos, todos los modelos de
regresión son heurísticos. Ejemplos: Yt = A + B*Xt, donde: Yt
es la variable dependiente que se va a explicar a partir de otra,
Xt es la variable independiente, A es la constante del modelo
en el hipotético evento de que Xt = 0 y B es la pendiente o
cociente de apalancamiento del modelo. Regresión Lineal
Inversa: Yt = A + Xt / B, Regresión Cuadrática: Y= Ax^2 + Bx + C,
Regresión Logarítmica: A + BlnX, Regresión Exponencial: Y=A* B^X
o Y = A* e ^BX, Regresión Potencial: Y = A* X^B. A diferencia de los
modelos determinísticos, los modelos heurísticos solo sirven para
explicar el PASADO nunca para predecir el futuro y solo pueden
utilizarse para INTERPOLAR datos que se hubiesen utilizado para
calcular la CURVA O RECTA DE REGRESIÓN ORIGINAL. La
variable dependiente NUNCA se explica totalmente a partir de las
variables independientes o conjunto de argumentos. Han de cumplir
esta propiedad: x1,x2,x3...xi € Xt y y1,y2,y3...yi € Yt.
3.3. Representación del modelo
La representación puede ser de la siguiente manera:
60
 Conceptual. Por una descripción cualitativa bien organizada que

permite la medición de sus factores.
 Matemático. Se refiere a una representación numérica por aspectos
lógicos y estructurados con aspectos de la ciencia matemática.
Pueden ser números, letras, imágenes, símbolos. Por ejemplo si se

refiere a un modelo gráfico de matemáticas, se observan imágenes y
gráficas matemáticas, que representan a un modelo numérico y de
ecuaciones, los cuales son expresiones visuales basadas en aspectos
cuantificables y de la ciencia matemática.
Físico. Basado en aspectos de la ciencia física, de aquellos

movimientos de los cuerpos, y que además es cuantificable. Estos
modelos generalmente representan el fenómeno estudiado utilizando
las mismas relaciones físicas del prototipo pero reduciendo su escala
para hacerlo manejable. Por ejemplo pertenecen a este tipo de modelo
las representaciones a escalas reducidas de presas hidráulicas,
puertos, o de elementos de estas obras, como un vertedero o una
escollera.
4. TECNOLOGÍAS PARA EL DESARROLLO DE LA

APLICACIÓN WEB
4.1. Servidores Web
Es un programa que aplica el protocolo HTTP (hypertext transfer

protocol). Este protocolo pertenece a la capa de aplicación del modelo
OSI12 y está diseñado para transferir lo que llamamos hipertextos,
páginas web o páginas HTML (hypertext markup language), los cuales
12
OSI.- Modelo de red descriptivo creado por la Organización Internacional para la Estandarización en el año 1984. Es un marco de
referencia para la definición de arquitecturas de interconexión de sistemas de comunicaciones.
61
son textos complejos con enlaces, figuras, formularios, botones y

objetos incrustados como animaciones o reproductores de música.
Es un programa que se ejecuta continuamente en un ordenador13,

manteniéndose a la espera de peticiones por parte de un cliente
(navegador web)14 y que responde a estas peticiones adecuadamente,
mediante una página web que se exhibirá en el navegador o mostrando
el respectivo mensaje si se detectó algún error.
Instalar un Servidor Web nos permitirá acoplar nuestra propia página

web sin necesidad de contratar hosting15, probar nuestros desarrollos
vía local, acceder a los archivos de nuestro equipo desde un PC remoto
o utilizar alguno de los programas basados en web tan interesantes que
están viendo la luz últimamente. El problema de usar nuestro ordenador
como Servidor Web es que conviene tenerlo encendido
permanentemente, con el supeditado coste debido al consumo de
electricidad, sin dejar de considerar que hay alojamientos web gratuitos,
incluso sin publicidad y con interesantes funciones).
“Sin embargo, el hecho de que HTTP y HTML estén íntimamente

ligados no debe dar lugar a confundir ambos términos. HTML es un
lenguaje de marcas y HTTP es un protocolo”16.
13
ORDENADOR.- También se emplea el término para referirse al ordenador que lo ejecuta.
14
NAVEGADOR WEB.- Programa que permite ver la información que contiene una página web
15HOSTING.- es una palabra del Ingles que quiere decir dar hospedaje o alojar. Aplicado al Internet, significa poner una página
web en un servidor de Internet para que ella pueda ser vista en cualquier lugar del mundo entero con acceso al Internet.
16
WIKIPEDIA, (2010) Servidores Web [en línea] Disponible en: http://es.wikipedia.org/wiki/Servidor_web[Consulta: 11
de Enero de 2010].
62
Fig. 11Servidor
Un ServidorWeb se mantiene a la espera de peticiones HTTP por parte

de un cliente HTTP que solemos conocer como Navegador. El cliente
realiza una petición al servidor y éste le responde con el contenido que
el cliente solicita. Por ejemplo, al teclear http://www.wikipedia.org/ en
nuestro navegador, éste realiza una petición HTTP al servidor de dicha
dirección. El servidor responde al cliente enviando el código HTML de la
página; el cliente, una vez recibido el código, lo interpreta y lo exhibe en
pantalla. El cliente es el encargado de interpretar el código HTML,
mientras el servidor se limita a transferir el código de la página.
4.2. JavaServer Faces
JavaServer Faces (JSF) es una tecnología y framework17 para

aplicaciones Java basadas en web que simplifica el desarrollo de
17
FRAMEWORK.- Estructura conceptual y tecnológica de soporte definida, con módulos de software concretos, en la que otro
proyecto de software puede ser organizado y desarrollado. Típicamente, puede incluir soporte de programas, bibliotecas y un
lenguaje interpretado entre otros programas para ayudar a desarrollar y unir los diferentes componentes de un proyecto.
63
interfaces de usuario en aplicaciones Java EE18. JSF usa JavaServer

Pages (JSP) como la tecnología que permite hacer el despliegue de las
páginas, pero también se puede acomodar a otras tecnologías como
XUL19.
JSF incluye20:
 Un conjunto de APIs21 para representar componentes de una interfaz

de usuario, administrar su estado, manejar eventos, validar entrada,
definir un esquema de navegación de las páginas y dar soporte para
internacionalización y accesibilidad.
 Un conjunto por defecto de componentes para la interfaz de usuario.
 Dos bibliotecas de etiquetas personalizadas para JSP que permiten
expresar una interfaz JSF dentro de una página JSP.
 Un modelo de eventos en el lado del servidor.
 Administración de estados.
 Beans administrados.
4.2.1. Objetivos
1. Definir un conjunto de clases base de Java para componentes

de la interfaz de usuario, estado de los componentes y eventos
de entrada.
18
JAVA EE.- Anteriormente conocido como Java 2 Platform, Enterprise Edition o J2EE hasta la versión 1.4, es una plataforma de
programación—parte de la Plataforma Java—para desarrollar y ejecutar software de aplicaciones en Lenguaje de programación
Java con arquitectura de N capas distribuidas y que se apoya ampliamente en componentes de software modulares ejecutándose
sobre un servidor de aplicaciones.
19
XUL.-Serie de etiquetasXML que permiten diferentes plataformas de operaciones para intercambiar datos que describen el
interfaz de usuario de un programa.
20
WIKIPEDIA, (2010) JavaServer Faces [en línea] Disponible en: http://es.wikipedia.org/wiki/JavaServer_Faces [Consulta: 12 de
Enero de 2010].
21
APIs.- Del inglésApplicationProgramming Interface, es el conjunto de funciones y procedimientos (o métodos, en la
programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción.
Son usados generalmente en las bibliotecas.
64
2. Proporcionar componentes para la interfaz de usuario,

incluyendo los elementos estándares de HTML para
representar un formulario.
3. Proporcionar un modelo de JavaBeans22 para enviar eventos
desde los controles de la interfaz de usuario del lado del cliente
a la aplicación del servidor.
4. Definir APIs para la validación de entrada, incluyendo soporte
para la validación en el lado del cliente.
5. Especificar un modelo para la internacionalización y
localización de la interfaz de usuario.
6. Automatizar la generación de salidas apropiadas para el
objetivo del cliente, teniendo en cuenta todos los datos de
configuración disponibles del cliente, como versión del
navegador.
Este modelo de programación bien definido y la librería de etiquetas

para componentes UI23 facilita de forma significativa la tarea de la
construcción y mantenimiento de aplicaciones web con UIs en el lado
servidor.
Con un mínimo esfuerzo, es posible:
 Conectar eventos generados en el cliente a código de la aplicación

en el lado servidor.
 Mapear componentes UI a una página de datos en el lado servidor.
 Construir una interfaz de usuario con componentes reutilizables y
extensibles.
22
JAVABEANS.- Son un modelo de componentes creado por Sun Microsystems para la construcción de aplicaciones
en Java.Se usan para encapsular varios objetos en un único objeto, para hacer uso de un solo objeto en lugar de
varios más simples.
23
UI.- La interfaz de usuario es el medio con que el usuario puede comunicarse con una máquina, un equipo o una computadora, y
comprende todos los puntos de contacto entre el usuario y el equipo.
65
Fig. 12 Interfaz de Usuario
Como se puede apreciar en la figura, la interfaz de usuario que se crea

con la tecnología JSF se ejecuta en el servidor y se renderiza en el
cliente.
4.2.2. Beneficios de JSF
 Pueden encontrarse implementaciones de distintos fabricantes.

 JSF trata la vista de una forma distinta a lo que estamos
acostumbrados en Aplicaciones Web, ya que este tratamiento
es mucho más cercano al estilo de Java Swing, Visual Basic o
Delphi.
 JSF es muy flexible. Nos permite crear nuestros propios
componentes, y/o renderizadores24 para pintar los
componentes en la forma que más nos convenga.
 Ofrece una clara separación entre el comportamiento y la
presentación.
24
RENDERIZADO.- (render en inglés) es un término usado en jerga informática para referirse al proceso de generar una imagen
desde un modelo. Este término técnico es utilizado por los animadores o productores audiovisuales y en programas de diseño en
3D.
66
 Separa la lógica del negocio de la presentación, y permite que

cada miembro del equipo de desarrollo de la Aplicación Web se
centre en su parte asignada del proceso de diseño,
proporcionando un modelo sencillo de programación para
enlazar todas las piezas.
 Mejora los conceptos familiares de componente-UI y capa-web
sin limitarnos a una tecnología de script particular o un lenguaje
de marcas.
 Aunque la tecnología JSF incluye una librería de etiquetas JSP
personalizadas para representar componentes en una página
JSP, las APIs de JSF se han creado directamente sobre el API
JavaServlet25. Esto permite, hacer algunas cosas avanzadas:
usar otra tecnología de presentación junto a JSP, crear
nuestros propios componentes personalizados directamente
desde las clases de componentes, y generar salida para
diferentes dispositivos cliente, entre otras.
 La tecnología JSF proporciona una rica arquitectura para
manejar el estado de los componentes, procesar los datos,
validar la entrada del usuario, y manejar eventos26.
4.2.3. Ciclo de vida de una página JavaServer Faces
Es similar al de una página JSP: El cliente hace una petición HTTP

(Hiper Text Transfer Protocol) de la página y el servidor responde
con la página traducida a HTML. Sin embargo, debido a las
características extras que ofrece la tecnología JSF, el ciclo de vida
proporciona algunos servicios adicionales.
25
SERVLETS.-Son objetos que corren dentro del contexto de un contenedor de servlets (ej: Tomcat) y extienden su funcionalidad.
26
WIKIPEDIA, (2010) JavaServer Faces [en línea] Disponible
en:http://www.sicuma.uma.es/sicuma/Formacion/documentacion/JSF.pdf [Consulta: 12 de Enero de 2010].
67
Los pasos del ciclo de vida se ejecutan dependiendo de si la

petición se originó o no desde una aplicación JSF y si la respuesta
es o no generada con la fase de renderizado del ciclo de vida de
JSF.
4.2.4. Escenarios de Procesamiento del Ciclo de Vida

de una Petición
 Respuesta Faces :Una respuesta servlet que se generó mediante

la ejecución de la fase Renderizar la respuesta del ciclo de vida de
procesamiento de la respuesta.
 Respuesta No-Faces: Una respuesta generada por el servlet en
la que no se ha ejecutado la fase Renderizar la respuesta. Un
ejemplo es una página JSP que no incorpora componentes JSF.
 Petición Faces: Una petición al servlet que fue enviada desde
una respuesta Faces previamente generada. Un ejemplo es un
formulario enviado desde un componente de interfaz de usuario
JSF, donde la URI27 de la petición identifica el árbol de
componentes JSF para usar el procesamiento de petición.
 Petición No-Faces: Una petición al servlet que fue enviada a un
componente de aplicación como un servlet o una página JSP, en
vez de directamente a un componente JSF.
La composición de estas peticiones y respuestas resulta en tres

posibles escenarios del ciclo de vida que pueden existir en una
aplicación JSF:
 Escenario 1: Una petición No-Faces genera una respuesta

Faces: Un ejemplo de este escenario es cuando se pulsa un
enlace de una página HTML que abre una página que contiene
27
URI.- UniformResourceIdentifier, Es una cadena corta de caracteres que identifica inequívocamente un recurso.
68
componentes JSF. Para construir una respuesta Faces desde una

petición No-Faces, una aplicación debe proporcionar un mapeo
Faces Servlet en la URL28 de la página que contiene componentes
JSF. Faces Servlet acepta peticiones entrantes y pasa a la
implementación del ciclo de vida para su procesamiento.
 Escenario 2: Una petición Faces genera una respuesta no-Faces:

Algunas veces una aplicación JSF podría necesitar redirigir la
salida a un recurso diferente de la aplicación Web (p.ej. una
imagen sencilla) o generar una respuesta que no contiene
componentes JSF. En estas situaciones, el desarrollador debe
saltarse la fase de renderizado (renderizar la respuesta) llamando
a FacesContext.response Complete. FacesContext contiene
toda la información asociada con una petición Faces particular.
Este método se puede invocar durante las fases aplicar valores de
respuesta, procesar validaciones o actualizar los valores del
modelo.
 Escenario 3: Una petición Faces genera una respuesta Faces:

Es el escenario más común en el ciclo de vida de una aplicación
JSF. Este escenario implica componentes JSF enviando una
petición a una aplicación JSF utilizando el FacesServlet. Como la
petición ha sido manejada por la implementación JSF, la
aplicación no necesita pasos adicionales para generar la
respuesta. Todos los oyentes, validadores y conversores serán
invocados automáticamente durante la fase apropiada del ciclo de
vida estándar.
28
URL.- Un localizador uniforme de recursos, más comúnmente denominado URL (sigla en inglés de uniformresourcelocator), es
una secuencia de caracteres, de acuerdo a un formato modélico y estándar, que se usa para nombrar recursos en Internet para su
localización o identificación, como por ejemplo documentos textuales, imágenes, vídeos, presentaciones, presentaciones digitales,
etc.
69
4.2.5. Ciclo de Vida Estándar de Procesamiento de

Peticiones
Fig. 13 Pasos del ciclo de vida petición-respuesta JSF
4.3. Sitio Web
Un Sitio Web puede ser el trabajo de una persona, una empresa u otra
organización y está típicamente dedicada a algún tema particular o propósito.
Cualquier Sitio Web puede contener hiperenlaces29 a cualquier otro sitio web,
de manera que la distinción entre sitios individuales, percibido por el usuario,
puede ser a veces borroso.
29
HIPERVÍNCULO.- (también llamado enlace, vínculo, o hiperenlace) es un elemento de un documento electrónico que hace
referencia a otro recurso, por ejemplo, otro documento o un punto específico del mismo o de otro documento.
70
No debemos confundir Sitio Web con Página Web, esta última es sólo un
archivo HTML, y forma parte de un Sitio Web. Al ingresar una dirección, como
por ejemplo www.wikimedia.org, siempre se está haciendo referencia a un
sitio web, que tiene una página HTML inicial, que es lo primero que se
visualiza. La búsqueda en Internet se realiza asociando el DNS 30 ingresado
con la dirección IP31 del servidor que contenga el Sitio Web en el cual está la
página HTML buscada.
Los Sitios Web están escritos en HTML, o dinámicamente convertidos a éste

y se acceden usando un software llamado navegador web, también conocido
como un cliente HTTP. Los Sitios Web pueden ser visualizados o accedidos
desde un abanico de dispositivos con disponibilidad de Internet como
computadoras personales, computadores portátiles, PDAs32 y teléfonos
móviles.
Un Sitio Web está alojado en una computadora conocida como Servidor Web,
también llamada servidor HTTP, y estos términos también pueden referirse al
software que se ejecuta en esta computadora y que recupera y entrega las
páginas de un Sitio Web en respuesta a peticiones del usuario. Apache es el
programa más comúnmente usado como Servidor Web y el Internet
33
Information Services (IIS ) de Microsoft también se usa comúnmente.
4.3.1. Sitio Web estático
Es aquel que tiene contenido que no se espera que cambie

frecuentemente y se mantiene manualmente por alguna persona o
personas que usan algún tipo de programa editor. Hay dos amplias
30
DNS.- DomainNameSystem (en castellano: sistema de nombres de dominio) es un sistema de nomenclatura jerárquica para
computadoras, servicios o cualquier recurso conectado a Internet o a una red privada.
31
DIRECCIÓN IP.- Es el número que identifica a cada dispositivo dentro de una red con protocolo IP.
32
PDA.- (del ingléspersonal digital assistant(asistente digital personal)), también denominado ordenador de bolsillo, es una
computadora de mano originalmente diseñado como agendaelectrónica (calendario, lista de contactos, bloc de notas y
recordatorios) con un sistema de reconocimiento de escritura.
33
IIS.-Internet InformationServices , IIS, es una serie de servicios para los ordenadores que funcionan con Windows.
71
categorías de programas editores usados para este propósito que

son editores de texto como Notepad34, donde el HTML se manipula
directamente en el programa editor o Editores WYSIWYG35 como
por ejemplo Microsoft FrontPage36 y Adobe Dreamweaver37, donde
el sitio se edita usando una interfaz GUI38 y el HTML subyacente se
genera automáticamente con el programa editor.
4.3.2. Sitio Web dinámico
Es aquel que puede tener cambios frecuentes en la información.

Cuando el Servidor Web recibe una petición para una determinada
página de un Sitio Web, la página se genera automáticamente por el
software como respuesta directa a la petición de la página; el Sitio
puede mostrar el estado actual de un diálogo entre usuarios,
monitorizar una situación cambiante, o proporcionar información
personalizada de alguna manera a los requisitos del usuario
individual.
4.3.3. Tipos de Sitios Web
Existen muchas variedades de Sitios Web, cada uno

especializándose en un tipo particular de contenido o uso, y pueden
ser arbitrariamente clasificados de diversas maneras. Entre ellas
incluimos:
34
NOTEPAD.- Bloc de notas (en inglés llamado Notepad) es un editor de texto simple incluido en los sistemas operativos de
Microsoft desde 1985. Su funcionalidad es muy sencilla.
35
WYSIWYG.-Es el acrónimo de WhatYouSeeIsWhatYouGet (en inglés, "lo que ves es lo que obtienes"
36
MICROSOFT FRONTPAGE.- Es una herramienta de construcción y edición de páginas web para el sistema operativo Windows.
37
ADOBE DREAMWEAVER.-Es una aplicación en forma de estudio (basada en la forma de estudio de Adobe Flash) enfocada a la
construcción y edición de sitios y aplicaciones Web basados en estándares.
38
GUI.-(GraphicalUser Interface). Sistema de interacción entre el ordenador y el usuario, caracterizado por la utilización de iconos
y elementos gráficos en su concepción.
72
 Sitio archivo: usado para preservar contenido electrónico valioso

amenazado con extinción. Dos ejemplos son: Internet Archive, el
cual desde 1996 ha preservado billones de antiguas (y nuevas)
páginas web; y Google Groups, que a principios de 2005 archivaba
más de 845.000.000 mensajes expuestos en los grupos de
noticias/discusión de Usenet39, tras su adquisición de DejaNews40.
 Sitio weblog(o blog): sitio usado para registrar lecturas online o
para exponer diarios en línea; puede incluir foros de discusión.
Ejemplos: Blogger, Xanga. [[LiveJournal], WordPress.
 Sitio de empresa: usado para promocionar una empresa o servicio.
 Sitio de comercio electrónico: para comprar bienes, como
Amazon.com.
 Sitio de comunidad virtual: un sitio donde las personas con
intereses similares se comunican con otros, normalmente por chat o
foros. Por ejemplo: Twitter, MySpace, Facebook,Hi5, Multiply, Orkut.
 Sitio de Base de datos: un sitio donde el uso principal es la
búsqueda y muestra de un contenido específico de la base de datos
como la Internet MovieDatabase.
 Sitio de desarrollo: cuyo propósito es proporcionar información y
recursos relacionados con el desarrollo de software, diseño web,
etc.
 Sitio directorio: un sitio que contiene contenidos variados que están
divididos en categorías y subcategorías, como el directorio de
Yahoo!, el directorio de Google y el Open Directory Project.
 Sitio de descargas: estrictamente usado para descargar contenido
electrónico, como software, demos de juegos o fondos de escritorio:
Download, Tucows, Softonic, Baulsoft.
 Sitio de juego: un sitio que es propiamente un juego o un "patio de
recreo" donde mucha gente viene a jugar, como MSNGames,
39
USENET.-Es el acrónimo de Users Network (Red de usuarios), consistente en un sistema global de discusión en Internet, que
evoluciona de las redes UUCP.
40
DEJANEWS.- Uno de los índices más completos acerca de los grupos de noticiasen el World Wide Web. Excelente recurso para
buscar información en los NEWS.
73
Pogo.com y los MMORPGsVidaJurasica, Planetarion y Kings of

Chaos.
 Sitio de información: comprendido por contenidos que pretenden
informar a los visitantes, pero no necesariamente de propósitos
comerciales; tales como: RateMyProfessors.com, Free Internet
Lexiconand Encyclopedia. La mayoría de los gobiernos e
instituciones educativas y sin ánimo de lucro tienen un sitio de
información.
 Sitio de noticias: Similar a un sitio de información, pero dedicada a
mostrar noticias y comentarios.
 Sitio pornográfico (porno): muestra imágenes y vídeos de contenido
sexual explícito.
 Sitio buscador: sitio que proporciona información general y está
pensado como entrada o búsqueda para otros sitios. Un ejemplo es
Google, y el tipo de buscador más conocido es Yahoo!.
 Sitio shock: incluye imágenes u otro material que tiene la intención
de ser ofensivo a la mayoría de visitantes. Ejemplos: rotten.com,
[ratemypoo.com].
 Sitio de subastas: subastas de artículos por internet, como eBay.
 Sitio personal: Mantenido por una persona o un pequeño grupo
(como por ejemplo familia) que contiene información o cualquier
contenido que la persona quiere incluir.
 Sitio portal: un sitio web que proporciona un punto de inicio, entrada
o portal a otros recursos en Internet o una intranet.
 Sitio Web 2.0: un sitio donde los usuarios son los responsables de
mantener la aplicación viva, usando tecnologías de última
generación: pikeo, flickr
 Creador de Sitios: es básicamente un sitio que te permite crear
otros sitios, utilizando herramientas de trabajo en línea.
 Sitio wiki: un sitio donde los usuarios editan colaborativamente (por
ejemplo: Wikipedia).
74
 Sitio político: un sitio web donde la gente puede manifestar su visión

política. Ejemplo: New Confederacy.
 Sitio de Rating: un sitio donde la gente puede alabar o
menospreciar lo que aparece.
 Sitios Educativos promueven cursos presenciales y a distancia,
información a profesores y estudiantes, permiten ver o descargar
contenidos de asignaturas o temas.
 Sitio Spam: Sitio Web sin contenidos de valor que ha sido creado
exclusivamente para obtener beneficios y fines publicitarios,
engañando a los motores de búsqueda.
4.4. Modelo Vista Controlador
4.4.1. Estructura MVC
Se puede definir que una aplicación informática se divide en dos

partes diferenciadas: la parte de la aplicación con la que interactúa
el usuario (interfaz), y que sirve para introducir datos, consultarlos,
modificarlos, etc. Y la parte que permanece oculta a la vista, y que
se encarga de mantener esos datos en un formato apropiado de
forma que sean accesibles, modificables, y perduren en el tiempo41.
El patrón MVC va más allá de esta división. Es un patrón de

arquitectura de software que separa los datos de una aplicación, la
interfaz de usuario, y la lógica de control en tres componentes
distintos. El patrón MVC se ve frecuentemente en aplicaciones
basadas en Entorno Web, donde la vista es la página HTML y el
código que provee de datos dinámicos a la página, el modelo es el
SGBD y la Lógica de negocio y el controlador es el responsable de
recibir los eventos de entrada desde la vista.
41
WIKIPEDIA, (2010) Modelo Vista Controlador [en línea] Disponible en: es.wikipedia.org/wiki/Modelo_Vista_Controlador
[Consulta: 12 de Enero de 2010].
75
Fig. 14 Modelo- Vista – Controlador
Nota: Las líneas negras indican una interacción directa, mientras

que las grises indican una interacción indirecta (básicamente
respuestas a las primeras).
 Modelo
Es la representación específica de la información con la que trabaja

el sistema. La lógica de datos asegura la integridad de estos y
permite derivar nuevos datos; por ejemplo, no permitiendo introducir
fechas incorrectas, determinando si el usuario ha superado su límite
de acceso, etc.
 Vista
Presenta el modelo en un formato adecuado para interactuar con él,

usualmente la interfaz de usuario.
 Controlador
Este responde a eventos, usualmente acciones del usuario e invoca

cambios en el modelo y probablemente en la vista.
76
Muchos sistemas informáticos utilizan un SGBD para gestionar los

datos. En MVC esta parte del sistema correspondería al modelo.
Aunque se pueden encontrar diferentes implementaciones de MVC,
el flujo que sigue el control generalmente es el siguiente:
 El usuario interactúa con la interfaz de usuario de alguna forma

(por ejemplo, el usuario pulsa un botón, enlace)
 El controlador recibe (por parte de los objetos de la interfaz-vista)
la notificación de la acción solicitada por el usuario. El controlador
gestiona el evento que llega, frecuentemente a través de un
gestor de eventos (handler) o callback42.
 El controlador accede al modelo, actualizándolo de forma
adecuada, a la acción solicitada por el usuario. Los controladores
complejos están estructurados usando un patrón de comando que
encapsula las acciones y simplifica su extensión.
 El controlador delega a los objetos de la vista la tarea de
desplegar la interfaz de usuario. La vista obtiene sus datos del
modelo para generar la interfaz apropiada para el usuario donde
se reflejan los cambios en el modelo. El modelo no debe tener
conocimiento directo sobre la vista.
 La interfaz de usuario espera nuevas interacciones del usuario,
comenzando el ciclo nuevamente.
4.4.2. Ventajas del Modelo Vista Controlador
 Hay una clara separación entre los componentes de un

programa; lo cual nos permite implementarlos por separado.
 La conexión entre el Modelo y sus Vistas es dinámica; se produce
en tiempo de ejecución, no en tiempo de compilación.
42
CALLBACK .-Es una devolución de llamada o retrollamada.
77
 Mayor cohesión43.
 Las vistas proveen mayor flexibilidad y agilidad.
 Mayor facilidad para el desarrollo de clientes ricos en múltiples
dispositivos y canales.
 Más claridad de diseño.
 Facilita el mantenimiento.
 Mayor escalabilidad.
4.5. Arquitectura Cliente – Servidor
Esta arquitectura reside en que un programa -el cliente- realiza

peticiones a otro programa -el servidor- que le da respuesta. Aunque
esta idea se puede aplicar a programas que se ejecutan sobre un solo
ordenador, es más ventajosa en un sistema operativo multiusuario
distribuido a través de una red de computadoras.
En esta arquitectura la capacidad de proceso está repartida entre los

clientes y los servidores, aunque son más importantes las ventajas de
tipo organizativo debido a la centralización de la gestión de la
información y la separación de responsabilidades, lo que facilita y
clarifica el diseño del sistema.
La separación entre cliente y servidor es de tipo lógico, donde el

servidor no se ejecuta necesariamente sobre una sola máquina ni es
necesariamente un sólo programa. Los tipos específicos de servidores
incluyen los Servidores Web, los Servidores de Archivo, los Servidores
del Correo, etc. Mientras que sus propósitos varían de unos servicios a
otros, la arquitectura básica seguirá siendo la misma.
Una disposición muy común son los sistemas multicapa en los que el
servidor se descompone en diferentes programas que pueden ser
43
COHESIÓN.- Hace referencia a la forma en que agrupamos unidades de software (módulos, subrutinas...) en una unidad mayor.
78
ejecutados por diferentes computadoras aumentando así el grado de

distribución del sistema. La arquitectura cliente-servidor sustituye a la
arquitectura monolítica en la que no hay distribución, tanto a nivel físico
como a nivel lógico.
4.5.1. Características del Cliente
En la arquitectura C/S el remitente de una solicitud es conocido

como cliente. Sus características son:
 Es quien inicia solicitudes o peticiones, tienen por tanto un papel

activo en la comunicación (dispositivo maestro o amo).
 Espera y recibe las respuestas del servidor.
 Por lo general, puede conectarse a varios servidores a la vez.
 Normalmente interactúa directamente con los usuarios finales
mediante una interfaz gráfica de usuario.
4.5.2. Características del Servidor
En los sistemas C/S el receptor de la solicitud enviada por cliente se

conoce como servidor. Sus características son:
 Al iniciarse se espera que lleguen las solicitudes de los clientes,
desempeñan entonces un papel pasivo en la comunicación
(dispositivo esclavo).
 Tras la recepción de una solicitud, la procesan y luego envían la
respuesta al cliente.
 Aceptan conexiones desde un gran número de clientes (en ciertos
casos el número máximo de peticiones puede estar limitado).
 No es frecuente que interactúen directamente con los usuarios
finales.
79
4.5.3. Ventajas
 Centralización del control: los accesos, recursos y la integridad de

los datos son controlados por el servidor de forma que un programa
cliente defectuoso o no autorizado no pueda dañar el sistema. Esta
centralización también facilita la tarea de poner al día datos u otros
recursos (mejor que en las redes P2P44).
 Escalabilidad: se puede aumentar la capacidad de clientes y
servidores por separado. Cualquier elemento puede ser aumentado
(o mejorado) en cualquier momento, o se pueden añadir nuevos
nodos a la red (clientes y/o servidores).
 Fácil mantenimiento: al estar distribuidas las funciones y
responsabilidades entre varios ordenadores independientes, es
posible reemplazar, reparar, actualizar, o trasladar un servidor,
mientras que sus clientes no se verán afectados por ese cambio.
Esta independencia de los cambios también se conoce como
encapsulación.
 Existen tecnologías desarrolladas, diseñadas para el paradigma de
C/S que aseguran la seguridad en las transacciones, la amigabilidad
de la interfaz, y la facilidad de empleo.
4.5.4. Desventajas
 La congestión del tráfico. Pues cuando una gran cantidad de

clientes envían peticiones simultaneas al mismo servidor, puede ser
que cause muchos problemas para éste. Al contrario, en las redes
P2P como cada nodo en la red hace también de servidor, cuantos
más nodos hay, mejor es el ancho de banda que se tiene.
44
P2P.-Una red Peer-to-Peer o red de pares o red entre iguales o red entre pares o red punto a punto (P2P, por sus siglas en
inglés) es una red de computadoras en la que todos o algunos aspectos funcionan sin clientes ni servidores fijos, sino una serie de
nodos que se comportan como iguales entre sí. Es decir, actúan simultáneamente como clientes y servidores respecto a los demás
nodos de la red.
80
 El paradigma de C/S clásico no tiene la robustez de una red P2P.

Cuando un servidor está caído, las peticiones de los clientes no
pueden ser satisfechas. En la mayor parte de redes P2P, los
recursos están distribuidos en varios nodos de la red. Aunque
algunos salgan o abandonen la descarga; otros pueden todavía
acabar de descargar consiguiendo datos del resto de los nodos en
la red.
 El software y el hardware de un servidor son muy determinantes. Un
hardware regular de un ordenador personal puede no poder servir a
cierto número de clientes. Normalmente se necesita software y
hardware específico, sobre todo en el lado del servidor, para
satisfacer el trabajo.
 El cliente no dispone de los recursos que puedan existir en el
servidor. Por ejemplo, si la aplicación es una Web, no podemos
escribir en el disco duro del cliente o imprimir directamente sobre las
impresoras sin sacar antes la ventana previa de impresión de los
navegadores.
81
E. RESULTADOS
E.1. DESARROLLO DE LA PROPUESTA ALTERNATIVA
Ante lo más relevante que evidenciamos en el proceso de Administración de

Campeonatos en FEDELIBAL tenemos:
FORTALEZAS DEBILIDADES
De acuerdo a nuestro análisis de las Las debilidades que existen en cuanto al
fortalezas, encontramos las siguientes: Proceso de Administración y Control de
Campeonatos son:
Con la implementación del
Sistema para la Gestión y Control Es difícil identificar que una misma
de Campeonatos Deportivos se persona participe en diversos equipos
optimizarán recursos como: del mismo campeonato
ahorro de tiempo en la El revisar actas de juego e ir
administración de los archivando por fechas complica el
campeonatos, equipos y mantenimiento de la información en
jugadores. forma ordenada.
Se podrá verificar con rapidez la Generar las tablas de máximos
información de los campeonatos, anotadores y de los equipos mejor
equipos y jugadores, al igual que puntuados, requiere la inversión de
la creación de informes como la mucho tiempo y un manejo ordenado
tabla de posiciones, los equipos de la información.
mejor puntuados, los máximos El llevar la administración de
anotadores del campeonato y los campeonatos en forma manual, a la
equipos clasificados. larga trae una enorme inversión de
Permitirá que toda la ciudadanía tiempo para tratar de llevar
conozca cómo se encuentran los eficientemente el desarrollo de los
equipos (como va su desempeño mismos.
en el campeonato) Existe un cierto grado de
82
Se automatizarán procesos como: desinformación por parte de la

inscripción de equipos y ciudadanía, al no contar con un
jugadores, sorteo y generación de medio que proporcione datos exactos
los enfrentamientos, realización de los campeonatos organizados por
del calendario de partidos a FEDELIBAL.
disputar en la jornada, la creación Los equipos que desean inscribirse,
de las actas de los partidos, deben necesariamente presentarse a
informes de jugadores y equipos las instalaciones de FEDELIBAL para
sancionados, etc., evitando poder hacerlo, convirtiéndose esto,
contratiempos que anteriormente en un impedimento para los usuarios.
se daban al llevar a cabo estos Pérdida de tiempo durante todo el
procesos de forma manual. proceso de Gestión de Campeonatos,
Evitará que jugadores actúen en es decir al realizar las distribuciones,
diferentes equipos en el mismo generar enfrentamientos, generar las
campeonato. tablas respectivas, y en la entrega de
Se economizará la documentación necesaria.
fundamentalmente en el tiempo
con resultados veraces, facilitando
el trabajo para los empleados de
la Federación Deportiva de Ligas
Barriales de Loja (FEDELIBAL).
El sistema permitirá manejar las
disciplinas tanto de fútbol como de
básquet.
En definitiva, la presente
Aplicación Web, constituirá un
apoyo al mejoramiento en el
proceso de gestionar los
campeonatos deportivos
organizados.
Tabla1 Evaluación del Objeto de Investigación
83
Por lo tanto el principal beneficio de la Implantación de un Sistema Web para la

Gestión y Control de Campeonatos Deportivos de las disciplinas de futbol y
básquet, organizados por FEDELIBAL, utilizando un modelo matemático para
la generación del calendario de enfrentamientos, es la optimización de tiempo,
recursos, y el poderle otorgar a la ciudadanía una información correcta del
desarrollo de los campeonatos antes, durante y después, de una manera
rápida, segura y amigable.
Con la finalidad de gestionar y controlar de una manera rápida, efectiva y

confiable los campeonatos deportivos de las disciplinas de fútbol y básquet de
la Federación Deportiva de Ligas Barriales de Loja (FEDELIBAL), hemos
desarrollado un Sistema Web de Gestión Deportiva, convencidos de que a
través de éste, lograremos una optimización de recursos, un manejo adecuado
de la información, una distribución de los encuentros en forma automática, y
una facilidad en la emisión de los informes, de tal manera que se pueda
solucionar la saturación de los datos que fluyen en la institución. El desarrollo
del presente Sistema fue estipulado en el cumplimiento de los siguientes
objetivos:
 Realizar un análisis minucioso de las actividades efectuadas en la gestión y

control de campeonatos, a través de la recolección de información dentro de
Fedelibal.- Proceso logrado gracias a las entrevistas con el personal
administrativo que labora en FEDELIBAL, principales conocedores del proceso
de generación y administración de campeonatos deportivos. Las mismas nos
permitieron recopilar la información más relevante, con lo que logramos realizar
un análisis de la funcionalidad de los procesos.
 Diseñar un módulo que permita generar automáticamente los horarios de

juego.- Proceso logrado a través de una representación matemática del fixture,
cubriendo de esta manera con los requerimientos solicitados por FEDELIBAL.
Dentro de la fase de eliminación del campeonato, en nuestro modelo
84
matemático se aplicó uno de los esquemas más populares de turno rotatorio, el

algoritmo Round Robin, mientras en la segunda ronda se aplicó un
campeonato de simple eliminación, en donde la mitad de los equipos se
eliminan en cada fecha.
 Diseñar el sistema web para administrar toda la información que se genera

dentro de los campeonatos deportivos, en las disciplinas de fútbol y básquet.-
Proceso logrado a través de la extracción de los principales requerimientos que
debía cumplir nuestra aplicación, al igual que la identificación de los casos de
uso y el prototipado de pantallas, para permitir una creación, búsqueda, edición
y eliminación de los datos que intervienen en la generación de un campeonato.
 Desarrollar el sistema web, cumpliendo los requerimientos y utilizando la

siguiente tecnología: Java, NetBeans 6.1, JavaServerFaces v1.1, y Apache –
Tomcat-6.0.14.- El Sistema cuenta con una interfaz grafica interactiva,
amigable, en entorno Web, y ha sido construida en lenguaje de programación
Java, con el entorno de programación JavaServerFaces v1.1, funciona bajo un
Servidor Web Apache – Tomcat-6.0.14, utiliza como navegador a Mozilla
(recomendado), y su información ha sido administrada en una Base de Datos
MySql v5.0.19.
 Realizar un plan de validación para el sistema.- Con la finalidad de tener

información relacionada con el funcionamiento y validación del Sistema Web,
se realizaron las pruebas en tres tipos: prueba de funcionalidad, a través de la
cual se verificó el cumplimiento de los requerimientos del sistema; la prueba de
aceptación para medir el nivel de satisfacción por parte de usuarios y
administradores; y la prueba de usabilidad, en la que se evaluó la utilidad y
robustez del sistema mediante encuestas.
85
E.2. VALORACIÓN TÉCNICO-ECONÓMICA-AMBIENTAL
RECURSOS HUMANOS
Se necesitó la participación de los siguientes recursos humanos:
 Los egresados de la Carrera de Ingeniería en Sistemas del Área de Energía,

Industrias y Recursos Naturales no Renovables de la Universidad Nacional
de Loja: Pablo Castillo y Lucía Figueroa.
 El personal de FEDELIBAL
 Árbitros
 Dirigentes barriales
 Integrantes de los equipos (Jugadores)
 El coordinador del proyecto de tesis.
RECURSOS HUMANOS
Desarrolladores Valor de hora Nº de Horas Valor Total
Pablo Castillo $ 0.00 600 $ 0,00
Lucía Figueroa $ 0.00 600 $ 0,00
Coordinador de Valor de hora Nº de Horas Valor Total
Anteproyecto
Ing. Wilman Chamba 0.00 100 $ 0,00
Asesorías Valor de hora Nº de Horas Valor Total
Experto en el Tema 25.00 20 500.00
SUBTOTAL $ 500.00
Tabla 2. Recursos Humanos
86
RECURSOS MATERIALES
RECURSOS MATERIALES
Material Cantidad Unidad Valor Total
Borradores 2 $ 0,20 $ 0,40
Carpetas de perfil 2 $ 0,45 $ 0,90
CD 5 $ 1,00 $ 5,00
Copias 1000 $ 0,02 $ 20,00
Cuaderno 1 $ 1,50 $ 1,50
Empastados 4 $ 30,00 $ 120,00
Grapadora 1 $ 1,00 $ 1,00
Grapas 1 $ 2,00 $ 2,00
Portaminas 2 $ 0,50 $1,00
Resma de Papel Inen A4 3 $ 4,00 $ 12,00
Tinta de color 2 $ 24,50 $ 49,00
Tinta negra 2 $ 22,50 $ 45,00
SUBTOTAL $ 257,80
Tabla 3. Recursos Materiales
SERVICIOS BÁSICOS
SERVICIOS BÁSICOS
Luz $ 80,00
Teléfono $ 50,00
Transporte $ 150,00
SUBTOTAL $ 280,00
Tabla 4 .Servicios Básicos
87
RECURSOS TÉCNICOS
RECURSOS TÉCNICOS Y TECNOLÓGICOS

Hardware
Equipo Cantidad Uso por horas Valor Total
Computadora de escritorio 1 600 $ 800,00
(P4 3 GHz, 2 Gb RAM,
Disco 250 Gb).
Computadora Portátil (AMD 2 500 $ 1000
Turion 64*21.6 GHz, 1Gb
RAM, Disco 120 Gb).
Flash Memory 2 10 $ 20,00
Impresora 1 10 $ 50,00
Software
SistemaOperativo: Windows XP Home Licencia comunitaria
Maquina Virtual Java: JDK 1.5.0_06 de Sun Microsystems Licencia comunitaria
NetBeans 6.1 Licencia comunitaria
Implementación de referencia de JavaServer Faces v1.1 Licencia comunitaria

MySQL Versión 5.0 o más Licencia comunitaria
Poseidon versión 4.1 o más Licencia comunitaria
Apache-Tomcat-6.0.14 Licencia comunitaria
Comunicaciones
Internet $ 100,00
Libros $ 50.00
SUBTOTAL $ 2020,00
Tabla 5 Recursos Técnicos
88
RECURSOS ECONÓMICOS
RECURSOS ECONÓMICOS
Recursos Humanos $500.00
Recursos Materiales $ 257.80
Servicios Básicos $ 280.00
Recursos Técnicos y Tecnológicos $ 2020.00
SUBTOTAL $ 3,057.80
Imprevistos $ 305.78
TOTAL $ 3363.58
Tabla 6 Recursos Económicos
89
F. DISCUSIÓN
F.1. MODELADO DEL SISTEMA
F.1.1. REQUERIMIENTOS FUNCIONALES
Estos requerimientos deberán cumplirse a cabalidad, e indican lo que el

sistema debe realizar, es decir, dictan la funcionalidad del mismo, y tienen
como fuente de información a los empleados de FEDELIBAL. El sistema
permitirá:
CÓDIGO DESCRIPCIÓN ESTADO

RF001 Al Usuario Directivo, administrar usuarios. Evidente
RF002 Reconocer rol de usuario para ingresar al sistema. No
evidente
RF00 Al Usuario Secretario, identificar la disciplina del Evidente
3 campeonato a desarrollarse.
RF00 Al Usuario Secretario, establecer la fecha de inicio del Evidente
4 campeonato.
RF00 Al Usuario Secretario, administrar jugador. Evidente
5
RF00 Al Usuario Secretario, agregar los jugadores al equipo. Evidente
6
RF00 Controlar que un jugador no participe en diferentes No
7 equipos del mismo campeonato. evidente
RF00 Al Usuario Secretario, administrar equipo. Evidente
8
RF00 Al Usuario Secretario, agregar los equipos al Evidente
9 campeonato.
90
RF01 Al Usuario Secretario, administrar árbitro. Evidente

0
RF01 Al Usuario Secretario, administrar escenario. Evidente
1
RF01 Al Usuario Secretario, administrar cancha. Evidente
2
RF01 Al Usuario Secretario, administrar campeonato Evidente
3
RF01 Al Usuario Secretario, asignar el escenario del Evidente
4 campeonato.
RF01 Al Usuario Secretario, establecer el sistema de Evidente
5 puntuación de los compromisos.
RF01 Al Usuario Secretario, generar el calendario del No
6 campeonato. evidente
RF01 Al Usuario Secretario, establecer la fecha en la que se Evidente
7 jugará cada jornada
RF01 Al Usuario Supervisor, asignar los resultados de los Evidente
8 compromisos
RF01 Al Usuario Supervisor, asignar los árbitros que dirigieron Evidente
9 el compromiso.
RF02 Al Usuario Secretario, revisar e imprimir las actas de Evidente
0 juegos
RF02 Al Usuario Secretario, revisar e imprimir el resumen de la Evidente
1 jornada
RF02 Al Usuario Secretario, revisar e imprimir los compromisos Evidente
2 de la próxima jornada
RF02 Al Usuario Secretario, generar e imprimir la tabla de Evidente
3 posiciones del campeonato
4 mayores anotadores del campeonato
91
5 jugadores sancionados de los campeonatos de fútbol

RF026 Al usuario externo, consultar los equipos participantes de Evidente
los campeonatos.
RF027 Al usuario externo, consultar los resultados de los Evidente
compromisos
RF028 Al usuario externo, consultar la próxima fecha a Evidente
disputarse
RF029 Al usuario externo, consultar la tabla de posiciones Evidente
RF030 Al usuario externo, consultar la tabla de los mayores Evidente
anotadores.
RF031 Al usuario externo, consultar la información de Evidente
campeonatos anteriores
Tabla 7. Requerimientos Funcionales
F.1.2. REQUERIMIENTOS NO FUNCIONALES
Los requerimientos no funcionales describen las características

que se necesita que el sistema cumpla:
CÓDIGO DESCRIPCIÓN
RNF001 El sistema será Multiplataforma.
RNF002 El sistema será desarrollado bajo la plataforma JAVA
RNF003 El sistema será desarrollado en el IDE NetBeans
RNF004 El sistema funcionará bajo un Servidor Web ApacheTomcat
RNF005 El sistema utilizará la base de datos MySQL
RNF006 El sistema tendrá una interfaz gráfica sencilla y amigable.
RNF007 La interfaz debe complementar un sistema de ayuda.
RNF008 El tiempo de respuesta debe ser optimo (0.03-0.05 segundos).
Tabla 8. Requerimientos No Funcionales

92
F.1.3. GLOSARIO DE TÉRMINOS
 DISCIPLINA: Es toda aquella actividad y costumbres, a menudo

asociadas a la competitividad, por lo general debe estar
institucionalizado (federaciones, clubes), requiere competición con uno
mismo o con los demás y tener un conjunto de reglas perfectamente
definidas.
 CAMPEONATO: Es una prueba deportiva en la que además, del
premio correspondiente, se disputa un título de supremacía individual
reconocido después oficialmente y que dura hasta que el vencedor o
campeón ha sido desposeído del mismo en un nuevo campeonato del
mismo tipo y extensión.
 ESCENARIO: Es una infraestructura que sirve para albergar deportes u
otras actividades. Es usado para varios tipos de deportes al aire libre
que son populares a nivel mundial como el fútbol, el rugby, el béisbol,
etc. Los estadios pueden influir de manera muy importante en la
economía de un país albergando toda clase de eventos deportivos
dependiendo de la capacidad que presentan.
 SISTEMA DE PUNTUACION: Es la asignación de puntos a los
resultados que presenta un deporte. En el fútbol el sistema de
puntuación es el siguiente: Partido ganado (3 puntos), Partido perdido
(0 puntos), Partido empatado (1 punto); mientras que en el básquet:
Partido ganado (2 puntos), Partido perdido (1 punto), y no existen
empates.
 COMPROMISO DEPORTIVO: Es la competición entre dos deportistas o
dos equipos de deportistas.
 CALENDARIO DE JUEGOS: Es la distribución de los enfrentamientos
deportivos, considerando fecha, hora y escenario.
 JORNADA O FECHA: Es el conjunto de enfrentamientos que se
suscitan en una fecha determinada
 RESULTADOS DE LOS COMPROMISOS: Es la puntuación que se
establece al culminar un enfrentamiento.
93
 ACTA DE JUEGO: Es una hoja de control, en la que se registran

detalladamente todos los eventos que se generan durante un
enfrentamiento.
 JUGADORES SANCIONADOS: Son aquellos deportistas que por
romper las reglas del juego, son amonestados o sancionados durante
un enfrentamiento. En el fútbol, la sanción puede impedir que un
jugador participe de cierto número de enfrentamientos próximos.
 PRÓXIMA FECHA: Son los compromisos establecidos, para
desarrollarse en una fecha mayor a la última suscitada.
 TABLA DE POSICIONES: Es un formato a través del cual se lleva la
estadística de un equipo durante el desarrollo del campeonato.
 TABLA DE MAYORES ANOTADORES: Es un formato en el que se
lleva la estadística de las anotaciones convertidas por un jugador,
durante los enfrentamientos de un campeonato.
94
class Diagrama de Dominio

F.2. MODELO DEL DOMINIO
Persona Direccion
- apellido: String - calle: String

- cedula: String - celular: String
- fechaNacimiento: Date - telefono: String
- idPersona: String
- nacionalidad: String
- nombre: String
- sexo: Boolean
1
Jugador Superv isor
Secretario Arbitro Directiv o
1 - categoria: String - idSupervisor: int
- foto: byte - idSecretario: int - idArbitro: int - idDirectivo: int 1
- idJugador: int
1 1
AñoDeportiv o
1 - idAnioDeportivo: Int
- nombre: Date
puede moderar Disciplina
1..*
- idDisciplina: int
SistemaPuntuacion
- nombre: String
DignidadModeracion - idSistemaPuntuacion: int
1..* 1 1 - nombre: String
- dignidad: String 1 1
- idFuncionModeración: int - puntosDerrotaSinJugar: int
- puntosPorEmpate: int
- puntosPorPerdida: int
1 - puntosPorVictoria: int
se juega - puntosVictoriaSinJugar: int
1..* 1..*
Campeonato
1..* Equipo
- duracionCompromiso: int
1 - fechaFin: Date - barrio: String
- fechaInicio: Date 1
- colorUniforme: String
FechaDeJuego - genero: String - escudo: byte
- fecha: Date - idCampeonato: int - genero: Boolean
Suspencion 1 1 - nombre: String
- idFechaDeJuego: int - idEquipo: int
1..* 1 - numeroClasificadosPorGrupo: int - nombre: String
- idSuspencion: int
1 - numeroEquiposPorGrupo: int - sobrenombre: String
- tiempoSuspencion: String se usan 1
0..* - numeroGrupos: int
- tipo: String 1
1..* - numeroVueltas: int 1
TablaPosiciones 1 1
Jornadas 1..*
Representante
- idTablaPosiciones: int
- idJornada: int Resultado - idRepresentante: int
- nombre: String
- idResultado: int
1 1..*
ModeradorEncuentro 1 1
1
- idModerador: int 1 1 1 1..*
1..*
1 1..*
InscripcionEquipo
1..* Encuentro 1..*
Escenario - idInscripcionEquipo: int
- idEncuentro: int
- foto: byte 1
- idEscenario: int 1
1..*
- nombre: String 1
- ubicacion: String 1 1 1..*
1..*
InscripcionJugador
0..2 - idInscripcionJugador: int

1..*
NominaEncuentro
1..*
- idNominaEncuentro: int
1..* - titularidad: Boolean 1
Amonestacion 1
1..* 1 1..* 1..*
- idAmonestacion: int
1 - Anotacion
tipo: String
- idAnotacion: int
- puntos: int
Fig. 15 Modelo del Dominio
95
F.3. PROTOTIPADO DE PANTALLAS
P000: Ingresar al Sistema
Fig. 16 Ingresar al Sistema

P001: Principal
Fig. 17 Principal
96
P002 Buscar Usuario
Fig. 18 Buscar Usuario
P002.1 Nuevo Usuario
Fig. 19 Nuevo Usuario
97
P002.2 Editar usuario
Fig. 20 Editar Usuario
P003 Buscar Jugador
Fig. 21 Buscar Jugador

98
P003.1: Nuevo Jugador
Fig. 22 Nuevo Jugador
P003.2: Editar Jugador
Fig. 23 Editar Jugador 99

P004: Buscar Equipo
Fig. 24 Buscar Equipo

P004.1: Nuevo Equipo
Fig. 25 Nuevo Equipo
100
P004.2: Editar Equipo
Fig. 26 Editar Equipo

P005: Buscar Árbitro
Fig. 27 Buscar Árbitro
101
P005.1: Nuevo Arbitro
Fig. 28 Nuevo Árbitro

P005.2: Editar Árbitro
Fig. 29 Editar Árbitro
102
P006: Buscar Escenario
Fig. 30 Buscar Escenario
P006.1: Nuevo Escenario
Fig. 31 Nuevo Escenario
103
P006.2: Editar Escenario
Fig. 32 Editar Escenario

P007: Buscar Cancha
Fig. 33 Buscar Cancha
104
P007.1: Nueva Cancha
Fig. 34 Nueva Cancha

P007.2: Editar Cancha
Fig. 35 Editar Cancha
105
P008: Buscar Campeonato
Fig. 36 Buscar Campeonato
P008.1: Nuevo Campeonato
106
Fig. 37 Nuevo Campeonato
P008.2: Editar Campeonato
Fig. 38 Editar Campeonato
P009: Inscripción de Equipos
Fig. 39 Inscripción de Equipos

107
P09.1: Listado de Equipos del Campeonato
Fig. 40 Listado de Equipos del Campeonato
P0010: Listado de Campeonatos por Iniciarse
Fig. 41 Listado de Campeonatos por Iniciarse

108
P010.1: Generación de Campeonato
Fig. 42 Generación de Campeonato
P010.2: Calendario del Campeonato
Fig. 43 Calendario del Campeonato

109
P011: Lista de Campeonatos Activos
Fig. 44 Lista de Campeonatos Activos
P011.1: Listado de Encuentro de la Fecha
Fig. 45 Listado de Encuentro de la Fecha
110
P012: Clasificación
Fig. 46 Clasificación
P013: Jugadores Sancionados
Fig. 47 Jugadores Sancionados
111
P014: Cambiar Calendario
Fig. 48Cambiar Calendario

P014.1: Listado de Jornadas
Fig. 49 Listado de Jornadas
P014.2: Cambiar Cancha
112
Fig. 50 Cambiar Cancha
F.4. MODELAMIENTO DE CASOS DE USO
F.4.1. IDENTIFICACIÓN DE CASOS DE USO
ACTORES META CASO USO COD

Usuario Directivo,
Login Usuario Login Usuario
Secretario y CU001
Supervisor Ingresar al Sistema Ingresar al Sistema CU002
Crear Cuenta Usuario CU003
Administrar Cuenta
Usuario Directivo Eliminar Cuenta Usuario CU004
Usuario
Modificar Cuenta Usuario CU005
Crear Jugador CU006
Administrar Jugador Eliminar Jugador CU007
Modificar Jugador CU008
Crear Equipo CU009
Administrar Equipo Eliminar Equipo CU010
Modificar Equipo CU011
Crear Arbitro CU012
Usuario
Administrar Arbitro Eliminar Arbitro CU013
Secretario
Modificar Arbitro CU014
Crear Escenario CU015
Administrar Escenario Eliminar Escenario CU016
Modificar Escenario CU017
Crear Cancha CU018
Administrar Cancha Eliminar Cancha CU019
Modificar Cancha CU020
Crear Campeonato CU021
Administrar
Eliminar Campeonato CU022
Campeonato
Modificar Campeonato CU023
Inscribir al equipo en Inscribir equipo al CU024
113
un Campeonato Campeonato
Seleccionar las
canchas en la que se Asignar cancha al
CU025
desarrollara el Campeonato
Campeonato
Generar
automáticamente el
Generar el calendario del
calendario de CU026
Campeonato
compromisos del
Campeonato.
Cambiar cancha a uno
Cambiar cancha a un
o más compromisos de CU027
compromiso
una jornada de juego
Registrar los resultados
Usuario Supervisor de los compromisos del Ingresar Resultados CU028
Campeonato.
Tabla 9 Identificación de Casos de Uso
114
uc Casos de uso principales Pablo Castillo y Lucía Figueroa
Límite del sistema
Ingresar al
Sistema
«precedes»
Usuario Directiv o Login Usuario
Modificar Cuenta
Usuario «precedes»
«precedes»
Crear Jugador
Eliminar Cuenta
Usuario
Modificar
Jugador
Crear Cuenta «invokes»

Usuario Eliminar
«invokes» Jugador
Usuario Secretario «invokes»
Buscar Jugador Crear Equipo
«invokes» Modificar
Equipo
Buscar Equipo «invokes»
«invokes» Eliminar
Equipo
Buscar Escenario
Crear
«invokes»
Escenario
«invokes»
Modificar
Buscar Cancha «invokes» Escenario
Eliminar
Escenario
Buscar Arbitro «invokes»
«invokes»
Crear Cancha
«invokes»
Buscar Campeonato
Modificar
Cancha
«invokes»
«invokes» Eliminar
Inscribir Equipo al Cancha
Campeonato «invokes»
Crear Arbitro
Asignar Cancha al
Campeonato «invokes»
Modificar
Arbitro
«invokes»
Generar el «invokes»
Eliminar
Calendario del Arbitro
Campeonato
Crear
Cambiar Cancha al Campeonato
Compromiso
Modificar 115
Campeonato
Usuario Superv isor
Ingresar
Resultados Eliminar
Campeonato
Fig. 51 Modelamiento de Casos de Uso

F.4.2. DESCRIPCION DE CASOS DE USO Y DIAGRAMAS DE

SECUENCIA
F.4.2.1. CASO DE USO: LOGIN USUARIO
NOMBRE LOGIN USUARIO CÓDIGO C.U. CU001

C.U.
Propósito: Permitir el uso total y/o parcial del Sistema únicamente al usuario
correcto
Actor(es): Usuario Directivo, Usuario Secretario, Usuario Supervisor
Descripción: El usuario ingresa adecuadamente su nombre de usuario y
password
Referencia al Requerimiento: RF002
Tipo de Caso de Uso: Sistema – Primario
Precondiciones:
 Que el usuario esté en el sistema.
Post condiciones:
 El usuario tiene un acceso total y/o parcial para manipular el
sistema.
CURSO NORMAL DE EVENTOS
1. El usuario ingresa su nombre de usuario y password en la pantalla [P000:

Ingresar al Sistema].
2. El usuario presiona el botón[INGRESAR].
3. El sistema verifica que la información ingresada sea correcta.
4. El caso de uso finaliza.
116
CURSO ALTERNO DE EVENTOS

CAMPO VACÍO.
A.3 El sistema presenta un mensaje de error indicando que no se ha ingresado
algún valor.
A.4 El caso de uso continúa en el paso 1 del curso normal de eventos.
DATOS INCORRECTOS
A.3 El sistema presenta un mensaje de error indicando que los datos
ingresados son incorrectos
Tabla 10 Descripción del Caso de Uso: Login Usuario
VALIDACIÓN DEL CASO DE USO
CASO DE USO TEST: TAMAÑO TEST: EBP VALIDACIÓN

Login Usuario SI SI SI
Tabla 11 Validación del Caso de Uso: Login Usuario
117
Lucía Figueroa y Pablo Castillo
sd 20: Login Usuario
CuentaUsuarioDao
CASO DE USO: LOGIN USUARIO
1. El usuario ingresa su nombre de Usuario Supervisor Ingresar al Sistema CuentaUsuario

usuario y password en la pantalla
[P000: Ingresar al Sistema].
2. El usuario presiona el botón ingresa datos()
[INGRESAR].
3. El sistema verifica que la información elige btnIngresar()
ingresada sea correcta.
verificaSiExiste(nombre, clave) :
boolean
A. CAMPO VACÍO.
A.3 El sistema presenta un mensaje de
obtenerListado() :List
error indicando que no se ha ingresado
valor alguno.
A.4 El caso de uso continúa en el paso 4
del curso normal de eventos.
B. DATOS INCORRECTOS
error indicando que los datos ingresados
son incorrectos (from Actores)
Fig. 52 Login Usuario 118

F.4.2.2. CASO DE USO: INGRESAR AL SISTEMA
NOMBRE INGRESAR AL SISTEMA CÓDIGO C.U. CU002

C.U.
Propósito: Operar el sistema

Actor(es): Usuario Directivo, Usuario Secretario, Usuario Supervisor
Descripción: El usuario ingresa al Sistema de Gestión de Campeonatos
Precondiciones:
 Que el usuario haya ejecutado la aplicación
Post condiciones:
 El usuario ingresa al sistema.
1. Se ejecuta el Caso de Uso Login Usuario
2. El sistema presenta la pantalla [P001: Principal].
Tabla 12 Descripción del Caso de Uso: Ingresar al Sistema

Ingresar al sistema SI SI SI
Tabla 13 Validación del Caso de Uso: Ingresar al Sistema
119
sd 19: Ingresar al Sistema
CASO DE USO: INGRESAR AL SISTEMA
1. Se ejecuta el Caso de Uso Login Usuario Ingresar al Sistema Principal

Usuario
2. El sistema presenta la pantalla [P001:
Principal]. presenta()
se ejecuta CU Login Usuario new()
Fig. 53 Ingresar al Sistema
120
F.4.2.3. CASO DE USO: CREAR CUENTA USUARIO
NOMBRE CREAR CUENTA USUARIO CÓDIGO C.U. CU003

C.U.
Propósito: Permitir crear cuentas de usuarios para que los mismos interactúen
con el sistema
Actor(es): Usuario Directivo
Descripción: El usuario registra adecuadamente los parámetros necesarios
para crear una cuenta de usuario.
Precondiciones:
 Que el usuario haya ingresado al sistema correctamente.
 Que el usuario se encuentre en la pantalla [P002: Buscar Usuario].
Post condiciones:
 La cuenta de usuario se ha creado.

1. El usuario elige [USUARIO] de la pantalla [P001: Principal].
2. El sistema presenta la pantalla [P002: Buscar Usuario].
3. El usuario elige [NUEVO USUARIO] de la pantalla [P002: Buscar Usuario].
4. El sistema presenta la pantalla [P002.1: Nuevo Usuario].
5. El usuario ingresa los datos requeridos y asigna el rol correspondiente.
6. El usuario presiona el botón [GUARDAR].
7. El sistema verifica que la información ingresada sea correcta.
8. El sistema guarda la información en la Base de Datos
CAMPO VACÍO.
algún valor.
121

CAMPO INVÁLIDO
B.7 El sistema presenta un mensaje de error indicando que se han ingresado
letras y/o números en donde no corresponde.
B.8 El caso de uso continúa en el paso 5 del curso normal de eventos.
IDENTIDAD EXISTENTE
C.7 El sistema presenta un mensaje de error indicando que la identidad del
nuevo usuario ya existe.
C.8 El caso de uso continúa en el paso 5 del curso normal de eventos.
Tabla 14 Descripción del Caso de Uso: Crear Cuenta Usuario

Crear Cuenta Usuario SI SI SI
Tabla 15 Validación del Caso de Uso: Crear Cuenta Usuario
122
sd 12: Crear Cuenta de Usuario
UsuarioDao
CASO DE USO: CREAR CUENTA
USUARIO Usuario Directivo Principal Buscar Usuario Nuevo Usuario Campos Vacios o Usuario ya Existe Usuario
Incorrectos
1. El usuario elige [USUARIO] de la elige Usuario()
pantalla [P001: Principal].
2. El sistema presenta la pantalla presenta()
[P002: Buscar Usuario].
3. El usuario elige [NUEVO
elige btnNuevo()
USUARIO] de la pantalla [P002:
Buscar Usuario]. presenta()
4. El sistema presenta la pantalla
[P002.1: Nuevo Usuario]. ingresa datos()
5. El usuario ingresa los datos
requeridos y asigna el rol
correspondiente. elige btnGuardar()
6. El usuario presiona el botón
verifica campos()
[GUARDAR].
7. El sistema verifica que la
información ingresada sea
correcta. ExisteUsuario(string login) :boolean
8. El sistema guarda la informacion
en la Base de Datos
9. El caso de uso finaliza. guardar()
CURSO ALTERNO DE EVENTOS presenta()

presenta()
A. CAMPO VACÍO.
A.7 El sistema presenta un mensaje
de error indicando que no se ha
ingresado valor alguno.
A.8 El caso de uso continúa en el
paso 4 del curso normal de eventos.
B. CAMPO INVÁLIDO (from Actores)
B.7 El sistema presenta un mensaje de
error indicando que se han ingresado
letras y/o números en donde no
corresponde. 123
B.8 El caso de uso continúa en el paso
4 del curso normal de eventos.
C. IDENTIDAD EXISTENTE
C.7 El sistema presenta un mensaje de
error indicando que la identidad del
Fig. 54 Crear Cuenta Usuario
nuevo usuario ya existe.
C.8 El caso de uso continúa en el paso
F.4.2.4. CASO DE USO: ELIMINAR CUENTA USUARIO
NOMBRE ELIMINAR CUENTA USUARIO CÓDIGO C.U. CU004

C.U.
Propósito: Eliminar una cuenta de usuario existente.

Descripción: El usuario selecciona la cuenta de un usuario y la elimina.
Precondiciones:
Post condiciones:
 El usuario ha sido eliminado.
1. El usuario ingresa los datos correspondientes para realizar la búsqueda
2. El usuario elige la opción [BUSCAR] dentro de la pantalla [P002: Buscar
Usuario].
3. Se cargan en la tabla los datos el usuario buscado
4. El usuario selecciona la cuenta de usuario a eliminar
5. El sistema presenta la pantalla [P002.2: Editar Usuario].
6. El usuario elige la opción [ELIMINAR]
7. El sistema elimina el registro de la base de datos.
Tabla 16 Descripción del Caso de Uso: Eliminar Cuenta Usuario
124

Eliminar Cuenta Usuario SI SI SI
Tabla 17 Validación del Caso de Uso: Eliminar Cuenta Usuario
125
sd 29: Eliminar la Cuenta de Usuario
UsuarioDao
CASO DE USO: ELIMINAR CUENTA
USUARIO Usuario Directivo Principal Buscar Usuario Editar Usuario Usuario
1. El usuario elige [USUARIO] de

la pantalla [P001: Principal]. elige Usuario()
[P002: Buscar Usuario]. presenta()
correspondientes para realizar
la búsqueda ingresa datos para busqueda()
4. El usuario elige la opción
[BUSCAR] dentro de la
elige btnBuscar()
pantalla [P002: Buscar
Usuario]. obtenerListado(string login) :List
5. Se cargan en la tabla los datos
el usuario buscado
6. El usuario selecciona la cuenta presenta()
de usuario a eliminar
elige link Editar/Eliminar()
[P002.2: Editar Usuario].
8. El usuario elige la opción obtenerUsuario() :Usuario
[ELIMINAR]
9. El sistema elimina el registro
de la base de datos.
presenta()
elige linkEliminar()
eliminar(Usuario)
126
(from Actores) Fig. 55 Eliminar Cuenta Usuario

F.4.2.5. CASO DE USO: MODIFICAR CUENTA USUARIO
NOMBRE MODIFICAR CUENTA CÓDIGO C.U. CU005

C.U. USUARIO
Propósito: Editar los datos de una cuenta de usuario existente.

Descripción: El usuario selecciona la cuenta de usuario y modifica sus datos.
Precondiciones:
Post condiciones:
 El usuario queda editado.
2. El usuario elige la opción [BUSCAR] dentro de la [P002: Buscar Usuario]
3. Se cargan en la tabla los datos el usuario buscado
4. El usuario selecciona la cuenta de usuario a modificar.
5. El sistema presenta la pantalla [P002.2: Editar Usuario].
6. El usuario modifica los datos que crea pertinente.
7. El usuario selecciona la opción [GUARDAR] dentro de la pantalla [P002.2
Editar Usuario].
8. El sistema valida que se encuentren completos todos los campos.
9. El sistema actualiza la base de datos.
7.1.1. CAMPO VACÍO.
algún valor.
127
7.1.2. CAMPO INVÁLIDO

Tabla 18 Descripción del Caso de Uso: Modificar Cuenta Usuario

Modificar Cuenta SI SI SI
Usuario
Tabla 19 Validación del Caso de Uso: Modificar Cuenta Usuario
128
sd Editar Cuenta de Usuario
UsuarioDao
CASO DE USO: MODIFICAR CUENTA
USUARIO
Usuario Directivo Principal Buscar Usuario Editar Usuario Campos Vacios o Usuario
Incorrectos
1. El usuario elige [USUARIO] de la
pantalla [P001: Principal]. elige Usuario()
[P002: Buscar Usuario]. presenta()
correspondientes para realizar la
búsqueda ingresa datos para busqueda()
elige btnBuscar()
[BUSCAR] dentro de la [P002:
Buscar Usuario] obtenerListado(string login) :List
5. Se cargan en la tabla los datos el
usuario buscado
6. El usuario selecciona la cuenta de presenta()
usuario a modifcar.
[P002.2: Editar Usuario]. elige link Editar/Eliminar()
8. El usuario modifica los datos que obtenerUsuario() :Usuario
crea pertinente. presenta()
9. El usuario selecciona la opción
[GUARDAR] dentro de la pantalla
[P002.2 Editar Usuario]. modifica datos()
10. El sistema valida que se
encuentren completos todos los elige btnGuardar()
campos.
11. El sistema actualiza la base de
verifica campos()
datos.
actualizar(Usuario)
presenta()
A. CAMPO VACÍO.
A.11 El caso de uso continúa en el 129
B. CAMPO INVÁLIDO
corresponde. Fig. 56 Modificar Cuenta Usuario
F.4.2.6. CASO DE USO: CREAR JUGADOR
NOMBRE CREAR JUGADOR CÓDIGO C.U. CU006

C.U.
Propósito: Permitir que se registren en el sistema los datos de un jugador

Actor(es): Usuario Directivo, Usuario Secretario
Descripción: El Usuario Secretario registra los datos correspondientes para
crear un jugador
Precondiciones:
 Que el usuario haya ingresado al sistema correctamente
 Que el usuario se encuentre en la pantalla P001 “Principal” y elija la
opción [Jugador] del menú
Post condiciones:
 El jugador se ha creado
1. El usuario elige [Nuevo Jugador] en la pantalla [P003: Buscar Jugador].
2. El usuario ingresa cada uno de los datos que se solicitan para la creación
de un jugador] en la pantalla [P003.1: Nuevo Jugador].
3. El usuario elige la opción [GUARDAR]
5. El sistema almacena en la tabla jugador de la base de datos, toda la
información ingresada.
algún valor.
DATOS INCORRECTOS
130
B.4 El sistema presenta un mensaje de error indicando que los datos

7.2.2. IDENTIDAD EXISTENTE
jugador ya existe.
Tabla 20 Descripción del Caso de Uso: Crear Jugador

Crear Jugador SI SI SI
Tabla 21 Validación del Caso de Uso: Crear Jugador
131
sd 11: Crear Jugador
Jugador Dao
CASO DE USO: CREAR JUGADOR
Usuario Secretario Pricipal Buscar Jugador Nuevo Jugador Campo vacio o Jugador ya existe Jugador
1. El usuario elige [JUGADOR] incorrecto
de la pantalla [P001:
Principal]. elige Jugador()
[P003: Buscar Jugador]. presenta()
3. El usuario elige [Nuevo
Jugador] en la pantalla [P003:
Buscar Jugador]. elige btnNuevo()
4. El usuario ingresa cada uno
de los datos que se solicitan presenta()
para la creación de un
jugador] en la pantalla
ingresa datos()
[P003.1: Nuevo Jugador].
[GUARDAR] elige btnGuardar()
encuentren completos todos verifica campos()
los campos.
7. El sistema almacena en la
tabla jugador de la base de ExisteJugador(string cedula) :boolean
datos, toda la información
ingresada.
guardar ()
presenta()
 CAMPO VACÍO.
A.6 El sistema presenta un presenta()
mensaje de error indicando que no
se ha ingresado valor
alguno.
 DATOS INCORRECTOS (from Actores)
B.6 El sistema presenta un mensaje
de error indicando que los datos 132
B.7 El caso de uso continúa en el
IDENTIDAD EXISTENTE
C.6 El sistema presenta un mensaje
de error indicando que la identidad Fig. 57 Crear Jugador
del jugador ya existe.
C.7 El caso de uso continúa en el
F.4.2.7. CASO DE USO: ELIMINAR JUGADOR
NOMBRE ELIMINAR JUGADOR CÓDIGO C.U. CU007

C.U.
Propósito:
 Eliminar un jugador existente
Actor: Usuario Secretario
Descripción: El usuario selecciona un jugador y lo elimina
Precondiciones:
 Que el usuario se encuentre en la pantalla P003 “Buscar Jugador”
Post condiciones:
 El jugador ha sido eliminado
Jugador].
3. Se cargan todos los datos del jugador seleccionado.
4. El usuario elige la opción [ELIMINAR] de la tabla.
5. Se cargan todos los datos del jugador seleccionado en la pantalla [P003.2:
Editar Jugador].
6. El usuario elige la opción [ELIMINAR] de la pantalla.
7. El sistema elimina de la tabla jugador de la base de datos, todo el registro
seleccionado.
Tabla 22 Descripción del Caso de Uso: Eliminar Jugador
133

Eliminar Jugador SI SI SI
Tabla 23 Validación del Caso de Uso: Eliminar Jugador
134
sd EliminarJugador
JugadorDao
CASO DE USO: ELIMINAR JUGADOR
Usuario Secretario Principal Buscar Jugador Editar Jugador Jugador
1. El usuario elige [JUGADOR] de la
2. El sistema presenta la pantalla elige Jugador()
[P003: Buscar Jugador].
correspondientes para realizar la presenta()
búsqueda
4. El usuario elige la opción [BUSCAR]
ingresa datos para busqueda()
dentro de la pantalla [P003: Buscar
Jugador].
5. Se cargan todos los datos del elige btnBuscar()
jugador seleccionado.
6. El usuario elige la opción obtenerListado(string cedula) :List
[ELIMINAR] de la tabla.
7. Se cargan todos los datos del
jugador seleccionado en la pantalla presenta()
[P003.2: Editar Jugador].
[ELIMINAR] de la pantalla. elige link Editar/Eliminar()
9. El sistema elimina de la tabla obtenerJugador() :Jugador
jugador de la base de datos, todo el
registro seleccionado.
presenta()
eliminar(Jugador)
135
F.4.2.8. CASO DE USO: MODIFICAR JUGADOR
NOMBRE MODIFICAR JUGADOR CÓDIGO C.U. CU008

C.U.
Propósito:
 Modificar los datos principales de un jugador
Actor:Usuario Secretario
Descripción: El usuario modifica los datos correspondientes al jugador
Precondiciones:
 Que el usuario se encuentre en la pantalla P003 “Buscar Jugador”
Post condiciones:
 El jugador ha sido modificado.
Jugador].
3. Se cargan todos los datos del jugador seleccionado.
4. El usuario elige la opción [MODIFICAR] de la tabla.
5. Se cargan todos los datos del jugador seleccionado en la pantalla [P003.2:
Editar Jugador].
6. El usuario modifica cada uno de los datos que crea pertinentes
7. El usuario elige la opción [GUARDAR].
8. El sistema valida que se encuentren completos todos los campos en la
pantalla [P003.2: Editar Jugador].
9. El sistema almacena en la tabla jugador de la base de datos, toda la
información actualizada.
136

algún valor.
Tabla 24 Descripción del Caso de Uso: Modificar Jugador

Modificar Jugador SI SI SI
Tabla 25 Validación del Caso de Uso: Modificar Jugador
137
sd Editar Jugador
JugadorDao
CASO DE USO: MODIFICAR JUGADOR
Usuario Secretario Principal Buscar Jugador Editar Jugador Campos Vacios o Jugador
1. El usuario elige [JUGADOR] de la
pantalla [P001: Principal]. Incorrestos
2. El sistema presenta la pantalla [P003: elige Jugador()
Buscar Jugador]. presenta()
dentro de la pantalla [P003: Buscar obtenerListado(string cedula) :List
Jugador].
5. Se cargan todos los datos del jugador
seleccionado. presenta()
[MODIFICAR] de la tabla.
7. Se cargan todos los datos del jugador elige link Editar/Eliminar()
seleccionado en la pantalla [P003.2: obtenerJugador() :Jugador
Editar Jugador].
8. El usuario modifica cada uno de los presenta()
datos que crea pertinentes
10. El sistema valida que se encuentren modifica datos()
completos todos los campos en la
pantalla [P003.2: Editar Jugador].
11. El sistema almacena en la tabla elige btnGuardar()
jugador de la base de datos, toda la verifica campos()
información actualizada.
actualizar (Jugador)
presenta()
138
F.4.2.9. CASO DE USO: CREAR EQUIPO
NOMBRE CREAR EQUIPO CÓDIGO C.U. CU009

C.U.
Propósito:
 Permitir al usuario registrar en el sistema los datos de un equipo
Descripción: El usuario ingresa los datos correspondientes al equipo
Precondiciones:
opción [Equipo] del menú Archivo
Post condiciones:
 El equipo se ha creado
1. El usuario elige la opción [NuevoEquipo] en la pantalla [P004: Buscar
Equipo].
2. El sistema presenta la pantalla [P004.1: Nuevo Equipo].
de un equipo.
6. El sistema almacena en las tablas: equipoyrepresentantede la base de
datos, toda la información ingresada.

139
algún valor.
B.5 El sistema presenta un mensaje de error, indicando que se han ingresado
IDENTIDAD EXISTENTE
equipo ya existe.
Tabla 26 Descripción del Caso de Uso: Crear Equipo

Crear Equipo SI SI SI
Tabla 27 Validación del Caso de Uso: Crear Equipo
140
sd 9: Crear Equipo Lucía Figueroa y Pablo Castillo
EquipoDao
CASO DE USO: CREAR EQUIPO
1. El usuario elige [EQUIPO] de la Usuario Secretario Principal Buscar Equipo Nuevo Equipo Campos vacios o Equipo ya existe Equipo
pantalla [P001: Principal]. incorrectos ()
2. El sistema presenta la pantalla elige Equipo()
[P004: Buscar Equipo]. presenta()
[Nuevo Equipo] en la pantalla elige btnNuevo()
[P004: Buscar Equipo].
[P004.1: Nuevo Equipo].
5. El usuario ingresa cada uno de Ingresa datos()
los datos que se solicitan para la
creación de un equipo. elige btnGuardar()
6. El usuario elige la opción valida campos()
[GUARDAR].
encuentren completos todos los
campos. ExisteEquipo(string nombre) :boolean
8. El sistema almacena en las
tablas: equipo y representante
de la base de datos, toda la guardar()
9. El caso de uso finaliza. presenta()
presenta()
A. CAMPO VACÍO.
B. CAMPO INVÁLIDO
B.7 El sistema presenta un mensaje (from Actores)
de error indicando que se han
ingresado letras y/o números en
141
donde no corresponde.
Fig. 60 Crear Equipo
C.7 El sistema presenta un mensaje
de error indicando que la identidad
del equipo ya existe.
F.4.2.10. CASO DE USO: ELIMINAR EQUIPO
NOMBRE ELIMINAR EQUIPO CÓDIGO C.U. CU010

C.U.
Propósito:
Eliminar un equipo existente
Descripción: El usuario selecciona un equipo y lo elimina
Precondiciones:
 Que el usuario se encuentre en la pantalla P004 “Buscar Equipo”
Post condiciones:
 El equipo ha sido eliminado.
2. El usuario elige la opción [BUSCAR] que se encuentra en la pantalla [P004:
Buscar Equipo].
3. Se cargan todos los datos del Equipo seleccionado en la pantalla [P004:
Buscar Equipo].
4. El usuario elige la opción [ELIMINAR] que se encuentra en la tabla.
5. El sistema presenta la pantalla [P004.2: Editar Equipo] con los datos del
6. El usuario elige la opción [ELIMINAR] de la pantalla [P004.2: Editar Equipo].
7. El sistema elimina de las tablas: equipo y representante de la base de
datos, todo el registro seleccionado.
Tabla 28 Descripción del Caso de Uso: Eliminar Equipo
142

Eliminar Equipo SI SI SI
Tabla 29 Validación del Caso de Uso: Eliminar Equipo
143
sd 13: Eliminar Equipo
EquipoDao
CASO DE USO: ELIMINAR EQUIPO
Usuario Secretario Principal Buscar Equipo Editar Equipo Equipo
1. El usuario elige [EQUIPO] de la
elige Equipo()
Buscar Equipo]. presenta()
correspondientes para realizar la ingresa datos para busqueda()
búsqueda
elige btnBuscar()
que se encuentra en la pantalla
[P004: Buscar Equipo]. obtenerListado(string nombre) :List
5. Se cargan todos los datos del Equipo
seleccionado en la pantalla [P004:
Buscar Equipo]. presenta()
que se encuentra en la tabla.
7. El sistema presenta la pantalla elige link Editar/Eliminar()
[P004.2: Editar Equipo] con los datos obtenerEquipo() :Equipo
del registro seleccionado.
de la pantalla [P004.2: Editar
presenta()
Equipo].
9. El sistema elimina de las tablas:
equipo y representante de la base de
datos, todo el registro seleccionado.
10. El caso de uso finaliza. eliminar (Equipo)
144
F.4.2.11. CASO DE USO: MODIFICAR EQUIPO
NOMBRE MODIFICAR EQUIPO CÓDIGO C.U. CU011

C.U.
Propósito:
 Permitir al usuario modificar los datos de un equipo
Descripción: El usuario modifica los datos correspondientes al equipo
Precondiciones:
 Que el usuario se encuentre en la pantalla P004 “Buscar Equipo”
Post condiciones:
 El equipo ha sido editado.
Equipo].
3. Se cargan todos los datos del Equipo seleccionado en la pantalla.
5. El usuario modifica cada uno de los datos que crea pertinentes en la
pantalla [P004.2: Editar Equipo].
6. El usuario elige la opción [GUARDAR] de la pantalla [P004.2: Editar
Equipo].
pantalla.
8. El sistema almacena en las tablas: equipo y representante de la base de
datos, toda la información modificada.
145

algún valor.

B.7 El sistema presenta un mensaje de error, indicando que se han ingresado
Tabla 30 Descripción del Caso de Uso: Modificar Equipo

Modificar Equipo SI SI SI
Tabla 31 Validación del Caso de Uso: Modificar Equipo
146
sd 3: Editar Equipo
EquipoDao
CASO DE USO: MODIFICAR EQUIPO
Usuario Secretario Principal Buscar Equipo Editar Equipo Campos vacios o Equipo
1. El usuario elige [EQUIPO] de la
incorrectos ()
2. El sistema presenta la pantalla elige Equipo()
[P004: Buscar Equipo].
3. El usuario ingresa los datos presenta()
[BUSCAR] dentro de la pantalla
[P004: Buscar Equipo]. elige btnBuscar()
obtenerListado(string nombre) :List
Equipo seleccionado en la pantalla.
presenta()
7. El usuario modifica cada uno de los
datos que crea pertinentes en la
pantalla [P004.2: Editar Equipo]. elige link Editar/Eliminar()
obtenerEquipo() :Equipo
[GUARDAR] de la pantalla [P004.2:
Editar Equipo].
presenta()
9. El sistema valida que se encuentren
completos todos los campos en la
pantalla.
modifica datos()
10. El sistema almacena en las tablas:
equipo y representante de la base
elige btnGuardar()
de datos, toda la información
modificada.
11. El caso de uso finaliza. verifica datos()
actualizar(Equipo)
A. CAMPO VACÍO. presenta()

valor alguno. 147
A.10 El caso de uso continúa en el paso
B. CAMPO INVÁLIDO
letras y/o números en donde no (from Actores) Fig. 62 Modificar Equipo
corresponde.
F.4.2.12. CASO DE USO: CREAR ÁRBITRO
NOMBRE CREAR ARBITRO CÓDIGO C.U. CU012

C.U.
Propósito:
 Permitir al usuario registrar en el sistema los datos de un arbitro
Descripción: El usuario ingresa los datos correspondientes de un arbitro
Precondiciones:
opción [Arbitro] del menú
Post condiciones:
 El árbitro se ha creado.
1. El usuario elige la opción [Nuevo Arbitro] en la pantalla [P005: Buscar
Arbitro].
2. El sistema presenta la pantalla [P005.1: Nuevo Arbitro].
de un árbitro.
6. El sistema almacena en la tabla árbitro de la base de datos, toda la
148

valor alguno.

IDENTIDAD EXISTENTE
árbitro ya existe.
Tabla 32 Descripción del Caso de Uso: Crear Árbitro

Crear Arbitro SI SI SI
Tabla 33 Validación del Caso de Uso: Crear Árbitro
149
sd 9: Crear Arbitro
ArbitroDao
CASO DE USO: CREAR ARBITRO
Usuario Secreatio Principal Buscar Arbitro Nuevo Arbitro Campos Vacios o Arbitro ya Existe Arbitro
Incorrectos
[Arbitro] del menú, dentro de la
pantalla [P001: Principal] elige Arbitro()
presenta()
[P007: Buscar Arbitro]
[btnNuevo] en la pantalla [P007: elige btnNuevo()
Buscar Arbitro]
[P007.1: Nuevo Arbitro].
5. El usuario ingresa cada uno de los
ingresa datos()
datos que se solicitan para la
creación de un árbitro.
6. El usuario elige la opción elige btnGuardar()
[GUARDAR].
verifica campos()
encuentren completos todos los
campos.
8. El sistema busca en la base de
ExisteArbitro(string cedula) :boolean
datos que el arbitro no este creado
9. El sistema almacena en la tabla
arbitro de la base de datos, toda
la información ingresada.
guardar()
presenta()
A. CAMPO VACÍO. presenta()

valor alguno.
A.8 El caso de uso continúa en el paso
B. CAMPO INVÁLIDO
error indicando que se han ingresado 150
corresponde.
C.7 El sistema presenta un mensaje de Fig. 63 Crear Árbitro
árbitro ya existe.
F.4.2.13. CASO DE USO: ELIMINAR ÁRBITRO
NOMBRE ELIMINAR ARBITRO CÓDIGO C.U. CU013

C.U.
Propósito:
 Permitir al usuario eliminar un árbitro del sistema.
Descripción: El usuario selecciona un árbitro y lo elimina
Precondiciones:
 Que el usuario se encuentre en la pantalla P005 “Buscar Arbitro”
Post condiciones:
 El árbitro ha sido eliminado.
Buscar Arbitro].
3. Se cargan todos los datos del Árbitro seleccionado en la pantalla [P008:
Buscar Arbitro].
5. Se presenta la pantalla [P005.2: Editar Arbitro] con los datos del árbitro a
eliminar.
6. El usuario elige la opción [ELIMINAR] de la pantalla [P005.2: Editar Arbitro].
7. El sistema elimina de la tabla arbitro de la base de datos, todo el registro
seleccionado
Tabla 34 Descripción del Caso de Uso: Eliminar Árbitro
151

Eliminar Arbitro SI SI SI
Tabla 35 Validación del Caso de Uso: Eliminar Árbitro
152
sd 23: Eliminar Arbitro
ArbitroDao
CASO DE USO: ELIMINAR ARBITRO
1. El usuario elige la opción [Arbitro] Usuario Secretario Principal Buscar Arbitro Editar Arbitro Arbitro
del menú, dentro de la pantalla
[P001: Principal]
2. El sistema presenta la pantalla [P007: elige Arbitro()
Buscar Arbitro] presenta()
búsqueda ingresa dato para busqueda()
que se encuentra en la pantalla elige btnBuscar()
[P008: Buscar Arbitro]. obtenerListado(string apellido) :List
5. Se cargan todos los datos del Árbitro
seleccionado en la pantalla [P008:
Buscar Arbitro].
6. El usuario elige la opción [ELIMINAR] presenta()
7. Se presenta la pantalla [P008.2:
elige link Editar/Eliminar()
Editar Arbitro] con los datos del
árbitro a eliminar. obternerArbitro() :Arbitro
de la pantalla [P008.2: Editar
Arbitro].
presenta()
9. El sistema elimina de la tabla arbitro
de la base de datos, todo el registro
seleccionado elige linkEliminar()
eliminar(Arbitro)
153
(from Actores)
F.4.2.14. CASO DE USO: MODIFICAR ÁRBITRO
NOMBRE MODIFICAR ARBITRO CÓDIGO C.U. CU014

C.U.
Propósito:
 Permitir al usuario modificar los datos de un árbitro.
Descripción: El usuario modifica los datos correspondientes del árbitro.
Precondiciones:
 Que el usuario se encuentre en la pantalla P005 “Buscar Arbitro”
Post condiciones:
 El árbitro ha sido editado.
Arbitro].
3. Se cargan todos los datos del Árbitro seleccionado en la pantalla.
5. Se presenta la pantalla [P005.2: Editar Arbitro].
pantalla.
7. El usuario elige la opción [GUARDAR] de la pantalla [P005.2: Editar Arbitro].
pantalla.
9. El sistema almacena en la tabla árbitro de la base de datos, toda la
información modificada.
154

valor alguno.

Tabla 36 Descripción del Caso de Uso: Modificar Árbitro

Modificar Arbitro SI SI SI
Tabla 37 Validación del Caso de Uso: Modificar Árbitro
155
sd 16: Editar Arbitro
ArbitroDao
CASO DE USO: MODIFICAR ARBITRO
1. El usuario elige la opción [Arbitro] Usuario Secretario Principal Buscar Arbitro Editar Arbitro Campos Vacios o Arbitro
del menú, dentro de la pantalla Incorrectos
[P001: Principal] elige Arbitro()
Buscar Arbitro] presenta()
correspondientes para realizar la ingresa dato para busqueda()
búsqueda
dentro de la pantalla [P008: Buscar elige btnBuscar()
Arbitro]. obtenerListado(string apellido) :List
5. Se cargan todos los datos del Árbitro
seleccionado en la pantalla.
6. El usuario elige la opción presenta()
Editar Arbitro]. elige link Editar/Eliminar()
8. El usuario modifica cada uno de los
datos que crea pertinentes en la obtenerArbitro() :Arbitro
pantalla. presenta()
[GUARDAR] de la pantalla [P008.2:
Editar Arbitro]. modifica datos()
completos todos los campos en la elige btnGuardar()
pantalla. verifica campos()
arbitro de la base de datos, toda la
información modificada. actualizar(Arbitro)

presenta()
A. CAMPO VACÍO.
error indicando que no se ha ingresado 156
valor alguno.
B. CAMPO INVÁLIDO
error indicando que se han ingresado letras
(from Actores)
y/o números en donde no corresponde.
Fig. 65 Modificar Árbitro
B.11 El caso de uso continúa en el paso 7
F.4.2.15. CASO DE USO: CREAR ESCENARIO
NOMBRE CREAR ESCENARIO CÓDIGO C.U. CU015

C.U.
Propósito:
 Permitir al usuario registrar en el sistema los datos de un escenario
Descripción: El usuario ingresa los datos correspondientes al escenario
Precondiciones:
opción [Escenario] del menú
Post condiciones:
 El escenario se ha creado.
1. El usuario elige la opción [Nuevo Escenario] en la pantalla [P006: Buscar
Escenario].
2. El sistema presenta la pantalla [P006.1: Nuevo Escenario].
de un escenario.
6. El sistema almacena en la tabla escenarios de la base de datos, toda la
157

valor alguno.

IDENTIDAD EXISTENTE
escenario ya existe.
Tabla 38 Descripción del Caso de Uso: Crear Escenario

Crear Escenario SI SI SI
Tabla 39 Validación del Caso de Uso: Crear Escenario
158
sd 10: Crear Escenario
Escenario
CASO DE USO: CREAR Dao
ESCENARIO Usuario Secretario Principal Buscar Escenario Nuevo Escenario Campo vacio o Escenario ya existe Escenario
incorrecto
1. El usuario elige
[ESCENARIO] de la pantalla elige Escenario()
[P001: Principal].
2. El sistema presenta la presenta()
pantalla [P005: Buscar
Escenario].
elige btnNuevo()
[Nuevo Escenario] en la
pantalla [P005: Buscar ingresa datos()
Escenario].
4. El sistema presenta la
pantalla [P005.1: Nuevo elige btnGuardar()
Escenario].
verifica campos()
5. El usuario ingresa cada uno
de los datos que se solicitan
para la creación de un
escenario. ExisteEscenario(string nombre) :boolean
[GUARDAR].
encuentren completos todos guardar ()
los campos. presenta()
8. El sistema almacena en la
tabla escenarios de la base presenta()
de datos, toda la
A. CAMPO VACÍO.
A.7 El sistema presenta un (from Actores)
mensaje de error indicando que
no se ha ingresado
valor alguno.
A.8 El caso de uso continúa en
el paso 4 del curso normal de
eventos.
B. CAMPO INVÁLIDO
B.7 El sistema presenta un
se han ingresado letras y/o
números en donde no
159
corresponde.
paso 4 del curso normal de
eventos. Fig. 66Crear Escenario
C.7 El sistema presenta un
la identidad del escenario ya
existe.
paso 4 del curso normal de
F.4.2.16. CASO DE USO: ELIMINAR ESCENARIO
NOMBRE ELIMINAR ESCENARIO CÓDIGO C.U. CU016

C.U.
Propósito:
 Permitir al usuario eliminar un escenario del sistema.
Descripción: El usuario selecciona un escenario y lo elimina
Precondiciones:
 Que el usuario se encuentre en la pantalla P006 “Buscar Escenario”
Post condiciones:
 El escenario ha sido eliminado.
Buscar Escenario].
3. Se cargan todos los datos del Escenario seleccionado en la pantalla [P006:
Buscar Escenario].
5. Se presenta la pantalla [P006.2: Editar Escenario] con los datos del
escenario a eliminar.
6. El usuario elige la opción [ELIMINAR] de la pantalla [P006.2: Editar
Escenario].
7. El sistema elimina de la tabla escenarios de la base de datos, todo el
registro seleccionado
Tabla 40 Descripción del Caso de Uso: Eliminar Escenario
160

Eliminar Escenario SI SI SI
Tabla 41 Validación del Caso de Uso: Eliminar Escenario
161
sd 14: Eliminar Escenario
EscenarioDao
CASO DE USO: ELIMINAR ESCENARIO
Usuario Secretario Principal Buscar Escenario Editar Escenario Escenario
1. El usuario elige [ESCENARIO] de la
elige Escenario()
[P005: Buscar Escenario]. presenta()
[BUSCAR] que se encuentra en la
elige btnBuscar()
pantalla [P005: Buscar Escenario].
5. Se cargan todos los datos del obtenerListado(string nombre) :List
Escenario seleccionado en la
pantalla [P005: Buscar Escenario].
[ELIMINAR] que se encuentra en la
tabla.
7. Se presenta la pantalla [P005.2: elige link Editar/Eliminar()
Editar Escenario] con los datos del obtenerEscenario() :Escenario
escenario a eliminar.
[ELIMINAR] de la pantalla [P005.2:
presenta()
Editar Escenario].
9. El sistema elimina de la tabla
escenarios de la base de datos, elige linkEliminar()
todo el registro seleccionado
10. El caso de uso finaliza. eliminar(Escenario)
162
F.4.2.17. CASO DE USO: MODIFICAR ESCENARIO
NOMBRE MODIFICAR ESCENARIO CÓDIGO C.U. CU017

C.U.
Propósito:
 Permitir al usuario modificar los datos un escenario
Descripción: El usuario modifica los datos correspondientes al escenario
Precondiciones:
 Que el usuario se encuentre en la pantalla P006 “Buscar Escenario”
Post condiciones:
 El escenario ha sido editado.
Escenario].
3. Se cargan todos los datos del Escenario seleccionado en la pantalla.
5. Se presenta la pantalla [P006.2: Editar Escenario].
pantalla.
Escenario].
pantalla.
9. El sistema almacena en la tabla escenarios de la base de datos, toda la
163

valor alguno.

Tabla 42 Descripción del Caso de Uso: Modificar Escenario

Modificar Escenario SI SI SI
Tabla 43 Validación del Caso de Uso: Modificar Escenario
164
sd Editar Escenario
EscenarioDao
CASO DE USO: MODIFICAR
ESCENARIO
Usuario Secretario Principal Buscar Escenario Editar Escenario Campo vacio o Escenario
1. El usuario elige [ESCENARIO] de incorrecto
elige Escenario()
la pantalla [P001: Principal].
[P005: Buscar Escenario].
correspondientes para realizar la ingresa datos para busqueda()
búsqueda
4. El usuario elige la opción elige btnBuscar()
[BUSCAR] dentro de la pantalla
[P005: Buscar Escenario]. obtenerListado(string nombre) :List
Escenario seleccionado en la
pantalla. presenta()
7. Se presenta la pantalla [P005.2: elige link Editar/Eliminar()
Editar Escenario]. obtenerEscenario() :Escenario
8. El usuario modifica cada uno de
presenta()
los datos que crea pertinentes en
la pantalla.
9. El usuario elige la opción modifica datos()
[GUARDAR] de la pantalla
[P005.2: Editar Escenario]. elige btnGuardar()
encuentren completos todos los verifica campos()
campos en la pantalla.
actualizar (Escenario)
escenarios de la base de datos,
toda la información modificada.
presenta()
A. CAMPO VACÍO.
ingresado valor alguno. 165
B. CAMPO INVÁLIDO
B.10 El sistema presenta un mensaje
de error indicando que se han
ingresado letras y/o números en donde
no corresponde. Fig. 68 Modificar Escenario
F.4.2.18. CASO DE USO: CREAR CANCHA
NOMBRE CREAR CANCHA CÓDIGO C.U. CU018

C.U.
Propósito:
 Permitir al usuario registrar en el sistema los datos de una cancha
Descripción: El usuario ingresa los datos correspondientes a la cancha
Precondiciones:
opción [Cancha] del menú
Post condiciones:
 La cancha se ha creado.
1. El usuario elige la opción [Nueva Cancha] en la pantalla [P007: Buscar
Cancha].
2. El sistema presenta la pantalla [P007.1: Nueva Cancha].
de una cancha
6. El sistema almacena en la tabla cancha de la base de datos, toda la
166

valor alguno.

IDENTIDAD EXISTENTE
C.5 El sistema presenta un mensaje de error indicando que la identidad de la
cancha ya existe.
Tabla 44 Descripción del Caso de Uso: Crear Cancha

Crear Cancha SI SI SI
Tabla 45 Validación del Caso de Uso: Crear Cancha
167
sd 11: Crear Cancha Lucía Figueroa y Pablo Castillo
CanchaDao
CASO DE USO: CREAR CANCHA
1. El usuario elige [CANCHA] de la Usuario Secretario Principal Buscar Cancha Nueva Cancha Campos Vacios o Cancha ya Existe Cancha
pantalla [P001: Principal]. Incorrectos
elige Cancha()
[P006: Buscar Cancha]. presenta()
3. El usuario elige la opción [Nueva
Cancha] en la pantalla [P006:
Buscar Cancha]. elige btnNuevo()
[P006.1: Nueva Cancha].
presenta()
5. El usuario ingresa cada uno de
los datos que se solicitan para la ingresa datos()
creación de una cancha
[GUARDAR]. elige btnGuardar()
encuentren completos todos los verifica campos()
campos.
cancha de la base de datos, toda ExisteCancha(string nombre) :boolean
la información ingresada.
guardar()
CURSO ALTERNO DE EVENTOS presenta()
A. CAMPO VACÍO.
A.7 El sistema presenta un mensaje presenta()
B. CAMPO INVÁLIDO
error indicando que se han ingresado (from Actores)
corresponde. 168
error indicando que la identidad de la
cancha ya existe. Fig. 69 Crear Cancha
F.4.2.19. CASO DE USO: ELIMINAR CANCHA
NOMBRE ELIMINAR CANCHA CÓDIGO C.U. CU019

C.U.
Propósito:
 Permitir al usuario eliminar una cancha del sistema.
Descripción: El usuario selecciona un escenario y lo elimina
Precondiciones:
 Que el usuario se encuentre en la pantalla P007 “Buscar Cancha”
Post condiciones:
 La cancha ha sido eliminada.
Buscar Cancha].
3. Se cargan todos los datos de la Cancha seleccionada en la pantalla [P007:
Buscar Cancha].
5. Se presenta la pantalla [P007.2: Editar Cancha] con los datos de la cancha
a eliminar.
6. El usuario elige la opción [ELIMINAR] de la pantalla [P007.2: Editar
Cancha].
7. El sistema elimina de la tabla cancha de la base de datos, todo el registro
seleccionado
Tabla 46 Descripción del Caso de Uso: Eliminar Cancha

169

Eliminar Cancha SI SI SI
Tabla 47 Validación del Caso de Uso: Eliminar Cancha
170
sd 25: Eliminar Cancha
CanchaDao
CASO DE USO: ELIMINAR CANCHA
1. El usuario elige [ESCENARIO] de la Usuario Secretario Principal Buscar Cancha Editar Cancha Cancha
2. El sistema presenta la pantalla [P006: elige Cancha()
Buscar Cancha]. presenta()
que se encuentra en la pantalla [P006: elige btnBuscar()
Buscar Cancha]. obtenerListado(string nombre) :List
5. Se cargan todos los datos de la Cancha
seleccionada en la pantalla [P006:
Buscar Cancha]. presenta()
7. Se presenta la pantalla [P006.2: Editar elige link Editar/Eliminar()
Cancha] con los datos de la cancha a obtenerCancha() :Cancha
eliminar.
de la pantalla [P006.2: Editar Cancha].
9. El sistema elimina de la tabla cancha presenta()
de la base de datos, todo el registro
seleccionado
eliminar(Cancha)
171
(from Actores)
F.4.2.20. CASO DE USO: MODIFICAR CANCHA
NOMBRE MODIFICAR CANCHA CÓDIGO C.U. CU020

C.U.
Propósito:
 Permitir al usuario modificar los datos una cancha
Descripción: El usuario modifica los datos correspondientes a lacancha
Referencia al Requerimiento:RF012
Precondiciones:
 Que el usuario se encuentre en la pantalla P007 “Buscar Cancha”
Post condiciones:
 El escenario ha sido editado.
Cancha].
3. Se cargan todos los datos de la Cancha seleccionada en la pantalla.
5. Se presenta la pantalla [P007.2: Editar Cancha].
pantalla.
Cancha].
pantalla.
9. El sistema almacena en la tabla cancha de la base de datos, toda la
172

valor alguno.

Tabla 48 Descripción del Caso de Uso: Modificar Cancha

Modificar Cancha SI SI SI
Tabla 49 Validación del Caso de Uso: Modificar Cancha
173
sd 18: Editar Cancha
CanchaDao
CASO DE USO: MODIFICAR CANCHA
Usuario Secretario Principal Buscar Cancha Editar Cancha Campos Vacios o Cancha
1. El usuario elige [CANCHA] de la
pantalla [P001: Principal]. Incorrectos
2. El sistema presenta la pantalla elige Cancha()
[P006: Buscar Cancha]. presenta()
[BUSCAR] dentro de la pantalla elige btnBuscar()
[P006: Buscar Cancha].
obtenerListado(string nombre) :List
5. Se cargan todos los datos de la
Cancha seleccionada en la
pantalla.
presenta()
Editar Cancha]. elige link Editar/Eliminar()
8. El usuario modifica cada uno de obtenerCancha() :Cancha
los datos que crea pertinentes en
la pantalla. presenta()
[GUARDAR] de la pantalla
modifica datos()
[P006.2: Editar Cancha].
encuentren completos todos los elige btnGuardar()
campos en la pantalla.
11. El sistema almacena en la tabla verifica campos()
cancha de la base de datos, toda
la información modificada. actualizar(Cancha)
presenta()
A. CAMPO VACÍO.
paso 7 del curso normal de eventos. (from Actores) 174
B. CAMPO INVÁLIDO
corresponde.
Fig. 71 Modificar Cancha
F.4.2.21. CASO DE USO: CREAR CAMPEONATO
NOMBRE CREAR CAMPEONATO CÓDIGO C.U. CU021

C.U.
Propósito:
 Identificar la fecha de inicio, el nombre, la disciplina, el género de los
participantes del campeonato, el número de equipos participantes, el
sistema de puntuación, y el número de vueltas del campeonato.
Descripción: El usuario ingresa los datos correspondientes para la creación de
un campeonato
Referencia al Requerimiento:RF003, RF004, RF013, RF015
Precondiciones:
 Que el usuario haya entrado correctamente al sistema
opción [ Campeonato] del menú Administración
Post condiciones:
 El Campeonato ha sido creado.

1. El usuario elige la opción [NuevoCampeonato] en la pantalla [P008: Buscar
Campeonato].
2. El sistema presenta la pantalla [P008.1: Nuevo Campeonato].
de un campeonato.
5. El sistema validaque se encuentren completos todos los camposrequeridos.
6. El sistema almacena en las tablas correspondientes de la Base de Datos
toda la información ingresada
175

CAMPO VACÍO.
A.5 El sistema presenta un mensaje de error indicando que no se han
ingresado todos los datos requeridos.

IDENTIDAD EXISTENTE
campeonato ya existe.
Tabla 50 Descripción del Caso de Uso: Crear Campeonato

Crear Campeonato SI SI SI
Tabla 51 Validación del Caso de Uso: Crear Campeonato
176
sd 7: Crear Campeonato
CampeonatoDao
CASO DE USO: CREAR CAMPEONATO
1. El usuario elige la opción Usuario Secretario Principal Buscar Nuevo Campos vacios o Campeonato ya Campeonato
[Campeonato] del menú, dentro de Campeonato Campeonato incorrectos existe
la pantalla [P001: Principal]
elige Campeonato()
[P009: Buscar Campeonato]
[btnNuevo] en la pantalla [P009:
Buscar Campeonato].
4. El sistema presenta la pantalla elige btnNuevo()
[P009.1: Nuevo Campeonato].
presenta()
datos que se solicitan para la
creación de un campeonato.
6. El usuario elige la opción ingresa datos()
[GUARDAR].
completos todos los campos. elige btnGuardar()
8. El sistema almacena en la tabla verifica campos()
campeonato de la base de datos
toda la información ingresada.
ExisteCampeonato(string nombre) :boolean
A. CAMPO VACÍO. guardar()

error indicando que no se ha ingresado presenta()
valor alguno.
presenta()
B. CAMPO INVÁLIDO
corresponde.
B.8 El caso de uso continúa en el paso 4
177
campeonato ya existe.
C.8 El caso de uso continúa en el paso 4 Fig. 72 Crear Campeonato
F.4.2.22. CASO DE USO: ELIMINAR CAMPEONATO
NOMBRE ELIMINAR CAMPEONATO CÓDIGO C.U. CU022

C.U.
Propósito:
 Eliminar un Campeonato existente
Descripción: El usuario selecciona un Campeonato y lo elimina
Referencia al Requerimiento: RF003, RF004, RF013, RF015
Precondiciones:
 Que el usuario haya entrado al sistema correctamente.
 Que el usuario se encuentre en la pantalla P008:“Buscar
Campeonato”
Post condiciones:
 El Campeonato ha sido eliminado.
Buscar Campeonato].
3. Se cargan todos los datos del Campeonato seleccionado en la pantalla
[P008: Buscar Campeonato].
5. El sistema presenta la pantalla [P008.2: Editar Campeonato].
6. El usuario selecciona la opción [ELIMINAR] dentro de la pantalla [P008.2:
Editar Campeonato].
7. El sistema valida que el Campeonato no se haya iniciado, es decir verifica
que la fecha actual sea menor a la fecha de inicio del Campeonato.
8. El sistema elimina de la tabla campeonato de la base de datos, todo el
178

CAMPEONATO INICIADO.
A.5 El sistema presenta un mensaje de error indicando que no se pueden
eliminar campeonatos ya iniciados.
A.6 El sistema presenta la pantalla [P008: Buscar Campeonato].
Tabla 52 Descripción del Caso de Uso: Eliminar Campeonato

Eliminar Campeonato SI SI SI
Tabla 53 Validación del Caso de Uso: Eliminar Campeonato
179
sd 12: Eliminar Campeonato
CampeonatoDao
CASO DE USO: ELIMINAR CAMPEONATO
1. El usuario elige la opción Usuario Secretario Principal Buscar Editar Campeonato

[Campeonato] del menú, dentro de la Campeonato Campeonato
pantalla [P001: Principal]
elige Campeonato()
Buscar Campeonato] presenta()
que se encuentra en la pantalla [P009:
elige btnBuscar()
Buscar Campeonato].
5. Se cargan todos los datos del obtenerListado(string nombre) :List
Campeonato seleccionado en la
pantalla [P009: Buscar Campeonato].
6. El usuario elige la opción [ELIMINAR] presenta()
[P009.2: Editar Campeonato]. elige link Editar/Eliminar()
obtenerCampeonato() :Campeonato
[ELIMINAR] dentro de la pantalla
[P009.2: Editar Campeonato].
9. El sistema valida que el Campeonato
no se haya iniciado, es decir verifica presenta()
que la fecha actual sea menor a la
fecha de inicio del Campeonato.
10. El sistema elimina de la tabla elige linkEliminar()
campeonato de la base de datos, todo
eliminar(Campeonato)
el registro seleccionado.
180
F.4.2.23. CASO DE USO: MODIFICAR CAMPEONATO
NOMBRE MODIFICAR CAMPEONATO CÓDIGO C.U. CU023

C.U.
Propósito:
 Modificar los parámetros del Campeonato
Descripción: El usuario modifica los datos requeridos del Campeonato
Referencia al Requerimiento:RF003, RF004, RF013, RF015
Precondiciones:
 Que el usuario se encuentre en la pantalla P008 “Buscar
Campeonato”
Post condiciones:
 El Campeonato ha sido editado.
Campeonato].
3. Se cargan todos los datos del campeonato seleccionado.
5. El sistema presenta la pantalla [P008.2: Editar Campeonato].
6. El usuario modifica los datos que crea pertinente.
7. El usuario selecciona la opción [GUARDAR] dentro de la pantalla [P008.2:
Editar Campeonato].
9. El sistema valida que el Campeonato no se haya iniciado, es decir verifica
que la fecha actual sea menor a la fecha de inicio del Campeonato.
8. El sistema almacena toda la información actualizada en las tablas
correspondientes de la Base de Datos.
181

CAMPO VACÍO.
A.8 El sistema presenta un mensaje de error indicando que no se han
ingresado todos los datos requeridos.
CAMPEONATO INICIADO.
B.8 El sistema presenta un mensaje de error indicando que no se pueden
modificar campeonatos ya iniciados.
B.9 El sistema presenta la pantalla [P008: Buscar Campeonato].
Tabla 54 Descripción del Caso de Uso: Modificar Campeonato

Modificar Campeonato SI SI SI
Tabla 55 Validación del Caso de Uso: Modificar Campeonato
182
sd 21: Editar Campeonato
CampeonatoDao
CASO DE USO: MODIFICAR CAMPEONATO
Usuario Secretario Principal Buscar Editar Campos vacios o Campeonato
[Campeonato] del menú, dentro de la Campeonato Campeonato incorrectos
pantalla [P001: Principal] elige Campeonato()
presenta()
Buscar Campeonato]
correspondientes para realizar la ingresa dato para busqueda()
búsqueda
dentro de la pantalla [P009: Buscar elige btnBuscar()
Campeonato]. obtenerListado(string nombre) :List
campeonato seleccionado en la
pantalla.
6. El usuario elige la opción [MODIFICAR]
de la tabla.
7. El sistema presenta la pantalla [P009.2:
Editar Campeonato]. elige link Editar/Eliminar()
8. El usuario modifica los datos que crea
obtenerCampeonato() :Campeonato
pertinente.
[GUARDAR] dentro de la pantalla
[P009.2: Editar Campeonato].
10. El sistema valida que se encuentren presenta()
completos todos los campos.
11. El sistema valida que el Campeonato
no se haya iniciado, es decir verifica modifica datos()
que la fecha actual sea menor a la
fecha de inicio del Campeonato. elige btnGuardar()
12. El sistema almacena toda la verifica campos()
información actualizada en las tablas
correspondientes de la Base de Datos.
13. El caso de uso finaliza. actuarlizar(Campeonato)

presenta()
A. CAMPO VACÍO. 183
valor alguno.
B. CAMPEONATO INICIADO.
error indicando que no se pueden modificar Fig. 74 Modificar Campeonato
campeonatos ya iniciados.
B.12 El sistema presenta la pantalla [P009:
F.4.2.24. CASO DE USO: INSCRIBIR EQUIPO AL CAMPEONATO
NOMBRE INSCRIBIR EQUIPO AL CÓDIGO C.U. CU024

C.U. CAMPEONATO
Propósito:
 Inscribir un Equipo con sus jugadores a un Campeonato.
Descripción: El usuario elige un equipo con sus respectivos jugadores, para
inscribirlo a un campeonato.
Referencia al Requerimiento:RF006, RF007, RF009
Precondiciones:
opción Inscribir Equipo.
Post condiciones:
 El Equipo ha sido inscrito.

1. El usuario elige la opción [InscribirEquipo] en la pantalla [P001: Principal].
2. El sistema presenta la pantalla [P009: Inscripción de Equipos].
3. El usuario elige el campeonato en el que desea inscribir el equipo.
4. El usuario elige la opción [INSCRIBIR EQUIPO] dentro de la pantalla [P010:
Inscripción de Equipos].
5. El sistema presenta la pantalla [P009.1: Listado de Equipos del
Campeonato].
6. El usuario elige la opción [SELECCIONAR] dentro de la tabla que contiene
los equipos existentes de la disciplina del campeonato.
7. El sistema almacena en labase de datos la inscripción del equipo
seleccionado al campeonatoy presenta la pantalla [P009.2 Listado de
Jugadores del Equipo]
184
8. El usuario elige la opción [SELECCIONAR] dentro de la tabla que contiene

los jugadores existentes del genero del campeonato.
9. El usuario elige la opción [GUARDAR] de la pantalla.
10. El sistema almacena en la base de datos la inscripción de los jugadores
seleccionados al equipo.
EQUIPO YA INSCRITO.
A.9 El sistema presenta un mensaje de error indicando que el equipo ya se
encuentra inscrito en el campeonato.
Tabla 56 Descripción del Caso de Uso: Inscribir Equipo al Campeonato

Inscribir Equipo al SI SI SI
Campeonato
Tabla 57 Validación del Caso de Uso: Inscribir Equipo al Campeonato
185
d 33: Inscribir Equipo
Equipo Dao Inscripcion Inscripcion Campeonato Jugador

CASO DE USO: INSCRIBIR EQUIPO AL Equipos Jugador Dao Dao
CAMPEONATO Dao Dao
Usuario Secretario Principal Inscripcion de Listado de Equipos Listado de Equipo Campeonato Inscripcion de Jugador Inscripcion de
1. El usuario elige la opción [Inscribir Equipos del Campeonato Jugadores del Equipo Jugador
Equipo] en la pantalla [P001: Equipo
Principal]. elige Inscribir Equipo()
[P010: Inscripción de Equipos]. ObtenerCampeonatosActivosNoGenerados() :List
3. El usuario elige el campeonato en
el que desea inscribir el equipo.
[INSCRIBIR EQUIPO] dentro de la
pantalla [P010: Inscripción de
Equipos]. elige el campeonato()
obtenerEquipos(genero, disciplina) :List
[P010.1: Listado de Equipos del
Campeonato].
[SELECCIONAR] dentro de la
tabla que contiene los equipos presenta()
existentes de la disciplina del
campeonato.
elige btnInscribirEquipo()
7. El sistema almacena en la base
de datos la inscripción del equipo
obtenerEquipos(string genero string disciplina) :List
seleccionado al campeonato y
presenta la pantalla [P010.2
Listado de Jugadores del Equipo] presenta()
[SELECCIONAR] dentro de la
tabla que contiene los jugadores elige linkSeleccionar de la tabla de equipos()
existentes del genero del obtenerEquipo(string nombre) :Equipo
campeonato.
9. El sistema almacena en la base
de datos la inscripción del jugador
seleccionado al equipo y lo
guardar(Equipo)
presenta en la lista de jugadores
que pertenecen al equipo en
pantalla [P010.2 Listado de
Jugadores del Equipo] presenta()
elige jugadores linkSeleccionar de la tabla()

obternerJugador(cedula) :Jugador
elige btnGuardar()
186
guardar(string inscripcionEquipo, List jugadores)
presenta()
Fig. 75 Inscribir Equipo al Campeonato

(from Actores)
F.4.2.25. CASO DE USO: ASIGNAR CANCHA AL CAMPEONATO
NOMBRE ASIGNAR CANCHA AL CÓDIGO C.U. CU025

C.U. CAMPEONATO
Propósito:
 Definir las canchas en las que se desenvolverán los enfrentamientos
del campeonato.
Descripción: El usuario selecciona la cancha y la asigna a un campeonato
aun no generado.
Precondiciones:
 Que el usuario se encuentre en la pantalla P014 “Asignar Cancha al
Campeonato”
Post condiciones:
 La cancha ha sido asignada.
1. El usuario se encuentra en la pantalla [P014: Asignar Cancha al
Campeonato].
2. El usuario selecciona la opción [Agregar Cancha] que se encuentran en la
pantalla [P014: Asignar Cancha al Campeonato].
3. El sistema presenta la pantalla [P014.1: Campeonatos y Canchas].
4. El usuario selecciona el Campeonato y la Cancha que se encuentran en la
pantalla [P014.1: Campeonatos y Canchas].
5. El usuario presiona la opción [GUARDAR] en la pantalla [P014.1:
Campeonatos y Canchas].
6. El Sistema asigna en la base de datos una cancha al Campeonato.
7. El caso de uso Finaliza.
187

MENSAJE DE AVISO.
A.5 El sistema presenta un mensaje de aviso indicando que la cancha
seleccionada, ya esta asignada al Campeonato.
Tabla 58Descripción del Caso de Uso: Asignar Cancha al Campeonato

Inscribir Equipo al Campeonato

Asignar Cancha al SI SI SI
Campeonato
Tabla 59Validación del Caso de Uso: Asignar Cancha al Campeonato

Inscribir Equipo al Campeonato
188
sd 1: Asignar Cancha al Campeonato
CASO DE USO: ASIGNAR CANCHA AL Cancha por Campeonato Cancha Dao

CAMPEONATO Campeonato Dao
1. El usuario se encuentra en la pantalla Dao
Usuario Secretario Principal Listado de Seleccione Campeonato Cancha Por Cancha Campeonato
[P014: Asignar Cancha al Canchas y Cancha Campeonato
Campeonato]. Campeonatos
[Agregar Cancha] que se encuentran elige Asignar Cancha al Campeonato()
en la pantalla [P014: Asignar Cancha
al Campeonato]. obtenerCanchaYCampeonato() :List
[P014.1: Campeonatos y Canchas].
4. El usuario selecciona el Campeonato presenta()
y la Cancha que se encuentran en la
pantalla [P014.1: Campeonatos y
Canchas]. elige btnAgregarCancha()
5. El usuario presiona la opción
[GUARDAR] en la pantalla [P014.1: obtenerCampeonatoNoGenerado() :List
Campeonatos y Canchas].
6. El Sistema asigna en la base de datos
una cancha al Campeonato. obtenerCanchas() :List

presenta()
A. MENSAJE DE AVISO.
elige campeonato()
aviso indicando que la cancha
seleccionada, ya esta asignada al
Campeonato. elige cancha()
del curso normal de eventos. elige guardar()
agregar(campeonato, cancha)
presenta()
(from Actores) 189
Fig. 76 Asignar Cancha al Campeonato

F.4.2.26. CASO DE USO: GENERAR EL CALENDARIO DEL CAMPEONATO
NOMBRE GENERAR EL CALENDARIO CÓDIGO C.U. CU026

C.U. DEL CAMPEONATO
Propósito:
 Facilitar al usuario la realización de las jornadas del campeonato
Descripción: El usuario selecciona el campeonato y automáticamente se
genera el calendario de compromisos.
Referencia al Requerimiento: RF016, RF017
Precondiciones:
 Que el usuario se encuentre en la pantalla P010 “Listado de
Campeonatos por iniciarse”
Post condiciones:
 El calendario del campeonato, ha sido generado.
8. El usuario se encuentra en la pantalla [P010: Listado de Campeonatos por
iniciarse].
9. El usuario selecciona la opción [GENERAR] que se encuentran en la
pantalla [P012: Listado de Campeonatos por iniciarse].
10. El sistema presenta la pantalla [P010.1: Generación de Campeonato].
11. El usuario selecciona la opción [PROCEDER CON LA GENERACION] que
se encuentran en la pantalla [P012.1: Generación de Campeonato].
12. El sistema presenta la pantalla [P010.2: Calendario del Campeonato].
13. El usuario selecciona la opción [GUARDAR GENERACION] que se
encuentran en la pantalla [P010.2: Calendario del Campeonato].
190
MENSAJE DE AVISO.
A.3 El sistema presenta un mensaje de aviso indicando que se ha generado
automáticamente la tabla de enfrentamientos entre los equipos
participantes.
Tabla 60 Descripción del Caso de Uso: Generar el Calendario del Campeonato

Generar el Calendario SI SI SI
del Campeonato
Tabla 61 Validación del Caso de Uso: Generar el Calendario del Campeonato
191
d 29: Generar el Sorteo del Campeonato
Campeonato Encuentro
CASO DE USO: GENERAR EL
CALENDARIO DEL CAMPEONATO Dao Dao
Usuario Secretario Principal Listado de Generacion de Calendario del Campeonato Encuentro
1. El usuario se encuentra en la Campeonatos Campeonatos Campeonato
pantalla [P012: Listado de
Campeonatos por iniciarse]. elige Generar Campeonato()
[GENERAR] que se encuentran en la obtenerCampeonatosNoGenerados() :List
pantalla [P012: Listado de
Campeonatos por iniciarse].
[P012.1: Generación de
Campeonato].
[PROCEDER CON LA GENERACION] elige btnGenerar()
que se encuentran en la pantalla obtenerCampeonato(string nombre) :Campeonato
[P012.1: Generación de
Campeonato]. presenta()
[P012.2: Calendario del
Campeonato].
elige btnGenerarCampeonato()
6. El usuario selecciona la opción generarCampeonato(Campeonto) :Vector
[GUARDAR GENERACION] que se
encuentran en la pantalla [P012.2:
Calendario del Campeonato].
(from Actores)
192
F.4.2.27. CASO DE USO: CAMBIAR CANCHA AL COMPROMISO
NOMBRE CU CAMBIAR CANCHA AL CÓDIGO CU CU027

COMPROMISO
Propósito:
 Asignar una nueva cancha a la jornada.
Descripción: El usuario elige una nueva cancha para el desarrollo de los
encuentros de una jornada de juego.
Referencia al Requerimiento:RF017
Precondiciones:
 El usuario haya entrado al sistema
 Se encuentre en la pantalla P014“CambiarCalendario”
Post condiciones:
 Se ha asignado la cancha a la jornada deportiva.
1. El usuario se encuentra en la pantalla [P014: Cambiar Calendario].
2. El usuario selecciona el link editar en la pantalla Cambiar Calendario].
3. Se presenta la pantalla [P014.1: Jornadas del Campeonato].
4. El sistema presenta las jornadas de juego del Campeonato antes
seleccionado.
5. El usuario elige el link [seleccionar] de la jornada a modificar de la pantalla
[P014.1: Jornadas del Campeonato].
6. El sistema presenta la pantalla [P014.2: Cambiar Cancha].
7. El usuario cambia la cancha
9. El sistema almacena en la Base de Datos la cancha de la jornada.
10. El caso de uso finaliza
Tabla 62 Descripción del Caso de Uso: Cambiar Cancha al Compromiso

193

Cambiar Fecha y SI SI SI
Escenario a la Jornada
Tabla 63 Validación del Caso de Uso: Cambiar Cancha al Compromiso
194
sd 2: Cambiar Fecha a la Jornada
Campeonato Fecha Encuentro

CASO DE USO: CAMBIAR FECHA Y Dao Juego Dao Dao
ESCENARIO A LA JORNADA
Usuario Secretario Principal Cambiar Fecha Jornadas del Cambiar Fecha y Campeonato Fecha Juego Encuentro
Campeonato Escenario
1. El usuario se encuentra en la
pantalla [P014: Cambiar Fecha y elige cambiar fecha()
Escenario a la Jornada].
2. El usuario selecciona el link buscar campeonatos generados() :List
cambiar fecha en la pantalla
[P014: Cambiar Fecha y Escenario
a la Jornada]. presenta()
3. Se presenta la pantalla [P014.1: Fig. 75Cambiar Fecha y Escenario a la Jornada
Jornadas del Campeonato].
4. El sistema presenta las jornadas
de juego del Campeonato antes elige cambiar fecha()
seleccionado. buscar fechas de juego(campeonato) :List
5. El usuario elige el link
[seleccionar] de la jornada a
modificar de la pantalla [P014:
Cambiar Fecha y Escenario a la
presenta()
Jornada].
[P014.2: Cambiar Fecha y elige seleccionar()
Escenario]. buscar ecuentros(fecha de juego) :List
7. El usuario cambia la fecha
8. El usuario cambia la cancha
[GUARDAR].
10. El sistema almacena en la Base presenta()
de Datos la nueva fecha y cancha
de la jornada.
cambia la fecha a la jornada de juego()
11. El caso de uso finaliza
cambia la cancha a los encuentro()
elige btnguardar()
asigna nueva fecha(fecha)
195
asigna nueva cancha()
(from Actores)
Fig. 78 Cambiar Cancha a un Compromiso
F.4.2.28. CASO DE USO: INGRESAR RESULTADOS
NOMBRE INGRESAR RESULTADOS CÓDIGO C.U. CU028

C.U.
Propósito:
 Registrar el resultado del enfrentamiento de un Campeonato
Actor:Usuario Secretario, Usuario Supervisor
Descripción:El usuario ingresa los datos requeridos para registrar el resultado
de un enfrentamiento.
Referencia al Requerimiento: RF018, RF019
Precondiciones:
 Que el usuario se encuentre en la pantalla P011 “Lista de
Campeonatos Activos”
Post condiciones:
 El resultado ha sido registrado.
1. El usuario elige la opción [INGRESAR] del listado de campeonatos dentro
de la pantalla [P011: Lista de Campeonatos Activos].
2. El sistema presenta la pantalla [P011.1: Listado de encuentro de la Fecha].
3. El usuario elige la opción [INGRESAR] del listado de enfrentamientos
dentro de la pantalla [P011.1: Listado de encuentro de la Fecha].
4. El sistema presenta la pantalla [P011.2: Encuentro].
5. El usuario ingresa cada uno de los datos que se solicitan para registrar el
marcador de un encuentro.
6. El usuario elige la opción [REGISTRAR RESULTADO] de la pantalla.
8. El sistema almacena toda la información actualizada en las tablas de la
base de datos.
196
9. El sistema presenta la pantalla [P011.1: Listado de encuentro de la Fecha]

con el encuentro registrado.
Tabla 64 Descripción del Caso de Uso: Ingresar Resultados

Ingresar Resultados SI SI SI
Tabla 65 Validación del Caso de Uso: Ingresar Resultados
197
d 31: Ingresar Resultados
Campeonato Encuentro Fecha Resultado

CASO DE USO: INGRESAR RESULTADOS Dao Dao Juego Dao Dao
1. El usuario elige [INGRESAR Usuario Supervisor Principal Listado de Listado de Encuentro Encuentro Campeonato Resultado
RESULTADO] de la pantalla [P001: Campeonatos Encuentros del
Principal]. Campeonato
elige Ingresar Resultado()
[P0011: Lista de Campeonatos obtenerCampeonatoGenerado() :List
Activos].
[INGRESAR] del listado de presenta()
campeonatos dentro de la pantalla
[P0011: Lista de Campeonatos
Activos].
4. El sistema presenta la pantalla elige linkIngresar ()
[P011.1: Listado de encuentro de la obtenerFechaNoJugada(Campeonato) :List
Fecha].
obtenerListaEcuentrosGrupos(int Fecha Juego) :List
[INGRESAR] del listado de
enfrentamientos dentro de la pantalla
[P011.1: Listado de encuentro de la
Fecha]. presenta()
[P011.2: Encuentro].
datos que se solicitan para registrar el elige linkIngresar()
marcador de un encuentro.
8. El usuario elige la opción obtenerEncuetroDeGrupo() :Encuentro
[REGISTRAR RESULTADO] de la
pantalla.
presenta()
completos todos los campos.
10. El sistema almacena toda la
información actualizada en las tablas
de la base de datos. ingresa datos()
elige btnRegistrarResultado()
valida campos()
guadar(Resultado)
198
(from Actores)
Fig. 79 Ingresar Resultados

F.5. DIAGRAMA DE CLASES FINAL

class Diagrama de Dominio
Persona Direccion
- apellido: String - calle: String

- cedula: String - celular: String
- fechaNacimiento: Date - telefono: String
- idPersona: String
- nacionalidad: String
- nombre: String
- sexo: Boolean
1
Jugador Superv isor
Secretario Arbitro Directiv o
1 - categoria: String - idSupervisor: int
- foto: byte - idSecretario: int - idArbitro: int - idDirectivo: int 1
- idJugador: int
1 1
AñoDeportiv o
1 - idAnioDeportivo: Int
- nombre: Date
puede moderar Disciplina

1..*
- idDisciplina: int
SistemaPuntuacion
- nombre: String
DignidadModeracion - idSistemaPuntuacion: int
1..* 1 1 - nombre: String
- dignidad: String 1 1
- idFuncionModeración: int - puntosDerrotaSinJugar: int
- puntosPorEmpate: int
- puntosPorPerdida: int
1 - puntosPorVictoria: int
se juega - puntosVictoriaSinJugar: int
1..* 1..*
Campeonato
1..* Equipo
- duracionCompromiso: int
1 -
fechaFin: Date - barrio: String
- fechaInicio: Date 1
- colorUniforme: String
FechaDeJuego - genero: String - escudo: byte
- idCampeonato: int - genero: Boolean
- fecha: Date
Suspencion 1 1 - nombre: String
- idFechaDeJuego: int - idEquipo: int
1..* 1 - numeroClasificadosPorGrupo: int - nombre: String
- idSuspencion: int
1 - numeroEquiposPorGrupo: int - sobrenombre: String
- tiempoSuspencion: String se usan 1
0..* - numeroGrupos: int
- tipo: String 1
1..* - numeroVueltas: int 1
TablaPosiciones 1 1
Jornadas 1..*
Representante
- idTablaPosiciones: int
- idJornada: int Resultado - idRepresentante: int
- nombre: String
- idResultado: int
1 1..*
1 ModeradorEncuentro 1
1
- idModerador: int 1 1 1 1..*

1..*
1 1..*
InscripcionEquipo
1..* Encuentro 1..*
Escenario - idInscripcionEquipo: int
- idEncuentro: int
- foto: byte 1
- idEscenario: int 1 1..*
- nombre: String 1
- ubicacion: String 1 1 1..*
1..*
InscripcionJugador
0..2 - idInscripcionJugador: int

1..*
Fig. 77Diagrama de Clases

NominaEncuentro
1..*
- idNominaEncuentro: int
1..* - titularidad: Boolean 1
Amonestacion 1
1..* 1 1..* 1..*
- idAmonestacion: int
1 - Anotacion
tipo: String
- idAnotacion: int
- puntos: int
Fig. 80 Diagrama de Clases Final
199
F.5.1. DIAGRAMA DE PAQUETES

class Vista general del proyecto
ProyectoFedelibal
Negocio
Modelo
Interfaz Seguridad DAO
Serv icio
Vista
Fragmentos Modelo
Pagina
200
Fig. 81 Diagrama de Paquetes
F.6. DIAGRAMA DE COMPONENTES
id Diagrama de Componentes
Negocio Vista (JSP)
Serializable Fragmentos
Fig. 82 Diagrama de Componentes
F.7. DIAGRAMA DE DESPLIEGUE
deployment Modelo de despliegue
Memoria Ram: 1GB Memoria Ram: 2GB min

Espacio en Disco 250 GB Espacio en Disco: 500 GB
Sistema Operativ o
Serv idor Web Apache Tomcat v 6.0.14

«Browser»
Cliente
Maquina Virtual
Nav egador Web:

Mozilla 3.0.6 o
superior JVM 1.6.0_03
BaseDatos: MySql v 5.0.19

Sistema Web para la
o superior
Gestion y Control de
Campeonatos Deportiv os
de las Disciplinas de
Futbol y Basquet,
Organizados por Firmas
FEDELIBAL
201
Fig. 83 Diagrama de Despliegue

F.8. PRUEBAS Y VALIDACIÓN
Las pruebas de validación del Sistema Web para la Gestión y Control de

Campeonatos Deportivos de las Disciplinas de Fútbol y Básquet,
organizados por FEDELIBAL, utilizando un Modelo Matemático para la
generación del calendario de enfrentamientos, se realizaron los días 2, 3,
4 y 5 de Mayo del 2011, y en dichas pruebas se distribuyó las
funcionalidades del sistema, de acuerdo a los roles de usuario y
secretario – administrador, definiendo lo siguiente: 2 administradores del
sistema y 6 usuarios respectivamente. El Secretario de Fedelibal y
principal encargado de la administración de los campeonatos, fue el
delegado a verificar que el proceso de validación se cumpla con eficacia
(Ver Anexo 4).
Cabe resaltar que las pruebas en el sistema se realizaron con el objeto

de que los usuarios, verifiquen el grado de funcionalidad y aceptación del
sistema (Ver Anexo 5). Para ello se efectuaron tres distribuciones en
dichas pruebas: Pruebas de Funcionalidad; Pruebas de Aceptación; y
Pruebas de Usabilidad.
F.8.1. TIPOS DE PRUEBA
F.8.1.1. Prueba de Funcionalidad
Son pruebas destinadas a comprobar que el sistema

cumpla con los requerimientos definidos inicialmente en
la etapa de análisis, verificando las funciones correctas o
ausentes tanto en la interfaz gráfica como en la base de
datos. Se evaluaron algunos procesos como:
 Creación de usuarios, jugadores, árbitros, equipos,

campeonatos, escenarios, canchas.
202
 Edición de usuarios, jugadores, árbitros, equipos,

 Eliminación de usuarios, jugadores, árbitros, equipos,
 Generación del calendario de enfrentamientos.
 Registro de las actas de juego.
 Generación de la tabla de posiciones.
 Inscripción de equipos y jugadores.
F.8.1.2. Prueba de Aceptación
Son las encargadas de verificar la funcionalidad de toda

la aplicación, y de comprobar el nivel de complacencia
que existe por parte de los usuarios y administrativos de
la Federación Deportiva de Ligas Barriales de Loja
(FEDELIBAL). Para ello, se aplicaron encuestas, cuyos
resultados mostraron que se cumple favorablemente con
todos los requerimientos planteados, llenando las
expectativas del usuario – administrador.
F.8.1.3. Prueba de Usabilidad
Son aquellas encargadas de la evaluación de la utilidad

y robustez del Sistema en lo concerniente a: Interfaz
Gráfica, Navegabilidad, Consultas, y Generación de
Reportes. Se utilizó un esquema de niveles para verificar
los resultados de las pruebas, el cual abarca los
siguientes ítems:
 Excelente
 MuyBueno
 Bueno
203
 Regular
Las funcionalidades a evaluar fueron las siguientes:
Para el administrador:
 Rapidez en el acceso
 Seguridad en el acceso
 Interfaz amigable
 Colores utilizados
 Tamaño y tipo de letra
 Información de ayuda
 Ingreso de datos
 Validación de datos
 Módulos de la aplicación
 Funcionalidades de cada módulo
 Búsqueda y organización de la información
 Rapidez en la Generación del Calendario de
Enfrentamientos
 Rapidez en la Generación de la Tabla de Posiciones
 Almacenamiento y recuperación de la información
 Listado y generación de reportes
Para el usuario:
 Rapidez en el acceso
 Interfaz amigable
 Colores utilizados
 Tamaño y tipo de letra
 Representación de resultados en tablas
 Información de ayuda
 Imágenes utilizadas en el sistema
204
 Información de Fedelibal
 Búsqueda de la información
 Organización de la información
 Lectura y almacenamiento de la información
F.8.2. RESULTADOS DE VALIDACIÓN
Luego de aplicar las encuestas, se procedió a tabular dichos

resultados (Ver Anexo 4 y 5), los cuales analizados de una manera
cuanti – cualitativa, nos permitieron calificar el nivel de aceptación
que tiene la aplicación. Los resultados de validación fueron:
205
Rango
Funcionalidad Excelente Muy Bueno Bueno Regular
1. Rapidez en el acceso - 2 - -
2. Seguridad en el acceso 2 - - -
3. Interfaz amigable 2 - - -
4. Colores utilizados 2 - - -
5. Tamaño y tipo de letra 2 - - -
6. Información de ayuda 1 1 - -
7. Ingreso de datos 2 - - -
8. Validación de datos 1 1 - -
9. Módulos de la aplicación 2 - - -
10. Funcionalidades de cada modulo 2 - - -
11. Búsqueda y organización de la información 2 - - -
12. Rapidez en la generación del Calendario de Enfrenta. 2 - - -
13. Rapidez en la generación de la Tabla de Posiciones 2 - - -
14. Almacenamiento y recuperación de la información 1 1 - -
15. Listado y generación de reportes 1 1 - -
TOTAL 24 6 - -
Tabla 66. Resultados de validación rol Administrador - Secretario
206
Rango
Funcionalidad Excelente Muy Bueno Bueno Regular
1. Rapidez en el acceso 2 4 - -
2. Interfaz amigable 5 1 - -
3. Colores utilizados 6 - - -
4. Tamaño y tipo de letra 3 3 - -
5. Representación de resultados en tablas 4 2 - -
6. Información de ayuda 3 2 1 -
7. Imágenes utilizadas en el sistema 4 2 - -
8. Información de Fedelibal 5 1 - -
9. Búsqueda de la información 2 3 1 -
10. Organización de la información 3 2 1 -
11. Lectura y almacenamiento de la información 3 3 - -
TOTAL 40 23 3 -
Tabla 67. Resultados de validación rol Usuario
207
Los resultados de las pruebas efectuadas al Sistema Web para la

Gestión y Control de las actividades deportivas de las disciplinas de
futbol y básquet, organizados por Fedelibal, en su mayoría estuvieron
valoradas en los niveles de Muy Bueno y Excelente, esto por parte
del administrador – secretario y los usuarios que fueron encuestados.
Vale resaltar que no existieron mayores novedades por parte de
quienes manipularon el sistema, pues nos comunicaron sentirse
cómodos con dicho Sistema Web, al cual lo calificaron de entendible
y fácil de operar.
F.8.3. CONTROL DE CALIDAD EN LA APLICACIÓN
Para lograr un Sistema eficiente y eficaz, es necesaria la utilización

de metodologías o procedimientos estándares para el Análisis de
Requisitos, Diseño Preliminar, Diseño e Implementación, de tal
manera que se logre una mayor confiabilidad, mantenimiento y
facilidad de prueba, a fin de realzar la productividad tanto en la fase
de desarrollo como en el control de calidad del Software.
Para determinar la calidad de nuestra aplicación, creímos

conveniente definir algunos parámetros que fueron modificados,
creados o eliminados; dichos parámetros elegidos para efectuar el
control de calidad, fueron considerados en base a cada modulo, y a la
interfaz grafica que rodea al sistema. En la siguiente tabla, se
muestra en detalle los aspectos mencionados anteriormente:
208
Nombre del Parámetro Anterior Parámetro Actual Observación

Módulo
Log In: Parámetro utilizado para que
cada usuario tenga acceso al sistema, de Iniciar Sesión Cambio de
acuerdo a su contraseña previamente nombre a
asignada. parámetro
Log Off: Parámetro utilizado para Cambio de
finalizar o cerrar una sesión de un usuario Cerrar Sesión nombre a
en el sistema. parámetro
Sistema Contador de intentos para ingresar al Parámetro nuevo
sistema
Indicio para recordar clave de acceso al Parámetro nuevo
sistema
Verificador de acceso al sistema, que evite
que un mismo usuario pueda logearse más Parámetro nuevo
de una vez al mismo tiempo
Us: Parámetro utilizado para identificar a Usuario Cambio de
cada usuario que ha iniciado sesión nombre a
parámetro
209
Validador de cada campo, que permita Parámetro nuevo

saber cuándo un dato es correcto o
incorrecto
Cuenta Se añadió un * a cada campo requerido Parámetro nuevo
Usuario Cancelar: Parámetro utilizado para salir
de la página e ingresar a una nueva Eliminado
Estado de usuario: El estado del usuario Ningún usuario
puede modificarse a inactivo, en caso de es eliminado de
ausencia temporal en el sistema y activo si la aplicación
todavía forma parte del mismo
Validador de cada campo que permita
saber cuándo un dato es correcto o Parámetro nuevo
incorrecto
Se añadió un * a cada campo requerido Parámetro nuevo
Jugador Cancelar: parámetro utilizado para salir
de la página e ingresar a una nueva. Eliminado
Opción para elegir una plantilla y sea Parámetro nuevo
asignada a la categoría seleccionada
210

incorrecto
Equipo Cancelar: parámetro utilizado para salir
incorrecto
Árbitro Cancelar: parámetro utilizado para salir
incorrecto
211
Escenario Cancelar: parámetro utilizado para salir

incorrecto
Cancha Cancelar: parámetro utilizado para salir
incorrecto
Campeonato Se añadió un * a cada campo requerido Parámetro nuevo
Cancelar: parámetro utilizado para salir
212

Cancelar: parámetro utilizado para salir Eliminado
de la página e ingresar a una nueva.
Inscripción Elegir equipos almacenados en el sistema
de Equipo Descripción en cada parámetro que se Módulo Nuevo
pueda editar
Generación Cancelar: parámetro utilizado para salir Eliminado
del de la página e ingresar a una nueva. Módulo Nuevo
Calendario
Establecer de la página e ingresar a una nueva. Módulo Nuevo
Fecha Elegir fechas almacenadas en el sistema
de la página e ingresar a una nueva.
Guardar: parámetro que permite guardar Parámetro nuevo
Ingresar los resultados que se encuentran en
Resultados edición
213
incorrecto
Validador de fechas: La fecha inicial no Módulo Nuevo
puede ser mayor a la final y viceversa
Los reportes se
Reporte generarán tanto
Generación de reportes gráficos en forma escrita
como en forma
gráfica
Generación de archivos log’s Parámetro nuevo
Interfaz Menú: Usuarios, Jugador, Equipo, Árbitro, Menú Archivo: Función para acceder a
Escenario, Cancha, Campeonato, Usuarios, Jugador, Equipo, Árbitro,
Generación del Calendario, Establecer Escenario, Cancha, Campeonato, Interfaz Menú
Fecha, Ingresar Resultados, Reportes Generación del Calendario, Establecer Principal
Fecha, Ingresar Resultados, Reportes
Tabla 68 Control de Calidad
214
G. CONCLUSIONES
 El análisis realizado en las actividades de la gestión y control de campeonatos

organizados por FEDELIBAL, nos permitió recolectar toda la información
necesaria y determinar que éstas se tornan largas y tediosas, por la gran
cantidad de equipos participantes, lo que hace preponderante la automatización
de los procesos, para que se realicen de forma organizada, rápida y confiable.
 El modelo matemático utilizado para la generación automática del calendario de

juegos, consiste en la fusión del algoritmo Round Robin para la primera fase, y el
campeonato de simple eliminación para la segunda fase, permitiendo un ahorro
significativo de recursos.
 El Sistema Web, permite administrar toda la información que se genera en el

desarrollo de los campeonatos de fútbol y básquet de una manera rápida y
eficaz, constituyéndose en un avance tecnológico para las instituciones
deportivas del siglo XXI.
 La construcción e implementación del Sistema Web, se realizó utilizando una

tecnología que simplifica el desarrollo de interfaces de usuario en aplicaciones
Java como lo es JavaServer Faces que además facilita la tarea de construcción y
mantenimiento de Aplicaciones Web, así mismo las facilidades que brinda el IDE
NetBeans en Aplicaciones Web permitió disminuir considerablemente los costos
y el tiempo de desarrollo.
 Las pruebas de validación efectuadas para comprobar el grado de

funcionamiento, aceptabilidad, usabilidad y robustez del sistema, nos permitieron
confirmar que la Aplicación Web cumple con todos los requerimientos del usuario
y que está funcionando de manera eficiente.
215
 La construcción de este proyecto abre las puertas a los estudiantes de la carrera

de Ingeniería en Sistemas, para continuar la investigación en el área de
planificación de fixtures deportivos, pues constituye una base sobre la cual, se
pueden agregar más restricciones y conseguir mejores resultados.
216
H.RECOMENDACIONES
 A los administrativos de FEDELIBAL, utilizar el presente proyecto para el

desarrollo de sus actividades, ya que esta herramienta brinda muchas ventajas
en la gestión y control de los campeonatos deportivos, y, además cuenta con
una interfaz amigable y dinámica.
 Definir en forma apropiada los roles de usuario, para acceder al sistema web,
esto con la finalidad de no tener cambios en la información administrada.
 Almacenar periódicamente respaldos de la información en dispositivos seguros

y en formatos comprimidos, con la finalidad de evitar la pérdida de la
información y optimizar el espacio en el equipo servidor.
 Leer el manual de usuario y del programador ya que son documentos

necesarios para aprovechar en un 100% las funcionalidades del sistema, para
darle un buen mantenimiento y para una posterior ampliación.
 Realizar las pruebas de validación, esto asegurará la entrega de un sistema de

calidad, que optimiza procesos, brinda una información confiable y cubre con
todas las necesidades del usuario.
 A los estudiantes de la carrera de Ingeniería en Sistemas de la Universidad

Nacional de Loja, les recomendamos utilizar los algoritmos empleados en la
generación del calendario de juegos, para futuras investigaciones de
construcción de fixtures deportivos, pues son los más usuales, y logran dar
mayor interés al desarrollo de un campeonato.
217
I. BIBLIOGRAFIA
LIBROS
 CÁCERES L., René. Administrador de Campeonatos Deportivos. 2005.

Santiago, Chile, Universidad Católica. Fac. de Ing. Sistemas. 11p.
 CASTEJÓN GARRIDO, JUAN SALVADOR.2004. Arquitectura y Diseño de
Sistemas Web Modernos. Revista de Ingeniería Informática del CIIRM Dep.
Legal: MU-2419-2004 ISSN: 1698-8841.
 DURÁN, Guillermo. FÚTBOL, MODELOS MATEMÁTICOS Y SUÁFRICA 2010.
2006. Santiago, Chile, Departamento de Ingeniería Industrial, Universidad de
Chile. 30p.
 HERNÁNDEZ HERNÁNDEZ, Enrique (2000). Auditoría en Informática. México
México DF. Editorial McGraw-Hill. 150p.
 LEIVA ZEA, Francisco (1980). Investigación Científica. 2ª. ed. Quito Ecuador,
Tipoffset “Ortiz”,96p.
 LEY DE CULTURA FÍSICA, DEPORTES Y RECREACIÓN, Registro Oficial 79
del 10 de Agosto del 2010. Ecuador, Quito, 20 de Octubre de 2010. [Consulta:
10 de Noviembre de 2010]
 MCCONNEL, Steve (1997). Desarrollo y Gestión de Proyectos Informáticos.
Madrid España. Editorial McGraw-Hill, 150p.
 PRESUMAN, Roger S. (1999). Ingeniería del Software, Un Enfoque Práctico. 4ª.
ed. Madrid España. McGraw Hill/Interamericana de España, 200p.
 STEWART, James. "Cálculo, Trascendentes Tempranas". 4 ed. Tr. de Andrés
Sestier. México, Ed. Thomson, 2002. p. 1151
 TAMAYO TAMAYO, Mario. El Proceso de Investigación Científica. Madrid
España. Editorial Limusa, 98p.
 WHITTEN, Jeffrey L. (1998). Análisis y Diseño de Sistemas de Información. 3ª.
ed. Bogotá Colombia. Editorial Mc Graw Hill, 250p.
218
SITIOS WEB:
 ASOCIACIÓN DEPORTE Y CIENCIA. 2004 [en línea]. Cómo organizar

campeonatos deportivos. DeporteyCiencia.com. [http://www.Deporteyciencia
Cómo organizar campeonatos deportivos.htm], [Consulta: 05 de Marzo de
2010].
 WIKIPEDIA, (2010) JavaServer Faces [en línea] Disponible en:
http://www.es.wikipedia.org/wiki/JavaServer_Faces [Consulta: 12 de Enero de
2010].
 WIKIPEDIA, (2010) Modelo Vista Controlador [en línea] Disponible en:
http://www.es.wikipedia.org/wiki/Modelo_Vista_Controlador [Consulta: 12 de
Enero de 2010].
 WIKIPEDIA, (2010) Servidores Web [en línea] Disponible en:
http://www.es.wikipedia.org/wiki/Servidor_web [Consulta: 11 de Enero de 2010].
 FEDENALIGAS, (2010) [en línea] Disponible en:
http://www.fedenaligas.org/textocat.php, [Consulta: 22 de Febrero de 2010].
 BALONCESTO. 2001 [en línea]. Reglas Básicas del Baloncesto.
RincondelVago.com [http://www.Reglas básicas del Baloncesto.htm], [Consulta:
23 de Febrero de 2010].
 EDUCACIÓN FÍSICA.DEPORTE. 2001 [en línea]. Reglas Básicas del Fútbol.
RincondelVago.com [http://www.Reglas básicas del fútbol.htm], [Consulta: 23 de
Febrero de 2010].
 TÉCNICAS DE INVESTIGACIÓN. 2006-2010[en línea].Técnicas de
Investigación.com [http://www.rrppnet.com.ar/tecnicasdeinvestigacion.htm],
[Consulta: 10 de Enero de 2010].
 JAVASERVER FACES, (2010) [en línea] Disponible
en:http://www.sicuma.uma.es/sicuma/Formacion/documentacion/JSF.pdf[Consul
ta: 12 de Enero de 2010].
219
ANEXO 1:

Área de la Energía , las Industrias y los Recursos Naturales no
Renovables
Nivel de Pre-Grado
Carrera de Ingeniería en Sistemas
GUÍA DE ENTREVISTA SEMIESTRUCTURADA QUE SERÁ APLICADA

AL PERSONAL ADMINISTRATIVO DE LA FEDERACION DEPORTIVA
DE LIGAS BARRIALES DE LOJA (FEDELIBAL)
1. PRESENTACIÓN
En nuestra calidad de egresados de la Carrera de Ingeniería en
Sistemas, perteneciente al Área de la Energía, las Industrias y los
Recursos Naturales no Renovables de la Universidad Nacional de Loja;
solicitamos a Usted de la manera más comedida, se digne responder
alas siguientesinterrogantes con la finalidad de obtener información
relacionada con el proceso de Gestión y Control de los Campeonatos
Deportivos, en las disciplinas de Fútbol y Básquet, que se llevan a cabo
en la institución.
2. INFORMACION ESPECÍFICA
2.1. El proceso de Gestión y Control de los Campeonatos

Deportivos en las disciplinas de Fútbol y Básquet, se llevan a
cabo de forma:
Manual ( ) Automática ( )
220
2.2. ¿Cuántos Campeonatos de Fútbol y Básquet, organiza

FEDELIBAL, durante el transcurso del año?
……………………………………………………………………………
……………………………………………………………………………
2.3. ¿Aproximadamente, cuantos equipos se inscriben en un

Campeonato de Fútbol?
……………………………………………………………………………
……………………………………………………………………………
2.4. ¿Aproximadamente, cuantos equipos se inscriben en un

Campeonato de Básquet?
……………………………………………………………………………
……………………………………………………………………………
2.5. ¿Con cuántos escenarios trabaja FEDELIBAL, para realizar

los Campeonatos de Fútbol?
……………………………………………………………………………
……………………………………………………………………………
2.6. ¿Con cuántos escenarios trabaja FEDELIBAL, para realizar

los Campeonatos de Básquet?
……………………………………………………………………………
……………………………………………………………………………
2.7. ¿Cuál es el modelo o esquema que utilizan para la

generación del calendario de juegos?
……………………………………………………………………………
……………………………………………………………………………
221
………………………………………………………………………
…….
2.8. ¿Qué días de la semana se realizan los compromisos?
……………………………………………………………………………
……………………………………………………………………………
2.9. ¿Qué medio de comunicación utilizan en FEDELIBAL para

difundir a los equipos, la próxima fecha a disputarse los
partidos?
……………………………………………………………………………
……………………………………………………………………………
2.10. ¿Existen inconvenientes durante la organización y ejecución

de Campeonatos Deportivos? ¿Indique cuáles son estos
inconvenientes?
……………………………………………………………………………
……………………………………………………………………………
……………………………………………………………………………
2.11. Se le dificulta llevar el archivo de los campeonatos

Disputados?
……………………………………………………………………………
……………………………………………………………………………
……………………………………………………………………………
2.12. Actualmente cuentan con el servicio de Pagina Web, o un

Sistema Informático para realizar actividades de la
Institución?
SI ( ) NO ( )
222
Gracias por su colaboración

ANEXO 2:

Renovables
Nivel de Pre-Grado
GUÍA DE ENCUESTA SEMIESTRUCTURADA QUE SERÁ APLICADA

AL PERSONAL ADMINISTRATIVO (SECRETARIO -
ADMINISTRADOR) DE LA FEDERACION DEPORTIVA DE LIGAS
BARRIALES DE LOJA (FEDELIBAL), RESPECTO DEL SISTEMA DE
GESTION Y CONTROL DE CAMPEONATOS
1. PRESENTACIÓN
solicitamos a Usted de la manera más comedida, se digne responder al
siguiente cuestionario, con la finalidad de obtener información
relacionada con el funcionamiento y validación del Sistema de Gestión y
Control de los Campeonatos Deportivos, en las disciplinas de Fútbol y
Básquet, que se llevan a cabo en la institución.
223
2.1. ¿Considera que la rapidez, al ingresar al sistema es?

Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.2. ¿Cómo considera la seguridad que presta el Sistema para el

ingreso?
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.3. Considera que el ambiente de trabajo del Sistema es:

Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.4. ¿Cuál es su opinión respecto a los colores, tamaño y tipo de

letra, utilizados en el Sistema?
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.5. ¿Cuál es su criterio respecto a las pautas que el Sistema le

ofrece para que pueda utilizarlo?
Excelente ( )
Muy Bueno ( )
224
Bueno ( )
Regular ( )
2.6. ¿Cree Usted que la información relacionada con FEDELIBAL

es?
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.7. ¿Cuándo busca información/documentos, considera que el

resultado es?
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.8. ¿Cómo considera el proceso de almacenamiento y

recuperación de la información del Sistema?
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.9. ¿Considera que la rapidez en la Generación del Calendario

de Enfrentamientos es?
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
225
2.10. ¿Considera que larapidez en la Generación de Tabla de

Posiciones es?
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.11. ¿Cómo considera la información obtenida de los resultados

de los compromisos?
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.12. ¿Cómo considera el proceso de inscripción de equipos y
jugadores al Campeonato?
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.13. ¿Considera que el proceso de suspensión de los jugadores

es?
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.14. ¿Considera que el proceso de cambio de canchas de una

fecha es?
226
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.15. ¿Considera que el proceso de cambio de fecha de una

jornada de juego es?
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
227
ANEXO 3:

Renovables
Nivel de Pre-Grado
GUÍA DE ENCUESTA SEMIESTRUCTURADA QUE SERÁ APLICADA

A LOS USUARIOS DEL SISTEMA DE GESTION Y CONTROL DE
CAMPEONATOS DE FÚTBOL Y BASQUET, ORGANIZADOS POR
FEDELIBAL
1. PRESENTACIÓN
solicitamos a Usted de la manera más comedida, se digne responder al
siguiente cuestionario, con la finalidad de obtener información
relacionada con el funcionamiento y validación del Sistema de Gestión y
Control de los Campeonatos Deportivos, en las disciplinas de Fútbol y
Básquet, que se llevan a cabo en FEDELIBAL.
2.1. ¿Considera que la rapidez, al ingresar al sistema es?

Excelente ( )
228
Muy Bueno ( )
Bueno ( )
Regular ( )
2.2. Considera que el ambiente de trabajo del Sistema es:

Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.3. ¿Cuál es su opinión respecto a los colores, tamaño y tipo de

letra, utilizados en el Sistema?
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.4. ¿Cuál es su opinión respecto a las imágenes utilizadas en el

Sistema?
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.5. ¿Cuál es su criterio respecto a las pautas que el Sistema le

Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
229
2.6. ¿Cree Usted que la información relacionada con FEDELIBAL

es?
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.7. ¿Cuándo busca información/documentos, considera que el

resultado es?
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
2.8. ¿Cómo considera la información obtenida de los resultados

de los compromisos?
Excelente ( )
Muy Bueno ( )
Bueno ( )
Regular ( )
230
231
ANEXO 4:
ANÁLISIS Y DISCUSIÓN DE RESULTADOS
Análisis Cuanti-Cualitativo de los Resultados del

Cuestionario Aplicado al Secretario y Administrador de FEDELIBAL,
respecto del Sistema de Gestión y Control de Campeonatos
organizados por dicha institución.
DATOS INFORMATIVOS.
¿Considera que la rapidez, al ingresar al sistema es?
CUADRO1
ASPECTOS FRECUENCIA %
Excelente 0 0
Muy Bueno 2 100
Bueno 0 0
Regular 0 0
TOTAL 2 100%
Fuente: Encuesta aplicada a los administrativos de FEDELIBAL
Responsables: Lucía Figueroa y Pablo Castillo
232
GRÁFICO1
100%
90%
80%
70%
60%
50% %
40%
30%
20%
10%
0%
Excelente Muy Bueno Bueno Regular
ANÁLISIS CUANTITATIVO:
Del universo encuestado en la parte administrativa de la

Federación Deportiva de Ligas Barriales de Loja (FEDELIBAL), 2
personas, que corresponde al 100%, indican que la rapidez al
ingresar al Sistema es “Muy Buena”
ANÁLISIS CUALITATIVO:
Podemos observar que tanto el Secretario como el Administrador

de FEDELIBAL, sienten que el ingreso al Sistema de Gestión y
Control de Campeonatos Deportivos de las Disciplinas de Fútbol
y Básquet, tiene una muy buena rapidez, lo que es satisfactorio
para la aplicación.
233
¿Cómo considera la seguridad que presta el Sistema para el

ingreso?
CUADRO2
Excelente 2 100
Muy Bueno 0 0
Bueno 0 0
Regular 0 0
TOTAL 2 100%
GRÁFICO2
100
90
80
70
60
50 %
40
30
20
10
0
234
Del universo encuestado, 2 personas que corresponde al 100%,

indican que la Seguridad que presenta el Sistema al ingresar, es
“Excelente”

de FEDELIBAL, sienten que las Seguridades prestadas por el
Sistema al momento de ingresar, son bastante aceptables, por lo
que las califican de excelentes.
Considera que el ambiente de trabajo del Sistema es:
CUADRO3
Excelente 2 100
Muy Bueno 0 0
Bueno 0 0
Regular 0 0
TOTAL 2 100%
235
GRÁFICO3
100
90
80
70
60
50 %
40
30
20
10
0
Del universo encuestado, dos personas, que corresponde al

100%, indican que el ambiente de trabajo del Sistema es
“Excelente”

de FEDELIBAL, sienten que el ambiente de trabajo del Sistema
de Gestión y Control de Campeonatos Deportivos de las
Disciplinas de Fútbol y Básquet, es óptimo, estableciendo
además que la interfaz de usuario es amigable.
236
¿Cuál es su opinión respecto a los colores, tamaño y tipo de letra,

utilizados en el Sistema?
CUADRO4
Excelente 2 100
Muy Bueno 0 0
Bueno 0 0
Regular 0 0
TOTAL 2 100%
GRÁFICO4
100
90
80
70
60
50 %
40
30
20
10
0
237

Federación Deportiva de Ligas Barriales de Loja (FEDELIBAL),
dos personas, que corresponde al 100%, indican que los colores,
tamaño y tipo de letra, utilizados en el Sistema son “Excelentes”

de FEDELIBAL, opinan que los colores, tamaño y tipo de letra
utilizados en el Sistema de Gestión y Control de Campeonatos
Deportivos de las Disciplinas de Fútbol y Básquet, son
adecuados, y embellecen aun más la aplicación.
¿Cuál es su criterio respecto a las pautas que el Sistema le

CUADRO5
Excelente 1 50
Muy Bueno 1 50
Bueno 0 0
Regular 0 0
TOTAL 2 100%
238
GRÁFICO5
50
45
40
35
30
25 %
20
15
10
5
0

una persona, que corresponde al 50%, indica que las pautas que
el Sistema ofrece para poder utilizarlo es “Excelente”, y una
persona que corresponde al 50% opina que es “Muy Bueno”.
Podemos observar que respecto a las pautas que el Sistema

ofrece para poder utilizarlo, concurren criterios de que podrían
constar ayudas más detalladas. Mientras también se opina que
dichas pautas son las propicias.
239
¿Cree Usted que la información relacionada con FEDELIBAL es?
CUADRO6
Excelente 1 50
Muy Bueno 1 50
Bueno 0 0
Regular 0 0
TOTAL 2 100%
GRÁFICO6
50
45
40
35
30
25 %
20
15
10
5
0
240

una persona, que corresponde al 50%, indica que la información
de la institución en el Sistema es “Excelente”, y una persona que
corresponde al 50% opina que es “Muy Buena”.
En lo concerniente a la información que el Sistema presenta de la

uno de los administrativos opina que lo referente a la institución
dentro de la aplicación es apropiado, mientras el otro opina que
dicha información podría ser más detallada.
¿Cuando busca información/documentos, considera que el

resultado es?
CUADRO7
Excelente 2 100
Muy Bueno 0 0
Bueno 0 0
Regular 0 0
TOTAL 2 100%
241
GRÁFICO7
100
90
80
70
60
50 %
40
30
20
10
0

dos personas, que corresponde al 100%, indican que la búsqueda
de información y/o documentos es “Excelente”.

de FEDELIBAL, sienten que la búsqueda de información y/o
documentos en el Sistema de Gestión y Control de Campeonatos
Deportivos de las Disciplinas de Fútbol y Básquet, es muy óptima.
242
¿Cómo considera el proceso de almacenamiento y recuperación

de la información del Sistema?
CUADRO8
Excelente 1 50
Muy Bueno 1 50
Bueno 0 0
Regular 0 0
TOTAL 2 100%
GRÁFICO8
50
45
40
35
30
25 %
20
15
10
5
0

243
una persona, que corresponde al 50%, considera que el proceso

de almacenamiento y recuperación de la información del Sistema
es “Excelente”, mientras una persona, equivalente al 50% indica
que es “Muy Bueno”

de FEDELIBAL, están satisfechos con el proceso de archivo y
recuperación de la información del Sistema pues nos supieron
indicar que el proceso de almacenamiento es óptimo y llenó sus
intereses.
¿Considera que la rapidez en la Generación del Calendario de

Enfrentamientos es?
CUADRO9
Excelente 2 100
Muy Bueno 0 0
Bueno 0 0
Regular 0 0
TOTAL 2 100%
244
GRÁFICO9
100
90
80
70
60
50 %
40
30
20
10
0

dos personas, que corresponde al 100%, indican que la rapidez
en la Generación del Calendario de Enfrentamientos es
“Excelente”.

de FEDELIBAL, sienten que la Generación del Calendario de
Enfrentamientos dentro del Sistema de Gestión y Control de
tiene una muy buena rapidez, pues los datos se obtuvieron de
inmediato.
245
¿Considera que la rapidez en la Generación de Tabla de

Posiciones es?
CUADRO10
Excelente 2 100
Muy Bueno 0 0
Bueno 0 0
Regular 0 0
TOTAL 2 100%
GRÁFICO10
100
90
80
70
60
50 %
40
30
20
10
0

246
dos personas, que corresponde al 100%, indican que la rapidez

en la Generación de la Tabla de Posiciones es “Excelente”.

de FEDELIBAL, sienten que la Generación de la Tabla de
Posiciones en el Sistema de Gestión y Control de Campeonatos
Deportivos de las Disciplinas de Fútbol y Básquet, tiene una muy
buena rapidez, y presenta los datos precisos.
¿Cómo considera la información obtenida de los resultados de los

compromisos?
CUADRO11
Excelente 1 50
Muy Bueno 1 50
Bueno 0 0
Regular 0 0
TOTAL 2 100%
GRÁFICO11
247
50
45
40
35
30
25 %
20
15
10
5
0

una persona, que corresponde al 50%, considera que la
información obtenida de los resultados de los compromisos es
“Excelente”, mientras una persona, que corresponde al 50%
señala que es “Muy Buena”

de FEDELIBAL, consideran que los datos que el Sistema de
Gestión y Control de Campeonatos Deportivos, de las Disciplinas
de Fútbol y Básquet presenta respecto a los resultados de los
enfrentamientos son muy aceptables.
248
¿Cómo considera el proceso de inscripción de equipos y

jugadores al Campeonato?
CUADRO12
Excelente 2 100
Muy Bueno 0 0
Bueno 0 0
Regular 0 0
TOTAL 2 100%
GRÁFICO12
100
90
80
70
60
50 %
40
30
20
10
0
249

dos personas, que corresponde al 100%, indican que el proceso
de inscripción de equipos y jugadores al Campeonato dentro del
Sistema es “Excelente”.

de FEDELIBAL, están conformes con el proceso de Inscripción de
equipos y jugadores al Campeonato, dentro del Sistema de
Gestión y Control de Campeonatos Deportivos de las Disciplinas
de Fútbol y Básquet, pues señalan que se lo realiza de una
manera ordenada.
¿Considera que el proceso de suspensión de los jugadores es?
CUADRO13
Excelente 2 100
Muy Bueno 0 0
Bueno 0 0
Regular 0 0
TOTAL 2 100%
250
GRÁFICO13
100
90
80
70
60
50 %
40
30
20
10
0

de suspensión de los jugadores es “Muy Bueno”

de FEDELIBAL, indican que el proceso de suspensión de los
jugadores dentro del Sistema de Gestión y Control de
incluye los parámetros necesarios, y por tal motivo están
conformes con dicho proceso.
251
¿Considera que el proceso de cambio de canchas de una fecha

es?
CUADRO14
Excelente 2 100
Muy Bueno 0 0
Bueno 0 0
Regular 0 0
TOTAL 2 100%
GRÁFICO14
100
90
80
70
60
50 %
40
30
20
10
0

252

de cambio de canchas de una fecha es “Excelente”

de FEDELIBAL, sienten que el proceso de cambio de canchas de
una fecha, en el Sistema de Gestión y Control de Campeonatos
Deportivos de las Disciplinas de Fútbol y Básquet, está acorde a
las necesidades o requerimientos del usuario, pues nos
manifestaron que se están considerando los parámetros
adecuados y es entendible.
¿Considera que el proceso de cambio de fecha de una jornada de

juego es?
CUADRO15
Excelente 2 100
Muy Bueno 0 0
Bueno 0 0
Regular 0 0
TOTAL 2 100%
253
GRÁFICO15
100
90
80
70
60
50 %
40
30
20
10
0

de cambio de fecha de una jornada de juego en el Sistema es
“Excelente”.

de FEDELIBAL, sienten que el proceso de cambio de fecha de
una jornada de juego dentro del Sistema de Gestión y Control de
al igual que el proceso anterior, se han desarrollado de una
manera apropiada, pues resultan aplicaciones útiles y sencillas
que atienden las necesidades del Sistema.
254
ANEXO 5:
ANÁLISIS Y DISCUSIÓN DE RESULTADOS
Análisis Cuanti-Cualitativo de los Resultados del

Cuestionario Aplicado a los Usuarios del Sistema de Gestión y Control
de Campeonatos de Fútbol y Básquet organizados por FEDELIBAL.
DATOS INFORMATIVOS.
¿Considera que la rapidez, al ingresar al sistema es?
CUADRO17
Excelente 2 33.3
Muy Bueno 4 66.7
Bueno 0 0
Regular 0 0
TOTAL 6 100%
Fuente: Encuesta aplicada a los usuarios del Sistema
255
GRÁFICO17
70
60
50
40
%
30
20
10
0
Nuestro universo está conformado por seis usuarios del Sistema,

de los cuales, 2 encuestados, que corresponde al 33.3%, indican
que la rapidez al ingresar al Sistema es “Excelente”, mientras 4
personas que corresponde al 66.7% indican que es “Muy Buena”.
Podemos observar que algo más de la mitad de los usuarios del

Sistema de Gestión y Control de Campeonatos Deportivos de las
Disciplinas de Fútbol y Básquet, indican que la rapidez al ingresar
al Sistema es bastante aceptable, mientras una menor cantidad
256
de usuarios, mencionan que a su parecer, la rapidez es

excelente.
Considera que el ambiente de trabajo del Sistema es:
CUADRO18
Excelente 5 83.3
Muy Bueno 1 16.7
Bueno 0 0
Regular 0 0
TOTAL 6 100%
GRÁFICO18
90
80
70
60
50
%
40
30
20
10
0
257
Nuestro universo, conformado por seis usuarios del Sistema,

supieron manifestar, respecto al ambiente de trabajo de la
aplicación, que es “Excelente” 5 encuestados, correspondiente al
83.3%; mientras 1 persona que corresponde al 16.7% indica que
es “Muy Bueno”
Podemos observar que casi la totalidad de encuestados

observaron una interfaz amigable, con la que es fácil interactuar;
mientras en un mínimo porcentaje, lo catalogaron al Sistema de
de Fútbol y Básquet, como aceptable.
¿Cuál es su opinión respecto a los colores, tamaño y tipo de letra,

utilizados en el Sistema?
CUADRO19
Excelente 6 100
Muy Bueno 0 0
Bueno 0 0
Regular 0 0
TOTAL 6 100%
258
GRÁFICO19
100
90
80
70
60
50 %
40
30
20
10
0
De nuestro universo encuestado, 6 personas, que corresponde al

100%, indican que los colores, tamaño y tipo de letra utilizados en
el Sistema son “Excelentes”.
Podemos observar que la totalidad de usuarios del Sistema de

de Fútbol y Básquet, coincidieron en valorar la aplicación como
apropiada tanto en los colores, tamaño y tipo de letra.
259
¿Cuál es su opinión respecto a las imágenes utilizadas en el

Sistema?
CUADRO20
Excelente 4 66.7
Muy Bueno 2 33.3
Bueno 0 0
Regular 0 0
TOTAL 6 100%
GRÁFICO20
70
60
50
40
%
30
20
10
0
De nuestro universo encuestado, 4 usuarios, que corresponde al

66.7%, indican que las imágenes utilizadas en el Sistema son
260
“Excelentes”, mientras 2 personas que corresponde al 33.3%

indican que son “Muy Buenas”.
Podemos observar que una gran cantidad de usuarios están

conformes con las imágenes presentadas en el Sistema de
de Fútbol y Básquet, pues opinan que embellecen la página;
mientras en un porcentaje menor a la mitad indicaron que las
imágenes son aceptables, pero podrían agregarse más.
¿Cuál es su criterio respecto a las pautas que el Sistema le

CUADRO21
Excelente 3 50
Muy Bueno 2 33.3
Bueno 1 16.7
Regular 0 0
TOTAL 6 100%
261
GRÁFICO21
50
45
40
35
30
25 %
20
15
10
5
0

50%, indican que las pautas que el Sistema ofrece para poder
utilizarlo son “Excelentes”, 2 usuarios que corresponde al 33.3%
piensan que son “Muy Buenas”, mientras 1 persona que
corresponde al 16.7% indica que son “Buenas”.
Podemos observar que la mitad de los encuestados perciben que

las ayudas del Sistema son las más apropiadas; en una menor
cantidad piensan que podrían ofrecerse mayores pautas para
poder utilizar el Sistema, mientras un mínimo número de usuarios
no se sienten conformes totalmente con las ayudas que ofrece el
262
Disciplinas de Fútbol y Básquet, pues indican que se podría

detallar en más contextos.
¿Cree Usted que la información relacionada con FEDELIBAL es?
CUADRO22
Excelente 5 83.3
Muy Bueno 1 16.7
Bueno 0 0
Regular 0 0
TOTAL 6 100%
GRÁFICO22
90
80
70
60
50
%
40
30
20
10
0
263

50%, indican que la información que el Sistema presenta sobre
FEDELIBAL es “Excelente”, mientras 1 persona que corresponde
al 16.7% indica que es “Muy Buena”.
Podemos observar que casi la totalidad de los usuarios del

Disciplinas de Fútbol y Básquet, opinan que existe la información
suficiente de la institución, mientras en una mínima cantidad nos
indicaron que se podrían agregar más datos de FEDELIBAL.
¿Cuándo busca información/documentos, considera que el

resultado es?
CUADRO23
Excelente 2 33.3
Muy Bueno 3 50
Bueno 1 16.7
Regular 0 0
TOTAL 6 100%
264
GRÁFICO23
50
45
40
35
30
25 %
20
15
10
5
0
De nuestro universo encuestado; 2 personas, que corresponde al

33.3%, indican que al buscar información o documentos en el
Sistema, los resultados son “Excelentes”; 3 encuestados que
corresponde al 50% indican que son “Muy Buenos”, mientras 1
persona que corresponde al 16.7% establece que son “Buenos”.
Podemos observar que la mitad de los usuarios encuestados nos

manifestaron que la búsqueda de información en el Sistema de
de Fútbol y Básquet, es aceptable. En una mínima cantidad
indicaron que podría ser más rápida, mientras algo menos de la
265
mitad de los encuestados, manifestaron sentirse conformes con

las búsquedas que ofrece el Sistema.
¿Cómo considera la información obtenida de los resultados de los

compromisos?
CUADRO24
Excelente 4 66.7
Muy Bueno 2 33.3
Bueno 0 0
Regular 0 0
TOTAL 6 100%
GRÁFICO24
70
60
50
40
%
30
20
10
0
266
De nuestro universo encuestado; 4 personas, que corresponde al

66.7%, indican que la información obtenida de los resultados de
los compromisos en el Sistema son “Excelentes”; mientras 2
personas que corresponde al 33.3% establecen que son “Muy
Buenos”.
Podemos observar que un considerable porcentaje de

encuestados se sienten muy conformes con los resultados de los
compromisos que se presentan en el Sistema de Gestión y
Control de Campeonatos Deportivos de las Disciplinas de Fútbol
y Básquet, mientras en menor número establecen que se podría
detallar más.
267

Castillo Duarte, Pablo Fernando, Figueroa Robles, Lucia Margarita

Cargado por

Copyright:

Formatos disponibles

Castillo Duarte, Pablo Fernando, Figueroa Robles, Lucia Margarita

Cargado por

Información del documento

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

Castillo Duarte, Pablo Fernando, Figueroa Robles, Lucia Margarita

Cargado por

Copyright:

Formatos disponibles

Sistema Web de Gestión Deportiva

Pablo Castillo y Lucía Figueroa

UNIVERSIDAD NACIONAL DE LOJA

ÁREA DE LA ENERGÍA, LAS INDUSTRIAS Y LOS

CARRERA DE INGENIERÍA EN SISTEMAS

“DISEÑO E IMPLANTACIÓN DE UN SISTEMA WEB

CASTILLO DUARTE PABLO FERNANDO

DIRECTOR: ING. WILMAN PATRICIO CHAMBA ZARAGOCÍN

CERTIFICACIÓN DEL DIRECTOR

Ing. Wilman Patricio Chamba Zaragocín,

Que la presente tesis de investigación previa la obtención del Título de Ingenieros en

Es todo cuanto puedo certificar en honor a la verdad.

Loja, Octubre del 2011

Ing. Wilman Patricio Chamba Zaragocín

Las ideas, definiciones, análisis, conclusiones y demás elementos teóricos de la

Nuestros sentimientos de gratitud van expresados a las dignas autoridades y docentes

Así también nuestro sincero agradecimiento a la planta administrativa de la Federación

Dejamos constancia de nuestra gratitud a todos los insignes maestros y brillantes

Y de manera muy especial, agradecemos al Señor Ingeniero Wilman Chamba

A mis padres Margarita y Estuardo,

A mi madre y hermanos, puntales

A mi padre, faro luminoso y tesoro que

A la niña de mis ojos, fuente inagotable de

Nosotros Lucía Margarita Figueroa Robles y Pablo Fernando Castillo Duarte,

La ciencia y tecnología avanzan continuamente, y las necesidades de automatizar

La metodología de desarrollo de software utilizada es la ICONIX, que es un proceso

El Sistema Web de gestión deportiva permite administrar los procesos que se

En la generación automática del calendario de juegos (fixture),se utilizó un modelo

El propósito del Sistema Web es lograr cubrir todas las actividades de la

Science and technology is continually advancing, and the need to computerize

INDICE DE TABLAS…………………..………………………………………………... XVII

INDICE DE FIGURAS……………………...…………………………………………... XXI

C.1.1. Método Deductivo…...………………………………………............. 4

C.1.2. Método Analítico – Crítico……………………………………........... 4

C.1.3. Método Descriptivo…...………….……………………...…………… 4

C.1.4. Metodología Iconix……………………………………...……………. 5

C.2. TECNICAS APLICADAS…………………………………….…….….... 6

1.3. Principales Disciplinas……….……………………………………………....... 10

2. GESTION DE CAMPEONATOS DEPORTIVOS

2.2. Campeonatos deportivos……………………………………………..…....... 21

2.2.1. Campeonatos por puntos………………………………………….…...... 21

2.2.2. Calendarios de juegos………………………………………………........ 22

2.2.3.2. Determinación del Número de Partidos……………..…...... 25

2.3.1. Descripción General………………………………………………..…...... 28

2.3.2. Programación Entera…………………………………………………....... 29

3.2. Clasificación de modelos matemáticos……………………………..…........ 31

3.2.1. Modelos Heurísticos…………………………………………….…........ 32

3.3. Representación del modelo………………………………………..……......... 33

4.1. Servidores Web…………………………………………………….….…......... 34

4.2. Java Server Faces…………………………………………………….…......... 36

4.2.2. Beneficios de JSF…………………………………….…...................... 38

4.2.3. Ciclo de vida de una página JSF…………………….…..................... 39

4.2.4. Escenarios de Procesamiento del Ciclo de Vida de una Petición...... 40

4.2.5. Ciclo de Vida Estándar de Procesamiento de Peticiones………....... 42

4.3. Sitio Web……………………………………………………………................. 42

4.3.1. Sitio Web estático…………………………………………................... 43

4.3.2. Sitio Web dinámico…………………………………….…................... 44

4.3.3. Tipos de Sitios Web………………………………………………………. 44

4.4. Modelo Vista Controlador…………………………………….……….…........ 47