Events Step by Step

Model Design

UML Diagrams of Events

   
 

Changes in the state of the system occur whenever a truck enters the system and when a van carrier finishes loading a truck. So we will need an event type describing the arrival of a truck (truck arrival event) and a second event type describing the end of the loading process (service end event).

A detail we have neglected so far is how to model waiting space. The trucks need to wait in line until a van carrier is free to fetch and load their container. Well, the term queueing system already says it all: this is done using queues. Our model will need a queue for trucks to enter in case the van carrier is busy. And it will use a second queue for the van carriers to enter in case there are no trucks to serve. This second queue might not seem necessary so long as there's only one van carrier to consider. But it has several advantages:

  • It is a flexible means to keep track of the van carrier(s). All other solutions become difficult to use if there is more than one van carrier in the model.
  • In DESMO-J, queues automatically provide statistics about average queue length and waiting time, for example. Thus, we don't have to bother about collecting such data when we implement our model.

Here's a UML activity diagram of the truck arrival event:

UML activity diagram of the truck arrival event

This occurs every time a truck enters the parking lot and requests service. It inserts the truck into the truck queue and then proceeds to check if a van carrier is available. If there is at least one VC available the event removes the van carrier from the queue of idle van carriers and removes the first truck from the queue of waiting trucks. To model the following loading activity it then creates and schedules a new service end event for the point in time the loading will be finished.

Here's a UML activity diagram of the service end event:

UML activity diagram of the service end event

This occurs whenever a van carrier finishes loading a truck. The truck just leaves the system leaving the van carrier free to start service on another truck. The event therefore has to check if there are still trucks waiting in the queue. If there are no trucks the event inserts the van carrier into the queue for idle van carriers (which models the VC driving back onot its parking spot waiting for the next customer). If there is at least one truck waiting, the event then removes the first truck from the queue and creates and schedules a new service end event.

The last detail we haven't yet covered is how trucks enter the system. We will need to "generate" truck objects and "feed" them into the system throughout the simulation. We will use an external event to achieve this, since trucks arrive from the outside of the system and none of the entities inside the system are concerned. The truck generator event creates a new truck entity and then creates and schedules a new truck arrival event for this truck. It then reschedules itself for the point in time when the next truck will arrive. The inter-arrival times for trucks will be determined by a suitable random distribution.

The event routine of the truck generator event is actually quite similar to the lifeCycle() of the truck generator process of the process oriented version of our model.

UML activity diagram of the truck generator event



   
  http://desmoj.sourceforge.net/tutorial/events/design2.html