Classification tags: business operations management, DES, next-event time progression
The potentially relevant object types are:
Notice that it seems preferable (more natural) to separate the service queue from the service desk and not consider the customer that is currently being served at the service desk to be part of the queue.
Conceptually, a queue is a linearly ordered collection of objects of a certain type with a First-In-First-Out policy: the next object to be removed is the first object, at the front of the queue, while additional objects are added at the end of the queue.
Potentially relevant types of events are:
Notice that a pair of start and end events, like "service start" and "service end", indicates that there is an activity that is temporally framed by these two events. It's an option to consider also activities, in addition to objects and events, in a conceptual model. We will do this in our 3rd simulation model of the service desk system.
Both object types and event types, together with their participation associations, can be visually described in a UML class diagram, as shown below.
ON (event type) | DO (event routine) | Diagram |
---|---|---|
customer arrival | If the service desk is busy, then the new customer queues up, else the service starts. | |
service start | After some time, the service ends. | |
service end | The served customer departs. If there are still customers waiting in the queue, then the next service starts. |
The involved types of events can be related with each other via their (possibly conditional) temporal succession, as visualized in the following BPMN process diagram:
In the given simulation project, the purpose of the simulation model is to compute only two statistics:
maximum queue length and average queue length, both based on a single state variable: the length of the queue
at the service desk. We may abstract away from all the object types listed in the conceptual information model
and model the queue length state variable in the form of a global variable queueLength
,
and the service duration random variable in the form of a global function serviceDuration()
.
Concerning the event types described in the conceptual information model, the goal is to keep only those of them, which are really needed, in the design model. This question is closely related to the question, which types of state changes and follow-up event creation have to be modeled for being able to answer the research question(s).
In the case of the given research question, we only need to keep track of changes of the queue length. For keeping track of queue length changes, we only need to consider those types of events that may change the queue length: customer arrivals and customer departures. These are the only relevant event types.
As an exogenous event type, CustomerArrival
has a recurrence
function representing
a random variable for computing the time in-between two subsequent event occurrences.
Notice that, for simplicity, we consider the customer that is currently being served to be part of the queue. In this way, in the simulation program, we can check if the service desk is busy by testing if the length of the queue is greater than 0.
An alternative approach would be not considering the currently served customer as
part of the queue, but rather use a Boolean attribute isBusy
for being able to keep track if the
service desk ist still busy with serving a customer.
ON (event type) | DO (event routine) | Rule design model |
---|---|---|
CustomerArrival @ t |
INCREMENT queueLength IF queueLength = 1 THEN SCHEDULE CustomerDeparture @ (t + serviceDuration()) |
|
CustomerDeparture @ t |
DECREMENT queueLength IF queueLength > 0 THEN SCHEDULE CustomerDeparture @ (t + serviceDuration()) |
ServiceDesk
, but abstracts away from individual customers
and from the composition of the queue.