Processes Step by Step

Model Implementation (1)

The init() Method

We will now implement the second method inherited from desmoj.core.simulator.Model called init(). The purpose of this method is to instantiate all static model components like queues and distributions. Although it is common practice to instantiate Java objects in the constructor of a class, it is not recommended to do so in DESMO-J.

The DESMO-J API explicitly warns you to do this. In DESMO-J an instance of a model is always connected to an experiment. All other objects of a DESMO-J model will use this connection to send their reports and other communications to the experiment which takes care of the reporting and the administration of the model.

If you don't use the init() method to instantiate your static model components, this communication can not be guaranteed to work properly. A simulation run of your model will not produce the desired results.

In order to implement the init() method the right way, we will follow the field definitions already listed in the model class (the ones we just set up) and instantiate an object for each field we just have created. Take a look at the code:

TIP:
Perhaps you should start coding these lines on your own and take a look at the following code later. This way you might get a deeper understanding of what you are doing and afterwards you will be able to write models on your own. Otherwise you might only be able to copy models on your own. ;-)

/**
 * Initialises static model components like distributions and queues.
 */
public void init() {

   // initialise the serviceTimeStream
   // Parameters:
   // this                = belongs to this model
   // "ServiceTimeStream" = the name of the stream
   // 3.0                 = minimum time in minutes to deliver a container
   // 7.0                 = maximum time in minutes to deliver a container
   // true                = show in report?
   // false               = show in trace?
   serviceTime= new ContDistUniform(this, "ServiceTimeStream",
                                          3.0, 7.0, true, false);

We have just written down the code for the first DESMO-J object to be instantiated. Let us take a closer look at its constructor. The most interesting parameter is the first one. Every DESMO-J object demands a parameter of the type desmoj.core.simulator.Model as its first constructor entry. This parameter defines which model this model component belongs to.

A DESMO-J model always consists of a collection of model components derived from desmoj.core.simulator.ModelComponent. Almost all the classes within the DESMO-J framework inherit from this ModelComponent class. Even Model itself inherits from ModelComponent in order to allow submodels being a ModelComponent of another Model. Only the NamedObject class and the Experiment class (and all classes derived from that one) form an exception to this rule, thus they can never be a part of a model.

It is possible that there is more than one model active in the namespace of your computer at a given point of time (if you build submodels or parallel models). In this case the framework needs to know which model component belongs to which model. This is determined by the first model parameter.

Doubtlessly, it is a burden to carry this parameter through each and every object of your model. But it helps keeping all the different models apart from each other. This way no entity of a certain model can manipulate other entities belonging to a different model.

It is likely that you will never write a submodel or a parallel model. But you have to pay attention to this parameter and handle it with care while you instantiate DESMO-J objects.

In this case it gets passed the value this, because this distribution is about to become a part of this, the ProcessesExample model.

   // ... init() continued

   // initialise the truckArrivalTimeStream
   // Parameters:
   // this                     = belongs to this model
   // "TruckArrivalTimeStream" = the name of the stream
   // 3.0                      = mean time in minutes between arrival of trucks
   // true                     = show in report?
   // false                    = show in trace?
   truckArrivalTime= new ContDistExponential(this, "TruckArrivalTimeStream",
                                                   3.0, true, false);

   // necessary because an inter-arrival time can not be negative, but
   // a sample of an exponential distribution can...
   truckArrivalTime.setNonNegative(true);

Every distribution in desmoj.core.dist inherits a method called setNonNegative() (API) from desmoj.core.dist.Distribution. With this method it is possible to influence the random stream to only produce samples that are greater or equal to zero (>=0).

Due to the fact that entries on the scheduler's event list can only be made with positive time stamps, and therefore TimeSpan objects can only be instantiated with positive values, it is extremely handy to use this feature instead of checking every sample drawn with hand written code before using it as a time stamp. DESMO-J will stop the execution if you try to use a negative time value.

   // ... init() continued

   // initialise the truckQueue
   // Parameters:
   // this          = belongs to this model
   // "Truck Queue" = the name of the Queue
   // true          = show in report?
   // true          = show in trace?
   truckQueue = new ProcessQueue<Truck>(this, "Truck Queue", true, true);

   // initialise the idleVCQueue
   // Parameters:
   // this            = belongs to this model
   // "idle VC Queue" = the name of the Queue
   // true            = show in report?
   // true            = show in trace?
   idleVCQueue = new ProcessQueue<VanCarrier>(this, "idle VC Queue", true, true);
}

If you check the DESMO-J API, you will probably recognise that every ModelComponent carries a boolean field called traceMode and every Reportable carries a boolean field called reportMode. These fields will be set by parameters found in the constructors of these classes. The parameters are called showInTrace and showInReport. They determine whether the object will produce trace messages being shown in the trace file or generating a report being shown in the report file.

Every ModelComponent also has a field called debugMode. The value of this field can be checked using the debugIsOn() method and set calling the debugOn() or debugOff() method. Setting it on will make the ModelComponent produce very detailed debug messages being shown in the debug file of your simulation run. For a more detailed description of these parameters check the API.