Plan de Iteración de Enero

Objetivo

El objetivo de esta iteración es fijar un diseño definitivo que nos permita trabajar de aquí a que terminemos el proyecto sin parones producidos porque hay partes que están sin diseñar. Todos los componentes, estén o no desarrollados, tienen que tener un comportamiento y unas dependencias bien definidas. Para ello, va a ser necesario crear una documentación de diseño.
Concretando algo más, en esta iteración vamos a realizar las siguientes tareas:

Planificación

La segunda iteración de el proyecto comienza tan pronto como terminó la anterior (21 de diciembre), y debería estar completa antes de la entrega del mes de enero. Como hay algunas tareas dependientes de otras, vamos a establecer 2 fechas para evitar que unos tengan que esperar a que esté el trabajo de otros. Estas fechas pueden ser el viernes 11 de enero y el siguiente viernes, 18 de enero. De esta forma aquellas personas que no puedan trabajar en navidad tendrán tiempo de hacer las cosas a la vuelta.

Tareas

1. Documentación

1.1. Completar y corregir las interfaces

  • a) Conviene ampliar la sección de las interfaces de forma que se indique cómo pasamos de una interfaz a otra, relacionando las interfaces con los casos de uso y añadiendo, si es necesario, nuevos casos de uso que describan el comportamiento de las interfaces.
  • b) Las interfaces deberían ser más auto-explicativas. Por ejemplo, la página principal debería tener un texto introductorio a los objetivos del sitio web, y cada una de las secciones debería describir su objetivo y funcionamiento. También se pueden incluir comentarios fuera de la propia interfaz para aclarar cosas que dentro de la aplicación están claras, pero en las imágenes no (por ejemplo, movimiento o animaciones).
  • c) Las interfaces de los juegos concretos necesitarán concretarse más, y ampliarse de forma que expliquen, si es necesario, los diferentes estados de juego dentro de la misma partida (esperando la unión de los demás jugadores, esperando el turno, realizando acciones, etc.).

1.2. Completar y corregir casos de uso

  • a) Realizar los cambios propuestos por el profesor, que según tengo anotados, son:
    • Incluir en los casos de uso solamente las acciones del usuario, eliminando o sustituyendo las acciones realizadas por el sistema.
    • En los casos de uso que incluyan la posibilidad de que se produzca un error, indicar la información que se le mostraría al usuario y las opciones para subsanarlo que éste tiene disponibles.
    • El Cu3 hace referencia a otros casos de uso pero no indica a cuáles. En este caso de uso, el nombre coincide con la primera acción y eso no está bien porque entonces el resto de acciones sobrarían. Quizás habría que renombrarlo.
    • En el Cu4 quizás convendría incluir una opción de crear una partida rápida en la que no haya que introducir valores y estos vengan dados por defecto.
    • Algunos casos de uso no indican cuándo o desde dónde son accesibles (principalmente los que se refieren a funcionalidades de la web).
    • Podríamos indicar también desde qué lugares es posible añadir amigos en el portal.
    • Hay que especificar si los juegos aparecen en una ventana aparte, de forma que podamos seguir consultando estadísticas, amigos, etc., o si por el contrario mientras jugamos no podemos hacer nada más sin abortar la partida.
    • Para los casos de uso que amplían otros casos de uso (por ejemplo Cu20), hacer referencia al caso de uso que amplían (algo parecido a herencia).
  • b) Crear nuevos casos de uso que faltan: enviar un mensaje de chat, unirse a un canal de chat (para estos dos quizás baste con especificar más claramente el Cu22, aunque también podemos chatear mientras buscamos partidas creadas), etc.
  • c) También hay que incluir un caso de uso (y puede que también un nuevo tipo de usuario) para la evaluación de los juegos enviados por desarrolladores.

1.3. Riesgos

  • a) Actualizar los riesgos añadiendo, si es necesario, aquellos riesgos deducidos de problemas que hayamos tenido hasta ahora (por ejemplo, para combinar distintos apartados del proyecto, o provocados por retrasos en algunos miembros del grupo consecuencia de catástrofes técnicas o de otro tipo).

1.4. Plan de trabajo

  • a) Completar el plan de la iteración de diciembre (si es que falta algo relevante) y, opcionalmente, añadir algún tipo de conclusión detallando lo que se ha conseguido con esa iteración, y las cosas que no se han logrado hacer.
  • b) Completar este plan de trabajo.
  • c) Realizar el plan de trabajo de la siguiente iteración. Para hacer esto contará con los documentos de diseño de cada uno de los componentes. Estos documentos indicarán fechas clave en la construcción de cada componente para que el diseño esté terminado a tiempo.

2. Diseño

2.1. Planteamiento de arquitectura

  • a) Para cada uno de los componentes de la arquitectura, definir su objetivo y sus dependencias. Esto es, crear un diagrama UML de clases en el que aparezcan los métodos que tendrá y además indicar para cada clase y, en particular, para cada método, su función, las clases externas que se van a utilizar (y qué métodos / atributos de estas clases) y las tablas de la base de datos que se van a leer o escribir. Recomiendo publicar esta información en la Wiki e ir añadiendo las cosas según vayan estando, para que los demás puedan consultar esta información y trabajar a partir de ella.
  • b) Cada grupo debe revisar que su parte no interfiere con las partes de los demás: que dos componentes no realicen la misma función, evitar que dos componentes puedan escribir simultáneamente en la base de datos (especialmente importante al tener por separado el servidor web del servidor de juegos) y otros problemas que ahora mismo no se me ocurren.
  • c) También hay que asegurarse de que los demás componentes hacen lo que esperamos que hagan, es decir, si decimos que utilizamos una clase para obtener el número de jugadores en una partida, que dicha clase pueda proporcionar ese dato.
  • d) Comprobar todos los componentes para asegurarse de que los dos problemas mencionados atrás no ocurren.

2.2. Documentación de la arquitectura

  • Elaborar un documento de diseño más detallado que incluya el diagrama UML de clases y diagramas de secuencia si son importantes (estos últimos relacionados con los casos de uso). El documento debe tener también información detallada explicando las responsabilidades de cada clase, las clases que utiliza (atributos) y, para cada método, su objetivo (responsabilidades) y los métodos que utiliza (ya sean propios o de otras clases, indicando cuáles).
  • El documento de diseño también debe detallar, si es necesario, qué clases deben construirse en proyectos separados y, para cada proyecto, qué otros proyectos debe importar.
  • Por último, debe incluir una indicación del estado de desarrollo de cada componente (cada clase o proyecto), y un plan que especifique qué clases o qué funcionalidades deben estar completadas en cada una de las iteraciones para que de tiempo a concluirlas.

2.3. Diseño de la base de datos

  • Hay que modificar la base de datos de forma que añada aquellas restricciones y aquellas columnas que sean necesarias para el correcto funcionamiento de todo el sistema.

3. Construcción

3.1. Prototipo

  • Concluir el desarrollo del prototipo, de forma que su funcionamiento sea el que se esperaba en un inicio.

3.2. Nueva arquitectura

  • Cada grupo debe crear las clases que ha diseñado, con un mínimo de documentación en javadoc que explique lo que hace cada clase y método. Las clases no tienen que estar completamente implementadas, basta con que tengan los atributos y métodos que se mencionan en el UML. La documentación en javadoc no tiene por qué se la definitiva, pues ésta se irá completando durante la fase de construcción. Solamente se pide que las clases estén en los proyectos adecuados y que los proyectos compilen.
  • Para los elementos que ya estuviesen implementados en el prototipo, las clases de la arquitectura diseñada durante esta iteración deben tener implementadas en el nuevo diseño al menos aquellas funcionalidades que estaban implementadas en el prototipo.

Asignación

Como he dicho antes, podemos dividir la iteración en 2 etapas, de forma que las tareas las hemos asignado a una u otra etapa, en función de las dependencias. Algunas dependencias siguen sin estar del todo resueltas, por lo que igualmente va a haber algunas esperas (espero que sean mínimas).

Daniel y Daniel

Primera etapa:

Plantear la arquitectura (2.1) del cargador de módulos.
Casos de uso: 1.2a.

Segunda etapa:

Hacer las modificaciones necesarias para que el cargador de módulos funcione según lo especificado en el diseño realizado (3.2).
Elaborar el documento de diseño del cargador de módulos (2.2).
Casos de uso: 1.2c.

Rubén y Beatriz

Primera etapa:

Corregir los problemas encontrados al tratar de hacer funcionar el prototipo en el laboratorio (3.1), solicitando a quienes desarrollaron cada elemento del prototipo que realicen cambios si es necesario.
Plantear la arquitectura definitiva del módulo de comunicaciones y el de bases de datos (2.1).
Actualizar y completar los riesgos, en función de los que hayamos descartado y los que hayamos descubierto a partir de los problemas con el prototipo (1.3). Los que descartemos, no eliminarlos, pero comentar que, a partir de la fecha que sea, están tratados.

Segunda etapa:

Módulos de comunicaciones y de bases de datos: tareas 2.2 y 3.2.

Santi y Victor

Primera etapa:

Colaborar en el correcto funcionamiento del prototipo, haciendo los cambios necesarios en el módulo de chat (3.1).
Plantear arquitectura definitiva del módulo de chat (2.1).
Casos de uso: pensar en nuevos casos de uso para 1.2b.

Segunda etapa:

Módulo de chat: tareas 2.2 y 3.2

Ezequiel y Guillermo

Primera etapa:

Plantear una arquitectura definitiva del módulo de juegos, añadiendo la carga dinámica de juegos y facilitando todo lo posible la tarea de desarrollar los juegos concretos (2.1).
Prestar especial atención a que todos los diseños encajen correctamente (2.1d)
Plan de fase: 1.4a

Segunda etapa:

Módulo de juegos: tareas 2.2 y 3.2.
Plan de fase: 1.4b y 1.4c.

Patri y Conrado

Primera etapa:

Colaborar en el diseño del cliente y el módulo de juegos, consultando los diseños que se vayan creando y añadiendo críticas y sugerencias con el objetivo de que estos diseños (que van a ser la interfaz visible para el desarrollador de juegos, es decir, el frame-work) faciliten lo máximo posible el desarrollo de juegos.
Ir planteando un prototipo de la arquitectura de un juego concreto, por ejemplo, las 7 y media.
Desarrollar las interfaces del juego de las 7 y media con más detalle (1.1c).

Segunda etapa:

Plantear el diseño definitivo del juego de las 7 y media (2.1) y elaborar el documento de diseño (2.2).
Si hay suficiente tiempo, realizar tarea 3.2.

Jonás, Lara, Jesús e Isaac

Este trabajo es para 4 personas pero es fácilmente divisible en 2 tareas, de manera que unos se encarguen de elaborar el diseño del cliente (obtener parámetros, comunicarse con el servidor, identificar el usuario, enviar solicitudes de partidas con unos parámetros dados, enviar solicitudes para unirse a una partida, etc.), y otros se encarguen de diseñar el frame-work (facilitar funcionalidades al desarrollador de juegos, como lanzar eventos cuando se pasa un turno, proporcionar información sobre los usuarios de la partida y todo aquello que se considere útil).

Primera etapa:

Plantear el diseño definitivo del cliente (2.1). Utilizar la experiencia adquirida en el desarrollo del prototipo para crear un diseño mejorado. Podéis basar el diseño en el patrón modelo-vista-controlador.
Acordar cuáles son los parámetros que se recibirán a través del código HTML.
Diseñar el frame-work del cliente, es decir: la funcionalidad proporcionada al desarrollador de juegos. El frame-work se puede plantear como una clase de juego abstracto que extenderán los desarrolladores para elaborar el cliente del juego concreto (2.1). Cuanta más funcionalidad proporcione el frame-work, menos trabajo habrá que hacer después para crear los juegos concretos.

Segunda etapa:

Crear el documento de diseño del frame-work y del cliente (2.2), y también la tarea 3.2.
Cuando toda la documentación nueva esté en la wiki, crear un documento Word que reuna todo para enviársela al profesor.

Cristian y Pablo

Primera etapa:

Corregir lo que sea necesario para que el prototipo funcione con el chat (3.1).
Diseñar la arquitectura definitiva del cliente de chat (2.1), teniendo en cuenta que la interfaz con el cliente puede cambiar radicalmente. Colaborar con el diseño del cliente, haciendo críticas y sugerencias orientadas a facilitar la integración del chat.
Casos de uso: pensar en nuevos casos de uso para 1.2b.

Segunda etapa:

Cliente de chat: tareas 2.2 y 3.2.

Gerardo y Eduardo

Primera etapa:

Modificar el prototipo para que funcione, colaborando en la integración del applet y solucionando los problemas existentes (3.1).
Mejorar y añadir interfaces, sobre todo en lo relacionado con el diseño de la web (1.1a y 1.1b).
Plantear un diseño definitivo de las secciones de la web, de la forma de pasar de una sección a otra y de las tablas de las bases de datos que se leen o escriben en cada acción (2.1).
También acordar los parámetros que se pasarán al applet en cada situación (2.1).

Segunda etapa:

Creo que Gerardo tiene un documento sobre las tecnologías disponibles en los laboratorios que falta por copiar a la Wiki. Otra tarea es pasar ese documento a la Wiki, manteniendo solamente la información que siga siendo relevante.
Elaborar un documento de diseño que describa lo diseñado en la etapa anterior (2.2), sobre todo en lo referente a las bases de datos.
Actualizar y corregir el diseño de la base de datos (2.3).
Si hay tiempo, implementar más funciones y revisar el código ya creado para aumentar la seguridad (por ejemplo, que los archivos "php" que no han sido diseñados para ser visualizados directamente, no sean accesibles al teclear la url).