Torneos Virtuales 2º Cuatrimestre 2009 Técnicas de Diseño Grupo D-

Contenido 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 simulador 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 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 Java Log4j JUnit ant Javadoc Ambientes de desarrollo: Windows GNU/Linux Ubuntu 9.10

Descripción de Arquitectura

Vista lógica (I) Descripción de Arquitectura (cont.) - Clases del Modelo de Análisis

Vista lógica (II) Descripción de Arquitectura (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 (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 (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 (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 (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 (cont.)

Vista de procesos Descripción de Arquitectura (cont.) ¿ ?

Vista de Despliegue (I) Descripción de Arquitectura (cont.)

Vista de Despliegue (II) Descripción de Arquitectura (cont.) java –jar simulador.jar configuracion.xml [salida.xml] Si no se especifica salida, default: simulacion_principal.xml

Descripción de Arquitectura (cont.) Vista de Casos de Uso ¿ ?

Patrones de diseño utilizados Builder Singleton Strategy Command Observer Mediator

Builder (I) Patrones de diseño utilizados (cont.) ¿Dónde? ¿Por qué?

Builder (II) Patrones de diseño utilizados (cont.)

Partido Mediador de Acciones Naturaleza EventQueue Singleton Patrones de diseño utilizados (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 utilizados (cont.) Strategy (I) ¿Dónde? ¿Por qué?

Patrones de diseño utilizados (cont.) Strategy (II)

Patrones de diseño utilizados (cont.) Command (I) ¿Dónde? ¿Por qué?

Command (II) Patrones de diseño utilizados (cont.)

Observer (I) ¿Dónde? ¿Por qué? Patrones de diseño utilizados (cont.)

Observer (II) Patrones de diseño utilizados (cont.)

¿Dónde? ¿Por qué? Mediator Patrones de diseño utilizados (cont.)

Posibilidades de extensión Creación de nuevos comandos. Crear estrategias propias defensivas u ofensivas. ¡No requiere recompilación! ¿Por qué? Creación de nuevas jugadas

Desafí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.

Mejoras para nuevas versiones

Demo / Muestra de código

¿Preguntas?

Miguel Abate Gabriel Cartuccia Mauro Cohen Federico Goldenberg María Eugenia Liva Lucas Mancini Pablo Mazzini Mario Silisque ¡Muchas Gracias! Grupo D