You are on page 1of 41

Noviembre de 2013 SDD – Documento de

Diseño del Sistema
Versión 1.0

JHONATHAN A CÓRDOBA CASTAÑEDA
PONTIFICIA UNIVERSIDAD JAVERIANA

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 1

Historial de Cambios

Sección
Versión Fecha Descripción Responsable
Modificada
16 de Octubre Creación de portada, tabla Jhonathan Córdoba
0.1 1
2013 historial de cambios. Castañeda
17 de Octubre Descripción Global de la Jhonathan Córdoba
0.2 1, 2
2013 Arquitectura Castañeda
19 de Octubre Adición de nuevas Jhonathan Córdoba
0.3 2
2013 secciones Castañeda
22 de Octubre Elaboración del Plan de Jhonathan Córdoba
0.4 2
2013 Riesgos Castañeda
24 de Octubre Adición de nuevas Jhonathan Córdoba
0.5 2, 3
2013 secciones Castañeda
26 de Octubre Adición de nuevas Jhonathan Córdoba
0.6 3,4
2013 secciones Castañeda
27 de Octubre Elaboración Diagramas de Jhonathan Córdoba
0.7 4
2013 Actividad Castañeda
30 de Octubre Elaboración de Diagramas Jhonathan Córdoba
0.8 4
2013 de Secuancia Castañeda
2 de Noviembr Adición del Diagrama de Jhonathan Córdoba
0.9 5
2013e Clases Castañeda
4 de Noviembre Adición del Árbol de Jhonathan Córdoba
1.0 5, 6
2013 Navegación Castañeda

JHONATHAN CÓRDOBA CASTAÑEDA 2

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 3

....................................... ÁRBOL DE NAVEGABILIDAD . 40 6...... 6......... DISEÑO DE INTERFACES DE USUARIO .....................1......................................... 40 JHONATHAN CÓRDOBA CASTAÑEDA 4 .......

.... 21 Ilustración 3: Niveles de detalle de la aplicación................. ............................................................... 30 Ilustración 8: Diagrama Actividad ......Jugar Turno Puzzle 6...... 34 Ilustración 12: Diagrama Actividad .............. 26 Ilustración 5: Diagrama Actividad .............. 38 Ilustración 16: Árbol de Navegación de iZafiro.. ............ ....Jugar Turno Puzzle 2....... ................... ... 36 Ilustración 14: Diagrama Secuencia . 19 Ilustración 2: Diagrama de Componentes de iZafiro. 31 Ilustración 9: Diagrama Actividad ..... .................................... 32 Ilustración 10: Diagrama Actividad . .... .........................Registrar Nuevo Usuario.................... 33 Ilustración 11: Diagrama Actividad . ........Jugar Turno Puzzle 1..Jugar Turno Puzzle 5 .... ................. 29 Ilustración 7: Diagrama Actividad ...........Jugar Turno Puzzle 4....................................Jugar Turno Puzzle 2.......................... 25 Ilustración 4: Diagrama de Despliegue de iZafiro......................... ........................ .......Jugar Turno Puzzle 3...... 35 Ilustración 13: Diagrama secuencia .................................................................................. 40 JHONATHAN CÓRDOBA CASTAÑEDA 5 ......................................................... Lista de Ilustraciones Ilustración 1: Módulos de iZafiro...........Jugar Turno Puzzle 7............... ..................... ......... .................................... 28 Ilustración 6: Diagrama Actividad ............. 37 Ilustración 15: Diagrama de Clases.....Registrar Nuevo Usuario........

............ 18 Tabla 7: Estrategias de Diseño........ 24 Tabla 8: Especificación Nodo Cliente......................................... 16 Tabla 4: Clasificación del riesgo........................................................................... ........................... ..... 16 Tabla 5: Criticidad de los Riesgos...................... 39 JHONATHAN CÓRDOBA CASTAÑEDA 6 ........................................................................ 27 Tabla 10: Relación Módulos y Clases.................................... ................................. ....... 17 Tabla 6: Plan de control de riesgos. ............ ...... Lista de Tablas Tabla 1: Suposiciones y Dependencias.......................... 14 Tabla 3: Riesgos de diseño identificados............................... ................ 26 Tabla 9: Especificación Nodo Orion......................................... .......................................................... ...................................... .............. 12 Tabla 2: Requerimiento de software y hardware............................................

de los usuarios objetivos para los cuales está destinada. El sistema estará conformado (de acuerdo a lo expuesto en el documento SRS 1. JHONATHAN CÓRDOBA CASTAÑEDA 7 . Introducción 1. iZafiro no es un sistema distribuido. 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. 2. Las restricciones generales para poder cumplir con los requerimientos de esta arquitectura son descritas en las secciones 2.0. que tengan conocimiento de las operaciones básicas en matemáticas (suma. multiplicación y división) y que estén en capacidad de leer. El sistema interactúa con la base de datos alojada remotamente en el servidor Orion de la Pontificia Universidad Javeriana.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. 2.2. 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. 1. 1. así como también.1.1.2. así que no habrá necesidad de internet si no se tiene posibilidad o si no se desea. resta. 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.4 del documento SRS 1. 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.3 y 2. Descripción del Sistema En esta primera sección se realiza una descripción a nivel general de la arquitectura de la herramienta iZafiro. 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).

Disponible en: http://www. Developer Tools. Página [12] JHONATHAN CÓRDOBA CASTAÑEDA 8 . Facultad de Ciencias de la Educación. 6]. Disponible en: http://www.Creativo.3. [Citado 2013 Nov. Junio 1998.  Diseño de bajo nivel:  Diagrama de clases. IEEE Recommended Practice for Software Requirements Specificacitions. Diccionario informático. Disponible en: http://www. Referencias y Documentos de Apoyo [1] Maria Dolores Sánchez Gala. Universidad de Málaga. [3] Oracle Corporation.com/term/1439. 2006. Plantilla SRS. Mayo de 2007.oracle.com.ar/Dic/hardware.14.  Diagrama de componentes. [Manual en Internet]. IEEE-SA Standards Board. Departamento de Métodos de Investigación e Innovación Educativa.com.php [5] Glosarium.  Diagramas de actividad y de secuencia. Tesis Doctoral: La Dramatización en Educación Primaria como eje del Aprendizaje Lúdico . Segundo Semestre 2008.  Diagrama Entidad Relación  GUI  Árbol de Navegabilidad 1. Málaga. Estados Unidos: Oracle Technology Network. [2] IEEE (Institute of Electrical and Electronics Engineers). Pontificia Universidad Javeriana.xhtml [6] IRONWORKS.alegsa. “Diccionario informático hardware típico de una computadora”.glosarium.com/technetwork/developer-tools/sql-developer/what-is-sqldev- 093866. What is SQL Developer?.html [4] ALEGSA.

Madrid: Pearson Educación. Segundo Semestre 2008. What. American Library Association. Pontificia Universidad Javeriana.volere. Plantilla SDD.A. Disponible en: http://www. Pontificia Universidad Javeriana. (Volumen 1. Segundo Semestre 2008. Plantilla SRS. Gamers in the Library? The Why. ¿Cuáles son los requisitos del sistema para Java 7? [Guía en Internet]. 2006. El lenguaje SQL. Segundo Semestre 2008.xml [8] Carme Martín Escofet.java. Pontificia Universidad Javeriana. Disponible en: http://www. Pág. and Jacobson I. Página [14] [11] Larman C. El lenguaje unificado de modelado. 41 [12] IRONWORKS. Prentice Hall. Página [13] [10] IRONWORKS. 1st ed. Rumbaugh J. No3): 5.2004 [17] Eli Neiburger. Pontificia Universidad Javeriana.. Plantilla SRS. Volere Requeriments Especification Template. Segundo Semestre 2008. UML Y PATRONES. Febrero 2007. Primera edición. Plantilla SRS. 2nd ed. Plantilla SRS. Universitat Oberta de Catalunya. Segundo Semestre 2008. Estados Unidos: Recursos de Ayuda. Página [25] [13] Volere Requeriments Resources. and how of Videogame Tournaments for al Ages. Aragón DF. 16]. S.com/es/download/help/sysreq. [9] IRONWORKS. Una introducción al análisis y diseño orientado a objetos y al proceso unificado.co.uk/template. Página [7] [16] Booch G.. [7] Oracle Corporation. Pontificia Universidad Javeriana. 2007. Página [29] [15] IRONWORKS.htm [14] IRONWORKS. Página [54] JHONATHAN CÓRDOBA CASTAÑEDA 9 . [Citado 2013 Sept.

us.es/docencia/get. [Citado 2013 Nov. [18] Escuela Técnica Superior de Ingeniería Informática. Diagramas de interacción UML + Patrones de Asignación de Responsabilidades (GRASP). Disponible en: http://www.lsi.php?id=1610. JHONATHAN CÓRDOBA CASTAÑEDA 10 . Departamento de Lenguajes y Sistemas Informáticos. 2].

Artefacto Producto de software resultado de una serie de actividades. 1. SQL Developer [3] Definen el comportamiento interno del software: cálculos. Requerimientos detalles técnicos. acrónimos y abreviaturas Término Descripción Software Design Document. JDeveloper Herramienta de desarrollo de la aplicación. Definiciones. Todas aquellas personas u organizaciones que afectan o son Stakeholders afectadas por el proyecto [4]. Documento de Diseño del Sistema. La tolerancia a fallos es la propiedad de ciertos computadores Tolerancia a fallos y/o aplicaciones software de funcionar aun cuando se haya producido una avería en alguno de sus componentes [5]. Palabra utilizada para describir la situación que se presentaría Supuesto si no se implementara un requerimiento. Papel que representa a las personas que interactúan en forma Usuario directa con el sistema cuando realizan su trabajo. manipulación de datos y otras funcionales funcionalidades específicas que muestran cómo los casos de uso serán llevados a la práctica.4. Especifican criterios que pueden usarse para juzgar la Requerimientos no operación de un sistema en lugar de sus comportamientos funcionales específicos. Es un código intermedio más abstracto que el código de Bytecode máquina. Documento donde se explica desde diferentes niveles SDD y desde diferentes entregables el diseño de la aplicación. sus componentes y la manera en como las funcionalidades se llevan a cabo. JHONATHAN CÓRDOBA CASTAÑEDA 11 .

Tabla 1: Suposiciones y Dependencias.1 del documento SRS 1. Consideraciones de Diseño 2.0 (Línea Base) de IRONWORKS [15]: Grupo Suposiciones y dependencias  El equipo de desarrollo cuenta con las plataformas necesarias para el desarrollo de la aplicación y la realización de pruebas.0.  Los equipos en los cuales se ejecutará la aplicación tienen el hardware requerido.1. JHONATHAN CÓRDOBA CASTAÑEDA 12 . 2. El equipo de  Se cuenta con el apoyo de herramientas CASE y de desarrollo 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). Suposiciones En esta sección se describen las suposiciones y dependencias identificadas para la elaboración de un diseño consistente. el cual se encuentra descrito en la sección 2. completo y correcto del sistema.  No se realizarán modificaciones sobre los requerimientos El cliente funcionales del sistema durante el desarrollo de la aplicación.  Contará con una conexión a internet (si se desea participar en la competencia online con otros jugadores de distintas partes).  En cuanto al software requerido para los computadores. Equipos mínimo deben tener JDK para poder ejecutar la aplicación (Computadores) con éxito. A continuación se agrupan estas suposiciones según los tres grupos generales propuestos en la plantilla SDD 1.

Restricciones 2.4 del SRS 1.1.0 están descritas las restricciones de hardware necesarias para el desarrollo y ejecución de la aplicación.3.4. 2. Restricciones de Software En la sección 2.1.  Además es indispensable que el usuario tenga conocimientos básicos en matemáticas sobre las operaciones básicas.1.2. 2.  Manejo básico de un computador.3. como saber sumar. 2.2. Restricciones de Hardware En la sección 2. JHONATHAN CÓRDOBA CASTAÑEDA 13 . Control del mouse y del teclado.3 del SRS 1.0 están descritas las restricciones de software necesarias para el desarrollo y ejecución de la aplicación.2.2.2. 2. 2. las cuales son indispensables para el completo y correcto funcionamiento de la aplicación una vez instalada.2. multiplicar y dividir. Restricciones Generales  La aplicación estará desarrollada únicamente en el idioma español. Restricciones de Usuario  El usuario debe saber leer. Entorno del Sistema A continuación se muestra una tabla con el resumen de las características tanto del software como del hardware. restar.  La tolerancia a fallos en la herramienta no será tenida en cuenta para esta versión.

cabe mencionar lo siguiente:  Como una observación adicional.) 2.  Su servidor de base de datos es Orion.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. Cliente Hardware Procesador Intel Pentium Dual Core 1.  La aplicación utilizará routers.0 o mayor Tabla 2: Requerimiento de software y hardware.4. y por cada una se determinó si contaba con las cualidades aptas para el desarrollo del sistema de iZafiro. Además. Windows Vista. tomando en cuenta el comportamiento y los modos de JHONATHAN CÓRDOBA CASTAÑEDA 14 . Windows 7 y Windows 8 Java Developement Kid Versión 6. hubs o switches. (si es alámbrica o inalámbrica. Metodología de Diseño Se realizó un análisis detallado de las diferentes arquitecturas vistas durante el transcurso de la carrera. Será la única interacción con sistemas externos. dependiendo de la infraestructura de la red mediante la cual establezca conexión con internet. la herramienta no será alojada en ningún servidor de aplicaciones puesto que no es una aplicación web. el cual pertenece a la facultad de Ingeniería de la Pontifica universidad javeriana.

describe cuatro pasos que llevan al diseño requerido para este tipo de aplicaciones: 1. en este caso. La salida del análisis es un modelo formal que captura los tres aspectos esenciales del sistema: Los objetos y sus relaciones.1. comunicación entre los diferentes módulos. Además se tomó en cuenta también. Implementación: En esta fase las clases de objetos y las relaciones planteadas en los diagramas. y después se utilizan para producir un diseño práctico a un nivel más detallado. Diseño del sistema: Es la fase en la cual se determina la arquitectura global del sistema. 3. La arquitectura utilizada para el desarrollo del prototipo es la de Stand-alone. Y de acuerdo a ello. 2. Se determina la implementación de cada asociación y de cada atributo. 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. JHONATHAN CÓRDOBA CASTAÑEDA 15 . 2. Metodología OMT (Técnica de modelado de objetos) Esta metodología. Diseño de objetos: En esta fase se elaboran los modelos de análisis. la modalidad del software que iba a desarrollarse. Se toman decisiones globales acerca de la comunicación entre procesos. el flujo dinámico de control. son trasladados finalmente a un lenguaje de programación concreto. una aplicación educativa de Ayuda Didáctica de apoyo en el aprendizaje en tópicos matemáticos. propuesta por Rumbaugh [16]. También se organiza el sistema en subsistemas utilizando el modelo de objetos como guía. se refinan. 4.4. 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. y la transformación funcional de datos que están sometidos a restricciones. La entrada inicial de esta fase es una descripción del problema que hay que resolver. almacenamiento de dato.

para implementar componentes que sean característicos de la misma. 2. RD-02 Cambio de algún detalle en un diagrama del cual dependen otros diagramas. RD-08 Encontrar errores en el diseño en el momento de la implementación (implica pérdida de tiempo). RD-05 Ataque de virus en la información de los diagramas y su documentación.5. La siguiente tabla clasifica los riesgos identificados anteriormente de acuerdo a su probabilidad de ocurrencia. el impacto generado en el proceso. JHONATHAN CÓRDOBA CASTAÑEDA 16 . RD-09 El desarrollador no está en capacidad de abordar la arquitectura seleccionada. RD-06 Cambio de requerimientos que implique cambios de los diagramas. y a partir de la misma. Tabla 3: Riesgos de diseño identificados. 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-07 Incoherencia entre los diagramas y el prototipo. 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. RD-04 Pérdida de los cambios realizados en los diagramas. RD-03 Pérdida de los diagramas.

ya sea para prevenirlos o para corregirlos. A continuación se describen las acciones para la mitigación de los riesgos. En la siguiente tabla. Realizarlos medio extraíble). JHONATHAN CÓRDOBA CASTAÑEDA 17 . RD-03 Definir más de un sitio en donde se Realizar nuevamente los diagramas guardarán los diagramas faltantes de acuerdo a lo elaborado (localmente. inmediatamente se identifica el error a corregir. en la nube o en algún anteriormente. RD-02 Hacer los respectivos cambios en los diagramas que cambian. se califica a cada uno de los riesgos identificados de acuerdo a los criterios planteados en cuanto a probabilidad e impacto. Riesgo Controles Preventivos Correctivos RD-01 El diseñador debe realizar un previo Investigar en fuentes como libros. estudio o repaso en cuanto a la internet o asesorarse mediante otras manera de realizar los diagramas personas para fortalecer la idea de los solicitados. 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. diagramas a realizar. inmediatamente luego de su perdida.

aprobada. momento de la elaboración del De ser necesario. Además. RD-07 Dedicación a un muy buen diseño Modificar el prototipo de acuerdo a para evitar inconvenientes al los cambios hechos en los diagramas. RD-08 Dedicación a un muy buen diseño Corregir el diseño para poder para evitar inconvenientes al modificar el prototipo. debe de contemplarse videojuegos. Instalar el antivirus antivirus en cada computador en el en los lugares respectivos. en caso de que éste sea erróneo. RD-04 Realizar el correspondiente control Realizar los cambios en todos los de versiones de los diagramas en diagramas desde la última versión cada uno de los repositorios. RD-05 Se realiza el mismo control que con Identificar la última versión que se el riesgo RD-03. la idea de cambiarla si por cuestiones de tiempo se trata. cambiar el diseño prototipo. Tabla 6: Plan de control de riesgos. RD-06 Realizar las modificaciones pertinentes en los diagramas de acuerdo a los cambios surgidos en los requerimientos. JHONATHAN CÓRDOBA CASTAÑEDA 18 . RD-09 El diseñador debe realizar un previo Una vez elegida la arquitectura. momento de la elaboración del prototipo. debe encuentre limpia para continuar contarse con una licencia de desde la misma. cual se tengan los diagramas. si estudio o repaso en cuanto a las esta es demasiado compleja para el arquitecturas más utilizadas en los desarrollador.

y además. 3. Y por ello. JHONATHAN CÓRDOBA CASTAÑEDA 19 .1 Descripción del Sistema. 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]. 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). Ilustración 1: Módulos de iZafiro. Apreciación Global De acuerdo con todos los aspectos mencionados en la sección 1. Con base en la idea de que el videojuego contará con una partida independiente para cada jugador.1. Arquitectura 3. que vaya acorde con la dinámica de la metodología del Proyecto EJE (o Simulación Dramatizada) basada en retos o puzzles. se implementará la arquitectura Stand-alone. y los requerimientos especificados en el documento SRS.

el módulo encargado de establecer las conexiones y realizar las consultas respectivas es el Gestor Persistencia. Beneficios:  Centralización de la información en la misma base de datos.  El servidor orion debe de estar disponible cada vez que se requiera operar sobre los datos allí alojados. Se observa a partir de la ilustración anterior. y en que niveles se encuentra cada uno. El concepto de niveles o capas es aplicable para dar una idea clara de cómo está organizada la aplicación. debido a que se encuentran en un mismo equipo. uno por uno.  Comunicación inmediata entre los diferentes módulos de la aplicación. JHONATHAN CÓRDOBA CASTAÑEDA 20 . debe de reinstalarse en cada equipo. Para ello. Riesgos:  Al surgir una nueva versión. interactúan con la misma base de datos. Todos los equipos en los cuales se ejecuta la aplicación.. de acuerdo a las funcionalidades que tenga destinadas realizar. se muestra en detalle cómo están separados los componentes que conforman la aplicación. 3.  Carga rápida de las imágenes del videojuego. aunque no quiere decir que cada una se encuentre operando en equipos o servidores diferentes a través de la web.  Fácil mantenibilidad y modificación de componentes.2. pues son cargadas y mostradas en el mismo equipo. Diagrama de Componentes En la siguiente ilustración. 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.

Ilustración 2: Diagrama de Componentes de iZafiro. JHONATHAN CÓRDOBA CASTAÑEDA 21 .

etc.  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. Durante el desarrollo del reto o actividad puzzle. Además se encarga de validar cada una de las acciones mientras el personaje se encuentra en el mapa. También se determinará. Y permite que el usuario tenga la posibilidad de desplazarse en las cuatro direcciones (arriba. para aceptar algún reto. izquierda y derecha) siempre y cuando no hayan obstáculos en frente. además de los créditos y la introducción del juego.  Componente de Manejo de Acceso: Además de solicitar información de un nuevo usuario o uno ya existente para continuar con su partida. establecer un diálogo con algún personaje. ya sea para atacar a los enemigos.  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. para pausar el juego.  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. abajo. sumará o no al puntaje parcial del ejercicio. si el jugador superó la prueba o deberá repetirla. los recursos que posee. y dependiendo de ello. Una vez finalizada la prueba. este componente se encarga de validar si la jugada reciente del jugador ha sido la correcta o no.  Componente Presentación Inicial: Este componente es el encargado de mostrar las primeras ventanas de la aplicación. Está encargado de realizar los registros de los nuevos usuarios a la base de datos local y remota. comenzando con el menú principal. tomando en cuenta en que parte del juego está el jugador. este componente determina cuál de todos deberá ejecutarse. de acuerdo al total. como por ejemplo el puntaje actual del jugador.  Gestor Estado de Partida: Se encarga de actualizar todos los datos sobre la partida cada vez que se requiera. y además se encarga de validar la existencia de un usuario cuando éste intenta entrar a una partida ya existente. Este componente es la comunicación directa con la capa de Integración (acceso a bases de datos). para pedir ayuda. la ubicación en el mapa y la salud (unidades sobre 5). JHONATHAN CÓRDOBA CASTAÑEDA 22 .  Gestor de Juegos Puzzle: Una vez aceptado algún reto.

 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. Estrategias de Diseño En esta sección se describen las estrategias que se han utilizado para el correcto desarrollo de la herramienta.3. Ejemplo: La clase GestorJuego o la clase Tiempo. Y lo mismo para cuando la hora da las 19:00 para que se dé el efecto de la noche en cada escenario. inmediatamente se da un evento en especial. Se tomó como referencia la tabla propuesta en la sección 3. este componente está en el nivel más bajo de la arquitectura. Ejemplo: en el momento en el la hora interna de la partida de las 17:00.  Componente Oracle DataBase: Como se puede ver en el diagrama. 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. JHONATHAN CÓRDOBA CASTAÑEDA 23 . almacenada en el servidor orion de la Pontificia Universidad Javeriana. todos los escenarios deben de actualizar su capa superior aparentando así un efecto de atardecer.  Gestor de Persistencia Remota: Es el componente encargado de administrar todas las consultas realizadas sobre la base de datos remota.3 de la plantilla SDD de IRONWORKS [15]: Estrategia de Diseño Descripción 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.  Observer: Es necesario para la actualización de Patrones de Diseño ciertos estados de la parida. 3.

los niveles Estilos Arquitectónicos 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) 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. JHONATHAN CÓRDOBA CASTAÑEDA 24 . 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.2.  Baja: La no implementación de este requerimiento no influye de manera indispensable en el funcionamiento del sistema. aunque es recomendable su implementación puesto que agrega funcionalidades útiles. tal cual como se menciona en la sección 3. Pero no sobra su implementación. y por tanto es Priorización de obligatoria su implementación. Requerimientos  Media: La importancia del requerimiento no es tan alta. Tabla 7: Estrategias de Diseño. pensando en su fáciles modificaciones. De acuerdo a esto.

1. 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]. En la ilustración 4 se muestra el diagrama de despliegue de la aplicación iZafiro. Aplicación iZafiro Niveles Módulos Componentes Clases Métodos y atributos Ilustración 3: Niveles de detalle de la aplicación. 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. 4. 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]. donde se muestra el nodo Cliente. 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. y el nodo Orion correspondiente al servidor que aloja la base de datos del videojuego. 4. JHONATHAN CÓRDOBA CASTAÑEDA 25 .

JHONATHAN CÓRDOBA CASTAÑEDA 26 . Ilustración 4: Diagrama de Despliegue de iZafiro. Nodo Cliente Nombre del nodo Cliente  Disco duro de 80 GB.1. Componentes Comentarios adicionales  Presentación Inicial  Gestor de  Nivel de Presentación  Presentación de Desplazamiento  Nivel de Negocio Estadísticas  Gestor de Juegos Puzzle  Nivel de Integración  Manejo de Acceso  Gestor Persistencia  Gestor Estado de  Archivo plano (BDL) Partida Tabla 8: Especificación Nodo Cliente. 7 u 8.1. uno de los PC. exacta de cada  132 MB libres en RAM. 153 MB para La ubicación el JDK versión 7. Mac OS X aplicación.0 o superior. Ubicación en los cuales  Sistema operativo Windows XP.  Procesador Intel Pentium Dual Especificación Core o procesadores compatibles. 4. esté instalada la Vista.  JDK 6.

utilizando los escenarios descritos en el documento de especificación de Casos de Uso:  [iZafiro] . Una actividad es una ejecución no atómica en curso.Casos de Uso_(1.1. Nodo Orion Nombre del nodo Orion  Mínimo 50 Megabytes de Sala de Servidores en capacidad de la Facultad de almacenamiento para Ingeniería. 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].1.1 MB) cada una. jugador) las cuales tiene un peso de 100 kilobytes (0.pdf JHONATHAN CÓRDOBA CASTAÑEDA 27 . permiten modelar la vista dinámica de dichas interacciones y ayudan a implementar la lógica de los métodos [18]. 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. dentro de una máquina de estados [16]. de la albergar por lo menos 500 Pontificia Universidad Especificación tuplas (una por cada Ubicación Javeriana. Componentes Comentarios adicionales  Base de Datos Remota de iZafiro. A continuación se muestran los diagramas de actividades realizados para el desarrollo de la aplicación iZafiro. Diagramas de Actividad Un diagrama de actividades muestra el flujo de actividades realizadas por diferentes actores. y con esto.0)_Linea_Base. 4.2.2. A continuación a través de los diagramas de actividad y de secuencia se mostrará las principales funcionalidades de la herramienta. 4. Ninguno Tabla 9: Especificación Nodo Orion.

2.1. 4.Registrar Nuevo Usuario. Módulo de Manejo de Acceso Ilustración 5: Diagrama Actividad . JHONATHAN CÓRDOBA CASTAÑEDA 28 .1.

Módulo Gestor de Juegos Puzzle Ilustración 6: Diagrama Actividad . JHONATHAN CÓRDOBA CASTAÑEDA 29 .Jugar Turno Puzzle 1.2.2.1. 4.

JHONATHAN CÓRDOBA CASTAÑEDA 30 .Jugar Turno Puzzle 2. Ilustración 7: Diagrama Actividad .

Jugar Turno Puzzle 3. JHONATHAN CÓRDOBA CASTAÑEDA 31 . Ilustración 8: Diagrama Actividad .

JHONATHAN CÓRDOBA CASTAÑEDA 32 . Ilustración 9: Diagrama Actividad .Jugar Turno Puzzle 4.

Ilustración 10: Diagrama Actividad .Jugar Turno Puzzle 5 JHONATHAN CÓRDOBA CASTAÑEDA 33 .

Jugar Turno Puzzle 6. Ilustración 11: Diagrama Actividad . JHONATHAN CÓRDOBA CASTAÑEDA 34 .

Ilustración 12: Diagrama Actividad . JHONATHAN CÓRDOBA CASTAÑEDA 35 .Jugar Turno Puzzle 7.

A continuación se muestran los más significativos para la aplicación. Ilustración 13: Diagrama secuencia . El nombre de usuario no puede ser uno que ya se encuentre registrado en la base de datos. 4. JHONATHAN CÓRDOBA CASTAÑEDA 36 .2. 4.2.Registrar Nuevo Usuario. Al igual que con los diagramas de actividad. 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. 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. los diagramas de secuencia están agrupados por los módulos o componentes definidos.1.2. con un nombre de usuario y una contraseña.2.

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.Jugar Turno Puzzle 2. Ilustración 14: Diagrama Secuencia .

JHONATHAN CÓRDOBA CASTAÑEDA 38 . Diagrama de Clases A continuación.5.1. Ilustración 15: Diagrama de Clases. También se muestra sus relaciones. sus respectivos atributos y métodos. 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. Diseño de Bajo Nivel 5.

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.A continuación se muestran algunas de las clases del diagrama anterior. JHONATHAN CÓRDOBA CASTAÑEDA 39 . mapeadas sobre cada uno de los módulos que componen la aplicación.

significan un desplazamiento bidireccional entre ventanas. Diseño de Interfaces de Usuario 6. JHONATHAN CÓRDOBA CASTAÑEDA 40 . Historia Menú Principal Continuar Partida Créditos Top 5 de Jugadores Registrar Nuevo Seleccionar Personaje Juegos Puzzle Usuario (desbloqueados) Puzzle 8 Puzzle 2 Puzzle 6 Puzzle 1 Puzzle 7 Puzzle 3 Puzzle 4 Puzzle 5 Ilustración 16: Árbol de Navegación de iZafiro.6. También se muestra el mapa o la serie de escenarios sobre los cuales se desarrolla la partida. Las líneas sin puntero (flecha). Árbol de Navegabilidad A continuación se muestra el árbol de navegabilidad de la aplicación iZafiro.1. el cual inicia con la ventana de menú principal.