Diseño para el juego implementado

En este punto del diseño, es posible abocarse a la tarea de extender la solución para el        escenario particular del juego desarrollado. En este escenario, aparecen los escenarios        particulares que corresponden a éste: 

● Las fuente de datos para el análisis (donde la información está almacenada) es una        base de datos MongoDB, formateada con un esquema.  

● En sus correspondientes colecciones en esta base de datos, la información de        usuarios, chats, partidas y acciones de juego se encuentra almacenada, en formato        JSON. En esta especificación se debe poder levantar y manipular la información        almacenada en dichos objetos para su lectura y modificación. 

● En este momento del diseño deben contemplarse los atributos particulares de las        acciones de juego para cada juego en particular. La especificación hecha del modelo        de análisis (la clase “Model”) contiene el código que permite llevar a cabo un análisis        significativo de la información de las acciones de juego. Por ejemplo, en el juego,        existen 3 tipos de acciones claramente diferenciadas; el formato de estas acciones y        la información que puede ser extraída de cada una debe tenerse en cuenta a la hora        de codificar el modelo. 

Corresponde tratar la funcionalidad referida en el punto 6 del apartado de especificación        de requerimientos, que refiere a la conexión a partidas en curso. Esa funcionalidad, como        se ha mencionado, se desea que sea sólo para el juego desarrollado, y no es preciso que        sea extensible a otros juegos; es implementada sólo con todos los mecanismos específicos        para conectarse al servidor del juego desarrollado. 

En primer término es preciso resolver la conexión con nuestro servidor. Esto se logra con        la inclusión de una librería         socket.io­client_​ , que posee la especificación del cliente de_​        socket.io para Java. Incluyéndola, podemos intercambiar mensajes con nuestro servidor        para solicitarle que nos muestre las partidas activas y nos incluya en las room de cada        partida, para poder intercambiar mensajes con los jugadores. 

Desde el punto de vista del código, toda la funcionalidad precisa puede incluirse en una        clase dentro del paquete “lotr”, donde especificamos la conexión al servidor y el código a        ejecutar ante la recepción de cada mensaje que nos envía al servidor, así como los        mensajes que le enviaremos desde el Analizador.      Fig. 28. Fragmento de Diagrama de Clases donde se observa la clase SocketIOConnection, que  concentra todos los métodos necesarios para la conexión al servidor del juego.   

Esta clase se vincula únicamente con la Interfaz, que a pedido del usuario se encarga de        instanciarla y acceder a sus métodos. Al instanciar esta clase, en el constructor se        especifica el código que debe ejecutarse como respuesta ante la recepción de los mensajes        del servidor.      Fig. 29. Captura de pantalla del Analizador. Se puede visualizar la pestaña “Conectar a servidor”.  Cada botón de la interfaz está vinculado a los métodos de la clase SocketIOConnection, empleando  su funcionalidad para conectarse y desconectarse del servidor, de una partida, mostrar mensajes  recibidos y enviar mensajes visibles a los jugadores de la partida. Se puede observar un ejemplo de  intercambio de mensajes.   

Por último, es preciso dar respuesta a la funcionalidad planteada que expresa el deseo        de poder generar estadísticas sobre el desempeño de los distintos usuarios en las partidas,        persisitiendo en sus perfiles información sobre, por ejemplo, cúantas partidas han jugado,        cuantos puntos han anotado, cuántas veces han llegado vivos al final de las partidas,        etcétera. A este requerimiento se da respuesta de forma sencilla: Se ha incluido en la        interfaz un botón “Calcular estadísticas” que recorre una por una las partidas almacenadas,        se fija sus resultados para cada jugador, y construye incrementalmente perfiles parciales        con información para cada usuario que encuentra vinculado a la partida. Al final de este        proceso, la información encontrada para cada usuario es persistida en su perfil en la base        de datos. 

Con estos componentes, se logra dar respuesta a los distintos requerimientos funcionales        básicos planteados. 

5.3. Atributos de calidad 

5.3.1. Modificabilidad

Escenario de calidad 1.       _​Se desea que los usuarios sean capaces de modificar ciertas        variables del modelo de análisis. El sistema debe poder implementar la carga de archivos de        configuración en los cuales se instancian estas variables, e integrarlos adecuadamente al        modelo de análisis. 

● Fuente: Usuario 

● Estímulo: Agregar configuraciones para el modelo de análisis  ● Entorno: En tiempo de ejecución 

● Artefacto: Plataforma desarrollada 

● Respuesta: El sistema debe permitir la carga del archivo de configuración si éste es        correcto, y llevar a cabo el análisis de datos con los parámetros que en este archivo        se especifican. 

● Medida rta: El agregado o modificación no debe interferir con el normal        funcionamiento de la plataforma. 

Para dar respuesta a este escenario, lo que se hizo fue, en primer lugar, identificar        aquellas partes del modelo propuesto que pueden ser parametrizables, en función de la        estructura de análisis que debe estar en el código de la aplicación. En función a éstos, se        agregó al sistema la capacidad de cargar un archivo JSON que contiene los parámetros de        análisis para diferentes escenarios; los valores de este archivo pueden ser fácilmente        modificados para dar soporte al uso de distintos valores para el análisis. 

En particular, se determinaron tres tipos de acciones de juego claramente diferentes (en        cuanto a su naturaleza y a la información que pueden aportar al análisis). Para cada uno de        estos tipos de acciones, distintos escenarios pueden ser planteados; ésto lleva al planteo de        distintos formatos de configuración de los objetos JSON en el archivo de configuración del        modelo, para soportar estas diferencias. El sistema debe soportar la correcta instanciación        de cada tipo de acción de juego en el código y configurar cada una adecuadamente. 

En particular, se modifica la clase       LotRModel_​  para que en su constructor le sea pasado_​       el archivo de configuración, que debe ser instanciado y parseado. Una vez que se se cuenta        con la información de las políticas de análisis para cada tipo de acción, ésta información        permite utilizar los valores contenidos en el archivo JSON para llevar a cabo el análisis.        Además, se agrega a       _​LotRModel todo el código necesario para llevar a cabo el análisis de        acuerdo a esta diferenciación. 

Por último, es preciso incorporar la información de contexto de la partida. Esto significa        que, para cada acción, independientemente de su tipo, el valor de análisis debe ser        diferente en función del contexto en el cual ésta acción fue tomada (por contexto se        entiende al estado del juego en el momento de tomar esa acción).  

Esto representa, en primer término, la necesidad por parte del Analizador de tener        conocimiento de el estado de juego a la hora de analizar cada acción. Para esto, se