Nodos
El sistema diseñado se ejecuta en un número indefinido de nodos, aunque existen solamente dos tipos de nodos en la arquitectura: clientes y un servidor. El servidor es único, mientras que el número de clientes puede ser muy numeroso (el número máximo está limitado, principalmente, por el ancho de banda de la conexión del servidor).
Los clientes se comunican con el servidor a través de la Red, pero dos clientes nunca pueden comunicarse directamente entre ellos. Los usuarios del sistema utilizan la aplicación a través de un cliente, cuyo nodo es, por lo general, proporcionado por el propio usuario. Solamente los administradores manipulan directamente el servidor.
Subsistemas
Subsistemas en el servidor
En el servidor, la arquitectura del sistema se divide en varios subsistemas o módulos, cada uno de los cuales es responsable de una funcionalidad concreta. Cada uno de estos módulos tiene una interfaz única que proporciona la funcionalidad propia de dicho módulo. Además, estos módulos pueden proporcionar otras interfaces para ofrecer funcionalidades más genéricas. Por ejemplo, todos los módulos proporcionan una interfaz única para ser tratados por el cargador de módulos de manera homogénea.
A continuación, describimos brevemente el cometido y el diseño de los módulos que forman el sistema:
Cargador de Módulos
El servidor se encarga de cargar los distintos módulos del sistema, en un orden que permita mantener las dependencias entre módulos. El cargador de módulos desconoce cuántos módulos es necesario cargar ni tampoco las dependencias que existen entre estos módulos. Esta información la obtiene directamente del sistema de ficheros.
El cargador trata todos los módulos de manera homogénea y desconoce la interfaz particular de cada uno de ellos.
Módulo de Juegos
El Módulo de Juegos posee referencias a todos los módulos, ya que es la fachada de cara a los juegos que se ejecuten en el servidor. Todos los juegos accederán a las funcionalidades del resto de los módulos a través de éste, con lo cuál no necesitan conocer la arquitectura del sistema y mucho menos la de cada módulo.
Módulo Log
Algunos módulos hacen uso del Módulo de Log para hacer depuraciones o dar información de salida. La utilidad radica en no usar la consola o salida estándar para dar mensajes. Con este módulo todo se almacena en un archivo de texto en el servidor para su inspección después de la ejecución.
Módulo Base de Datos
Utiliza únicamente el Módulo de Log. Otros módulos se valen de él para actualizar la base de datos que se usa de nexo entre el servidor y el portal.
Módulo Comunicaciones
Utiliza el Módulo de Log y el Módulo de Base de Datos. Su funcionalidad radica en facilitar el envío y recepción de mensajes entre el programa servidor (y sus módulos) y los clientes. Los módulos que necesiten hacer un uso pasivo del Módulo de Comunicaciones (es decir, recibir notificaciones cuando se produce un cambio como la recepción de un mensaje), necesitan poporcionar una interfaz de observador de eventos de comunicaciones.
Paquetes
La distribución de paquetes que se ha realizado pretende agrupar los elementos de la arquitectura tanto por su funcionalidad (subsistemas), como por el nodo en que se ejecutan (Cliente, Servidor o Compartido). Un sencillo esquema de la ubicación de los paquetes se encuentra en el siguiente esquema:
Todos los paquetes están incluidos dentro de otro paquete llamado IStation, que tiene como objetivo identificar el producto al que pertenecen todos los paquetes así como evitar posibles colisiones en el espacio de nombres con otros componentes. Dentro del paquete IStation se encuentran:
Servidor
Este paquete contiene, principalmente, el cargador de módulos. Esta funcionalidad está bastante aislada del resto del sistema, por lo que tiene un paquete aparte.
Modulos
Dentro de este paquete se encuentran otros paquetes con los elementos propios de cada módulo individual, además de la interfaz común que tienen todos los módulos y la factoría abstracta para cargarlos.
Dentro de cada uno de los paquetes que identifican un módulo en concreto se pueden distinguir 3 paquetes que indican el nodo en el que se ejecutan (Cliente, Servidor o Compartido)
Juegos
Al igual que ocurre con los módulos, todos los paquetes que identifican cada juego están incluidos dentro de un paquete superior llamado Juegos. Cada juego tiene su propio paquete que además se encuentra dividido en 3 partes que identifican el nodo en el que son ejecutados.
Requisitos especiales
El sistema debe cumplir ciertos requisitos de rendimiento: debería dar respuesta a las solicitudes de cada uno de los clientes en un tiempo inferior a un segundo (para un número total de 100 clientes).
También existen otros requisitos de fiabilidad: la tasa de fallos en la gestión de los usuarios debe ser mínima (< 1%), y la tasa de fallos en la administración del flujo de una partida debe ser también pequeña ( < 2%). Además, un fallo de este tipo no debe afectar al correcto funcionamiento del resto del sistema.
Diagrama de secuencia UML (vida de un juego)
Diagrama de secuencia UML desde que el usuario crea la partida en el portal web, hasta que es iniciada.
En este diagrama, se han realizado algunas abstracciones para simplificar el diagrama. En primer lugar, se ha omitido el funcionamiento interno del módulo de Base de Datos, sólamente se ha mostrado la interfaz. En segundo lugar, para el Jugador 2, no se muestran las clases que componen el cliente que utiliza dicho jugador ya que solamente eran relevantes los mensajes que desde el equipo de dicho jugador se envían al servidor (el procesamiento y los objetos existentes para el Jugador 2 son los mismos que para el Jugador 1.
