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 PseudoMediator

Builder (I) Patrones de diseño utilizados (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 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é? 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 utilizados (cont.) Strategy (II)

Patrones de diseño utilizados (cont.) Command (I) ¿Dónde? ¿Por qué? En el comportamiento de cada jugador Necesidad de una jerarquía que permita extender nuevos comandos y poder deshacer las acciones.

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

Observer (I) ¿Dónde? ¿Por qué? Patrones de diseño utilizados (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 utilizados (cont.)

¿Dónde? ¿Por qué? PseudoMediator Patrones de diseño utilizados (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ó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.

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