Simulación Orientada a Objetos
La Simulación Orientada a Objetos (SOO) es una metodología que utiliza los principios del paradigma metodológico de objetos para resolver problemas que se presentan en una simulación.
Esta metodología utiliza herramientas que nos proveen el paradigma orientado a objetos, tales como, Diagrama de Transición de Estados (DTE), Diagramas de Clases, Diagramas de Secuencia o Escenarios y Diagramas de colaboración.
Parte del acto de modelar una realidad es abstraer. Una abstracción supone capturar la esencia de la realidad y plasmarla en un modelo. Ese modelo representa a la realidad, libre de todos los elementos que no afectan al estudio.
Un modelo de simulación ideal comenzaría con la nada absoluta. Partiendo de esta "hoja en blanco", agregaríamos a los participantes de la simulación. Primero el tiempo, el espacio, luego un cajero, los clientes, la cola que ellos forman y la puerta del banco por donde entran azarosamente.
Una vez colocados los participantes, le daríamos vida a la simulación dejando que ellos se muevan e interactúen, cada uno según su naturaleza y comportamiento. El análisis de los datos que obtendríamos de este microuniverso nos daría la información necesaria para comprender la realidad simulada.
El hecho de modelar utilizando objetos nos permite definir a cada participante con mayor precisión y claridad que en otras metodologías.
La metodología de objetos se basa en realizar una abstracción de aquellos elementos (participantes) que son relevantes dentro del ámbito donde se desarrollará la simulación. Cada uno de estos objetos representa a un elemento del modelo y está constituido de Propiedades (que son las características propias del objeto), y Métodos (que son aquellas acciones que realiza dicho objeto).
Son las características intrínsecas del objeto y definirán los estados del mismo. Por ejemplo, velocidad actual, forma, peso y color son algunas de las propiedades de un automóvil.
Las propiedades aparecen cuando uno intenta describir al objeto que se quiere estudiar. En el modelado de objetos nos daremos cuenta de que hay sólo un conjunto reducido de propiedades que son relevantes para el planteo de la simulación (dependiendo de la complejidad de la realidad a simular).
Son los comportamientos que tendrá el objeto de acuerdo a los estímulos (mensajes) que reciba, y a partir de los cuales se establece el estado del objeto.
Los métodos constituyen la conducta del objeto en la simulación. Definen qué reacción (descripta en el "código" del método) corresponderá a qué acción, qué respuestas ofrecerán ante una determinada solicitud.
Estos métodos serán los encargados de modificar (o no) las propiedades (estado) del objeto al cual hacen referencia. Por ejemplo, acelerar y frenar variarán la velocidad del auto, chocar variará la forma, etc.
Mientras que el pie del conductor ejerce una acción sobre el auto (acelerar), éste debe responder a ese estímulo (incrementando la velocidad). Esto significa que si quiero ejercer una determinada acción sobre un objeto, éste debe contar con un método que responda adecuadamente. Por lo tanto, se deben identificar todas los posibles estímulos que se puedan efectuar sobre un objeto, para luego diseñar las respuestas (métodos) a dichos estímulos.
Los estados de un objeto son una instancia particular de sus propiedades, es como se halla el objeto en un instante del tiempo.
Las propiedades asignadas a un objeto deberán poder describir el estado del mismo. Si vemos que el conjunto de propiedades de un objeto no describe todos sus estados, seguro estamos omitiendo alguna.
Provocan una reacción en el objeto estimulado. Este a su vez, puede ser desencadenante de otros estímulos hacia otros objetos. Esto define la interacción entre objetos que se describe en la filosofía de la metodología. Un objeto responde a un estímulo con sus métodos.
Son aquellos objetos que contienen a otros objetos.
La utilización de estos objetos tiene por fin incorporar al modelo aquellas entidades que son formadas por conjuntos de objetos. Cuando decimos que los clientes forman colas, o que existe una lista de pedidos, o flota de taxis, nos referimos a objetos que son formados por otros objetos, pero que tienen propiedades (cantidad, máximo, mínimo,...) y métodos (buscar uno, buscar disponible, hay lugar,...).
Hay varios tipos de objetos contenedores, y todo depende de cómo sea la realidad modelada. Por ejemplo, un contenedor "clásico" sería una cola o una lista, pero si pensamos que una mesa de un restaurante "contiene" al cliente que se sienta en ella, entonces la mesa es un objeto contenedor de clientes y así debemos modelarlo. Además hay situaciones en las que este tipo de objetos cobra mayor protagonismo que sus contenidos (por ejemplo, un mozo tiene a cargo mesas y atiende a los clientes por mesa).
La realidad no supone la existencia de este tipo de objetos. Para modelar una cola de clientes que esperan a ser atendidos sin la ayuda de estas entidades deberíamos modelar la actitud e intención de cada cliente a quedarse formado detrás de otro que llegó antes. Esto resultaría muy complejo, por ello recurrimos a este tipo de objetos. De todos modos, los resultados que obtendríamos serían los mismos, por ello nos guiamos por la regla KISS (Keep It Simple and Stupid – MSE Mantenlo Simple y Estúpido) y elegimos el camino más económico.
LAS HERRAMIENTAS
Existen muchas herramientas provistas por estándares de modelado como UML. Debemos elegir aquellas que sean más representativas y que vengan soportadas por algún software de modelado.
Es importante entender que si bien existen una infinidad de herramientas disponibles, no es necesario utilizar todas. Tampoco es necesario que todos los problemas deban utilizar el mismo conjunto de herramientas. Un problema complejo quizás requiera de la utilización de una herramienta especializada que sobraría en un problema simple.
Es aconsejable utilizar algún soft de diseño orientado a objetos para realizar el modelado. A pesar de que el soft disponible no contempla el 100% de los detalles que pueda incluir un modelo, son de gran ayuda a la hora de organizar modelos grandes en donde todos los diagramas tienen cierto grado de correspondencia e integridad. Además, dibujar estos diagramas a mano puede resultar frustrante (especialmente cuando un pequeño cambio un diagrama implica modificar otros cinco).
Entre el soft disponible encontramos a Rational Rose, GDPro, Visual UML y otros. Para realizar los diagramas de este trabajo se utilizó Rational Rose 98 SR1 (se pueden bajar trials de 30 días totalmente funcionales en
http://www.rational.com/rose).
Las herramientas que seleccionamos para realizar los modelos cubren la mayoría de las necesidades del diseño y son las siguientes:
Diagrama de Transición de Estados
Dado que el estado de un objeto es una instancia de sus propiedades este diagrama ayuda a mostrar los cambios significativos de estas propiedades en un esquema que se aproxima a una descripción de la vida del objeto en la simulación.
Tiene el aspecto de un grafo dirigido. Está compuesto por cuadros, que representan a los estados, y flechas, que representan los cambios de estados. A cada flecha se le puede asignar un rótulo que representa la situación en la que se produce el cambio de estado. Esta situación es normalmente llamada evento. Las condiciones en las que se produce un evento ayuda a definir los comportamientos de los objetos que viven en el sistema. En un ejemplo práctico mostraremos cómo se dibujan los DTE.
Representa las relaciones de conocimiento entre los objetos que integran nuestro modelo.
Las relaciones de conocimiento implican que un objeto "sabe" de la existencia de otro, debido a que su comportamiento hace referencia o "estimula" a este otro objeto.
Cuando intervienen muchos objetos contenedores es necesario crear jerarquías de contención para mejorar la visión del problema. Por ejemplo: en un restaurante vamos a encontrar una lista de mesas que contendrá mesas que contendrán grupos de clientes que contendrán clientes.
Diagramas de Colaboración:
Las relaciones de comunicación muestran la dinámica de los mensajes entre los objetos.
Este es un enfoque dinámico porque nos ayuda a entender como se comunican los objetos y por lo tanto cómo interactúan. De alguna manera, también estamos viendo las relaciones de conocimiento ya que el hecho de que un objeto dispare un mensaje a otro objeto implica que el primero "sabe" de la existencia del segundo. Más adelante, con un ejemplo, mostraremos cómo construir estos diagramas.
Diagrama de secuencia o Diagramas de escenario:
Muestra qué sucede cuando un objeto es estimulado. Muestra la reacción de dicho objeto y cómo interactúa con su entorno. Es importante el cómo, ya que el DIO aproxima una idea de lo que el objeto hace cuando es estimulado y se acerca a una especie de pseudocódigo. También muestra una secuencia de hechos o sucesos da una idea clara del cuándo.
Framework S.O.O.
Un framework es un marco de trabajo. Es un conjunto de elementos que ayudan a desarrollar algo (abarca los aspectos metodológicos, de análisis, de diseño y programación). Todos los problemas de la simulación tienen cosas en común: el tiempo, objetos que interactúan, lapsos esperados para realizar una tarea, un esquema de coordinación, sincronización y colaboración, y el espacio. Bajo estas líneas se presenta un framework para simulación. Utiliza UML como estándar de notación y Java como lenguaje de programación. Pueden utilizarse cualquier sistema de notación y cualquier lenguaje que soporten objetos. Nosotros elegimos UML/Java pero UML/VB o BOOCH/C++ también son válidos. Este framework es simple pero puede extenderse para cubrir necesidades que requieran mayor especialización.
En este diagrama se representan los componentes del framwork y sus relaciones. El objeto está "inmerso" en el tiempo y tiene asociada una posición de un espacio.
A continuación se muestra como se efectúa el paso del tiempo. Se debe tener en cuenta que todos los objetos de una simulación están asociados a un tiempo que les da vida al "pedires" que procesen un tic.
Esta manera de concebir las cosas es simple y versátil. Se pueden simular incluso situaciones inverosímiles y fantásticas como objetos que interactúan y obedecen a distintos tiempos. Se podría modelar las sensaciones de una persona que mira cómo una fruta madura según un tiempo acelerado diez veces más que el suyo.
El concepto de tics permite dar cierta "continuidad" a los modelos discretos. De esta manera se pueden mezclar modelos discretos con continuos. Por ejemplo, se pueden modelar objetos con comportamientos que antes caían en la visión continua (fermentación, cambios de temperatura, etc.) y hacerlos vivir en situaciones típicas de la simulación discreta (colas de trabajo, células de manufactura, etc.). Así, por ejemplo, se podría modelar el proceso de pintura de algún producto contemplando el escurrido previo a la entrada del horno de secado rápido (un modelo continuo), combinado con los tiempos en los que la cinta transportadora se "traba" y el operario tarda en reparar (un modelo discreto y aleatorio).
Sincronización:
La elección del significado de cada tic depende de la naturaleza del problema. Si estamos trabajando con constelaciones 10.000 años por cada tic puede ser útil, no así si trabajamos con cines o estaciones de servicio. Para elegir el significado de cada tic se construye al tiempo con un número que indica cuantos tics representan a una unidad de tiempo considerada (new STiempo(20) indica que una unidad de tiempo será dividida en 20 tics).
Este modelo de trabajo emula el transcurso del tiempo de la misma forma que la película de cine. Una serie de tics hacen mover a los objetos en el tiempo de la misma manera que el cinematógrafo muestra cuadro tras cuadro dando sensación de una realidad continua.
Para lograr lo antedicho, el tiempo obliga a los objetos a procesar cada tic mediante procesarTic(). Una vez que el tiempo terminó de hacer vivir a todos los objetos, el estado resultante es la imagen de la realidad modelada en dicho instante.
Debido a que el tiempo procesa a los objetos uno por uno se pueden dar situaciones de error. ¿Qué sucedería si un objeto requiere una respuesta de otro que todavía no ha sido animado por el tiempo? Para obtener buenos resultados hay que asegurarse de que todos los objetos que participaron en esta suerte de "imagen" de la realidad correspondan al mismo instante. De todas maneras, el tiempo hará procesar el tic en todos los objetos, pero para no acarrear errores (defasaje de un tic) se debe verificar si el objeto ha sido animado o no antes de dar una respuesta.
Los objetos tienen un tiempo de sincronización (tiempoSinc en el modelo) que indica, como si fuese un reloj interno, en que instante "se quedó" dicho objeto. Un método sincronizar() verifica que el objeto se halle en el mismo instante que el tiempo y procesa el tic si es necesario. De este modo, ejecutando sincronizar() antes de ofrecer una respuesta, garantiza que todos los objetos estén al día a la hora de simular un instante.
A pesar de lo complejo que parece a primera vista, los modelos resultantes son más claros y representativos. La dinámica del sistema modelado se refleja mejor ya que las herramientas utilizadas para modelarlo son adecuadas para esa tarea y la forma de concebir la realidad en el modelo es más directa debido al paradigma de objetos.
Concluyendo...
Para concluir resumimos los lineamientos y postulados a respetar: