Chapter 12. Case Studies
12.1. Make and Deliver Pizza
A pizza service company takes phone orders for making and delivering pizzas, with the help of order takers, pizza makers, ovens and a crew of pizza delivery scooter drivers. From time to time the order takers cannot cope with the number of incoming calls, and then customers grow impatient and hang up the phone without placing an order.
For getting a quick impression, you can run this model from the Sim4edu website, or inspect its OESjs code.
Since there is a high number of lost orders due to long waiting times in the first model, assigning different responsibilities to organizational roles for allowing a more flexible use of human resources is considered in a variant of the first model.
Our Make-and-Deliver-Pizza modeling problem is based on the chapter "Example Model 3: Pizzeria operation" in the book The Art of Process-Centric Modeling with AnyLogic by Arash Mahdavi.
Conceptual Model
A pizza service company has resource pools for order takers, pizza makers, pizza ovens, delivery staff and scooters. While take order activities are performed by an order taker, make pizza activities require both an oven and a pizza maker. Finally, deliver pizza activities require a delivery staff member and a scooter.
Conceptual Information Model
The potentially relevant object types are:
- pizza service company,
- customers,
- orders,
- pizzas,
- order takers,
- pizza makers,
- pizza ovens
- delivery scooter drivers,
- scooters.
Potentially relevant types of events and activities are:
- pizza ordering calls coming in from customers,
- order taking (an activity performed by order takers),
- customers hanging up the phone when having to wait for too long,
- pizza making (performed by pizza makers using ovens),
- pizza delivery (performed by delivery staff using scooters).
Object, event and activity types, together with their participation associations, can be visually described in a conceptual information model in the form of a special kind of UML class diagram, called Object Event (OE) class diagram, as shown below.
The association end annotations «rr» and «rp» denote resource roles and resource pools. For instance, the activity type make pizza has two resource roles, pizza makers and oven. A pizza service company has resource pools for order takers, pizza makers, ovens, delivery scooter drivers and scooters.
Resource roles have resource cardinality constraints. For instance, a make pizza activity requires 2 pizza makers and 1 oven.
A conceptual OE class diagram like the one above, describes resource roles (like oven), resource role types (like ovens) and resource cardinality constraints (like "exactly 1") for all types of activities.
An organization defines organizational positions, which are filled by human resources. Each organizational position is characterized by a set of human resource roles to be played by position holders. In the Pizza Service organization, there are three positions: order takers, pizza makers and delivery scooter drivers.
Strictly speaking, order phone calls are instantaneous (zero duration) events while a take order activity is an event with a non-zero duration. For simplicity, though, we'll often say "events" instead of "instantaneous events" or "objects, events and activities" instead of "objects, instantaneous events and activities".
Conceptual Process Model
The following BPMN diagram shows a conceptual process model of the Make-and-Deliver-Pizza business process, with three swimlanes for the three performers of the process:
Notice the BPMN Boundary Timeout Event circle attached to the take order activity representing timeout events that cancel the activity. They are supposed to model the reneging behavior of waiting customers loosing their patience and hanging up the phone without placing an order. However, BPMN does not allow restricting such a timeout mechanism to the waiting phase of a planned activity, that is the time span during which the planned activity has been enqueued, but not yet started. Rather, it applies to the entire cycle time of take order activities, which means that also started activities, where the order taker is already listening to the customer, may be canceled due to reneging.
While BPMN allows modeling the performers of activities with swimlanes, it does not support modeling other types of resource objects. As a workaround, we have included the resource objects ovens and scooters in the form of BPMN Data Objects.
The third, and most severe, issue of the BPMN model is its uniform (semantically overloaded) use of "sequence flow" arrows for sequencing events and activities. While in the case of all three activities, incoming "sequence flow" arrows do not mean that an activity is started, but rather that a new planned activity is enqueued (and only started when all required resources become available), in the case of the event lost order, the incoming "sequence flow" arrow means that a new event is scheduled to occur immediately.
These three issues of BPMN have been solved in DPMN, where resource-dependent activity scheduling (RDAS) arrows are distinguished from event scheduling arrows, as shown in the following DPMN process diagram:
Notice how the timeout event circle (with a clock icon) is attached to the three bars of the RDAS arrow representing the queue of planned order taking activities waiting for the availability of an order taker. This implies that the timeout applies to the waiting phase only, and not to the entire order taking activity.
A conceptual DPMN process diagram does normally not include any element representing a resource pool. Yet, it may display the performer roles of activity types, like order taker and pizza maker in the diagram above. It is assumed that for any organizational position described in the underlying OE class model, the organization under consideration has a corresponding resource pool.
Simulation Design
In our simulation design, we make the following simplifications. We consider only one particular pizza service company, which does not have to be modeled as an explicit object. Also, we abstract away from individual customers, orders and pizzas. And we merge the resource roles delivery scooter driver and scooter, keeping only scooters as resources of deliver pizza activities.
We consider a scenario with two order takers, ten pizza makers, five ovens and 20 scooters.
Information Design Model
An information design model, in the form of an OE class diagram as shown below, is derived from a conceptual information model by
- Abstracting away from items that are not design-relevant.
- Adding properties, functions and methods to object, event and activity classes. In particular, a status attribute is added to all resource object types, such as OrderTaker and Oven, and a class-level duration function is added to all activity classes.
Notice how functions representing random
variables, like the duration function of all activity types,
are marked with the keyword (or UML 'stereotype') «rv» standing for "random
variable". These random variable functions sample from a probability
distribution function (PDF), which is symbolically indicated with
expressions like Tri(30,40,50) standing for the triangular
PDF with lower and upper bounds 30 and 50 and a median of 40, or
DU(1,4) standing for the discrete uniform PDF with lower and
upper bounds 3 and 6.
In the case of the event type OrderCall, the random variable function recurrence samples from an exponential PDF with five different event rates given for the five consecutive hours during which the pizza service operates.
The activity type TakeOrder is associated with the object type OrderTaker via the implicit resource role orderTaker (with a resource cardinality constraint of "exactly 1"), indicated with the association end stereotype «rr» standing for "resource role". A resource role assigns resource objects to activities.
Likewise, MakePizza is associated with PizzaMaker and Oven via the (implicitly named) resource roles pizzaMakers, having a resource cardinality constraint of "exactly 2", and oven, having a resource cardinality constraint of "exactly 1".
An OE class design diagram like the one above, defines resource roles (like pizzaMakers), resource role types (like PizzaMaker) and resource cardinality constraints (like "exactly 2") for all types of activities. Normally, in an OE simulation there is a one-to-one correspondence between resource role types and resource pools. By convention, a resource pool has the same name as the corresponding resource role type, yet pluralized and starting with a lowercase character. For instance, the name of the resource pool for PizzaMaker is pizzaMakers.
Notice that OrderCall events are exogenous, having a recurrence function defined case-wise for each of the five hours per day operation of the pizza service company (in the attached invariant box).
For implementing the waiting timeout event defined in the process model, the activity type TakeOrder has a class-level waitingTimeout function implementing a random variable with PDF U(3,6).
Process Design Model
A process design model, in the form of a DPMN process diagram as shown below, is derived from a conceptual process model by abstracting away from items that are not design-relevant and possibly adding certain computational details.
A DPMN process design model (like the one shown in Figure 12-2) essentially defines the admissible sequences of events and activities together with their dependencies and effects on objects, while its underlying OE class design model (like the one shown in Figure 12-1) defines the types of objects, events and activities, together with the participation of objects in events and activities, including the resource roles of activities, as well as resource cardinality constraints, parallel participation constraints, alternative resources, and task priorities.
It is an option, though, to enrich a DPMN process design model by displaying more computational details, especially the recurrence of exogenous events, the duration of activities and the most important resource management features defined in the underlying OE class design model, such as resource roles (in particular, performer roles can be displayed in the form of Lanes) and resource cardinality constraints. The following model shows an enriched version of Figure 12-2:
Such an enriched DPMN process design model includes all computational details needed for an implementation without a separate explicit OE class design model. In fact, such a process model implicitly defines a corresponding class model. For instance, the enriched DPMN model of Figure 12-3 implicitly defines the OE class model of Figure 12-1 above.
The notation for defining performer roles in Lanes consists of a performer role name (such as pizzaMakers) and and an object type name (such as PizzaMaker) denoting its range, separated by a colon. When the performer role name is appended by a multiplicity expression in brackets, as in pizzaMakers[2], this denotes a resource cardinality constraint (stating that exactly 2 pizzaMakers are required). When only a performer type prefixed with a colon (such as :OrderTaker) is provided, this means that the implicit performer role name is obtained by lowercasing the performer type name (as in orderTaker:OrderTaker).
The notation for defining a non-performer resource role, such as oven:Oven, consists of a named object rectangle, such as the :Oven rectangle in Figure 12-3, attached to an activity rectangle by means of a connection line with a small filled square representing a resource link, such as the line between the MakePizza activity rectangle and the :Oven object rectangle in Figure 12-3.Notice that the model of Figure 12-3 does not include any element representing a resource pool. It is assumed that for any organizational position described in the underlying OE class model, the organization under consideration has a corresponding resource pool. By default, each resource role of an activity type is associated with a resource pool having the same (yet pluralized) name, such that its resource objects are instances of a corresponding resource role type, which is an organizational position in the case of human resources.
For instance, for the MakePizza activity a pool ovens is assigned to its resource role oven by default. The members of the pool ovens are instances of the (resource) object type Oven. Likewise, a pool pizzaMakers is assigned to the MakePizza resource role pizzaMaker. The members of this pool are instances of the organizational position PizzaMaker. These default pool assignments are normally not shown in a DPMN diagram, but an OE simulator takes care of them.
Combined with its underlying OE class design model, a DPMN process design model provides a computationally complete specification of a simulation model that can be directly turned into implementations.
Model Variant: Orders May Also Be Taken by Pizza Makers
For decreasing the number of lost orders due to long waiting times, it is advisable to charge pizza makers with taking orders whenever no order taker is available. In resource management terminology, the organizational position pizza maker is redefined by adding the performer role order taker to its portfolio of organizational roles.
In an OE class diagram, this can be expressed by adding a subtyping arrow from pizza makers to order takers categorized as an alternative resource subtyping arrow with the stereotype «ar», as shown in the following diagram:
The DPMN process model is not affected by this change.
12.1.1. Implementation with OESjs
The JavaScript-based simulator OESjs-Core2 implements the Object Event Simulation (OES) paradigm, and, consequently, allows a straight-forward coding of OE class models and DPMN process models.
Implementing the
Information Design Model
For implementing the OE class design model with OESjs-Core2, we have to code all object types, event types and activity types specified in the model in the form of JavaScript classes extending the respective OESjs framework classes oBJECT, eVENT and aCTIVITY. We start with the object type OrderTaker shown in the following diagram:
The OrderTaker object class can be
coded in the following way:
class OrderTaker extends oBJECT {
constructor({ id, name, status}) {
super( id, name);
this.status = status;
}
}All object classes inherit an id attribute and a
name attribute from the pre-defined OES foundation class
oBJECT. Since order takers are resource objects, we need to
define a status property having the pre-defined enumeration
data type ResourceStatusEL as its range.
The other object classes (PizzaMaker, Oven and Scooter) are coded in the same way.
We next show how to code the event type OrderCall depicted in the following diagram:
The OrderCall event class is coded in
the following way:
class OrderCall extends eVENT {
constructor({ occTime, delay}) {
super({occTime, delay});
}
createNextEvent() {
return new OrderCall({delay: OrderCall.recurrence()});
}
static recurrence() {
var hour = Math.floor(sim.time / 60);
return rand.exponential( OrderCall.arrivalRates[hour]);
}
}
// arrival rates per minute (for a daily operation for 5 hours)
OrderCall.arrivalRates = [1/6, 1/0.66, 1/1.5, 1/6, 1/12];All
event classes inherit an occTime attribute and a
delay attribute from the pre-defined OES foundation class
eVENT. Any event in OES can be created either with a
value for the attribute occTime (standing for occurrence
time) or with a value for the attribute delay. In the
latter case, the event's occurrence time is automatically derived by adding
the value of delay to the current simulation time.
Notice how the time-varying recurrence rates (representing order
arrival rates) are implemented in the recurrence function: by
first computing the current hour, which is then used as an index for
accessing the corresponding element of the
OrderCall.arrivalRates array.
Finally, we show how to code the activity type TakeOrder depicted in the following diagram:
The TakeOrder activity class is coded in the following way:
class TakeOrder extends aCTIVITY {
constructor({id, startTime, duration}={}) {
super({id, startTime, duration});
}
static duration() {
return rand.uniform( 1, 4);
}
static waitingTimeout() {
return rand.uniformInt( 3, 6);
}
}
TakeOrder.resourceRoles = {
"orderTaker": {range: OrderTaker}
}All activity classes inherit the attributes id,
startTime and duration from the pre-defined OES foundation class
aCTIVITY. When an activity is created as a JS object during a
simulation run, the value of its duration property is obtained
by invoking the duration() function defined as a class-level
("static") function for its activity class. These activity duration
functions typically implement a random variable by invoking a random variate
sampling function, such as rand.triangular(30,50,40), which
samples from the triangular probability distribution function (with
min/max=30/50 and mode=40).
Notice how the resource role association
between TakeOrder and OrderTaker, which defines the resource
reference property TakeOrder::orderTaker, is coded by a corresponding
entry in the map-valued class-level property
resourceRoles.
Implementing the Process Design
Model
The following process design model specifies six types of events: order call events, take order waiting timeouts, lost order events, take order activities, make pizza activities, and deliver pizza activities:
A DPMN process design model can be decomposed into
a set of event rule design models, one for each type of event specified in
the design model. Since the LostOrder event and the
DeliverPizza activity do not have any effects, we only need
four event rules.
1 The OrderCall event
rule
Starting with the following OrderCall event rule
design model, we show how the event rules specified by each of these event
rule design models can be coded.
The
OrderCall event rule does not define any state changes of
affected objects, but only the resource-dependent scheduling of a
TakeOrder activity, which is coded with the following OESjs
statement:
OrderCall.successorActivity = "TakeOrder";
2
The TakeOrder Waiting Timeout event rule
The TakeOrder Waiting Timeout event
rule only schedules the immediate occurrence of a LostOrder
event, which is coded with the following OESjs event routine within the
TakeOrder activity class:
onWaitingTimeout() {
var followupEvents=[];
followupEvents.push( new LostOrder());
return followupEvents;
}3 The TakeOrder event rule
Since activities are composite events, we also have event rules for them. These rules are triggered when an activity completes, that is, by the corresponding activity end events.
The
TakeOrder event rule only takes care of the resource-dependent
scheduling of a MakePizza activity, which is coded with the
following OESjs statement:
TakeOrder.successorActivity = "MakePizza";
4
The MakePizza event rule
The
MakePizza event rule only takes care of the resource-dependent
scheduling of a DeliverPizza activity, which is coded with the
following OESjs statement:
MakePizza.successorActivity = "DeliverPizza";
You can run this model from the OES GitHub website, or inspect its OESjs code.