**Classification tags**: business operations management,
DES, next-event time progression, queueing system

The potentially relevant object types are:

- customers,
- service desks,
- service queues,
- service clerks.

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:

- customer arrivals,
- customers queuing up,
- customers being notified/invited to move forward to the service desk,
- service start,
- service end,
- customer departures.

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) | Rule 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 current simulation project, the purpose of the simulation model is to compute two statistics: the
*service utilization* and *the maximum queue length*. We may therefore abstract away from many of the object types from the conceptual
information model:

`Customer`

: we don't need any information about individual customers;`ServiceQueue`

: we don't need to know who is next, it's sufficient to know*the length of the queue*;`ServiceDesk`

: we don't need any information about the service desks, the information if*the service desk is busy*or not is obtained by testing if the queue's length is greater than 0.`ServiceClerk`

: we don't need any information about service clerks.

Consequently, a computational design for the purpose of computing the two statistics *maximum queue length* and *service
utilization* is obtained by modeling only one object type: ** ServiceDesk** with one (integer-valued) attribute

`queueLength`

. The varying duration of a service is modeled with a function `serviceDuration()`

representing a random variable
based on an empirical probability distribution function with a probability of 30% for the value 2, 50% for 3 and 20% for 4 (time units),
symbolically expressed as 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
two research questions, we need to keep track of changes of the queue length and we need to be able to add up the service durations. For keeping
track of queue length changes, we need to consider all types of events that may change the queue length: *customer arrivals* and *customer
departures*. For being able to add up the service durations, we need to catch *service start* and *service end
events*.

After identifying the relevant event types, we can look for further simplification opportunities by analyzing their possible temporal coincidence. Clearly, we can consider customer departures to occur immediately after the corresponding service end events, without having any effects that could not be merged. Therefore, we can drop service end events, and take care of their effects (the cumulative service time computation) when handling the related customer departure event.

In addition, we can drop service start events, since they temporally coincide with customer arrivals when the queue is empty, or otherwise (when the queue is not empty) they coincide with service end (and, hence, with customer departure) events, because each service end event causes a new service start event as long as the queue is not empty.

As a result of the above considerations, we get the following two types of events:

with a reference property`CustomerArrival`

`serviceDesk`

with range`ServiceDesk`

. As an exogenous event type,`CustomerArrival`

has a`recurrence`

function representing a random variable for computing the time in-between two subsequent event occurrences. It is a design choice to use a uniform distribution function with lower bound 1 and upper bound 6, symbolically expressed as*U(*1, 6*)*.with a reference property`CustomerDeparture`

`serviceDesk`

with range`ServiceDesk`

.

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 is still busy with serving a customer.

The object types and event types described above, together with their participation associations ("service desks participate in customer arrival events and in customer departure events"), are visually described in the following UML class diagram:

Notice how functions representing random variables, like `serviceDuration()`

and
`recurrence()`

, are marked with the keyword (or UML stereotype) «rv» standing for "random variable".

ON (event type) | DO (event routine) |

CustomerArrival( sd) @ t | INCREMENT sd.queueLength IF sd.queueLength = 1 THEN SCHEDULE CustomerDeparture( sd) @ (t + sd.serviceDuration()) |

CustomerDeparture( sd) @ t | DECREMENT sd.queueLength IF sd.queueLength > 0 THEN SCHEDULE CustomerDeparture( sd) @ (t + sd.serviceDuration()) |

Conceptual rule models | Rule design models |
---|---|

- ServiceDesk-2: A service queue model (one service and one queue) with one statistic: the Mean Response Time,
which is the average length of time a customer spends in the system from arrival to departure. For recording their arrival time, individual
customers are represented explicitly in a
*waitingCustomers*queue. - ServiceDesk-3: A service queue model where the service is modeled as an activity with the service desk as its resource, for which the utilization statistics is computed automatically.
- ServiceDesk-4: A service queue model where the service desk is modeled as a processing node of a processing
network that has an entry node and an exit node for arriving and departing customers. The model is based on the pre-defined
*Processing Network*concepts: WorkObject, Arrival, EntryNode, ProcessingNode and ExitNode, such that processing objects 'flow through the system'. - ConsecutiveServices: An activity-based service queue model of two consecutive service providers with customer waiting lines.
- ProcessingNetwork-1: A service queue model where service providers are modeled as processing nodes (with
input queues) within a processing network that has an entry node and an exit node for arriving and departing customers. The model is based on
the pre-defined
*Processing Network*concepts: WorkObject, Arrival, EntryNode, ProcessingNode and ExitNode, such that processing objects 'flow through the system'.

- Queueing_Simulation_Discrete_Event: This NetLogo simulation uses NetLogo's tick-advance primitive to advance simulation time by non-integral amounts. However, NetLogo's standard ticks display is unable to display non-integral values, so a custom ticks display has to be programmed. Copyright 2010, Nick Bennett.