Plan De Iteración Diciembre

Objetivo

El objetivo de esta iteración es producir un prototipo funcional de la aplicación utilizando diversas tecnologías para poder eliminar los riesgos del tipo "que el protocolo no sea valido", "que no sepamos usar las tecnologías" o "que las tecnologías no sirvan realmente para lo que necesitemos"

Planificación

Esta iteración tendrá lugar desde el 20 de Noviembre al 19 de Diciembre. Puesto que hay muchas tareas dependientes entre si se ha de priorizar la resolución de 2.1 y 4.1 para que el resto de grupos tengan interfaces sobre los que trabajar. También hay que intentar tener lo antes posible toda la tarea 1 para poder hacer pruebas multimódulo.

Asignación

1. Servidor/Cargador de Módulos (Daniel y Daniel)

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 habrán de ser guardadas en alguna estructura que elijáis 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.

Subtareas

  • 1.1 Ser capaz de extraer información de los ficheros JAR que contienen los módulos
  • 1.2 Cargar dinámicamente un módulo contenido en un JAR
  • 1.3 Resolver información de interdependencias para obtener un orden de instanciación adecuado

2. Módulo de Comunicaciones + Módulo de BD (Rubén y Beatriz)

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 receptoras de eventos de comunicación (parecido a los Listener que se usan para los eventos en swing). El de bases de datos debe ser capaz de lanzar consultas contra una base de datos MySQL y devolver los resultados.

Subtareas

  • 2.1 Especificar interfaces comunes para permitir el uso de los módulos desde fuera
  • 2.2 Implementar los mecanismos descritos en los interfaces para permitir otras clases reciban y envien mensajes
  • 2.3 Implementar sistema de consulta contra la base de datos
  • 2.4 Integrar un sistema de autentificacion de clientes basado en la información de la base de datos

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 descripción del Cargador de Módulos, una clase que exponga los métodos que decidáis 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 implementáis completo pues tanto mejor). Habréis 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 actúa de intermediario entre las distintas partidas y el exterior. Debe proporcionar la funcionalidad básica común a todas las partidas, como facilitar la comunicacion de las éstas con el módulo de comunicaciones para interactuar con los usuarios. Así mismo deberá poder actualizar la base de datos según 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 mínimo 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 los mensajes relacionados con la creación, incorporación de usuarios y transmisión de mensajes con las 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 la posibilidad de realizar acciones como actualizar los puntos de los Usuarios (utilizando el módulo de comunicaciones para ello).

Subtareas

  • 4.1 Especificar unos interfaces comunes que pueden ser usados por los juegos
  • 4.2 Implementar un protocolo mínimo de comunicación de la parte cliente y servidor de un juego

Mensajes que el cliente debe enviar:

  • Solicitud de incorporación a la partida
  • Iniciar partida
  • Pasar turno

Mensajes que el cliente debe recibir:

  • Confirmación de que un jugador ha entrado en la partida
  • Mensaje como que la partida ha empezado
  • Mensaje como que se ha pasado un turno
  • Mensaje como que has perdido
  • 4.3 Implementar un conjunto de funcionalidades mínimas de acuerdo a los interfaces de 4.1 (hecho)

5. Parte servidor del Juego de pasar turno aka "Patata caliente" (Patri y Conrado)

Una implementación 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 posesión 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 habrá 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 botón de pasar turno). Deberá utilizar el cliente básico del apartado 6 para todas sus necesidades de comunicación por lo que habrán 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 distintos juegos.

9. Páginas web (Gerardo y Eduardo)

Conjunto de páginas para permitir una funcionalidad mínima (registro, login, visión de partidas creadas del juego de pasar turno y posibilidad de crear/unirse). La página que contenga al applet cliente deberá facilitarle vía parámetros de applet el nombre de usuario y contraseña al mismo para que pueda identificarse ante el servidor.

Subtareas

  • 9.1 Implementar registro e identificación contra base de datos
  • 9.2 Mostrar listas de partidas
  • 9.3 Permitir crear partidas

Conclusiones

Esta ha sido la primera de las dos iteraciones que tenemos pensado dedicar a la especificación y diseño del proyecto. Hemos construido un prototipo rápido de toda aplicación, tratando de incluir todas las tecnologías que podrían dar problemas. Efectivamente, algunas de estas tecnologías han dado problemas, de manera que el prototipo ha servido para poder estimar mejor las posibilidades de que ocurran ciertos riesgos, y para eliminar otros. Por ejemplo, tuvimos problemas con algunas librerías que utilizamos y también con las limitaciones que tenemos en los puestos de laboratorio en cuanto a software instalado.
También hemos podido probar un esbozo de la arquitectura del proyecto, habiendo probado que esta arquitectura, aún pendiente de ser optimizada y completada, es válida para nuestros propósitos.