UNIDAD ACADÉMICA DE INGENIERÍA CIVIL CARRERA DE

UNIDAD ACADÉMICA DE INGENIERÍA CIVIL
CARRERA DE INGENIERÍA DE SISTEMAS
TEMA:
ANÁLISIS Y DISEÑO DE UN SOFTWARE PARA LA GESTIÓN DE LA INFORMACIÓN
DE REVISTAS DE JUEGOS DE AJEDREZ MEDIANTE UML.
TRABAJO PRÁCTICO DEL EXAMEN COMPLEXIVO PREVIO A LA OBTENCIÓN DEL
TÍTULO DE INGENIERA DE SISTEMAS
AUTORA:
FARES ROMERO PRISCILA ESTEFANIA
MACHALA - EL ORO
CESIÓN DE DERECHOS DE AUTOR
Yo, FARES ROMERO PRISCILA ESTEFANIA, con C.I. 0705399384, estudiante
de la carrera de INGENIERÍA DE SISTEMAS de la UNIDAD ACADÉMICA DE
INGENIERÍA CIVIL de la UNIVERSIDAD TÉCNICA DE MACHALA, en calidad
de Autora del siguiente trabajo de titulación ANÁLISIS Y DISEÑO DE UN
SOFTWARE PARA LA
GESTIÓN DE LA INFORMACIÓN DE REVISTAS DE JUEGOS DE AJEDREZ
MEDIANTE UML.
•
Declaro bajo juramento que el trabajo aquí descrito es de mi autoría; que
no ha sido previamente presentado para ningún grado o calificación
profesional. En consecuencia, asumo la responsabilidad de la originalidad
del mismo y el cuidado al remitirme a las fuentes bibliográficas respectivas
para fundamentar el contenido expuesto, asumiendo la responsabilidad
frente a cualquier reclamo o demanda por parte de terceros de manera
EXCLUSIVA.
•
Cedo a la UNIVERSIDAD TÉCNICA DE MACHALA de forma NO
EXCLUSIVA con referencia a la obra en formato digital los derechos de:
a. Incorporar la mencionada obra al repositorio digital institucional para
su democratización a nivel mundial, respetando lo establecido por la
Licencia
Creative
Commons
Atribución-NoComercialCompartirIgual 4.0 Internacional (CC BY-NC-SA 4.0), la Ley de
Propiedad Intelectual del Estado Ecuatoriano y el Reglamento
Institucional.
b. Adecuarla a cualquier formato o tecnología de uso en internet, así
como incorporar cualquier sistema de seguridad para documentos
electrónicos, correspondiéndome como Autor(a) la responsabilidad
de velar por dichas adaptaciones con la finalidad de que no se
desnaturalice el contenido o sentido de la misma.
Machala, 24 de Noviembre de 2015
II
ANÁLISIS Y DISEÑO DE UN SOFTWARE PARA LA GESTIÓN DE LA
INFORMACIÓN DE REVISTAS DE JUEGOS DE AJEDREZ MEDIANTE
UML.
RESUMEN
El presente trabajo permite analizar y diseñar un software para la gestión de la
información de revistas de ajedrez,
estas
revistas se basan en
torneos
nacionales como internacionales en donde se publica una serie de información
como registro de partidas, una variedad de estilos de apertura que emplean los
jugadores,
se asignan los
pareos además se publica el puntaje obtenido
permitiendo que los aficionados por este deporte puedan comentar las jugadas
haciendo que la información recopilada sea de interés para las personas que se
inclinan por este tipo deporte.
Para el desarrollo de este tema realizamos una investigación de campo en el
coliseo de deportes Machala, en el cual se llevó acabo un torneo escolar a nivel
provincial donde se pudo recolectar información sobre cómo se llevan a cabo los
torneos de ajedrez además tomamos como referencia el sistema informático
Swiss Manager el cual utiliza el sistema de competición suizo que es el más
usado en el ajedrez ya que permite con pocos duelos disputados catalogar a un
amplio número de jugadores, se logra haciendo que cada jugador se enfrente a
otro con el mismo nivel es decir se enfrentan los jugadores que hayan ganado
contra los que hayan ganado, y los que hayan perdido contra los que hayan
perdido, solo en la primera ronda se sortean los duelos, si nadie tiene ranking y
para elaboración del análisis y diseño partimos del lenguaje unificado de
modelado UML como Enterprise Architect, Toad Data Modeler permitiendo de
esta manera diseñar y automatizar los diferentes procesos cumpliendo con cada
uno de los requerimientos establecidos en la investigación.
Palabras Claves: UML, Enterprise Architect, partida, Toad Data Modeler,
revistas de ajedrez.
III
ANÁLISIS Y DISEÑO DE UN SOFTWARE PARA LA GESTIÓN DE LA
INFORMACIÓN DE REVISTAS DE JUEGOS DE AJEDREZ MEDIANTE
UML.
SUMMARY
This work enables analyzing and designing programs of the United Nations
Information Management chess magazines, journals yes Basan bathroom These
national and international tournaments where a series of information is published
as a record of games, a variety of styles Opening Hiring Players are assigned the
pairings: In addition it publishes the score obtained by allowing fans to comment
esta sport plays making information collected sea of interest to people who are
inclined to this type sport.
Development on this issue conducted a field research in the Coliseum Sports
Machala, which took just tournament un School provincial level where if it could
collect information on how a Cape chess tournaments take: In addition we
consider the Swiss Manager computer system which is Suizo The Swiss system
competition is most often used in chess because it allows to catalog a few duels
disputed un large number of players, is achieved by each player faces another
with the es Same level Say Yes facing players who have won against Hayan That
won and those who lost against those who lost Hayan Hayan, alone in the first
round duels are drawn, if anyone has the classification and paragraph
development of analysis and design As we start from the Enterprise Architect
UML unified modeling language, allowing Toad Data Modeler de este fashion
design and automate the different processes to comply with each of the
requirements established in the investigation.
Keywords: UML, Enterprise Architect, starting Toad Data Modeler, chess
magazines.
IV
ÍNDICE GENERAL
CESIÓN DE DERECHOS DE AUTOR............................................................... II
RESUMEN........................................................................................................ III
SUMMARY ...................................................................................................... IV
ÍNDICE GENERAL ........................................................................................... V
1.
INTRODUCCIÓN ........................................................................................ 7
MARCO CONTEXTUAL ................................................................................. 7
PROBLEMA ................................................................................................... 8
OBJETIVO GENERAL ................................................................................... 8
2.
DESARROLLO ........................................................................................... 9
MARCO TEÓRICO ........................................................................................ 9
2.1.1
PARTIDA DE AJEDREZ................................................................. 9
2.1.2
REVISTA DE AJEDREZ ................................................................. 9
2.1.3
TORNEO DE AJEDREZ ................................................................. 9
2.1.4
METODOLOGÍA ICONIX ............................................................... 9
2.1.5
UML ............................................................................................... 9
2.1.6
DIAGRAMAS DE CASO DE USO ................................................ 10
2.1.7
DIAGRAMAS DE CLASES ........................................................... 10
2.1.8
DICCIONARIO DE DATOS .......................................................... 10
2.1.9
MODELO ENTIDAD-RELACION .................................................. 10
2.1.10
DIAGRAMAS DE INTERACCIÓN (SECUENCIA Y
COLABORACIÓN).................................................................................... 10
MARCO METODOLÓGICO ......................................................................... 11
RESULTADOS ............................................................................................. 13
3.
CONCLUSIONES ..................................................................................... 14
4.
BIBLIOGRAFÍA......................................................................................... 15
ANEXOS ......................................................................................................... 16
ANEXO 1 – ANÁLISIS DE REQUISITOS DE SOFTWARE .......................... 16
ANEXO 2 – DIAGRAMAS DE CASOS DE USOS ........................................ 20
ANEXO 3 – CUADRO DE ACTORES Y RELACIONES ............................... 26
ANEXO 4 – DIAGRAMA DE CLASES .......................................................... 26
ANEXO 5 – DIAGRAMA DE OBJETOS ....................................................... 27
ANEXO 6 – DICCIONARIO DE DATOS ....................................................... 27
V
ANEXO 7 – DIAGRAMA DE ENTIDAD-RELACIÓN ..................................... 30
ANEXO 8 – DIAGRAMA RELACIONAL DE BASE DE DATOS .................... 31
ANEXO 9 – DIAGRAMA FÍSICO DE BASE DE DATOS............................... 31
ANEXO 10 – DIAGRAMA DE SECUENCIA ................................................. 36
ANEXO 11 – DIAGRAMAS DE COLABORACIÓN ....................................... 42
ANEXO 12 – DIAGRAMA DE DESPLIEGUE ............................................... 44
ANEXO 13 – DIAGRAMA DE COMPONENTES .......................................... 44
ANEXO 14 – INVESTIGACIÓN DE CAMPO – TORNEO ESCOLAR DE
AJEDREZ DE LA PROVINCIA DEL ORO .................................................... 45
ANEXO 15 - REPORTE DE SIMILITUD URKUND ...................................... 46
VI
1. INTRODUCCIÓN
El presente trabajo permite analizar y diseñar un software para la gestión de la
información de revistas de ajedrez en la cual se encuentra una serie de
información como registro de torneos nacionales o internacionales, registro de
jugadores, tipos de pareos, además cuenta con una variedad de estilos de
apertura que emplean de acuerdo a su estilo de jugada, dicha información es de
gran importancia ya que permite que se mantengan actualizadas las personas
que se inclinan por este tipo deporte.
Para el desarrollo de este tema realizamos una investigación de campo en el
coliseo de deportes Machala, en el cual se llevó acabo un torneo escolar a nivel
provincial donde se pudo recolectar información sobre cómo se llevan a cabo los
torneos de ajedrez además tomamos como referencia el sistema informático
Swiss Manager y para elaboración del análisis y diseño partimos del lenguaje
unificado de modelado UML como Enterprise Architect, Toad Data Modeler
permitiendo de esta manera diseñar y automatizar los diferentes procesos
cumpliendo con cada uno de los requerimientos establecidos en la investigación.
MARCO CONTEXTUAL
Para el estudio se tomó como referencia el sistema informático Swiss Manager
utilizado para realizar la gestión de un torneo de ajedrez el cual utiliza el sistema
de competición suizo que es el más usado en el ajedrez ya que permite con
pocos duelos disputados catalogar a un amplio número de jugadores, se logra
haciendo que cada jugador se enfrente a otro con el mismo nivel es decir se
enfrentan los jugadores que hayan ganado contra los que hayan ganado, y los
que hayan perdido contra los que hayan perdido. Solo en la primera ronda se
sortean los duelos, si nadie tiene ranking. (Barroso, 2013)
También se realizó una entrevista al coordinador del torneo escolar de ajedrez a
nivel provincial donde se recolectaron los requisitos necesarios para desarrollar
un análisis detallado sobre este tema para desarrollar un sistema de calidad y
que cumpla con las expectativas planteadas.
7
PROBLEMA
Actualmente en el Ecuador no existe un software que permita gestionar y publicar
la información de revistas de ajedrez donde se encuentre plasmado todo lo
referente a este tipo de torneos, donde los aficionados por este deporte puedan
consultar los tipos de aperturas que se asemejen más a su estilo de juego y
puedan realizar comentarios de cómo les pareció las estrategias y tácticas que
utilizaron los jugadores, debido a esta problemática me planteo realizar el
análisis y diseño de un software mediante el lenguaje unificado de modelado
utilizando la metodología Iconix.
OBJETIVO GENERAL
Analizar y diseñar un software para la gestión de la información de revistas de
juegos de ajedrez mediante UML con la finalidad de brindar una guía sobre las
mejores jugadas, técnicas y estrategias que emplean para ganar.
8
2. DESARROLLO
MARCO TEÓRICO
2.1.1 PARTIDA DE AJEDREZ
La partida de ajedrez inicia con el juego entre dos adversarios que alternan sus
movimientos de las piezas en un tablero, llamado “tablero de ajedrez”. El jugador
que es asignado con las piezas blancas realiza el primer movimiento seguido del
segundo jugador con las piezas negras. (ajedrezecuador, 2014)
2.1.2 REVISTA DE AJEDREZ
Las revistas de ajedrez son publicaciones que se realizan por parte de las
diferentes editoriales adjuntando las principales partidas de ajedrez que ocurren
a nivel nacional como internacional.
2.1.3 TORNEO DE AJEDREZ
El torneo de ajedrez compone una serie de 6 rondas en la cual intervienen varios
jugadores que seleccionan sus piezas, además utilizan diferentes tipos de
aperturas que permitan acoplarse a su estilo de jugada una vez cumplido el límite
de rondas establecidas se determina el ganador de la competencia mediante el
puntaje obtenido en las rondas jugadas.
2.1.4 METODOLOGÍA ICONIX
Iconix es una metodología ligera de desarrollo de software que se hayan en
medio camino de la RUP y la XP, consta de cuatro fases: la primera el análisis
de requisitos, siguiendo el análisis y diseño preliminar, después viene el diseño
y por ultimo tenemos la fase de implementación (Castro, Diego, Saavedra, &
Jhonatan, 2013).
2.1.5 UML
Según el concepto de (Lidia & Antonio, 2009, pág. 1), UML en una herramienta
de modelado grafico para detallar, documentar y construir un sistema. El
lenguaje UML es un lenguaje de propósito general, lo que significa que puede
ser utilizado para determinar la mayoría de los sistemas basados en objetos o
9
en componentes, y para modelar las aplicaciones de muy diversos dominios y
plataformas de objetos distribuidos.
2.1.6 DIAGRAMAS DE CASO DE USO
(Booch, Rumbaugh, & Jacobson, 1999, pág. 7) Explican que los diagramas de
caso de uso se especifican o detalla el sistema desde el punto de vista del
usuario para representar las acciones que realizan cada actor del sistema.
2.1.7 DIAGRAMAS DE CLASES
Los diagramas de clases son representaciones de las diferentes entidades, se
conforman por sus atributos, métodos con los que se interactúan los datos y sus
relaciones entre las clases, están relaciones incluye la generalización y la
asociación (Muñetón, Zapata, & Arango, 2007).
2.1.8 DICCIONARIO DE DATOS
Cobo Ángel (Diseño y programación de bases de datos, pág. 15), deduce que:
El diccionario de datos es una base de datos donde se almacenan las
descripciones conceptuales de la BD así como las reglas de correspondencia
necesarias para el paso de un esquema a otro.
2.1.9 MODELO ENTIDAD-RELACION
El modelo entidad-relación en su forma más simple implica identificar los asuntos
de importancia dentro de una organización (entidades), las propiedades de esos
asuntos (atributos) y cómo se relacionan entre sí (relaciones), (Barker, 1994).
2.1.10 DIAGRAMAS DE INTERACCIÓN (SECUENCIA Y COLABORACIÓN)
Según (Booch, Rumbaugh, & Jacobson, 1999, pág. 7), añade que los diagramas
de interacción muestran una interacción concreta entre un conjunto de objetos y
sus relaciones en conjunto con los mensajes que se trasmiten entre ellos. Los
diagramas de secuencia resaltan el orden temporal de los mensajes, mientras
tanto que los diagramas de colaboración resaltan la organización de los objetos
estructurados que intercambian mensajes.
10
MARCO METODOLÓGICO
Tabla 1: FASES DE LA METODOLOGIA ICONIX
METODOLOGÍA ICONIX
FASES
DISEÑO DE
DIAGRAMAS
DESCRIPCIÓN
Diagrama de
caso de uso
Para el desarrollo del diagrama de
caso de uso nos basamos del texto
UML por parte de los señores Grady
Booch, Jim Rumbaugh e Ivar
Jacobson, que nos especifican como
modelar la relación de cada caso de
uso con su respectivo autor viéndolo
desde el punto de vista del usuario, es
decir, teniendo una mejor perspectiva
para la comprensión del usuario.
Cuadro de
actores y
relaciones
En el cuadro de actores y sus
relaciones detallamos el vínculo o
nexo que tiene cada uno de los
actores con los casos de usos en el
modelado del sistema.
Diagrama de
clase
Empleando la teoría de Andrés
Muñetón, Carlos M. Zapata y
Fernando Arango se realizó el
diagrama de clases definiendo los
atributos de cada clase, los métodos
con los que se van a interactuar y las
respectivas relaciones entre clases.
Diagrama de
objetos
En la elaboración del diagrama de
objetos se empleó como base principal
el diagrama de clase, ya que mediante
este se representa sus atributos con
posibles datos que pueden ser
establecidos.
Diccionario de
datos
En el diccionario de datos aplicamos el
formato establecido en el libro de
(Cobo, pág. 15), donde describimos el
Análisis de
requerimientos
Análisis y
diseño
preliminar
11
atributo de cada entidad, el tipo de
atributo del mismo y describimos cuál
será su función o que datos tendrán
asignados.
Modelo entidadrelación
Diagrama físico
de la BD
Diseño
Implementación
Para la elaboración del diagrama
entidad-relación nos guiamos del libro,
modelo entidad-relación de (Barker,
1994, pág. 215), donde detallamos de
una forma sencilla las relaciones entre
las entidades mediante conectores y
definimos los atributos respectivos de
cada entidad.
Para el desarrollo de la solución o
modelo físico de la base de datos
aplicamos
ya
las
diferentes
normalizaciones,
desarrollando
nuevas tablas y relaciones, teniendo
un mayor control de la información que
van a estar definidos en una base de
datos.
Diagramas de
secuencia y
colaboración
Teniendo como base ya el texto UML
de los autores Grady Booch, Jim
Rumbaugh e Ivar Jacobson, también
logramos especificar los diagramas de
interacción que vienen a ser los
diagramas
de
secuencia
y
colaboración.
Diagramas de
despliegue y
componentes
Finalmente
desarrollamos
los
diagramas
de
despliegue
y
componentes
donde
cada
componente es una parte de la
interacción entre el usuario con el
sistema especificando el proceso que
se
lleva
desde
el
usuario/administrador hasta el ingreso
de datos de la base de datos.
Fuente: Datos de la investigación
Elaborado por: Priscila Fares
12
RESULTADOS
En el siguiente cuadro se describe todas las fases de la metodologia Iconix
conjuntamente con la integración de los diferentes diagramas que se realizaron
obteniendo un analisis mas detallado de los procesos que va a tener el sistema
de revistas de juegos de ajedrez.
Tabla 2: Estructura de la solución con metodología
METODOLOGÍA ICONIX
FASES
Fase 1
Fase 2
DISEÑO DE DIAGRAMAS
RESULTADO
Análisis de requisitos de
software.
Ver anexo 1
Diagramas de casos de uso
Ver anexo 2
Cuadro de actores y
relaciones
Ver anexo 3
Diagrama de clase
Ver anexo 4
Diagrama de objetos
Ver anexo 5
Diccionario de datos
Ver anexo 6
Modelo entidad-relación
Ver anexo 7
Diagrama relacional de la
BD
Ver anexo 8
Diagrama físico de la BD
Ver anexo 9
Diagramas de secuencia
Ver anexo 10
Diagramas de colaboración
Ver anexo 11
Diagramas de despliegue
Ver anexo 12
Diagramas de componentes
Ver anexo 13
Fase 3
Fase 4
Fuente: Datos de la investigación
Elaborado por: Priscila Fares
13
3. CONCLUSIONES
-
Con el desarrollo del análisis y diseño de la gestión de la información de
revistas de ajedrez, se obtuvo un mejor enfoque de las gestiones que este
sistema va a realizar.
-
Se utilizó la metodología Iconix la cual me permitió unificar un conjunto de
procesos de forma secuencial que permitieron determina claramente las
actividades a desarrollar en cada etapa del ciclo de vida del proyecto.
-
Este software permitirá establecer un diseño sencillo y claro tanto para el
usuario como para el administrador que van a interactuar con el mismo.
-
Este software permitirá que los seguidores por este juego estén
actualizados de los resultados de las partidas y de las técnicas empleadas
en los torneos.
14
4. BIBLIOGRAFÍA
ajedrezecuador. (1 de julio de 2014). Recuperado el 20 de octubre de 2015, de
http://www.ajedrezecuador.com/leyesfide2014.pdf
Barker, R. (1994). El modelo entidad-relación CASE*methodtm. (Wilmington,
Ed.) Estados Unidos de América: Addison-Wesley Iberoamericana. S.A.
Booch, G., Rumbaugh, J., & Jacobson, I. (1999). Recuperado el 5 de octubre de
2015,
de
CECAP
-
Webnode:
http://files.cecap49.webnode.es/200000016-6cd116dccb/3E-UML.pdf
Castro, A., Diego, A., Saavedra, J., & Jhonatan, C. (abril de 2013). asociación de
ex-alumnos liceistas. Recuperado el 22 de octubre de 2015, de
http://www.aealiceistas.com/files/d1562ad595b4782fdd86bfe008b25fde.
doc
Cobo, Á. (s.f.). Diseño y programación de bases de datos. (M. Gozález, Ed.)
Madrid, España: Visión Libros.
Lidia, F., & Antonio, V. (2009). Recuperado el 5 de octubre de 2015, de
Lenguajes
y
Ciencias
de
la
Computación:
http://lcc.uma.es/~av/Publicaciones/04/UMLProfiles-Novatica04.pdf
Muñetón, A., Zapata, C., & Arango, F. (2007). Recuperado el 05 de octubre de
2015,
de
SCIELO
(scientific
electronic
http://www.scielo.org.co/scielo.php?pid=S001273532007000300028&script=sci_arttext
15
library
online):
ANEXOS
ANEXO 1 – ANÁLISIS DE REQUISITOS DE SOFTWARE
MÓDULO GESTIÓN DE APERTURAS
GESTION DE APERTURAS
#
REQUISITO
DESCRIPCIÓN DEL
REQUISITO
DATOS
R1
Registrar Nueva
Apertura
Código,
descripción.
Modificar Apertura
Datos de R1 a
excepción del
Código.
R2
R3
R4
Eliminar Apertura
Consultar Apertura
RESTRICCIÓN /
OBSERVACIÓN
Datos de R1
validados
Previa búsqueda
según R4
Datos de R1
Previa búsqueda
según R4
Datos de R1
Según Criterios de
Búsqueda:
– Descripción
R5
Imprimir
información de
apertura
Descripción
Previa búsqueda
según R4
MÓDULO GESTIÓN DE REVISTAS DE AJEDREZ
GESTIÓN DE REVISTAS DE AJEDREZ
#
REQUISITO
DESCRIPCIÓN DEL
REQUISITO
R6
Registrar Revistas
Código, título,
editorial, país, año.
Modificar Revistas
Datos de R6 a
excepción del
Código.
R7
R8
Eliminar Revistas
DATOS
Datos de R6
16
RESTRICCIÓN /
OBSERVACIÓN
Datos de R6 validados
Previa búsqueda
según R9
Previa búsqueda
según R9
Según Criterios de
Búsqueda:
R9
R10
Consultar Revistas
Datos de R6
Datos de R6
Imprimir información
(Listado de
de Revistas
Revistas)
–editorial, - país
origen
Previa búsqueda
según R9
MÓDULO ADMINISTRACIÓN DE JUGADORES
GESTION DE ADMINISTRACIÓN DE JUGADORES
#
REQUISITO
DESCRIPCIÓN DEL
REQUISITO
R11
Registrar Jugador
Código, nombre,
fecha nacimiento,
genero, puntaje
Modificar Jugador
Datos de R11 a
excepción del Código.
R12
R13
R14
Eliminar Jugador
Consultar Jugador
DATOS
RESTRICCIÓN /
OBSERVACIÓN
Datos de R11
validados
Previa búsqueda
según R14
Datos de R11
Previa búsqueda
según R14
Datos de R11
Según Criterios de
Búsqueda:
–genero, -equipo
R15
Imprimir
información de
Jugador
Datos de R11 (Listado
de jugadores)
Previa búsqueda
según R14
MÓDULO ADMINISTRACIÓN DE TORNEOS
GESTIÓN DE ADMINISTRACIÓN DE TORNEOS
#
REQUISITO
R16
DESCRIPCIÓN
DEL REQUISITO
DATOS
Registrar Torneo
Código, nombre, lugar,
número de jugadores,
número de rondas, país,
fecha inicio, fecha fin.
17
RESTRICCIÓN /
OBSERVACIÓN
Datos de R16
validados
R17
R18
Modificar Torneo
Datos de R16 a excepción
del Código.
Eliminar Torneo
Previa búsqueda
según R19
Previa búsqueda
según R19
Código
Según Criterios de
Búsqueda:
R19
Consultar Torneo
Datos de R16
R20
Imprimir
información de
Torneo
Datos de R16
(cronograma de torneo)
–nombre, - país, fecha
Previa búsqueda
según R19
MÓDULO ADMINISTRACIÓN DE EQUIPOS
GESTIÓN DE ADMINISTRACIÓN DE EQUIPOS
#
REQUISITO
DESCRIPCIÓN DEL
REQUISITO
R21
R22
R23
DATOS
RESTRICCIÓN /
OBSERVACIÓN
Registrar Equipos
Código,
descripción
Datos de R21 validados
Modificar Equipos
Datos de R21 a
excepción del
Código.
Previa búsqueda según
R24
Eliminar Equipos
Código
Previa búsqueda según
R24
Según Criterios de
Búsqueda:
R24
Consultar Equipos
Datos de R21
R25
Imprimir
información de
Equipos
Datos de R21
(Lista de Equipos)
18
–número de mesa, número partida, -torneo
Previa búsqueda según
R24
MÓDULO GESTIÓN DE PARTIDAS DE AJEDREZ
GESTIÓN DE PARTIDAS DE AJEDREZ
#
REQUISITO
DESCRIPCIÓN
DEL
REQUISITO
DATOS
R31
Registrar
Partida
Código, número ronda,
numero de mesa, fecha de
partida, nombre jugador 1,
nombre jugador 2, color
pieza jug 1, color pieza jug 2,
puntaje jugador 1, puntaje
jugador 2, nombre árbitro,
apertura, torneo.
R32
Modificar
Partida
Datos de R31 a excepción
del Código.
R33
R34
R35
Eliminar Partida
Consultar
Partida
Imprimir
información de
Partida
Código
RESTRICCIÓN /
OBSERVACIÓN
Datos de R31
validados
Previa búsqueda
según R34
Previa búsqueda
según R34
Según Criterios
de Búsqueda:
Datos de R31
Datos de R31 (Lista de
partidas realizadas por
torneo.)
19
–Apertura, torneo.
Previa búsqueda
según R34
ANEXO 2 – DIAGRAMAS DE CASOS DE USOS
MÓDULO GESTIÓN DE APERTURAS
Escenario
1. Gestión de Aperturas
Actores
Administrador
Nivel
Detallado o Específico
Guión o
procedimiento





Registrar Nueva Apertura
Modificar Apertura
Eliminar Apertura
Consultar Apertura
 Por Descripción
Imprimir Información de Aperturas
20
MÓDULO GESTIÓN DE REVISTAS DE AJEDREZ
Escenario
2. Gestión de Revistas de Ajedrez
Actores
Administrador
Nivel
Detallado o Específico
Guión o




procedimiento

Registrar Nueva Revista de Ajedrez
Modificar Revista de Ajedrez
Eliminar Revista de Ajedrez
Consultar Revistas de Ajedrez
 Por Editorial
 Por País de Origen
Imprimir Información de Aperturas
 Listado de Revistas registradas
21
MÓDULO ADMINISTRACION DE JUGADORES
Escenario
3. Administración de Jugadores
Actores
Administrador, Jugador
Nivel
Detallado o Específico
Guión o




procedimiento

Registrar Nuevo Jugador
Modificar Jugador
Eliminar Jugador
Consultar Jugador
 Por Genero
 Por Federación
Imprimir Información de Jugadores
 Listado de Jugadores
22
MÓDULO ADMINISTRACION DE TORNEOS DE AJEDREZ
Escenario
4. Administración de Torneos de Ajedrez
Actores
Administrador, Jugador
Nivel
Detallado o Específico
Guión o




procedimiento

Registrar Nuevo Torneo
Modificar Torneo de Ajedrez
Eliminar Torneo de Ajedrez
Consultar Torneos de Ajedrez
 Por Nombre
 Por País
 Por fecha
Imprimir Información de Torneos
 Cronograma de Torneos de Ajedrez
23
MÓDULO ADMINISTRACION DE EQUIPOS
Escenario
5. Administración de Equipos
Actores
Administrador, Jugador
Nivel
Detallado o Específico
Guión o
procedimiento





Registrar Nuevo Equipo
Modificar Equipo
Eliminar Equipo
Consultar Equipo
 Por Numero Torneo
Imprimir Información Equipos
 Lista de Equipos de Jugadores
24
MÓDULO GESTION DE PARTIDAS DE AJEDREZ
Escenario
6. Gestión de Partidas de Ajedrez
Actores
Administrador
Nivel
Detallado o Específico
Guión o




procedimiento

Registrar Partida de Ajedrez
Modificar Partida de Ajedrez
Eliminar Partida de Ajedrez
Consultar Partida de Ajedrez
 Por Apertura
 Por Torneo
Imprimir Información de Partidas
 Lista de Partidas realizadas por torneo
25
ANEXO 3 – CUADRO DE ACTORES Y RELACIONES
ACTOR
DESCRIPCIÓN
Administrador
Automatiza información contenida en revistas de
ajedrez.
Jugador
Persona que se destaca en su estilo de juego y
apertura que imponga en sus partidas
ANEXO 4 – DIAGRAMA DE CLASES
26
ANEXO 5 – DIAGRAMA DE OBJETOS
ANEXO 6 – DICCIONARIO DE DATOS
Revista de ajedrez
NOMBRE
TIPO
NOTAS
cod_rev_aje
int
Código de revistas
Titulo_rev_aje
char
Título de Revistas
editorial_rev_aje
char
Editorial de la Revista
pais_rev_aje
char
País de la revista de ajedrez
anio_rev_aje
int
Año de publicación de revista
Partida
NOMBRE
TIPO
NOTAS
cod_part
Int
Código de partida
num_ronda_part
Int
Número de la ronda de partida
num_mesa_part
Char
Calificación de la partida
27
NOMBRE
TIPO
NOTAS
fecha_part
Date
Fecha de la partida
jugador1_part
Char
Nombre del 1er Jugador de la partida
jugador2_part
Char
Nombre del 2do Jugador de la partida
color_pieza_jug1
Char
Color de pieza Jugador 1
color_pieza_jug2
Char
Color de pieza Jugador 2
puntaje_jug1
Double
Puntaje del Jugador 1
puntaje_jug2
Double
Puntaje del Jugador 2
nom_arbitro_part
Char
Nombre de arbitro
Apertura
NOMBRE
TIPO
NOTAS
cod_aper
Int
Código de Apertura
descr_aper
Char
Descripción del tipo de apertura
Tipo_pareo
NOMBRE
TIPO
NOTAS
cod_tipo_pareo
Int
Código de Tipo de Pareo
desc_tipo_pareo
Char
Descripción del Tipo de Pareo
Equipo
NOMBRE
TIPO
NOTAS
cod_equipo
Int
Código de Equipo
Desc_equipo
Char
Descripción del equipo
Torneo
28
NOMBRE
TIPO
NOTAS
cod_torneo
Int
Código de torneo
nombre_torneo
Char
Nombre del torneo
lugar_torneo
Char
Ciudad o establecimiento del torneo
num_jug_torneo
Int
Número total de jugadores del torneo
num_rondas_torneo
Int
Numero de rondas del torneo
pais_torneo
Char
País donde se realiza el torneo
fecha_inicio_torneo
Date
Fecha de comienzo de torneo
fecha_fin_torneo
Date
Fecha de finalización del torneo
nom_arb_torneo
Char
Nombre del árbitro del torneo
tip_par_torneo
Char
Tipo de pareo del torneo
Comentarios
NOMBRE
TIPO
NOTAS
cod_coment
Int
Código del comentario
nombre_usu_coment
Char
Nombre del usuario del comentario
descripcion_coment
Char
Descripción del comentario
fecha_coment
Date
Fecha del comentario
hora_coment
time
Hora del comentario
29
ANEXO 7 – DIAGRAMA DE ENTIDAD-RELACIÓN
30
ANEXO 8 – DIAGRAMA RELACIONAL DE BASE DE DATOS
ANEXO 9 – DIAGRAMA FÍSICO DE BASE DE DATOS
-- Table revista_ajedrez
CREATE TABLE revista_ajedrez
(
cod_rev_aje Int NOT NULL AUTO_INCREMENT,
titulo_rev_aje Varchar(500) NOT NULL,
editorial_rev_aje Varchar(200) NOT NULL,
pais_origen_rev_aje Varchar(50) NOT NULL,
anio_rev_aje Varchar(20) NOT NULL,
PRIMARY KEY (cod_rev_aje)
)
;
-- Table partida_juego
CREATE TABLE partida_juego
(
cod_part Int NOT NULL AUTO_INCREMENT,
num_ronda_part Int NOT NULL,
num_mesa_part Int NOT NULL,
fecha_part Date NOT NULL,
cod_jug1 Int,
cod_jug2 Int,
color_pieza_jug1 Varchar(100) NOT NULL,
color_pieza_jug2 Varchar(100) NOT NULL,
puntaje_jug1 Double(1,2) NOT NULL,
puntaje_jug2 Double(1,2) NOT NULL,
nom_arbitro_part Varchar(200) NOT NULL,
cod_apert Int,
cod_torneo Int,
PRIMARY KEY (cod_part)
)
31
;
CREATE INDEX IX_Relationship12 ON partida_juego (cod_torneo)
;
CREATE INDEX IX_Relationship28 ON partida_juego (cod_jug1)
;
CREATE INDEX IX_Relationship31 ON partida_juego (cod_jug2)
;
-- Table apertura
CREATE TABLE apertura
(
cod_apert Int NOT NULL AUTO_INCREMENT,
desc_apert Varchar(200) NOT NULL,
PRIMARY KEY (cod_apert)
)
;
-- Table equipo
CREATE TABLE equipo
(
cod_equipo Int NOT NULL AUTO_INCREMENT,
desc_equipo Varchar(200) NOT NULL,
PRIMARY KEY (cod_equipo)
)
;
-- Table jugadores
CREATE TABLE jugadores
(
cod_jug Int NOT NULL AUTO_INCREMENT,
nombre_jug Varchar(500) NOT NULL,
fecha_nac_jug Date NOT NULL,
genero_jug Varchar(50) NOT NULL,
punt_total_jug Double(1,2) NOT NULL,
cod_equipo Int,
PRIMARY KEY (cod_jug)
)
;
CREATE INDEX IX_Relationship35 ON jugadores (cod_equipo)
;
-- Table torneo
CREATE TABLE torneo
(
cod_torneo Int NOT NULL AUTO_INCREMENT,
nombre_torneo Varchar(200) NOT NULL,
lugar_torneo Varchar(200) NOT NULL,
num_jug_torneo Int NOT NULL,
32
num_rondas_torneo Int NOT NULL,
pais_torneo Varchar(50) NOT NULL,
fecha_inicio_torneo Date NOT NULL,
fecha_fin_torneo Date NOT NULL,
cod_tipo_pareo Int,
PRIMARY KEY (cod_torneo)
)
;
CREATE INDEX IX_Relationship36 ON torneo (cod_tipo_pareo)
;
-- Table detalle_partida_revista
CREATE TABLE detalle_partida_revista
(
cod_rev_aje Int NOT NULL,
cod_part Int NOT NULL
)
;
ALTER TABLE detalle_partida_revista ADD
(cod_rev_aje,cod_part)
;
PRIMARY KEY
-- Table detalle_equip_torneo
CREATE TABLE detalle_equip_torneo
(
cod_torneo Int NOT NULL,
cod_equipo Int NOT NULL
)
;
ALTER TABLE detalle_equip_torneo ADD
(cod_torneo,cod_equipo)
;
PRIMARY KEY
-- Table comentarios
CREATE TABLE comentarios
(
cod_coment Int NOT NULL AUTO_INCREMENT,
nombre_usu_coment Varchar(200) NOT NULL,
descripcion_coment Varchar(500) NOT NULL,
fecha_coment Date NOT NULL,
hora_coment Time NOT NULL,
cod_part Int,
PRIMARY KEY (cod_coment)
)
;
CREATE INDEX IX_Relationship32 ON comentarios (cod_part)
;
-- Table tipo_pareo
33
CREATE TABLE tipo_pareo
(
cod_tipo_pareo Int NOT NULL AUTO_INCREMENT,
desc_tipo_pareo Varchar(100) NOT NULL,
PRIMARY KEY (cod_tipo_pareo)
)
;
-- Create relationships section -----------------------------------------------ALTER TABLE partida_juego ADD CONSTRAINT Relationship2 FOREIGN
KEY (cod_apert) REFERENCES apertura (cod_apert) ON DELETE NO
ACTION ON UPDATE NO ACTION
;
ALTER TABLE partida_juego ADD CONSTRAINT Relationship12 FOREIGN
KEY (cod_torneo) REFERENCES torneo (cod_torneo) ON DELETE
RESTRICT ON UPDATE RESTRICT
;
ALTER TABLE detalle_partida_revista ADD CONSTRAINT
Relationship23 FOREIGN KEY (cod_rev_aje) REFERENCES
revista_ajedrez (cod_rev_aje) ON DELETE RESTRICT ON UPDATE
RESTRICT
;
ALTER TABLE detalle_partida_revista ADD CONSTRAINT
Relationship24 FOREIGN KEY (cod_part) REFERENCES partida_juego
(cod_part) ON DELETE RESTRICT ON UPDATE RESTRICT
;
ALTER TABLE detalle_equip_torneo ADD CONSTRAINT Relationship25
FOREIGN KEY (cod_torneo) REFERENCES torneo (cod_torneo) ON
DELETE RESTRICT ON UPDATE RESTRICT
;
ALTER TABLE detalle_equip_torneo ADD CONSTRAINT Relationship26
FOREIGN KEY (cod_equipo) REFERENCES equipo (cod_equipo) ON
DELETE RESTRICT ON UPDATE RESTRICT
;
ALTER TABLE partida_juego ADD CONSTRAINT Relationship28 FOREIGN
KEY (cod_jug1) REFERENCES jugadores (cod_jug) ON DELETE RESTRICT
ON UPDATE RESTRICT
;
ALTER TABLE partida_juego ADD CONSTRAINT Relationship31 FOREIGN
KEY (cod_jug2) REFERENCES jugadores (cod_jug) ON DELETE RESTRICT
ON UPDATE RESTRICT
;
ALTER TABLE comentarios ADD CONSTRAINT Relationship32 FOREIGN
KEY (cod_part) REFERENCES partida_juego (cod_part) ON DELETE
RESTRICT ON UPDATE RESTRICT
34
;
ALTER TABLE jugadores ADD CONSTRAINT Relationship35 FOREIGN KEY
(cod_equipo) REFERENCES equipo (cod_equipo) ON DELETE RESTRICT
ON UPDATE RESTRICT
;
ALTER TABLE torneo ADD CONSTRAINT Relationship36 FOREIGN KEY
(cod_tipo_pareo) REFERENCES tipo_pareo (cod_tipo_pareo) ON
DELETE RESTRICT ON UPDATE RESTRICT
;
35
ANEXO 10 – DIAGRAMA DE SECUENCIA
MÓDULO GESTIÓN DE APERTURAS
36
MÓDULO GESTIÓN DE REVISTAS DE AJEDREZ
37
MÓDULO GESTIÓN DE JUGADORES
38
MÓDULO ADMINISTRACIÓN DE TORNEOS DE AJEDREZ
39
MÓDULO ADMINISTRACIÓN DE EQUIPOS
40
MÓDULO GESTIÓN DE PARTIDAS DE AJEDREZ
41
ANEXO 11 – DIAGRAMAS DE COLABORACIÓN
MÓDULO GESTIÓN DE APERTURAS
MÓDULO GESTIÓN DE REVISTAS DE AJEDREZ
MÓDULO ADMINISTRACIÓN DE JUGADORES
42
MÓDULO ADMINISTRACIÓN DE TORNEOS DE JUGADORES
MÓDULO ADMINISTRACIÓN DE EQUIPOS
MÓDULO GESTIÓN DE PARTIDAS DE AJEDREZ
43
ANEXO 12 – DIAGRAMA DE DESPLIEGUE
ANEXO 13 – DIAGRAMA DE COMPONENTES
44
ANEXO 14 – INVESTIGACIÓN DE CAMPO – TORNEO ESCOLAR DE
AJEDREZ DE LA PROVINCIA DEL ORO
Lugar: coliseo de deportes de Machala
45
ANEXO 15 - REPORTE DE SIMILITUD URKUND
46