CHAPTER 8

AN EXAMPLE: MODEL FEDERATION

In JSIM, models may be formed as Java beans so that model federations may be dynamically formed out of simpler models and immediately executed. In addition, models may be dynamically associated with beans, such as model agents and database beans, from the environment. Model beans may be either atomic or composite, and may be assembled into model federations. Before further discussion, the events fired and listened for by beans and agents involved in JSIM simulation environment are summarized in following table

Table 1: Events fired and listened by beans and agents involved

in JSIM simulation environment

8.1 Atomic/Composite Models

The simplest type of model is an atomic model. An atomic model is built as a connected digraph with a single source and a single sink. The source is the producer of entities (e.g., customers) that flow through the graph to be consumed by the sink. All other nodes must have both incoming and outgoing edges.

A composite model consists of two or more models sharing a common environment and display frame. Since general models may have multiple sources, different types of entities can be created (e.g., McDonald's customers and Wendy's customers). These flows may be independent (no shared nodes), competing (shared nodes), or interacting (one playing client role and other playing server role). Allowing digraphs with multiple sources and sinks introduces complex issues of well-formedness.

Composite models may be formed by combining two or more simpler existing models. This is done by loading the two models into the jmodel designer and allowing the user to link them as appropriate. New code is then generated for this composite model. Note that synthesizing a new composite model is less dynamic than assembling a new model federation. This is because elements are more tightly coupled in a composite model (e.g., they share a common Future Event List).

A simple illustration of a composite model is the FoodCourt example. It contains two Sources, three Facilitys and two Sinks forming two digraphs. The top digraph represents a fast food establishment in which multiple clerks are fed by individual queues (as is done at McDonald's), while the bottom digraph represents an establishment in which the multiple clerks are fed by a single queue (as is done at Wendy's).

Figure 1: Screen shot of FoodCourt Animation

A screen shot of the design diagram of this model is shown in figure 1. This is a classic comparison of a G/G/2 queue versus two G/G/1

8.2 Assembling Models into a Model Federation

Models can be assembled to form a model federation without requiring any traditional programming. Each model may be represented by an icon and implemented as a Java bean. A designer can select from existing models to dynamically build a model federation. Individual models in the federation are linked via Java bean events. When an entity in one model reaches a sink, an external event can be triggered which will be handled in another model. Handling the external event will cause an entity to be created by a source in that model. Effectively, one model is able to interact with another model (by injecting an entity). (Currently, we assume that entity injection occurs "now" in the target model with appropriate method synchronization to prevent race conditions. If a time, t, is given for entity injection, it is possible t could be in the past for the target model, so techniques for parallel simulation would be needed.)

Such interactions require that sinks in one model be linked to sources in another model. This linkage is not designed or coded in, but rather established dynamically using the facilities of visual development tools like the BeanBox in the Beans Development Kit (BDK), Java Studio or Visual Cafe, etc.

Consider the following situation (the FoodAndHealth model federation) as one to connect the two models. Some of the customers leaving the FoodCourt find that they are feeling ill, so with probability triggerProb they choose to go to a hospital Emergency Room (ERoom). Patients enter the ERoom and wait to see the Triage Nurse, who will decide whether the patient will see the Physician's Assistant or one of the Doctors. Before this step, the patient must register with the Admit Clerk. A screen shot of the design diagram of this model is shown in figure 2.

The FoodCourt and ERoom models can be easily assembled into a model federation. For example, using the BDK bean box one would carry out the following steps:

1. Select the FoodCourt model/bean from the toolbox and drag-and-drop it into the bean box.
2. Adjust any of properties using the BDK property editor.



Figure 2: Screen shot of ERoom Animation

3. Do the same with the ERoom model/bean.
4. Edit the FoodCourt's events and connect its EntityEvents to the ERoom by clicking on the ERoom 's icon in the bean box. This will enable the FoodCourt model to feed the ERoom model.
5. Select the appropriate method from the event target dialog box which pops up.

The selected method will be executed when these events occur. The events will be constructed and broadcast when an entity is captured by a Sink in the FoodCourt bean. This will cause the Source in the ERoom bean to create and start (i.e., inject) a new entity. Basically, Sink.capture calls Model.triggerEntityEvent, which constructs and broadcasts an EntityEvent to all targets (specified or linked dynamically and graphically using the BeanBox.) The adaptor class (which is automatically generated at event linkage time) listens for any EntityEvents. When it hears one, it will call ERoom.injectEntity (also established at linkage time). This method then calls Source.startEntity, which injects a new entity into the ERoom in response to this external stimulus. These injected entities are in addition to any that the Source would normally (internally) produce.

When the model federation is executed, each model is animated in a separate frame. The models may run independently, but typically will interact through external events created by one model being handled by another. The animation of a very complex model is hard to watch in its totality and make any sense of it. With multi-frame animation, one can easily focus in on parts of the simulation by bringing the relevant window frames into the foreground of the screen.

An example of the execution framework for FoodAndHealth model federation is shown in figure 3 runAgency. It depicts the arrangement of the FoodCourt and ERoom beans as well as their relationships in the bean box.

Figure 3: Beans in the runAgency