Primera descomposición del sistema en partes

Contando con esta información, se puede comenzar a desmenuzar el problema para        arribar a un diseño que cumpla con los requisitos. 

Como ya se ha anticipado, estos requisitos pueden resolverse a través de una aplicación        simple constante de un ejecutable, distribuida a las personas responsables del análisis de        los datos, permita dar respuesta a las necesidades de funcionalidad. 

Para el desarrollo de esta aplicación, se tomó como decisión emplear       Java_​ . Esta_​    decisión, además del factor de la familiaridad que ya se posee con dicho lenguaje, responde       

el paradigma orientado a objetos resulta conveniente para el desarrollo de una aplicación        con los requerimientos planteados, en la cual la abstracción y la extensión deberán jugar        papeles claves. También fueron factores de peso la portabilidad que Java provee, y la        existencia de drivers para Java del DBMS MongoDB, que es el utilizado en el caso        particular de la persistencia de la información para el caso particular del juego desarrollado. 

Un punto central de cara al desarrollo de la aplicación es, como se ha mencionado, que        debe ser extensible para su uso en otros juegos, además de contener, naturalmente, la        especificación de los elementos necesarios para su uso en el juego desarrollado para este        trabajo. Entonces, como primer elemento, se observa la necesidad de reconocer y abstraer        tanto como sea posible los elementos precisos en en análisis que son comunes para éste,        independientemente del juego para el cual pretenda utilizarse. Algunos de estos elementos        son: 

● Una fuente de información      _​. Puede tratarse de un archivo, base de datos o        cualquier otro elemento que brinde persistencia a la información almacenada del        juego. En el caso de una fuente de información compleja, como una base de datos,        debe permitirse también la provisión de toda la información que sea necesaria para        que el sistema pueda conectarse con esta fuente de datos. 

● Un esquema de usuarios      _​. Para generar los perfiles SYMLOG y asociarlos a        usuarios, es preciso tener una estructura que represente a un usuario, con toda la        información y métodos que sean precisos. 

● Un esquema de partidas      _​. Sea cual sea el juego empleado, se debe poseer una        estructura que represente a una partida de dicho juego, que será el objeto general        de análisis por parte del Analizador, y ha de contener toda la información referente a        usuarios participantes, acciones de juego a analizar, y variables del estado de juego,        para recuperar la información del contexto en el cual cada acción de juego fue        tomada, al fin de evaluar más precisamente su significado. 

● Un esquema de acciones de juego          . Las acciones de juego son las unidades_​        mínimas de acción de los usuarios participantes de una partida, que permiten        determinar qué decisión ha tomado cada uno en cada contexto. El análisis de las        acciones de juego es la clave de la construcción del perfil SYMLOG de cada jugador,        y por eso es vital poseer una estructura que las represente. 

● Un esquema de perfil SYMLOG        _​. Siendo que el objetivo del análisis es la        construcción de perfiles SYMLOG, y estos pueden representarse a través de un        conjunto de variables que representan la ubicación en la escala anteriormente        descripta, será preciso tener una estructura que represente este perfil. El análisis        consiste en mapear acciones de juegos a trinomios de valores para las 3        dimensiones de Symlog (Up/Down, Positive/Negative, Forward/Backwards) y        agregarlas incrementalmente a los perfiles de cada jugador. Al final del análisis, se        normalizan estos valores en función a los rangos dados por todas las alternativas        que fueron posibles para cada jugador en cada decisión tomada (información que        también debe guardarse aquí), y se producen los resultados normalizados para cada        usuario. 

● Un esquema de conflicto IPA        _​. Para el análisis de chats a través del modelo IPA,        que cuenta con diferentes conflictos en función de las categorías de mensajes,        habrá que contar con un elemento que represente a un conflicto en este modelo,        para poder instanciar los distintos tipos de conflicto en el sistema, 

● Un modelo de análisis      _​. Una parte clave del análisis consiste en especificar el        modelo que se utilizará para llevar a cabo el mismo. El modelo de análisis consiste        de todo el código que se ejecutará ante la necesidad de evaluar una partida para        producir los resultados; además de la especificación de código, algunos elementos        varibles del modelo deben poder ser cargados para permitir la configurabilidad del        mismo. 

● Un analizador de datos      _​. La parte del sistema que se encarga de conectarse a la        fuente de datos, obtener las partidas analizables, e instanciar los elementos precisos        para que el análisis se lleve a cabo. Es la clase principal en la cual se especifica un        modelo y una fuente de datos para llevar a cabo el análisis propiamente dicho a        través de la instanciación y uso de otras clases. 

Habiendo identificado algunos elementos claves, resulta intuitivo pensar, partiendo de un        concepto básico de la programación orientada a objetos, en la especificación de estos        elementos para cada juego como una extensión de elementos abstractos con ciertos        elementos básicos que siempre estarán presentes. En esta línea de pensamiento, se puede        arribar a un primer diagrama de clases que represente a estos elementos:        Fig. 26. Primer Diagrama de Clases del Analizador de Datos.   

A través de la extensión de las clases abstractas e interfaces presentes en el diagrama        superior, pueden llevarse a cabo las especificaciones de elementos del Analizador para los        distintos juegos. En el caso particular del juego tratado en el presente trabajo, por ejemplo,        bastaría con extender estos elementos, codificando implementaciones para sus métodos        abstractos. Cabe entonces hacer una división en paquetes. Uno, llamado “data.analyzer”,       

que contendrá todos los elementos comunes en todas las extensiones del sistema (tanto las        clases abstractas e interfaces que requerirán una extensión, como las clases        “SymlogProfile” e IPAConflictSchema, que siempre serán necesarias, y la clase        “DataAnalyzer”, que actúa como main class). Otro paquete, llamado “lotr”, debería contener        la especificación de todos los elementos abstractos para este juego en particular. Esta        división tendría un aspecto como el siguiente:      Fig. 27. Segundo Diagrama de Clases del Analizador de Datos. Puede verse la divisón teórica en  paquetes y las clases del paquete “lotr”, que contienen la implementación para los elementos  abstractos del paquete “data.analyzer”.     

Esta es la forma general de la solución implementada. Queda, entonces, por delante la        especificación de las clases del paquete “lotr”. En estas clases deberá encontrarse la        funcionalidad que permite que el análisis sea aplicado al juego tratado, teniendo en cuenta        sus características propias y atributos de calidad deseables. Para arribar al diseño final se        desarrollarán, entonces, los atributos de calidad que condicionaron el diseño de la solución y        llevaron a la adición de nuevas funcionalidades.