Como ya sabreis por los correos y el post en el foro, hay que entregar prototipos funcionales para el próximo dia 20 y no tenemos mucho tiempo para hacerlos. Aunque todavía hay que hacer los diseños en serio de la arquitectura del proyecto, vamos a definir unos puntos que permitan juntar todo lo que hagamos en este puente y la semana siguiente. Para ello vamos a explicar los interfaces que se deberían implementar/tener en cuenta por cada grupo que trabaja y otros aspectos importantes para que el dia 20 Gervás no nos corte las pelotas/ovarios/alas (para los ángeles) y se haga un collar con ellas.
Es aconsejable leerse las partes de los demás puesto que muchas tienen dependencias entre ellas y además hacerlo lo antes posible para detectar posibles fallos o partes que falten para garantizar que los mínimos están listos para la entrega de diciembre. Adjunto un fichero de la herramienta argoUML con la que se ha generado el diagrama que aparece en esta página y que puede servir para identificar los nombres de packages utilizados y mantener una cierta coherencia.
1. Servidor/Cargador de Módulos (Garijo y Grifin)
Consiste en una aplicación de consola (sin JFrames ni nada por el estilo) capaz de leer los ficheros .JAR de un directorio y a partir de su fichero de manifiesto obtener el nombre de la clase que implementa IInicioModulo y mediante ésta crear instancias de cada uno de los módulos. Estas instancias habran de ser guardadas en alguna estructura que elijais y deben poder ser accesibles por su nombre (también sacado del fichero de manifiesto) a través de una clase que implemente IGestorModulos. El orden de creación de las instancias habrá de ser calculado a partir de las dependencias que tengan entre ellos.
Como atributos para el fichero de manifiesto se proponen:
NombreModulo : Nombre del módulo
ClaseInicio : Nombre completo (con su ruta dentro los packages) de la clase cargadora que hereda de IInicioModulo
Dependencias: NombreModulo1,NombreModulo2,..,NombreModuloN
Puesto que no disponemos de mucho tiempo antes del 20 el mínimo necesario de esta parte es que sea capaz de iniciar los modulos de 3 ficheros jar en concreto llamados
- ModuloComunicaciones.jar
- ModuloChat.jar
- ModuloJuegos.jar
en este mismo orden a traves de sus clases cargadoras:
- IStation.Modulos.Comunicaciones.Servidor.InicioModuloComunicaciones
- IStation.Modulos.Comunicaciones.Servidor.InicioModuloChat
- IStation.Modulos.Comunicaciones.Servidor.InicioModuloJuegos
y por supuesto proveer de acceso a ellas como se indica en el primer párrafo de la sección.
2. Módulo de Comunicaciones (Rubén y Bea)
El módulo de comunicaciones ha de tener una estructura que se corresponda casi al 100% con el definitivo ya que sobre el trabajan la mayoría de otras secciones. Debe soportar el registro de clases recpetoras de eventos de comunicacion (parecido a los Listener que se usan para los eventos en swing) y para ello implementa el interfaz IModuloComunicaciones que expone métodos pensados para el registro/desregistro de estos receptores así como un método que permite enviar mensajes a clientes conectados y otros métodos destinados a conocer más datos sobre el cliente (si se ha identificado o no, y en caso de que lo haya hecho poder obtener la instancia de la clase Usuario que lo describe).
Cualquier módulo que necesite estar comunicado con el exterior habrá de registrarse ante el módulo de comunicaciones facilitandole un identificador de protocolo (un numero elegido para cada módulo que permite distribuir los mensajes correctamente) y una clase que implemente IReceptorComunicaciones. Es muy importante que los métodos de esta clase terminen rápido puesto que se ejecutan en el hilo del servidor y pueden provocar parones si se alargan
Para mandar datos a un cliente conectado se usará el método enviarUsuario de IModuloComunicaciones, indicando el protocolo que usamos, un string que describe el mensaje llamado comando (puede ser algo como Identificar, EstadoCambiado, TurnoSiguiente o cualquier cosa que decidais para el diseño de vuestros módulos) y los datos que necesiteis enviar (nombre y contraseña, un objeto con el nuevo estado del juego…).
El unico protocolo definido de base es el número 0 que va destinado al propio modulo de comunicaciones y que admite los siguientes mensajes:
Comando: Identificar
Datos: String con el siguiente formato: nombre,contraseña
Descripción: Lo enviarán los clientes cuando necesiten identificarse (al iniciar un cliente de juego o de chat normalmente)
Comando: ResultadoIdentificacion
Datos: Booleano con true si la identificacion ha tenido exito o false en caso contrario
Descripcion: Respuesta del módulo a un comando Identificar
3. Módulo de Chat (Santi y Victor)
Es un módulo de servidor (con las implicaciones correspondientes, a saber tener una clase cargadora que implemente IInicioModulo cuyo nombre ya aparece en la descripcion del Cargador de Módulos, una clase que exponga los métodos que decidais necesarios como por ejemplo crearCanal y reflejar estos nombres en el fichero de manifiesto del jar). Deberá registrarse mediante el módulo servidor con un número de protocolo que será el 1 y responder a los mensajes que le lleguen por esa vía. Aunque el módulo debería tener soporte para canales, para este primer prototipo se puede quedar con uno solo (aunque si lo implementais completo pues tanto mejor). Habreis de definir un protocolo (comandos+datos) que permita las acciones básicas de un chat (unirse a un canal, mandar un mensaje, susurrar a alguien…) junto con la gente encargada del apartado 8 (cliente de chat) ya que lo tendrán que usar ellos también. Como dato adicional, el módulo no deberá permitir su uso a clientes no identificados para lo cual puede usar los métodos apropiados del IModuloServidor.
4. Módulo de Juegos (Ezequiel y Guillermo)
Es el módulo que actua de intermediario entre las distintas partidas y el exterior. Debe registrar los protocolos que le pidan los juegos y facilitar la comunicacion de éstos con el módulo servidor. Así mismo deberá poder actualizar la base de datos segun se creen/terminen las partidas y comprobar mediante el módulo de comunicaciones que no tienen acceso clientes no identificados. Éste grupo habrá de definir un juego minimo de funciones (en un interfaz a elegir) que podrán usar los juegos así como registrar un protocolo de identificador 2 por el que recibirán las peticiones de crear/unirse a partidas. También habrán de decidir junto con el grupo 6 los comandos y datos necesarios para implementar las funcionalidades anteriores. Además deberá ser capaz de facilitar a las implementaciones de juegos instancias de la clase Usuario obtenidas a través del módulo servidor que les permitiran realizar acciones como actualizar los puntos.
5. Parte servidor del Juego de pasar turno aka "Patata caliente" (Patri y Conrado)
Una implementacion sencilla de un juego que consiste en pasar turno hasta que pasa un determinado tiempo tras el cual el jugador que tenga el turno en posesion pierde (le estalla la patata) y todos los demás jugadores obtienen X puntos. Tras Y rondas la partida se da por finalizada y se actualizan los puntos a través de las instancias de la clase Usuario que les facilitará el Módulo de Juegos. Toda la comunicación se hará a través del módulo de juegos y habra que definir los aspectos de su protocolo junto con el grupo 7.
6. Cliente base (Jonás y Lara)
Un applet básico capaz de realizar las tareas comunes como identificar al usuario (que solo va a ser pasar al servidor un mensaje con protocolo 0 de identificación -ver modulo de comunicaciones- con el nombre y la password que se le pasarán como parámetros al applet), facilitar métodos de comunicación… Para ello se puede partir como base del prototipo de chat usando XServer donde se ve a grandes rasgos el uso de las tres clases que gestionan los mensajes (Mensaje, ReconstructorMensajes, Metadatos) así como la forma de usar sockets e hilos para gestionar la comunicación. Deberán acordar con el grupo 4 los detalles del protocolo a usar para crear/unirse a partidas
7. Implementación cliente del Juego de pasar turno (Jesús e Isaac)
Interfaz de usuario y código necesario para representar el juego definido en la parte 5 y permitir al jugador interactuar con el juego (vamos, darle al boton de pasar turno). Deberá utilizar el cliente basico del apartado 6 para todas sus necesidades de comunicación por lo que habran de ponerse de acuerdo con ellos y se espera que aunque el concepto de juego sea tonto el resultado sea visualmente agradable.
8. Chat integrable en cliente (Christian y Pablo)
Se deberán implementar las clases necesarias para mostrar un chat en cualquier applet java que tenga como base el cliente del apartado 6 (el cual usarán para comunicarse con el exterior). Hay que decidir las especificaciones del protocolo de servidor junto con el grupo 3 y quizás permitir que el aspecto del chat sea lo mas personalizable posible para poderlo adaptar a distintintos juegos.
9. Páginas web (Gerardo y Eduardo)
Conjunto de páginas para permitir una funcionalidad mínima (registro, login, vision de partidas creadas del juego de pasar turno y posibilidad de crear/unirse). La página que contenga al applet cliente deberá facilitarle via parámetros de applet el nombre de usuario y contraseña al mismo para que pueda identificarse ante el servidor.
