SDD Documento de - pegasus.javeriana.edu.copegasus.javeriana.edu.co/~CIS1310IS08/archivos/[iZafiro] - SDD_(1.0... · 17 de Octubre 2013 1, 2 Descripción Global de la Arquitectura

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


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


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


6. DISEÑO DE INTERFACES DE USUARIO ...................................................... 40

6.1. ÁRBOL DE NAVEGABILIDAD .................................................................. 40


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


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


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.


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]


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





[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



[13] Volere Requeriments Resources. Volere Requeriments Especification Template.

Disponible en: http://www.volere.co.uk/template.htm



[15] IRONWORKS, Plantilla SDD, Segundo Semestre 2008, Pontificia Universidad


[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]


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


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.


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.


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.


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


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.


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.


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.


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.


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.


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.


Ilustración 2: Diagrama de Componentes de iZafiro.


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.


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.


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.


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


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.


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


4.2.1.1. Módulo de Manejo de Acceso

Ilustración 5: Diagrama Actividad - Registrar Nuevo Usuario.


4.2.1.2. Módulo Gestor de Juegos Puzzle

Ilustración 6: Diagrama Actividad - Jugar Turno Puzzle 1.








Ilustración 10: Diagrama Actividad - Jugar Turno Puzzle 5






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.


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.


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.


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.


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

Documents

SDD Documento de - pegasus.javeriana.edu.copegasus.javeriana.edu.co/~CIS1310IS08/archivos/[iZafiro] - SDD_(1.0... · 17 de Octubre 2013 1, 2 Descripción Global de la Arquitectura