SDD Documento de Diseño del Sistema

Transcripción

1 Noviembre de 2013 SDD Documento de Diseño del Sistema Versión 1.0 JHONATHAN A CÓRDOBA CASTAÑEDA PONTIFICIA UNIVERSIDAD JAVERIANA

2 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

3 Historial de Cambios Versión Fecha 16 de Octubre de Octubre de Octubre de Octubre de Octubre de Octubre de Octubre de Octubre de Noviembr 2013e 4 de Noviembre 2013 Sección Modificada 1 1, , 3 3, , 6 Descripción Creación de portada, tabla historial de cambios. Descripción Global de la Arquitectura Adición de nuevas secciones Elaboración del Plan de Riesgos Adición de nuevas secciones Adición de nuevas secciones Elaboración Diagramas de Actividad Elaboración de Diagramas de Secuancia Adición del Diagrama de Clases Adición del Árbol de Navegación Responsable Jhonathan Córdoba Castañeda Jhonathan Córdoba Castañeda Jhonathan Córdoba Castañeda Jhonathan Córdoba Castañeda Jhonathan Córdoba Castañeda Jhonathan Córdoba Castañeda Jhonathan Córdoba Castañeda Jhonathan Córdoba Castañeda Jhonathan Córdoba Castañeda Jhonathan Córdoba Castañeda JHONATHAN CÓRDOBA CASTAÑEDA 2

4 Tabla de Contenido 1. INTRODUCCIÓN DESCRIPCIÓN DEL SISTEMA MAPA DEL DISEÑO REFERENCIAS Y DOCUMENTOS DE APOYO DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS CONSIDERACIONES DE DISEÑO SUPOSICIONES RESTRICCIONES Restricciones Generales Restricciones de Usuario Restricciones de Software Restricciones de Hardware ENTORNO DEL SISTEMA METODOLOGÍA DE DISEÑO Metodología OMT (Técnica de modelado de objetos) RIESGOS ARQUITECTURA APRECIACIÓN GLOBAL DIAGRAMA DE COMPONENTES ESTRATEGIAS DE DISEÑO DISEÑO DE ALTO NIVEL DIAGRAMA DE DESPLIEGUE Nodo Cliente Nodo Orion DIAGRAMAS DE COMPORTAMIENTO E INTERACCIÓN Diagramas de Actividad Módulo de Manejo de Acceso Módulo Gestor de Juegos Puzzle Diagramas de Secuencia Módulo de Manejo de Acceso DISEÑO DE BAJO NIVEL DIAGRAMA DE CLASES JHONATHAN CÓRDOBA CASTAÑEDA 3

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

6 Lista de Ilustraciones Ilustración 1: Módulos de izafiro Ilustración 2: Diagrama de Componentes de izafiro Ilustración 3: Niveles de detalle de la aplicación Ilustración 4: Diagrama de Despliegue de izafiro Ilustración 5: Diagrama Actividad - Registrar Nuevo Usuario Ilustración 6: Diagrama Actividad - Jugar Turno Puzzle Ilustración 7: Diagrama Actividad - Jugar Turno Puzzle Ilustración 8: Diagrama Actividad - Jugar Turno Puzzle Ilustración 9: Diagrama Actividad - Jugar Turno Puzzle Ilustración 10: Diagrama Actividad - Jugar Turno Puzzle Ilustración 11: Diagrama Actividad - Jugar Turno Puzzle Ilustración 12: Diagrama Actividad - Jugar Turno Puzzle Ilustración 13: Diagrama secuencia - Registrar Nuevo Usuario Ilustración 14: Diagrama Secuencia - Jugar Turno Puzzle Ilustración 15: Diagrama de Clases Ilustración 16: Árbol de Navegación de izafiro JHONATHAN CÓRDOBA CASTAÑEDA 5

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

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

9 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 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 [3] Oracle Corporation. What is SQL Developer?. [Manual en Internet]. Estados Unidos: Oracle Technology Network, Developer Tools. [Citado 2013 Nov. 6]. Disponible en: html [4] ALEGSA. Diccionario informático hardware típico de una computadora, 2006; Disponible en: [5] Glosarium.com. Diccionario informático. Disponible en: [6] IRONWORKS, Plantilla SRS, Segundo Semestre 2008, Pontificia Universidad Javeriana. Página [12] JHONATHAN CÓRDOBA CASTAÑEDA 8

10 [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: [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.; 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: [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; Página [54] JHONATHAN CÓRDOBA CASTAÑEDA 9

11 [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: JHONATHAN CÓRDOBA CASTAÑEDA 10

12 1.4. Definiciones, acrónimos y abreviaturas Término Descripción Software Design Document. Documento de Diseño del Sistema. 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. 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] Definen el comportamiento interno del software: cálculos, Requerimientos detalles técnicos, 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. Requerimientos no funcionales Stakeholders Supuesto Tolerancia a fallos Usuario Especifican criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos. Todas aquellas personas u organizaciones que afectan o son afectadas por el proyecto [4]. Palabra utilizada para describir la situación que se presentaría si no se implementara un requerimiento. 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]. Papel que representa a las personas que interactúan en forma directa con el sistema cuando realizan su trabajo. JHONATHAN CÓRDOBA CASTAÑEDA 11

13 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 El equipo de desarrollo Equipos (Computadores) El cliente 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. 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). 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). 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 12

14 2.2. Restricciones 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 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 Restricciones de Software En la sección del SRS 1.0 están descritas las restricciones de software necesarias para el desarrollo y ejecución de la aplicación Restricciones de Hardware En la sección del SRS 1.0 están descritas las restricciones de hardware necesarias para el desarrollo y ejecución de la aplicación 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 13

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

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

17 2.5. Riesgos ID Riesgo de Diseño RD-01 RD-02 RD-03 RD-04 RD-05 RD-06 RD-07 RD-08 RD-09 Riesgo Falta de capacitación del equipo de trabajo en cuanto a los diagramas de comportamiento e interacción. Cambio de algún detalle en un diagrama del cual dependen otros diagramas. Pérdida de los diagramas. Pérdida de los cambios realizados en los diagramas. Ataque de virus en la información de los diagramas y su documentación. Cambio de requerimientos que implique cambios de los diagramas. Incoherencia entre los diagramas y el prototipo. Encontrar errores en el diseño en el momento de la implementación (implica pérdida de tiempo). 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 16

18 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 RD RD RD RD RD RD RD RD 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 RD-01 RD-02 RD-03 Controles Preventivos Correctivos 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. diagramas a realizar. Hacer los respectivos cambios en los diagramas que cambian, inmediatamente se identifica el error a corregir. Definir más de un sitio en donde se Realizar nuevamente los diagramas guardarán los diagramas faltantes de acuerdo a lo elaborado (localmente, en la nube o en algún anteriormente. Realizarlos medio extraíble). inmediatamente luego de su perdida. JHONATHAN CÓRDOBA CASTAÑEDA 17

19 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 Identificar la última versión que se encuentre limpia para continuar contarse con una licencia de desde la misma. Instalar el antivirus antivirus en cada computador en el en los lugares respectivos. cual se tengan los diagramas. 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 Modificar el prototipo de acuerdo a para evitar inconvenientes al los cambios hechos en los diagramas. momento de la elaboración del prototipo. 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 Corregir el diseño para poder para evitar inconvenientes al modificar el prototipo. momento de la elaboración del 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 18

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

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

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

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

24 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 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 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. Patrones de Diseño 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 23

25 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) De acuerdo a la importancia considerada para la implementación de cada uno de los requerimientos se definieron 3 calificaciones: Priorización de Requerimientos 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 24

26 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. Aplicación izafiro Niveles Módulos Componentes Clases Métodos y atributos Ilustración 3: Niveles de detalle de la aplicación 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]. JHONATHAN CÓRDOBA CASTAÑEDA 25

27 Ilustración 4: Diagrama de Despliegue de izafiro Nodo Cliente Nombre del nodo Especificación Cliente Disco duro de 80 GB. 153 MB para el JDK versión MB libres en RAM. Procesador Intel Pentium Dual Core o procesadores compatibles. Sistema operativo Windows XP, Vista, 7 u 8. Mac OS X JDK 6.0 o superior. Ubicación La ubicación exacta de cada uno de los PC, en los cuales esté instalada la aplicación. Componentes 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) Tabla 8: Especificación Nodo Cliente. Comentarios adicionales Nivel de Presentación Nivel de Negocio Nivel de Integración JHONATHAN CÓRDOBA CASTAÑEDA 26

28 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 Base de Datos Remota de izafiro. Comentarios adicionales Ninguno Tabla 9: Especificación Nodo Orion 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 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 27

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

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

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

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

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

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

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

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

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

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

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

40 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 Módulo de Presentación Inicial Modulo Manejo de Acceso Modulo Gestor Estado de Partida Modulo Gestor de Desplazamiento Modulo Gestor de Juegos Puzzle IZafiro IniciarApp Historia Creditos Clases (algunas) CrearPartida ContinuarPartida GestorJuego Deposito Tiempo Pausa Desplazamiento Reloj GuardarPartida Escenario Ayuda Espadazo 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 39

41 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. Historia Menú Principal Continuar Partida Créditos Top 5 de Jugadores Registrar Nuevo Usuario Juegos Puzzle (desbloqueados) Seleccionar Personaje 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. JHONATHAN CÓRDOBA CASTAÑEDA 40