Simulador de Carreras

Transcripción

1 75:10 Técnicas de Diseño Trabajo práctico Documento de Arquitectura Simulador de Carreras Grupo 6: Integrantes: Anaya, Roxana Maribel Esteban Alejandro Czelada Gorgazzi, Martín Osvaldo Ledo, María Soledad Saldaño, María Alejandra Tripodi, Eduardo Martín Cátedra: Titular: Ing. Guillermo G. Pantaleo Ayudante: Florencia Diaz 2. do cuatrimestre 2009

2 ÍNDICE Índice 1. Organización del trabajo Hipótesis Lista de tareas Casos de uso Descripción de casos de uso Ejecutar Simulación Inscribirse en Carrera Mirar Carrera Mantener Carrera Mantener Vehículo Mantener Conductor Mantener Escenario Diagramas de Arquitectura 7 Vista lógica Vista lógica Vista de componentes Vista de procesos Vista de despliegue Diagramas del paquete Simulación 10 Modelo de control de simulación Secuencia tentativa de control de simulación Diagramas del paquete Persistencia (persistencia lógica) 11 Interfaz entre la capa de persistencia y la física Secuencia de utilización de la capa de persistencia Excepciones Diagramas del paquete Modelo 15 1

3 1 Organización del trabajo 1. Organización del trabajo 1.1. Hipótesis a. Cada cuadra tiene un solo sentido, son solo de asfalto y tiene una única velocidad máxima. b. Los vehículos van a tener 3 posiciones solamente: vertical, horizontal y diagonal. c. Cuando los autos chocan automáticamente pierden y después de 50 tick desaparecen de la competencia. d. La cantidad de puntos que se decrementan al carnet del conductor es de 1 punto por cada infracción. e. Cada jugador solo puede elegir un solo auto para competir en una carrera. f. Si un auto esta circulado a una velocidad máxima en cada tick se va a mover una posición de la grilla.en cambio si circula en un velocidad media después de 2 tick se va a mover a la siguiente posición de la grilla y así sucesivamente para las distintas velocidades. g. En la creación de una carrera se debe establecer el horario de largada. h. Al iniciar la Carrera, todos los vehículos que compiten se encuentran en el punto de largada Lista de tareas 1. Casos de Uso. 2. Diseño del modelo. Diseño del modelo completo de una carrera, con vehículos, conductores, multas, puntuaciones, conductores, etc. 3. Mensajería y comunicación con los clientes. Manera de proveer a los clientes (jugadores) la información de cada carrera. Así como también los medios para inscribirse en las que aun no han sido cerradas. Formato de mensajes. 4. Control de la ejecución de la simulación. Definir: La forma en que se define quien y como actúa en cada instante. Las clases necesarias para el control de la simulación como un todo. Proveer una manera de secuenciar tareas transparente al modelo. 5. Arquitectura. Estructura general de todo el sistema, con las interfaces necesarias para separar las capas. 6. Resolución de las decisiones de conductores. Definir: 7. Carrera. Definir: La manera en que un conductor comprende la situaciones de su ambiente. La forma en que pondera las situaciones que considera importantes. El mecanismo de selección de las acciones a tomar. Manejo de decisiones pasadas y futuras, plan de acción. Tener en cuenta el recorrido en la lógica del conductor. Clases que representan el escenario. 2

4 1.2 Lista de tareas Elementos estáticos del escenario. Cuadras, Calles, Sentidos. Clases que representen regiones del escenario (para los rangos de visión de los conductores, cámaras y policías). 8. Persistencia. Definir: Que clases requieren poder ser guardadas. Sobre que se almacenan los datos Compresión de archivos de texto. Base de datos vs. archivos planos XML. Definir interfaz de interacción. Candidatos a tener persistencia: Configuraciones varias. Plantillas de carreras (configuración general sin tener en cuenta jugadores). Inscripciones a las distintas carreras. Carrera siendo simulada o ya terminada, más los cuadros simulados. Vehículos disponibles. Conductores disponibles. Registros de ejecución. 9. Capa lógica de persistencia (persistencia lógica). Fachada para la interacción con la persistencia física. Debe encapsular la implementación del almacenamiento de datos. Obtener una forma uniforme de almacenar datos del modelo. Idea: aplicar AbstractFactory de persistencia lógica, que sea capaz de comprender un string de conexión para la decisión de que AbstractFactory de persistencia física utilizar. Definir el comportamiento de: Clase Entidad. Clase Ensamblador. Excepción de Entidad incompatible (el Objeto no es compatible con el ensamblador suministrado). Excepción de Entidad no identificable (al obtener una entidad no se dan los datos necesarios para identificarla). Clase Registro de ensambladores (posible Singleton). 10. Capa de servicios de aplicación. Definir la interacción con los diferentes clientes. 11. Objetos que ocupan un lugar del escenario. Definir el comportamiento de: Clase Elemento. 3

5 1.2 Lista de tareas Clase Posición. Clase Grilla. Clase Autoparte. Clase Aretriaparte. 12. Encontrar recorrido. Definir el comportamiento de: Clase GuiaT. Clase Cruce. Clase Cuadra. Clase Recorrido. Clase Arteria. Definir la manera de construir un recorrido. Se representa la ciudad mediante un grafo, y se utilizara una libreria de grafos para la obtención de un camino mínimo. 13. Vehículo. Definir las responsabilidades de un vehículo. Diagramas de secuencia de como resuelve el momento en que le toca mover (sin especificar la obtención de una acción a partir de acciones recomendadas). 14. Infracciones y Control. Definir la clase Infracción así como también la administración de las infracciones que se le aplican a cada conductor. Sus puntajes y consecuencias. 15. Toma de decisiones. Definir el comportamiento de: Clase Conductor. Clase Comportamiento. Clase Situación. Clase Acción. Clase Comportamiento. Se debe tener en cuenta las interacciones con Obstáculo. 4

6 2 Casos de uso 2. Casos de uso 2.1. Descripción de casos de uso 2.2. Ejecutar Simulación Figura 1: Diagrama de casos de uso En la hora de inicio de la carrera, un Simulador ejecuta la carrera con los autos predefinidos más los agregados por los participantes y almacena los resultados de la misma. De esto se desprende hacer: Cargar la ciudad y participantes. Las decisiones que debe tomar cada uno de los conductores ante una determinada acción. Controlar las infracciones Almacenar los resultados (de carreras parciales y completadas) Inscribirse en Carrera Este caso de uso permite a los jugadores inscribirse para poder participar de una carrera en el horario predefinido. De esto desprende hacer: Seleccionar un vehiculo y sus caracteristicas. Definir los comportamientos ante los posibles eventos. Seleccionar una carrera de todas las que creo el administrador. 5

7 2.4 Mirar Carrera 2.4. Mirar Carrera Este caso de uso se encarga de mostrar una carrera que ya finalizo. También te permite visualizar el resultado de la misma Mantener Carrera Permite a un Administrador hacer altas, bajas, modificaciones y listados de Carreras. Una carrea esta compuesta por un Escenario, un conjunto de vehiculos no participantes y un conjunto de competidores (que tienen asignado un Vehículo). De esto se desprende hacer: Fijar una fecha y hora de inicio. Un punto de inicio y fin. Seleccionar un escenario. Seleccionar los vehiculos que no participan pero forman parte de la ciudad Mantener Vehículo En este caso de uso el administrador puede hacer altas, bajas, modificaciones y listados de los Vehículos. Un vehiculo son los principales componentes de una carrera Mantener Conductor Este caso de uso permite a un Administrador realizar las altas, bajas, modificaciones y listados de Conductores. Un conductor es la forma de comportarse de cada vehiculo antes los distintos eventos de la simulación Mantener Escenario En este caso de uso un Administrador puede hacer altas, bajas, modificaciones y listado de Escenarios. Un escenario esta definido por las cuadras disponibles para correr y obstaculos. 6

8 3 Diagramas de Arquitectura 3. Diagramas de Arquitectura Figura 2: Vista lógica 7

9 3.1 Vista lógica 3.1. Vista lógica Figura 3: Vista de componentes 8

10 3.1 Vista lógica Figura 4: Vista de procesos Figura 5: Vista de despliegue 9

11 4 Diagramas del paquete Simulación 4. Diagramas del paquete Simulación Es responsabilidad del paquete Simulación la planificación y ejecución de tareas (representadas mediante Compartido.ITransaccion). Para tal fin se provee de la clase IPlanificador que es capaz de realizar tareas basicas de administración de tareas. Permite además proveer de un comparador de ITransaccion con el fin de determinar prioridades de ejecución. Un IPlanificador está pensando principalmente como una colección de ITransacciones a las que se deben activar en determinado instante, no tiene consideraciones sobre que tareas realiza cada una. Se presenta una implementación basica de un comparador (PrimerRegistradoMayorPrioridad), que permite agregar una ITransaccion y definir una secuencia de prioridad basandose en la clase de la instancia provista. Además se muestra ActivarTodos, cuya unica responsabilidad es llamar al método activar de cada una de las transacciones registradas en cada instante. Esta implementación de IPlanificador no controla tiempo alguno de ejecución entre instantes. La interfaz IPlanificador permite la construcción de formas más eficientes de activación, como por ejemplo un planificador que solo active las transacciones que deben realizar alguna tarea en el instante actual. Figura 6: Modelo de simulación.control 10

12 5 Diagramas del paquete Persistencia (persistencia lógica) Figura 7: Secuencia tentativa de control de simulación. Escenario: Activar todo en cada instante. 5. Diagramas del paquete Persistencia (persistencia lógica) La capa de persistencia lógica abstrae al modelo de la forma en que se almacenan las entidades del mismo. Se pueden plantear las siguiente equivalencias entre las interfaces del paquete y su correspondiente representación en un soporte rigido: IProducto: Es la representación de una entidad del modelo en disco. IIngrediente: Un atributo de una entidad del modelo. IGondola: Un conjunto de entidades del modelo que pertenecen a un mismo tipo. Permite obtener una entidad de un conjunto mediante un identificador. IAlmacen: Un conjunto de gondolas agrupadas, accesibles a travez de un string de conexión. Su tarea es la obtención de un conjunto de entidades (una instancia de IGondola) mediante un identificador. ILector: Provee la manera de convertir un producto determinado en una entidad del modelo. IEscritor: Encapsula la forma en que se transforma una entidad del modelo en una representación física del mismo. Se provee un conjunto de excepciones para evidenciar casos de utilización incorrecta de la capa de persistencia. 11

13 5 Diagramas del paquete Persistencia (persistencia lógica) Figura 8: Interfaces provistas para encapsular la persistencia. 12

14 5 Diagramas del paquete Persistencia (persistencia lógica) Figura 9: Un código cliente utiliza un almacen creado previamente para guardar sus entidades. 13

15 5 Diagramas del paquete Persistencia (persistencia lógica) Figura 10: Excepciones de la capa de persistencia. 14

16 6 Diagramas del paquete Modelo 6. Diagramas del paquete Modelo 15