unidad acadÉmica de ingenierÍa civil carrera de...
TRANSCRIPT
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
II
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-NoComercial-CompartirIgual 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
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.
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.
IV
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.
V
Í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
VI
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
7
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.
8
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.
9
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
10
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.
11
MARCO METODOLÓGICO
Tabla 1: FASES DE LA METODOLOGIA ICONIX
METODOLOGÍA ICONIX
FASES DISEÑO DE
DIAGRAMAS
DESCRIPCIÓN
Análisis de
requerimientos
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.
Análisis y
diseño
preliminar
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
12
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 entidad-
relació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.
Diagrama físico
de la BD
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.
Diseño
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.
Implementació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
13
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 DISEÑO DE DIAGRAMAS RESULTADO
Fase 1
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
Fase 2
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
Fase 3 Diagramas de secuencia Ver anexo 10
Diagramas de colaboración Ver anexo 11
Fase 4 Diagramas de despliegue Ver anexo 12
Diagramas de componentes Ver anexo 13
Fuente: Datos de la investigación Elaborado por: Priscila Fares
14
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.
15
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 library online):
http://www.scielo.org.co/scielo.php?pid=S0012-
73532007000300028&script=sci_arttext
16
ANEXOS
ANEXO 1 – ANÁLISIS DE REQUISITOS DE SOFTWARE
MÓDULO GESTIÓN DE APERTURAS
GESTION DE APERTURAS
#
REQUISITO
DESCRIPCIÓN DEL
REQUISITO
DATOS RESTRICCIÓN /
OBSERVACIÓN
R1 Registrar Nueva
Apertura
Código,
descripción.
Datos de R1
validados
R2 Modificar Apertura
Datos de R1 a
excepción del
Código.
Previa búsqueda
según R4
R3 Eliminar Apertura Datos de R1
Previa búsqueda
según R4
R4 Consultar Apertura 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
DATOS RESTRICCIÓN /
OBSERVACIÓN
R6 Registrar Revistas Código, título,
editorial, país, año. Datos de R6 validados
R7 Modificar Revistas
Datos de R6 a
excepción del
Código.
Previa búsqueda
según R9
R8 Eliminar Revistas Datos de R6
Previa búsqueda
según R9
17
R9 Consultar Revistas Datos de R6
Según Criterios de
Búsqueda:
–editorial, - país
origen
R10 Imprimir información
de Revistas
Datos de R6
(Listado de
Revistas)
Previa búsqueda
según R9
MÓDULO ADMINISTRACIÓN DE JUGADORES
GESTION DE ADMINISTRACIÓN DE JUGADORES
#
REQUISITO
DESCRIPCIÓN DEL
REQUISITO
DATOS RESTRICCIÓN /
OBSERVACIÓN
R11 Registrar Jugador
Código, nombre,
fecha nacimiento,
genero, puntaje
Datos de R11
validados
R12 Modificar Jugador Datos de R11 a
excepción del Código.
Previa búsqueda
según R14
R13 Eliminar Jugador Datos de R11
Previa búsqueda
según R14
R14 Consultar Jugador 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
DESCRIPCIÓN
DEL REQUISITO DATOS
RESTRICCIÓN /
OBSERVACIÓN
R16 Registrar Torneo
Código, nombre, lugar,
número de jugadores,
número de rondas, país,
fecha inicio, fecha fin.
Datos de R16
validados
18
R17 Modificar Torneo Datos de R16 a excepción
del Código.
Previa búsqueda
según R19
R18 Eliminar Torneo Código
Previa búsqueda
según R19
R19 Consultar Torneo Datos de R16
Según Criterios de
Búsqueda:
–nombre, - país, -
fecha
R20
Imprimir
información de
Torneo
Datos de R16
(cronograma de torneo)
Previa búsqueda
según R19
MÓDULO ADMINISTRACIÓN DE EQUIPOS
GESTIÓN DE ADMINISTRACIÓN DE EQUIPOS
#
REQUISITO
DESCRIPCIÓN DEL
REQUISITO
DATOS RESTRICCIÓN /
OBSERVACIÓN
R21 Registrar Equipos Código,
descripción
Datos de R21 validados
R22 Modificar Equipos
Datos de R21 a
excepción del
Código.
Previa búsqueda según
R24
R23 Eliminar Equipos Código
Previa búsqueda según
R24
R24 Consultar Equipos Datos de R21
Según Criterios de
Búsqueda:
–número de mesa, -
número partida, -torneo
R25
Imprimir
información de
Equipos
Datos de R21
(Lista de Equipos)
Previa búsqueda según
R24
19
MÓDULO GESTIÓN DE PARTIDAS DE AJEDREZ
GESTIÓN DE PARTIDAS DE AJEDREZ
#
REQUISITO
DESCRIPCIÓN
DEL
REQUISITO
DATOS RESTRICCIÓN /
OBSERVACIÓN
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.
Datos de R31
validados
R32 Modificar
Partida
Datos de R31 a excepción
del Código.
Previa búsqueda
según R34
R33 Eliminar Partida Código
Previa búsqueda
según R34
R34 Consultar
Partida Datos de R31
Según Criterios
de Búsqueda:
–Apertura, -
torneo.
R35 Imprimir
información de
Partida
Datos de R31 (Lista de
partidas realizadas por
torneo.)
Previa búsqueda
según R34
20
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
21
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
22
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
23
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
24
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
25
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
26
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
27
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
28
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
29
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
30
ANEXO 7 – DIAGRAMA DE ENTIDAD-RELACIÓN
31
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)
)
32
;
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,
33
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 PRIMARY KEY
(cod_rev_aje,cod_part)
;
-- 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 PRIMARY KEY
(cod_torneo,cod_equipo)
;
-- 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
34
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
35
;
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
;
36
ANEXO 10 – DIAGRAMA DE SECUENCIA
MÓDULO GESTIÓN DE APERTURAS
37
MÓDULO GESTIÓN DE REVISTAS DE AJEDREZ
38
MÓDULO GESTIÓN DE JUGADORES
39
MÓDULO ADMINISTRACIÓN DE TORNEOS DE AJEDREZ
40
MÓDULO ADMINISTRACIÓN DE EQUIPOS
41
MÓDULO GESTIÓN DE PARTIDAS DE AJEDREZ
42
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
43
MÓDULO ADMINISTRACIÓN DE TORNEOS DE JUGADORES
MÓDULO ADMINISTRACIÓN DE EQUIPOS
MÓDULO GESTIÓN DE PARTIDAS DE AJEDREZ
44
ANEXO 12 – DIAGRAMA DE DESPLIEGUE
ANEXO 13 – DIAGRAMA DE COMPONENTES
45
ANEXO 14 – INVESTIGACIÓN DE CAMPO – TORNEO ESCOLAR DE
AJEDREZ DE LA PROVINCIA DEL ORO
Lugar: coliseo de deportes de Machala
46
ANEXO 15 - REPORTE DE SIMILITUD URKUND