Classification tags: business operations management, DES, next-event time progression
The potentially relevant object types are:
Potentially relevant types of events are:
Both object types and event types, 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:
A computational design for the purpose of computing one statistic: the mean response time, defined as the average length of time a customer spends in the system from arrival to departure, which is equal to the average waiting time plus the average service duration. For being able to compute the mean response time, we need to store the arrival time of all arrived customers. This can be achieved by explicitly modeling customers as an object type, in addition to service desks. So, we get the following types of objects:
Customer
having one (decimal-valued) attribute arrivalTime
;ServiceDesk
having an association with Customer
representing the multi-valued reference property
waitingCustomers
, and a random variable serviceDuration()
that models the random variation of service durations
(expressed as a function).There are two event types:
CustomerArrival
having two participation associations representing the reference properties: (1) customer
with the class Customer
as range, and (2) serviceDesk
with the class ServiceDesk
as range. As an
exogenous event type, CustomerArrival
has a recurrence
function representing a random variable for computing the time
in-between two subsequent event occurrences.CustomerDeparture
having one participation association with ServiceDesk
representing the reference property
serviceDesk
.Notice that in our design we don't need the participation association between CustomerDeparture
and Customer
since for any customer departure event the customer concerned can be retrieved by getting the first item from the waitingCustomers
queue.
The object types and event types described above, together with their participation associations, are visually described in the following UML class diagram:
ON (event type) | DO (event routine) |
CustomerArrival( c, sd) @ t with c:Customer and sd:ServiceDesk |
PUSH c TO sd.waitingCustomers IF sd.waitingCustomers.length = 1 THEN SCHEDULE CustomerDeparture( sd) @ (t + ServiceDesk.serviceDuration()) |
CustomerDeparture( sd) @ t with sd:ServiceDesk |
POP c FROM sd.waitingCustomers IF sd.waitingCustomers.length > 0 THEN SCHEDULE CustomerDeparture( sd) @ (t + ServiceDesk.serviceDuration()) |