torneos virtuales 2º cuatrimestre 2009 técnicas de diseño 75.10 -grupo d-

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)


- 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)


- 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)


- 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)


- 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


Vista de procesos


¿¿ ??

Vista de Despliegue (I)


Vista de Despliegue (II)


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

Si no se especifica salida, default: simulacion_principal.xml


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)


• Partido Mediador de Acciones Naturaleza EventQueue

Singleton


¿Dónde?

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

instancia de cada clase para ser accedida desde diferentes lugares


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


Strategy (II)


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)


Observer (I)

¿Dónde?

¿Por qué?


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)


¿Dónde?

¿Por qué?

PseudoMediator


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

torneos virtuales 2º cuatrimestre 2009 técnicas de diseño 75.10 -grupo d-

Documents