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()) |