Torneos VirtualesTorneos Virtuales2º Cuatrimestre 2009

Técnicas de Diseño 75.10

-Grupo D-

ContenidoContenido

• Requerimientos del simulador• Información general del proyecto • Descripción de Arquitectura• Patrones utilizados• Posibilidades de extender la aplicación• Desafíos del proyecto• Mejoras para nuevas versiones• Demo / Muestra de código

Requerimientos del Requerimientos del simuladorsimulador

• Jugadores actúan de acuerdo a su posición en cancha.

• Acciones: patear, marcar, avanzar, atajar.

• Diseño flexible para agregar nuevas jugadas y estrategias

• Jugadores en contacto Habilidades + factor de azar definen acciones.

• Detección de faltas y expulsiones

Información general del proyectoInformación general del proyecto

Herramientas y tecnologías:

Datos sobre la base de código:

3950 Líneas de código (incluidos los tests unitarios) 393 commits de SVN Alojado en http://code.google.com/p/tecnicas-grupo2/

Java Log4j JUnit ant Javadoc

Ambientes de desarrollo:

Windows GNU/Linux Ubuntu 9.10

Descripción de Descripción de ArquitecturaArquitectura

Vista lógica (I)

Descripción de Arquitectura Descripción de Arquitectura (cont.)(cont.)

- Clases del Modelo de Análisis

Vista lógica (II)

Descripción de Arquitectura Descripción de Arquitectura (cont.)(cont.)- Mediador de Acciones (I)

¿Qué ocurre cuando dos jugadores chocan?

(1) Falta

(2) Conflicto de Pelota

(3) Conflicto de Posición

Vista lógica (III)

Descripción de Arquitectura Descripción de Arquitectura (cont.)(cont.)

- Mediador de Acciones (II)

(1) Falta

AR=Agresividad/Resistencia

AR Jugador s/pelota > AR Jugador c/pelota ¡Hay falta!

¿Hay Falta? Castigar a Jugador s/pelota

Vista lógica (IV)

Descripción de Arquitectura Descripción de Arquitectura (cont.)(cont.)

- Mediador de Acciones (III)

(2) Conflicto de Pelota

private int calculoMarcacion(HabilidadesJugador hab){int Pm=3; /* ponderacion de habilidad de marcacion */int Pv=2; /* ponderacion de velocidad */int Pa=1; /* ponderacion azar */

int azar= Naturaleza.getInstancia().generarValorEnteroAleatorio(0, 10);

return (hab.getHabilidadMarcando()*Pm +hab.getHabilidadVelocidad()*Pv + azar*Pa)/(Pm+Pv+Pa);

}

private int calculoGambeta(HabilidadesJugador hab){int Pc=3; /* ponderacion de habilidad corriendo */int Pg=2; /* ponderacion de gambeta */int Pa=1; /* ponderacion azar */

int azar= Naturaleza.getInstancia().generarValorEnteroAleatorio(0, 10);

return (hab.getHabilidadCorriendo()*Pc +hab.getHabilidadGambeta()*Pg +azar*Pa)/(Pc+Pg+Pa);}

Vista lógica (V)

Descripción de Arquitectura Descripción de Arquitectura (cont.)(cont.)

- Mediador de Acciones (IV)

(3) Conflicto de Posición

private int calculoVelocidadCorriendo(HabilidadesJugador hab) {int Pc=2; /* ponderacion de habilidad corriendo */int Pv=3; /* ponderacion de velocidad */int Pa=1; /* ponderacion azar */

int azar= Naturaleza.getInstancia().generarValorEnteroAleatorio(0, 10);return (hab.getHabilidadMarcando()*Pc +hab.getHabilidadVelocidad()*Pv +

azar*Pa)/(Pc+Pv+Pa);}

Vista lógica (VI)

Descripción de Arquitectura Descripción de Arquitectura (cont.)(cont.)

- Secuencia de un tick de juego

Vista de componentes

Recibe dos parámetros de entrada. Más detalles en Vista de Despliegue.

Único componente:

¡TRIVIAL!

simulador.jar

Descripción de Arquitectura Descripción de Arquitectura (cont.)(cont.)

Vista de procesos

Descripción de Arquitectura Descripción de Arquitectura (cont.)(cont.)

¿¿ ??

Vista de Despliegue (I)

Descripción de Arquitectura Descripción de Arquitectura (cont.)(cont.)

Vista de Despliegue (II)

Descripción de Arquitectura Descripción de Arquitectura (cont.)(cont.)

java –jar simulador.jar configuracion.xml [salida.xml]

Si no se especifica salida, default: simulacion_principal.xml

Descripción de Arquitectura Descripción de Arquitectura (cont.)(cont.)

Vista de Casos de Uso

¿¿ ??

Patrones de diseño Patrones de diseño utilizadosutilizados

Builder

Singleton

Strategy

Command

Observer

PseudoMediator

Builder (I)

Patrones de diseño Patrones de diseño utilizadosutilizados(cont.)(cont.)

¿Dónde?

¿Por qué?

En la construcción de un Partido

Porque un Partido se construye progresivamente a medida que se van construyendo sus partes: Jugadores, Equipos, Pelota y Cancha

Builder (II)

Patrones de diseño Patrones de diseño utilizadosutilizados(cont.)(cont.)

• Partido Mediador de Acciones Naturaleza EventQueue

Singleton

Patrones de diseño Patrones de diseño utilizadosutilizados(cont.)(cont.)

¿Dónde?

¿Por qué?Por la necesidad de tener una única

instancia de cada clase para ser accedida desde diferentes lugares

Patrones de diseño Patrones de diseño utilizadosutilizados(cont.)(cont.)

Strategy (I)

¿Dónde?

¿Por qué?

En la jerarquía de Estrategias de los equipos

Por la necesidad de una interfaz flexible para añadir nuevas estrategias y evitar numerosas sentencias if que representen el comportamiento de cada equipo

Patrones de diseño Patrones de diseño utilizadosutilizados(cont.)(cont.)

Strategy (II)

Patrones de diseño Patrones de diseño utilizadosutilizados(cont.)(cont.)

Command (I)

¿Dónde?

¿Por qué?

En el comportamiento de cada jugador

Necesidad de una jerarquía que permita extender nuevos comandos ypoder deshacer las acciones.

Command (II)

Patrones de diseño Patrones de diseño utilizadosutilizados(cont.)(cont.)

Observer (I)

¿Dónde?

¿Por qué?

Patrones de diseño Patrones de diseño utilizadosutilizados(cont.)(cont.)

En el bloque de Persistencia. Persistor es Observer y Partido es Observable.

Porque es necesario que se comuniquen los cambios que ocurren en un tick, como ser posiciones, eventos de gol y tarjetas, etc.Partido notifica a Persistor de estos cambios para que sean escritos en la salida XML

Observer (II)

Patrones de diseño Patrones de diseño utilizadosutilizados(cont.)(cont.)

¿Dónde?

¿Por qué?

PseudoMediator

Patrones de diseño Patrones de diseño utilizadosutilizados(cont.)(cont.)

En lo que respecta al Mediador de Acciones y todos los participantes

Porque el conocimiento entre Partido y Mediador es bidireccional.El conocimiento hacia Jugador, Pelota y Árbitro es unidireccional, aquí es similar a un Facade.

Posibilidades de extensiónPosibilidades de extensión

Creación de nuevos comandos.

• Crear estrategias propias defensivas u ofensivas. ¡No requiere recompilación! ¿Por qué?

<equipo nombre="Sacachispas" estrategia="EstrategiaOfensiva">

• Creación de nuevas jugadas

Desafíos del proyectoDesafíos del proyecto

Trabajar en un grupo de muchos integrantes.

Numerosas soluciones propuestas.

Definir protocolo para la comunicación con la

aplicación del otro grupo, codificada con

otras tecnologías.

Poco tiempo para implementar.

La etapa de testing es compleja.

Demo / Muestra de códigoDemo / Muestra de código

¿Preguntas?¿Preguntas?

Miguel Abate Gabriel Cartuccia

Mauro Cohen

Federico Goldenberg

María Eugenia Liva

Lucas Mancini

Pablo Mazzini

Mario Silisque

¡Muchas Gracias!¡Muchas Gracias!

Grupo D