sdd documento de - pegasus.javeriana.edu.copegasus.javeriana.edu.co/~cis1310is08/archivos/[izafiro]...
Post on 27-Sep-2018
215 Views
Preview:
TRANSCRIPT
Noviembre de 2013
SDD – Documento de Diseño del Sistema Versión 1.0
JHONATHAN A CÓRDOBA CASTAÑEDA PONTIFICIA UNIVERSIDAD JAVERIANA
JHONATHAN CÓRDOBA CASTAÑEDA 1
Página de Firmas
El presente documento es aprobado y constatado por las personas directamente involucradas,
mostradas a continuación:
Ing. José Hernando Hurtado Rojas
Cliente
Jhonathan A. Córdoba Castañeda
Director de Proyecto
Director de Desarrollo
JHONATHAN CÓRDOBA CASTAÑEDA 2
Historial de Cambios
Versión Fecha Sección
Modificada Descripción Responsable
0.1 16 de Octubre
2013 1
Creación de portada, tabla
historial de cambios.
Jhonathan Córdoba
Castañeda
0.2 17 de Octubre
2013 1, 2
Descripción Global de la
Arquitectura
Jhonathan Córdoba
Castañeda
0.3 19 de Octubre
2013 2
Adición de nuevas
secciones
Jhonathan Córdoba
Castañeda
0.4 22 de Octubre
2013 2
Elaboración del Plan de
Riesgos
Jhonathan Córdoba
Castañeda
0.5 24 de Octubre
2013 2, 3
Adición de nuevas
secciones
Jhonathan Córdoba
Castañeda
0.6 26 de Octubre
2013 3,4
Adición de nuevas
secciones
Jhonathan Córdoba
Castañeda
0.7 27 de Octubre
2013 4
Elaboración Diagramas de
Actividad
Jhonathan Córdoba
Castañeda
0.8 30 de Octubre
2013 4
Elaboración de Diagramas
de Secuancia
Jhonathan Córdoba
Castañeda
0.9 2 de Noviembr
2013e 5
Adición del Diagrama de
Clases
Jhonathan Córdoba
Castañeda
1.0 4 de Noviembre
2013 5, 6
Adición del Árbol de
Navegación
Jhonathan Córdoba
Castañeda
JHONATHAN CÓRDOBA CASTAÑEDA 3
Tabla de Contenido
1. INTRODUCCIÓN ................................................................................... 7
1.1. DESCRIPCIÓN DEL SISTEMA .................................................................... 7
1.2. MAPA DEL DISEÑO ............................................................................. 7
1.3. REFERENCIAS Y DOCUMENTOS DE APOYO ..................................................... 8
1.4. DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS ................................................ 11
2. CONSIDERACIONES DE DISEÑO .............................................................. 12
2.1. SUPOSICIONES ............................................................................... 12
2.2. RESTRICCIONES .............................................................................. 13
2.2.1. Restricciones Generales ........................................................... 13
2.2.2. Restricciones de Usuario .......................................................... 13
2.2.3. Restricciones de Software ......................................................... 13
2.2.4. Restricciones de Hardware ........................................................ 13
2.3. ENTORNO DEL SISTEMA ...................................................................... 13
2.4. METODOLOGÍA DE DISEÑO ................................................................... 14
2.4.1. Metodología OMT (Técnica de modelado de objetos) ........................ 15
2.5. RIESGOS ..................................................................................... 16
3. ARQUITECTURA ................................................................................ 19
3.1. APRECIACIÓN GLOBAL ....................................................................... 19
3.2. DIAGRAMA DE COMPONENTES ............................................................... 20
3.3. ESTRATEGIAS DE DISEÑO .................................................................... 23
4. DISEÑO DE ALTO NIVEL ....................................................................... 25
4.1. DIAGRAMA DE DESPLIEGUE .................................................................. 25
4.1.1. Nodo Cliente ......................................................................... 26
4.1.2. Nodo Orion ........................................................................... 27
4.2. DIAGRAMAS DE COMPORTAMIENTO E INTERACCIÓN ......................................... 27
4.2.1. Diagramas de Actividad ............................................................ 27
4.2.1.1. Módulo de Manejo de Acceso .......................................................... 28
4.2.1.2. Módulo Gestor de Juegos Puzzle ...................................................... 29
4.2.2. Diagramas de Secuencia ........................................................... 36
4.2.2.1. Módulo de Manejo de Acceso .......................................................... 36
5. DISEÑO DE BAJO NIVEL ....................................................................... 38
5.1. DIAGRAMA DE CLASES ....................................................................... 38
JHONATHAN CÓRDOBA CASTAÑEDA 4
6. DISEÑO DE INTERFACES DE USUARIO ...................................................... 40
6.1. ÁRBOL DE NAVEGABILIDAD .................................................................. 40
JHONATHAN CÓRDOBA CASTAÑEDA 5
Lista de Ilustraciones
Ilustración 1: Módulos de iZafiro. .................................................................. 19
Ilustración 2: Diagrama de Componentes de iZafiro. ........................................... 21
Ilustración 3: Niveles de detalle de la aplicación. .............................................. 25
Ilustración 4: Diagrama de Despliegue de iZafiro. .............................................. 26
Ilustración 5: Diagrama Actividad - Registrar Nuevo Usuario. ................................. 28
Ilustración 6: Diagrama Actividad - Jugar Turno Puzzle 1. .................................... 29
Ilustración 7: Diagrama Actividad - Jugar Turno Puzzle 2. .................................... 30
Ilustración 8: Diagrama Actividad - Jugar Turno Puzzle 3. .................................... 31
Ilustración 9: Diagrama Actividad - Jugar Turno Puzzle 4. .................................... 32
Ilustración 10: Diagrama Actividad - Jugar Turno Puzzle 5 .................................... 33
Ilustración 11: Diagrama Actividad - Jugar Turno Puzzle 6. ................................... 34
Ilustración 12: Diagrama Actividad - Jugar Turno Puzzle 7. ................................... 35
Ilustración 13: Diagrama secuencia - Registrar Nuevo Usuario. ............................... 36
Ilustración 14: Diagrama Secuencia - Jugar Turno Puzzle 2. .................................. 37
Ilustración 15: Diagrama de Clases. ................................................................ 38
Ilustración 16: Árbol de Navegación de iZafiro. ................................................. 40
JHONATHAN CÓRDOBA CASTAÑEDA 6
Lista de Tablas
Tabla 1: Suposiciones y Dependencias. ............................................................ 12
Tabla 2: Requerimiento de software y hardware. ............................................... 14
Tabla 3: Riesgos de diseño identificados. ......................................................... 16
Tabla 4: Clasificación del riesgo. ................................................................... 16
Tabla 5: Criticidad de los Riesgos. ................................................................. 17
Tabla 6: Plan de control de riesgos. ............................................................... 18
Tabla 7: Estrategias de Diseño. ..................................................................... 24
Tabla 8: Especificación Nodo Cliente. ............................................................. 26
Tabla 9: Especificación Nodo Orion. ............................................................... 27
Tabla 10: Relación Módulos y Clases. .............................................................. 39
JHONATHAN CÓRDOBA CASTAÑEDA 7
1. Introducción
1.1. Descripción del Sistema
En esta primera sección se realiza una descripción a nivel general de la arquitectura de la
herramienta iZafiro, así como también, de los usuarios objetivos para los cuales está
destinada.
La aplicación tiene como población objetivo a los niños (ambos sexos) de 9 a 10 años que
actualmente estén cursando cuarto o quinto grado de primaria, que tengan conocimiento de
las operaciones básicas en matemáticas (suma, resta, multiplicación y división) y que estén
en capacidad de leer. Los usuarios podrán hacer uso de la herramienta tanto en sus casas
como en la entidad educativa (en caso de que en ella se decida incorporar la aplicación como
una herramienta de entrenamiento didáctico sobre números fraccionarios). El sistema
interactúa con la base de datos alojada remotamente en el servidor Orion de la Pontificia
Universidad Javeriana, aunque se contará con un módulo especial para guardar los datos de
manera local en la máquina en la cual se esté ejecutando el juego, así que no habrá necesidad
de internet si no se tiene posibilidad o si no se desea. iZafiro no es un sistema distribuido.
El sistema estará conformado (de acuerdo a lo expuesto en el documento SRS 1.0) por los
7 módulos principales a través de los cuales se puede ver de manera más sencilla todas las
funcionalidades de la aplicación. Las restricciones generales para poder cumplir con los
requerimientos de esta arquitectura son descritas en las secciones 2.1, 2.2, 2.3 y 2.4 del
documento SRS 1.0.
1.2. Mapa del Diseño
En esta sección se listan cuáles fueron los tipos de diagramas a través de los cuales se definió
el diseño del sistema, de acuerdo a las categorías propuestas en la plantilla SDD de
IRONWORKS [15]:
Diseño de alto nivel:
Estilo arquitectónico
Diagrama de despliegue.
JHONATHAN CÓRDOBA CASTAÑEDA 8
Diagrama de componentes.
Diagramas de actividad y de secuencia.
Diseño de bajo nivel:
Diagrama de clases.
Diagrama Entidad Relación
GUI
Árbol de Navegabilidad
1.3. Referencias y Documentos de Apoyo
[1] Maria Dolores Sánchez Gala. Tesis Doctoral: La Dramatización en Educación Primaria
como eje del Aprendizaje Lúdico - Creativo. Málaga, Mayo de 2007. Universidad de
Málaga. Facultad de Ciencias de la Educación. Departamento de Métodos de Investigación
e Innovación Educativa.
[2] IEEE (Institute of Electrical and Electronics Engineers), IEEE Recommended Practice
for Software Requirements Specificacitions, IEEE-SA Standards Board, Junio 1998.
[3] Oracle Corporation. What is SQL Developer?. [Manual en Internet]. Estados Unidos:
Oracle Technology Network, Developer Tools. [Citado 2013 Nov. 6]. Disponible en:
http://www.oracle.com/technetwork/developer-tools/sql-developer/what-is-sqldev-
093866.html
[4] ALEGSA. “Diccionario informático hardware típico de una computadora”, 2006;
Disponible en: http://www.alegsa.com.ar/Dic/hardware.php
[5] Glosarium.com. Diccionario informático. Disponible en:
http://www.glosarium.com/term/1439,14,xhtml
[6] IRONWORKS, Plantilla SRS, Segundo Semestre 2008, Pontificia Universidad
Javeriana. Página [12]
JHONATHAN CÓRDOBA CASTAÑEDA 9
[7] Oracle Corporation. ¿Cuáles son los requisitos del sistema para Java 7? [Guía en
Internet]. Estados Unidos: Recursos de Ayuda. [Citado 2013 Sept. 16]. Disponible en:
http://www.java.com/es/download/help/sysreq.xml
[8] Carme Martín Escofet, Universitat Oberta de Catalunya. El lenguaje SQL. Febrero 2007;
(Volumen 1, No3): 5.
[9] IRONWORKS, Plantilla SRS, Segundo Semestre 2008, Pontificia Universidad
Javeriana. Página [13]
[10] IRONWORKS, Plantilla SRS, Segundo Semestre 2008, Pontificia Universidad
Javeriana. Página [14]
[11] Larman C. UML Y PATRONES. Una introducción al análisis y diseño orientado a
objetos y al proceso unificado. 2nd ed. Aragón DF. Madrid: Pearson Educación. S.A.; 2006.
Pág. 41
[12] IRONWORKS, Plantilla SRS, Segundo Semestre 2008, Pontificia Universidad
Javeriana. Página [25]
[13] Volere Requeriments Resources. Volere Requeriments Especification Template.
Disponible en: http://www.volere.co.uk/template.htm
[14] IRONWORKS, Plantilla SRS, Segundo Semestre 2008, Pontificia Universidad
Javeriana. Página [29]
[15] IRONWORKS, Plantilla SDD, Segundo Semestre 2008, Pontificia Universidad
Javeriana. Página [7]
[16] Booch G., Rumbaugh J. and Jacobson I. El lenguaje unificado de modelado. Primera
edición. Prentice Hall.2004
[17] Eli Neiburger. Gamers in the Library? The Why, What, and how of Videogame
Tournaments for al Ages. 1st ed. American Library Association; 2007. Página [54]
JHONATHAN CÓRDOBA CASTAÑEDA 10
[18] Escuela Técnica Superior de Ingeniería Informática. Departamento de Lenguajes y
Sistemas Informáticos. Diagramas de interacción UML + Patrones de Asignación de
Responsabilidades (GRASP). [Citado 2013 Nov. 2]. Disponible en:
http://www.lsi.us.es/docencia/get.php?id=1610.
JHONATHAN CÓRDOBA CASTAÑEDA 11
1.4. Definiciones, acrónimos y abreviaturas
Término Descripción
SDD
Software Design Document. Documento de Diseño del
Sistema. Documento donde se explica desde diferentes niveles
y desde diferentes entregables el diseño de la aplicación, sus
componentes y la manera en como las funcionalidades se
llevan a cabo.
Artefacto Producto de software resultado de una serie de actividades.
Bytecode Es un código intermedio más abstracto que el código de
máquina.
JDeveloper Herramienta de desarrollo de la aplicación.
SQL Developer [3]
Requerimientos
funcionales
Definen el comportamiento interno del software: cálculos,
detalles técnicos, manipulación de datos y otras
funcionalidades específicas que muestran cómo los casos de
uso serán llevados a la práctica.
Requerimientos no
funcionales
Especifican criterios que pueden usarse para juzgar la
operación de un sistema en lugar de sus comportamientos
específicos.
Stakeholders
Todas aquellas personas u organizaciones que afectan o son
afectadas por el proyecto [4].
Supuesto
Palabra utilizada para describir la situación que se presentaría
si no se implementara un requerimiento.
Tolerancia a fallos
La tolerancia a fallos es la propiedad de ciertos computadores
y/o aplicaciones software de funcionar aun cuando se haya
producido una avería en alguno de sus componentes [5].
Usuario Papel que representa a las personas que interactúan en forma
directa con el sistema cuando realizan su trabajo.
JHONATHAN CÓRDOBA CASTAÑEDA 12
2. Consideraciones de Diseño
2.1. Suposiciones
En esta sección se describen las suposiciones y dependencias identificadas para la
elaboración de un diseño consistente, completo y correcto del sistema. A continuación se
agrupan estas suposiciones según los tres grupos generales propuestos en la plantilla SDD
1.0 (Línea Base) de IRONWORKS [15]:
Grupo Suposiciones y dependencias
El equipo de
desarrollo
El equipo de desarrollo cuenta con las plataformas
necesarias para el desarrollo de la aplicación y la
realización de pruebas.
Se cuenta con el apoyo de herramientas CASE y de
aquellos programas que sirven de editor de imágenes (para
la elaboración de los escenarios del mapa) y editor de
sonidos (cambio de formato de las pistas que serán
reproducidas durante el funcionamiento de la aplicación).
Equipos
(Computadores)
Los equipos en los cuales se ejecutará la aplicación tienen
el hardware requerido, el cual se encuentra descrito en la
sección 2.1 del documento SRS 1.0.
En cuanto al software requerido para los computadores,
mínimo deben tener JDK para poder ejecutar la aplicación
con éxito.
Contará con una conexión a internet (si se desea participar
en la competencia online con otros jugadores de distintas
partes).
El cliente
No se realizarán modificaciones sobre los requerimientos
funcionales del sistema durante el desarrollo de la
aplicación.
Tabla 1: Suposiciones y Dependencias.
JHONATHAN CÓRDOBA CASTAÑEDA 13
2.2. Restricciones
2.2.1. Restricciones Generales
La aplicación estará desarrollada únicamente en el idioma español.
La tolerancia a fallos en la herramienta no será tenida en cuenta para esta versión.
2.2.2. Restricciones de Usuario
El usuario debe saber leer.
Manejo básico de un computador. Control del mouse y del teclado.
Además es indispensable que el usuario tenga conocimientos básicos en
matemáticas sobre las operaciones básicas, como saber sumar, restar, multiplicar y
dividir.
2.2.3. Restricciones de Software
En la sección 2.1.4 del SRS 1.0 están descritas las restricciones de software necesarias para
el desarrollo y ejecución de la aplicación.
2.2.4. Restricciones de Hardware
En la sección 2.1.3 del SRS 1.0 están descritas las restricciones de hardware necesarias para
el desarrollo y ejecución de la aplicación.
2.3. Entorno del Sistema
A continuación se muestra una tabla con el resumen de las características tanto del software
como del hardware, las cuales son indispensables para el completo y correcto
funcionamiento de la aplicación una vez instalada.
JHONATHAN CÓRDOBA CASTAÑEDA 14
Cliente
Hardware
Procesador Intel Pentium Dual Core 1.7 Ghz o equivalente
Adaptador y monitor Pantalla que soporte (1024 x 768) o mayor resolución
Disco duro Más 132 MB de espacio libre
RAM Mínimo 512 MB
Teclado con su respectivo driver instalado
Mouse con su respectivo driver instalado
Unidad de CD Capacidad de lectura mayor o igual a 52x
Software
Sistema Operativo Windows XP, Windows Vista, Windows 7 y Windows 8
Java Developement Kid Versión 6.0 o mayor
Tabla 2: Requerimiento de software y hardware.
Además, cabe mencionar lo siguiente:
Como una observación adicional, la herramienta no será alojada en ningún servidor
de aplicaciones puesto que no es una aplicación web.
Su servidor de base de datos es Orion, el cual pertenece a la facultad de Ingeniería
de la Pontifica universidad javeriana. Será la única interacción con sistemas
externos.
La aplicación utilizará routers, hubs o switches, dependiendo de la infraestructura
de la red mediante la cual establezca conexión con internet. (si es alámbrica o
inalámbrica.)
2.4. Metodología de Diseño
Se realizó un análisis detallado de las diferentes arquitecturas vistas durante el transcurso
de la carrera, y por cada una se determinó si contaba con las cualidades aptas para el
desarrollo del sistema de iZafiro, tomando en cuenta el comportamiento y los modos de
JHONATHAN CÓRDOBA CASTAÑEDA 15
comunicación entre los diferentes módulos. La arquitectura utilizada para el desarrollo del
prototipo es la de Stand-alone.
Además se tomó en cuenta también, la modalidad del software que iba a desarrollarse, en
este caso, una aplicación educativa de Ayuda Didáctica de apoyo en el aprendizaje en
tópicos matemáticos. Y de acuerdo a ello, viendo que los requerimientos en cuanto a
usabilidad son de gran importancia, se prestó una especial atención a soluciones que
apoyarían un buen despliegue de las imágenes y efectos gráficos dentro de la herramienta.
2.4.1. Metodología OMT (Técnica de modelado de objetos)
Esta metodología, propuesta por Rumbaugh [16], describe cuatro pasos que llevan al diseño
requerido para este tipo de aplicaciones:
1. Análisis: Es la fase que se dedica a la comprensión y modelado de la aplicación y del
dominio en el cual funciona. La entrada inicial de esta fase es una descripción del
problema que hay que resolver. La salida del análisis es un modelo formal que captura
los tres aspectos esenciales del sistema: Los objetos y sus relaciones, el flujo dinámico
de control, y la transformación funcional de datos que están sometidos a restricciones.
2. Diseño del sistema: Es la fase en la cual se determina la arquitectura global del sistema.
También se organiza el sistema en subsistemas utilizando el modelo de objetos como
guía. Se toman decisiones globales acerca de la comunicación entre procesos,
almacenamiento de dato.
3. Diseño de objetos: En esta fase se elaboran los modelos de análisis, se refinan, y después
se utilizan para producir un diseño práctico a un nivel más detallado. Se determina la
implementación de cada asociación y de cada atributo.
4. Implementación: En esta fase las clases de objetos y las relaciones planteadas en los
diagramas, son trasladados finalmente a un lenguaje de programación concreto.
JHONATHAN CÓRDOBA CASTAÑEDA 16
2.5. Riesgos
ID Riesgo de Diseño Riesgo
RD-01 Falta de capacitación del equipo de trabajo en cuanto a los
diagramas de comportamiento e interacción.
RD-02 Cambio de algún detalle en un diagrama del cual dependen otros
diagramas.
RD-03 Pérdida de los diagramas.
RD-04 Pérdida de los cambios realizados en los diagramas.
RD-05 Ataque de virus en la información de los diagramas y su
documentación.
RD-06 Cambio de requerimientos que implique cambios de los
diagramas.
RD-07 Incoherencia entre los diagramas y el prototipo.
RD-08 Encontrar errores en el diseño en el momento de la
implementación (implica pérdida de tiempo).
RD-09 El desarrollador no está en capacidad de abordar la arquitectura
seleccionada, para implementar componentes que sean
característicos de la misma.
Tabla 3: Riesgos de diseño identificados.
La siguiente tabla clasifica los riesgos identificados anteriormente de acuerdo a su
probabilidad de ocurrencia, y a partir de la misma, el impacto generado en el proceso.
Rango Probabilidad Impacto
1 Muy Baja Ninguno
2 Baja Bajo
3 Media Moderado
4 Alta Severo
5 Muy Alta Trágico
Tabla 4: Clasificación del riesgo.
JHONATHAN CÓRDOBA CASTAÑEDA 17
En la siguiente tabla, se califica a cada uno de los riesgos identificados de acuerdo a los
criterios planteados en cuanto a probabilidad e impacto.
Riesgo Probabilidad Impacto Criticidad
RD-01 4 3 7
RD-02 4 4 8
RD-03 2 5 7
RD-04 3 3 6
RD-05 1 4 5
RD-06 3 3 6
RD-07 4 4 8
RD-08 3 4 7
RD-09 3 3 6
Tabla 5: Criticidad de los Riesgos.
A continuación se describen las acciones para la mitigación de los riesgos, ya sea para
prevenirlos o para corregirlos.
Riesgo Controles
Preventivos Correctivos
RD-01 El diseñador debe realizar un previo
estudio o repaso en cuanto a la
manera de realizar los diagramas
solicitados.
Investigar en fuentes como libros,
internet o asesorarse mediante otras
personas para fortalecer la idea de los
diagramas a realizar.
RD-02 Hacer los respectivos cambios en los
diagramas que cambian,
inmediatamente se identifica el error
a corregir.
RD-03 Definir más de un sitio en donde se
guardarán los diagramas
(localmente, en la nube o en algún
medio extraíble).
Realizar nuevamente los diagramas
faltantes de acuerdo a lo elaborado
anteriormente. Realizarlos
inmediatamente luego de su perdida.
JHONATHAN CÓRDOBA CASTAÑEDA 18
RD-04 Realizar el correspondiente control
de versiones de los diagramas en
cada uno de los repositorios.
Realizar los cambios en todos los
diagramas desde la última versión
aprobada.
RD-05 Se realiza el mismo control que con
el riesgo RD-03. Además, debe
contarse con una licencia de
antivirus en cada computador en el
cual se tengan los diagramas.
Identificar la última versión que se
encuentre limpia para continuar
desde la misma. Instalar el antivirus
en los lugares respectivos.
RD-06 Realizar las modificaciones
pertinentes en los diagramas de
acuerdo a los cambios surgidos en
los requerimientos.
RD-07 Dedicación a un muy buen diseño
para evitar inconvenientes al
momento de la elaboración del
prototipo.
Modificar el prototipo de acuerdo a
los cambios hechos en los diagramas.
De ser necesario, cambiar el diseño
en caso de que éste sea erróneo.
RD-08 Dedicación a un muy buen diseño
para evitar inconvenientes al
momento de la elaboración del
prototipo.
Corregir el diseño para poder
modificar el prototipo.
RD-09 El diseñador debe realizar un previo
estudio o repaso en cuanto a las
arquitecturas más utilizadas en los
videojuegos.
Una vez elegida la arquitectura, si
esta es demasiado compleja para el
desarrollador, debe de contemplarse
la idea de cambiarla si por cuestiones
de tiempo se trata.
Tabla 6: Plan de control de riesgos.
JHONATHAN CÓRDOBA CASTAÑEDA 19
3. Arquitectura
3.1. Apreciación Global
De acuerdo con todos los aspectos mencionados en la sección 1.1 Descripción del Sistema,
y los requerimientos especificados en el documento SRS, la arquitectura de iZafiro estará
diseñada de tal manera que atienda las funcionalidades en cuanto a las características de un
videojuego modalidad RPG/Acción [17], y además, que vaya acorde con la dinámica de la
metodología del Proyecto EJE (o Simulación Dramatizada) basada en retos o puzzles.
Con base en la idea de que el videojuego contará con una partida independiente para cada
jugador, la aplicación concentrará sus módulos en un solo computador de manera
centralizada (esto es independiente de la interacción del sistemas con la base de la datos del
videojuego alojada remotamente). Y por ello, se implementará la arquitectura Stand-alone.
Ilustración 1: Módulos de iZafiro.
JHONATHAN CÓRDOBA CASTAÑEDA 20
Se observa a partir de la ilustración anterior, la interacción que se da entre iZafiro y el
servidor de Orion (a través de alguna red) únicamente en cuanto a las base de datos que
persiste los datos de todos los jugadores. Para ello, el módulo encargado de establecer las
conexiones y realizar las consultas respectivas es el Gestor Persistencia. Todos los equipos
en los cuales se ejecuta la aplicación, interactúan con la misma base de datos.
Beneficios:
Centralización de la información en la misma base de datos.
Comunicación inmediata entre los diferentes módulos de la aplicación, debido a
que se encuentran en un mismo equipo.
Fácil mantenibilidad y modificación de componentes.
Carga rápida de las imágenes del videojuego., pues son cargadas y mostradas en el
mismo equipo.
Riesgos:
Al surgir una nueva versión, debe de reinstalarse en cada equipo, uno por uno.
El servidor orion debe de estar disponible cada vez que se requiera operar sobre los
datos allí alojados.
3.2. Diagrama de Componentes
En la siguiente ilustración, se muestra en detalle cómo están separados los componentes que
conforman la aplicación, y en que niveles se encuentra cada uno, de acuerdo a las
funcionalidades que tenga destinadas realizar. El concepto de niveles o capas es aplicable
para dar una idea clara de cómo está organizada la aplicación, aunque no quiere decir que
cada una se encuentre operando en equipos o servidores diferentes a través de la web.
JHONATHAN CÓRDOBA CASTAÑEDA 21
Ilustración 2: Diagrama de Componentes de iZafiro.
JHONATHAN CÓRDOBA CASTAÑEDA 22
Componente Presentación Inicial: Este componente es el encargado de mostrar las
primeras ventanas de la aplicación, comenzando con el menú principal, además de
los créditos y la introducción del juego.
Presentación de Estadísticas: Es el componente encargado de mostrar al usuario el
Top 5 de los jugadores con el mejor puntaje registrado en la base de datos de orion.
Componente de Manejo de Acceso: Además de solicitar información de un nuevo
usuario o uno ya existente para continuar con su partida. Este componente es la
comunicación directa con la capa de Integración (acceso a bases de datos). Está
encargado de realizar los registros de los nuevos usuarios a la base de datos local y
remota, y además se encarga de validar la existencia de un usuario cuando éste
intenta entrar a una partida ya existente.
Gestor de Desplazamiento: Es el componente encargado de mantener en orden
todos los escenarios para dar una lógica geográfica dentro de la partida. Y permite
que el usuario tenga la posibilidad de desplazarse en las cuatro direcciones (arriba,
abajo, izquierda y derecha) siempre y cuando no hayan obstáculos en frente.
Además se encarga de validar cada una de las acciones mientras el personaje se
encuentra en el mapa, ya sea para atacar a los enemigos, establecer un diálogo con
algún personaje, para pausar el juego, para pedir ayuda, para aceptar algún reto,
etc.
Gestor Estado de Partida: Se encarga de actualizar todos los datos sobre la partida
cada vez que se requiera, como por ejemplo el puntaje actual del jugador, los
recursos que posee, la ubicación en el mapa y la salud (unidades sobre 5).
Gestor de Juegos Puzzle: Una vez aceptado algún reto, este componente determina
cuál de todos deberá ejecutarse, tomando en cuenta en que parte del juego está el
jugador. Una vez finalizada la prueba. Durante el desarrollo del reto o actividad
puzzle, este componente se encarga de validar si la jugada reciente del jugador ha
sido la correcta o no, y dependiendo de ello, sumará o no al puntaje parcial del
ejercicio. También se determinará, de acuerdo al total, si el jugador superó la prueba
o deberá repetirla.
Gestor de Persistencia Local: Es el componente encargado de administrar todas las
consultas realizadas sobre la base de datos local (archivo plano) almacenada en el
equipo que esté ejecutando iZafiro.
JHONATHAN CÓRDOBA CASTAÑEDA 23
Gestor de Persistencia Remota: Es el componente encargado de administrar todas
las consultas realizadas sobre la base de datos remota, almacenada en el servidor
orion de la Pontificia Universidad Javeriana.
Componente Oracle DataBase: Como se puede ver en el diagrama, este
componente está en el nivel más bajo de la arquitectura, se encuentra comunicado
únicamente con el componente de acceso remoto a datos de la capa de integración
y es el que se encarga de almacenar todos los datos de los usuarios de iZafiro.
Componente datoslocales: Es el componente en el cual son almacenados los datos
de los usuarios de manera local permitiendo así el uso del juego sin necesidad de
estar conectado a Internet.
3.3. Estrategias de Diseño
En esta sección se describen las estrategias que se han utilizado para el correcto desarrollo
de la herramienta. Se tomó como referencia la tabla propuesta en la sección 3.3 de la
plantilla SDD de IRONWORKS [15]:
Estrategia de Diseño Descripción
Patrones de Diseño
En la aplicación iZafiro se ha hecho uso de 2 patrones de
diseño los cuales son explicados a continuación:
Singleton: Es necesario para el manejo de clases que
debe ser instanciadas solamente una vez. Ejemplo: La
clase GestorJuego o la clase Tiempo.
Observer: Es necesario para la actualización de
ciertos estados de la parida, inmediatamente se da un
evento en especial. Ejemplo: en el momento en el la
hora interna de la partida de las 17:00, todos los
escenarios deben de actualizar su capa superior
aparentando así un efecto de atardecer. Y lo mismo
para cuando la hora da las 19:00 para que se dé el
efecto de la noche en cada escenario.
JHONATHAN CÓRDOBA CASTAÑEDA 24
Estilos Arquitectónicos
El estilo arquitectónico escogido es el de Multiniveles
porque es el que facilitará la organización o clasificación
de cada uno de los módulos que componen la aplicación,
pensando en su fáciles modificaciones, tal cual como se
menciona en la sección 3.2. De acuerdo a esto, los niveles
están enumerados como:
Presentación
Negocio
Integración (con las bases de datos)
Datos (artefactos como el archivo plano y la base
de datos remota)
Priorización de
Requerimientos
De acuerdo a la importancia considerada para la
implementación de cada uno de los requerimientos se
definieron 3 calificaciones:
Alta: El requerimiento es indispensable pensando
en el propósito y alcance del sistema, y por tanto es
obligatoria su implementación.
Media: La importancia del requerimiento no es tan
alta, aunque es recomendable su implementación
puesto que agrega funcionalidades útiles.
Baja: La no implementación de este requerimiento
no influye de manera indispensable en el
funcionamiento del sistema. Pero no sobra su
implementación.
Tabla 7: Estrategias de Diseño.
JHONATHAN CÓRDOBA CASTAÑEDA 25
4. Diseño de Alto Nivel
En esta sección, se dará a conocer el diseño de alto nivel de iZafiro mediante diagramas que
representen el funcionamiento en interacción entre los diferentes módulos desde diferentes
vistas.
En la siguiente ilustración se muestran los diferentes niveles de detalle con los cuales se
muestra el diseño de la aplicación en este documento.
Ilustración 3: Niveles de detalle de la aplicación.
4.1. Diagrama de Despliegue
Los diagramas de despliegue muestran la configuración de los nodos que participan en la
ejecución y de los componentes que residen en ellos [16]. En la ilustración 4 se muestra el
diagrama de despliegue de la aplicación iZafiro, donde se muestra el nodo Cliente, y el nodo
Orion correspondiente al servidor que aloja la base de datos del videojuego. Y seguidamente
se muestra la especificación de cada uno de los nodos mediante la planilla sugerida por
IRONWORKS en su documento del SDD [15].
Aplicación iZafiro
Niveles
Módulos Componentes
Clases
Métodos y atributos
JHONATHAN CÓRDOBA CASTAÑEDA 26
Ilustración 4: Diagrama de Despliegue de iZafiro.
4.1.1. Nodo Cliente
Nombre del nodo Cliente
Especificación
Disco duro de 80 GB. 153 MB para
el JDK versión 7.
132 MB libres en RAM.
Procesador Intel Pentium Dual
Core o procesadores compatibles. Ubicación
La ubicación
exacta de cada
uno de los PC,
en los cuales
esté instalada la
aplicación.
Sistema operativo Windows XP,
Vista, 7 u 8. Mac OS X
JDK 6.0 o superior.
Componentes Comentarios adicionales
Presentación Inicial
Presentación de
Estadísticas
Manejo de Acceso
Gestor Estado de
Partida
Gestor de
Desplazamiento
Gestor de Juegos Puzzle
Gestor Persistencia
Archivo plano (BDL)
Nivel de Presentación
Nivel de Negocio
Nivel de Integración
Tabla 8: Especificación Nodo Cliente.
JHONATHAN CÓRDOBA CASTAÑEDA 27
4.1.2. Nodo Orion
Nombre del nodo Orion
Especificación
Mínimo 50 Megabytes de
capacidad de
almacenamiento para
albergar por lo menos 500
tuplas (una por cada
jugador) las cuales tiene un
peso de 100 kilobytes (0.1
MB) cada una.
Ubicación
Sala de Servidores en
la Facultad de
Ingeniería, de la
Pontificia Universidad
Javeriana.
Componentes Comentarios adicionales
Base de Datos Remota de iZafiro. Ninguno
Tabla 9: Especificación Nodo Orion.
4.2. Diagramas de Comportamiento e Interacción
Los diagramas de comportamiento de UML permiten tener un mejor acercamiento a lo que
sucederá cuando la aplicación realice alguna funcionalidad específica [15]. Los diagramas
de interacción tiene como propósito ilustrar el modo en el que los objetos de un sistema
interactúan por medio de mensajes, y con esto, permiten modelar la vista dinámica de dichas
interacciones y ayudan a implementar la lógica de los métodos [18].
A continuación a través de los diagramas de actividad y de secuencia se mostrará las
principales funcionalidades de la herramienta.
4.2.1. Diagramas de Actividad
Un diagrama de actividades muestra el flujo de actividades realizadas por diferentes actores.
Una actividad es una ejecución no atómica en curso, dentro de una máquina de estados [16].
A continuación se muestran los diagramas de actividades realizados para el desarrollo de la
aplicación iZafiro, utilizando los escenarios descritos en el documento de especificación de
Casos de Uso:
[iZafiro] - Casos de Uso_(1.0)_Linea_Base.pdf
JHONATHAN CÓRDOBA CASTAÑEDA 28
4.2.1.1. Módulo de Manejo de Acceso
Ilustración 5: Diagrama Actividad - Registrar Nuevo Usuario.
JHONATHAN CÓRDOBA CASTAÑEDA 29
4.2.1.2. Módulo Gestor de Juegos Puzzle
Ilustración 6: Diagrama Actividad - Jugar Turno Puzzle 1.
JHONATHAN CÓRDOBA CASTAÑEDA 30
Ilustración 7: Diagrama Actividad - Jugar Turno Puzzle 2.
JHONATHAN CÓRDOBA CASTAÑEDA 31
Ilustración 8: Diagrama Actividad - Jugar Turno Puzzle 3.
JHONATHAN CÓRDOBA CASTAÑEDA 32
Ilustración 9: Diagrama Actividad - Jugar Turno Puzzle 4.
JHONATHAN CÓRDOBA CASTAÑEDA 33
Ilustración 10: Diagrama Actividad - Jugar Turno Puzzle 5
JHONATHAN CÓRDOBA CASTAÑEDA 34
Ilustración 11: Diagrama Actividad - Jugar Turno Puzzle 6.
JHONATHAN CÓRDOBA CASTAÑEDA 35
Ilustración 12: Diagrama Actividad - Jugar Turno Puzzle 7.
JHONATHAN CÓRDOBA CASTAÑEDA 36
4.2.2. Diagramas de Secuencia
Un diagrama de secuencia es un diagrama de interacción que destaca la ordenación temporal
de los mensajes entre diferentes actores para llevar a cabo con alguna de las funcionalidades
del sistema.
Al igual que con los diagramas de actividad, los diagramas de secuencia están agrupados
por los módulos o componentes definidos. A continuación se muestran los más
significativos para la aplicación.
4.2.2.1. Módulo de Manejo de Acceso
Registrar Nuevo Usuario
Registrar un nuevo usuario en la base de datos remota (BD Orion) al iniciar una partida, con
un nombre de usuario y una contraseña. El nombre de usuario no puede ser uno que ya se
encuentre registrado en la base de datos.
Ilustración 13: Diagrama secuencia - Registrar Nuevo Usuario.
JHONATHAN CÓRDOBA CASTAÑEDA 37
Jugar Turno Puzzle 2 (Cima del Trueno)
Seleccionar la fracción correcta entre las cinco opciones, de acuerdo a la representación
gráfica mostrada en pantalla.
Ilustración 14: Diagrama Secuencia - Jugar Turno Puzzle 2.
JHONATHAN CÓRDOBA CASTAÑEDA 38
5. Diseño de Bajo Nivel
5.1. Diagrama de Clases
A continuación, se muestra el diagrama de clases de la aplicación en donde puede verse cada una de las clases que harán parte del diseño de bajo nivel, y por cada una, sus respectivos atributos y métodos. También se muestra sus relaciones.
Ilustración 15: Diagrama de Clases.
JHONATHAN CÓRDOBA CASTAÑEDA 39
A continuación se muestran algunas de las clases del diagrama anterior, mapeadas sobre cada uno de los
módulos que componen la aplicación.
Modulo o Componente Clases (algunas)
Módulo de Presentación Inicial
IZafiro
IniciarApp
Historia
Creditos
Modulo Manejo de Acceso
CrearPartida
ContinuarPartida
Modulo Gestor Estado de Partida
GestorJuego
Deposito
Tiempo
Pausa
Modulo Gestor de Desplazamiento
Desplazamiento
Reloj
GuardarPartida
Escenario
Ayuda
Espadazo
Modulo Gestor de Juegos Puzzle
Prueba Puzzle
Puzzle1
Puzzle2
Puzzle3
Puzzle4
Puzzle5
Puzzle6
Puzzle7
Modulo Gestor de Persistencia
AdministradorConsultaSQL
AdministradorBDLocal
Conexión
Tabla 10: Relación Módulos y Clases.
JHONATHAN CÓRDOBA CASTAÑEDA 40
6. Diseño de Interfaces de Usuario
6.1. Árbol de Navegabilidad
A continuación se muestra el árbol de navegabilidad de la aplicación iZafiro, el cual inicia con la ventana de menú principal. También se muestra el mapa o la serie de escenarios sobre los cuales se desarrolla la partida. Las líneas sin puntero (flecha), significan un desplazamiento bidireccional entre ventanas.
Ilustración 16: Árbol de Navegación de iZafiro.
Menú Principal
Continuar Partida Créditos
Juegos Puzzle
(desbloqueados)
Top 5 de Jugadores
Registrar Nuevo
Usuario
Seleccionar Personaje
Historia
Puzzle 1
Puzzle 2
Puzzle 3 Puzzle 4
Puzzle 5
Puzzle 6
Puzzle 7
Puzzle 8
top related