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

Presentación del tema: "Torneos Virtuales 2º Cuatrimestre 2009 Técnicas de Diseño 75.10 -Grupo D-"— Transcripción de la presentación:

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

2 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

3 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

4 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 http://code.google.com/p/tecnicas-grupo2/ Java Log4j JUnit ant Javadoc Ambientes de desarrollo: Windows GNU/Linux Ubuntu 9.10

5 Descripción de Arquitectura

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

7 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

8 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

9 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); }

10 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); }

11 Vista lógica (VI) Descripción de Arquitectura (cont.) - Secuencia de un tick de juego

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

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

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

15 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

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

17 Patrones de diseño utilizados Builder Singleton Strategy Command Observer PseudoMediator

18 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

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

20 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

21 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

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

23 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.

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

25 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

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

27 ¿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.

28 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

29 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.

30 Demo / Muestra de código

31 ¿Preguntas?

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