10.1. Make and Deliver Pizza

Image by monkik

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.

conceptual information model describing object, event and activity types

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:

A conceptual process model in the form of a DPMN 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.

Figure 10-1. An information design model defining object, event and activity types.

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 10-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 10-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.

Figure 10-2. A process design for the Make-and-Deliver-Pizza business process

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 10-2:

Figure 10-3. An enriched process design model

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 10-3 implicitly defines the OE class model of Figure 10-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 10-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 10-3.

Notice that the model of Figure 10-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.

10.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.