Information Model

We can extract the following candidates for object types from the problem description by identifying and analyzing the domain-specific noun phrases: shops (for being more precise, we also say single product shops), products (or items), inventories, customers, customer orders, replenishment orders, and vendors. Since noun phrases may also denote events (or event types), we need to take another look at our list and drop those noun phrases. We recognize that customer orders and replenishment orders denote messages or communication events, and not ordinary objects. This leaves us with the five object types described in the diagram shown in Figure 2.1.

Notice that the model also includes associations between object types. The association shops–have–products is one-to-one because we assume that shops only sell a single product, while the association shops–have–inventories is one-to-one because we assume that shops only have one inventory for their single product.

In the next step, event types are added, together with their participation associations with involved object types. They can be identified, e.g., by considering the verb phrases in the problem description, such as pay order, hand out product, and deliver. In the model shown in Figure 2.2, for forming names for event types, these verb phrases are nominalized.

Notice that a participation association between an object type and an event type is typically one-to-many, since an event of that type has typically exactly one participating object of that type, and, vice versa, an object of that type typically participates in many events of that type.

We now derive an information design model from the solution-independent conceptual information model shown in Figure 2.2. A design model is solution-specific because it is a computational design for a specific research question. In the example under consideration, we deal with the following specific research question: compute the average percentage of lost sales (if an order quantity is greater than the current stock level, the difference counts as a lost sale). A design model is platform-independent in the sense that it does not use any modeling element that is specific for a particular platform, such as a Java datatype.

In the solution design model, the goal is to keep only those entity types in the model, which are needed for being able to answer the research question(s).In the design model, we follow a widely used naming convention: the name of a class is a capitalized singular noun phrase in mixed case.

For simplicity, we add a lostSales attribute to the SingleProductShop class for storing the lost-sales statistics for each shop. Alternatively, we could add a special class for defining statistics variables.

Since for computing the percentage of lost sales, we don’t need the order quantities of individual orders, but only the total number of ordered items, it’s sufficient to model an aggregate of customer orders like, for instance, the daily demand. Consequently, we don’t need to consider individual customers and their orders. We can also drop all object types except SingleProductShop and all event types except DailyDemand and Delivery.

Thus, the simplifications of design modeling lead to a model as shown in Figure 2.3.

Notice that we distinguish between two kinds of event types: exogenous event types and caused event types, and that the two associations model the participation of the shop both in DailyDemand events and in Delivery events, and the association end names shop and receiver represent the reference properties DailyDemand::shop and Delivery::receiver (as implied by the corresponding association end ownership dots). These reference properties allow to access the properties and invoke the methods of a shop from an event, which is essential for the event routine of each event type. Thus, the ontological pattern of objects participating in events and the implied software pattern of object reference properties in event types are the basis for defining event routines (and rules) in event types.

While exogenous events of a certain type occur again and again with some (typically random) recurrence, caused events occur at times that result from the internal causation dynamics of the simulation model. So, for any event type adopted from the conceptual model, we choose one of these two categories. For any exogenous event type, we add a recurrence operation, which is responsible for computing the time until the next event occurs, and a createNextEvent operation, which is invoked for creating a new instance of the event type as its next occurrence.

Process Model

We make a conceptual process model and a process design model for the inventory management system. These models can be expressed visually in the form of BPMN and DPMN process diagrams and textually in the form of event rule tables.

A conceptual process model should include the event types identified in the conceptual information model, and describe in which temporal sequences events may occur, based on conditional and parallel branching. We can do this by describing, for each of the event types from the conceptual information model, the causal regularity associated with it in the form of an event rule that defines the state changes and follow-up events caused by events of that type.

The purpose of a conceptual process model for simulation is to identify causal regularities and express them in the form of event rules, one for each relevant type of events, at a conceptual level. We can describe event rules textually and visually in an event rule table like Table 2.1.

Conceptual event rule models.

ON (event type)	DO (event routine)	Conceptual Event Rule Diagram
customer order	check inventory; if there is sufficient inventory, then product handover, else customer departure
product handover	decrement (get product from) inventory; customer payment
customer payment	customer departure [Notice that we do not describe the increase of the shop's cash balance due to the payment, because we focus on inventory.]
replenishment order	delivery
delivery	increment inventory; payment

We can integrate these conceptual event rule models in a conceptual process model, as shown in Figure 2.4.

Notice that the BPMN End Event circles used in the event rule models may have to be converted to BPMN Intermediate Event circles in the integrated model.

A process design model needs to provide a computationally complete specification of event rules, one for each event type defined in the information design model. An event rule for a given event type essentially defines a set of (possibly conditional) state changes and a set of (possibly conditional) follow-up events triggered by an event of that type. We show below how a computational form of event rules can be visually expressed in DPMN diagrams.

Since our information design model (tailored to the given research question of computing the lost sales statistics) only includes two event types, DailyDemand and Delivery, we need to model the two corresponding event rules, only, as in the event rule design Table 2.2, where these rules are modeled textually using pseudo-code.

var sQ := sh.stockQuantity
var newSQ := sQ - demQ
var rP := sh.reorderPoint
sh.stockQuantity := max( 0, newSQ)
if sQ > rP & newSQ <= rP then
  if newSQ < 0 then
    sh.lostSales += demQ - sQ
    newSQ := 0
  var delQ := sh.targetInventory − newSQ
  schedule Delivery( sh, delQ) @ t + leadTime()

rec.stockQuantity += delQ

Notice the general structure of an event expression like DailyDemand( sh, demQ) @ t: it starts with the name of an event type (here: DailyDemand) followed by a comma-separated list of event parameter names (here, sh and demQ), corresponding to event attributes, and an occurrence time annotation @ t. The event expression is complemented with a parameter legend (here, sh: SingleProductShop) defining the type of each event parameter.

We can also express these two rules in DPMN event rule design diagrams, as shown in Figure 2.5 and Figure 2.6.

In general, a DPMN event rule design diagram contains event circles with two-part names (like dd: DailyDemand) specifying an event variable (like dd) and an event type (like DailyDemand). Event circles may be associated with one or more data object rectangles (like sh: SingleProductShop). There is exactly one start event circle without incoming arrows, which may contain rule variable declarations in an attached text annotation. The data object rectangles contain state change statements using the event variable and possibly the rule variable(s).

An event circle may have one or more outgoing arrows leading to gateways or to event circles. The incoming arrows to an event circle represent event scheduling control flows. They must be annotated with event attribute assignments (like quantity and receiver in Figure 2.5) and an assignment of the scheduled event's occurrence time, which is provided in the form of a delay expression prefixed with "+". E.g, the annotation +Delivery.leadTime() in Figure 2.5 means that the scheduled Delivery event will occur with a delay provided by invoking the Delivery.leadTime() function.

Notice that Delivery events trigger a state change, but no follow-up events.

These two event rule design models can be merged into a process design model shown in Figure 2.7.

Information Model

It is straight-forward to extract four object types and six event types from the problem description above, resulting in the conceptual information model shown in Figure 2.8.

The associations between event types and object types represent participation relationships. For instance, in the model of Figure 2.8, we express that a customer arrival event has exactly one customer and one service desk as its participants. For completing the conceptual information model, we may add attributes for describing objects and events of these types.

The model of Figure 2.8 implicitly contains an activity type composed of the two event types service start and service end. It is well-known that, conceptually, an activity is a composite event that is temporally framed by a pair of start and end events. When making an information model for a form of DES with activities, we can replace such pairs of start and end event types with corresponding activity types. For instance, in Figure 2.8, we could replace the two event types service start and service end with the activity type service performances.

We now derive a solution-specific, but platform-independent information design model from the solution-independent conceptual information model shown in Figure 2.8. A design model is solution-specific because it is a computational solution design for answering one or more research questions, allowing to abstract away from those object and event types that are not relevant for the solution design.

We consider the following specific research question: compute the Mean Response Time, which is the average length of time a customer spends in the system from arrival to departure. This research question allows abstracting away from all object types of the conceptual model except service desks and customers, and from all event types except customer arrivals and customer departures. However, for getting a uniform series of models, we also include service start and service end events.

In an information design model we distinguish between two kinds of event types: exogenous event types and caused event types. While exogenous events of a certain type occur again and again, typically with some random recurrence that can be modeled with a probability distribution, caused events occur at times that result from the internal causation dynamics of the simulation model.

In our example model, shown in Figure 2.9, we define CustomerArrival as an exogenous event type with a recurrence function that implements a random variable based on the exponential distribution with event rate 0.5, symbolically expressed as Exp(0.5). Notice that all event types have a functional association with the object type ServiceDesk, which will be implemented in the form of a serviceDesk reference property.

Notice that we have modeled the random duration of a service with the help of the random variable operation serviceDuration() shown in the third compartment of the ServiceDesk class. It must be implemented by a method that samples the exponential distribution function Exp(0.5).

The information design model shown in Figure 2.9 supports simulation scenarios with one or more service desks, each having its own waitingCustomers queue and its own events, operating in parallel. For chained service desks scenarios, an optional successor property would have to be added to the ServiceDesk object type. Chained service desks will be discussed in Example 4.

Process Model

The most basic form of a process model consists of a set of event rule models, expressed textually in the form of event rule statements, or visually in the form of event rule diagrams, preferably collected in an event rule table. Alternatively, a process model may be obtained by integrating all event rule diagrams within a consolidated process diagram.

Conceptual process models can be expressed visually in the form of BPMN process diagrams or textually in the form of English event rule statements.

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.

Conceptual event rule models for the service system example.

ON (event type)	DO (event routine)	Conceptual Event Rule Diagram
customer arrival	the queue (length) is incremented; if there is no one else in the queue (queue length = 1), the service for the newly arrived customer starts
service start	service end
service end	customer departure
customer departure	the queue (length) is decremented; if there is still someone in the queue (queue length > 0), the next service starts

The individual event rule diagrams shown in Table 2.1 can be integrated with each other as shown in Figure 22 where we have to express the event types service start, service end and customer departure in the form of BPMN’s intermediate events for complying with the BPMN syntax.

If we would make a process model for a form of basic DES extended with activities, as in the next example, we would replace the two event types service start and service end with the activity type service performance resulting in the model depicted below in Figure 2.11.

Process design models can be visually expressed in the form of DPMN process diagrams and textually in the form of event rule pseudo code.

In the process design model, we include one event rule for each of the event types of the information design model in Figure 2.9. Notice that the event scheduling time expression @t', e.g., in the CustomerArrival and ServiceEnd rules, denotes scheduling at the next moment in time, which is either t+1, if time is discrete, or, otherwise, t+ε where ε is the smallest time point distance depending on the time granularity of the model.

sd.waitingCustomers.push(c)
if sd.waitingCustomers.length = 1 then
  schedule ServiceStart( sd) @ t'

schedule ServiceEnd( sd) @ 
    (t + ServiceDesk.serviceDuration())

schedule CustomerDeparture( sd) @ t'

sd.waitingCustomers.pop()
if sd.waitingCustomers.length > 0 then
  schedule ServiceStart( sd) @ t'

These event rule design models can be merged into a process design model:

The operators PUSH and POP in the sd.ServiceDesk data object rectangles refer to the standard queue operations push and pop. Generally, in DPMN, state change statements are expressed in a language that depends on the state structure of the modeled system. Typically, this will be an object-oriented system state structure where basic state changes consist of attribute value changes as well as link creations and destructions. If an attribute has a complex data value, such as a set or an array list, a state change statement can be expressed in terms of the operations provided by the complex (collection) datatype.

Information Model

We again consider the service desk system, as described in the section about Example 2. But now we model the service performed at the service desk as an activity.

Conceptually, an activity is a composite event that is temporally framed by a pair of start and end events. Consequently, whenever a model contains a pair of related start and end event types, like service start and service end in the model of Figure 2.8, they can be replaced with a corresponding activity type, like service performances, as shown in Figure 2.13.

As in Example 2, in the design model we only need the object types ServiceDesk and Customer. But instead of the pair of related start/end event types ServiceStart and ServiceEnd, we now have the activity type ServicePerformance.

Notice that we have moved the random variate sampling method serviceDuration() from ServiceDesk to ServicePerformance, as shown in Figure 2.14, since this is the most natural context class for it.

This model only supports scenarios with either just one service desk or multiple service desks operating in parallel. For chained service desks scenarios, an optional next property, defining a successor association, can be added to the ServiceDesk object type, as shown in the following diagram.

The successor association defines a network of service desks. The resulting service network model is discussed in the section on Example 4.

Process Model

Conceptual event rule models for Example 3.

ON (event type)	DO (event routine)	Conceptual Event Rule Diagram
customer arrival	the queue (length) is incremented; if there is no one else in the queue (queue length = 1), the service for the newly arrived customer starts
service performance	customer departure
customer departure	the queue (length) is decremented; if there is still someone in the queue (queue length > 0), the next service starts

The conceptual event rule models shown in Table 2.5 are integrated with each other in the diagram shown in Figure 2.11.

An activity is scheduled by providing both its start time t and its duration Δ in the form of an ordered pair [t, Δ]. In the following table, when the start time is specified with the expression t' refering to a given time instant t, this represents the next moment in time, which means the activity starts immediately.

increment sd.queueLength 
if sd.queueLength = 1 then
schedule ServicePerformance( sd) @
 [t', ServicePerformance.serviceDuration()]

schedule CustomerDeparture( sd) @ t'

decrement sd.queueLength 
if sd.queueLength > 0 then
schedule ServicePerformance( sd) @
 [t', ServicePerformance.serviceDuration()]

Notice that activities are composite events with duration. Scheduling an activity means scheduling its start event. An activity completes with the occurence of its end event. Conseqeuntly, an activity occurs at the same time as its end event.

The three event rule design models described in the above table can be merged into a process design model:

In a DPMN diagram, an activity scheduling time expression of the form [t', Δ], where t' means starting the activity without delay, is simplified to the expression +Δ.

A Specific Model

A specific information design model for a service desk chain consisting of a reception desk and a case handling desk is shown in the following diagram:

The next property of ReceptionDesk defines a successor relationship that allows ReceptionDesk objects to access the waitingCustomers queue of their successor service desks.

Using this model, the initial state of a simulation scenario can be coded by creating a CaseHandlingDesk instance and a ReceptionDesk instance that references the CaseHandlingDesk instance in its next property:

CaseHandlingDesk{ id: 2};
ReceptionDesk{ id: 1, next: 2};

A Generic Model

A generic information design model for a service network is shown in the following diagram:

The optional next property of service desks defines a successor relationship. Whenever the next property of a service desk has no value, this means that the service desk has no successor, so the customer must depart.

Using this generic model, the initial state of a simulation scenario can be coded by creating two ServiceDesk instances with names receptionDesk and caseHandlingDesk, such that the receptionDesk object references the caseHandlingDesk object in its next property:

ServiceDesk{ id: 2, name:"caseHandlingDesk"};
ServiceDesk{ id: 1, name:"receptionDesk", next: 2}

Conceptual event rule models for a generic service network model.

ON (event type)	DO (event routine)	Conceptual Event Rule Diagram
customer arrival	the queue (length) is incremented; if there is no one else in the queue (queue length = 1), the service for the newly arrived customer starts
service performance	the queue (length) is decremented; check simultaneously if the service desk has a successor and if there is still someone in the queue; if the service desk has a successor, then the next service performance at the successor desk starts, if its queue is empty; otherwise, if the service desk does not have a successor, the customer departs; if there is still any customer in the queue, then start the service for the next customer

Based on these conceptual event rule models, we can make a process design model:

Notice that the condition (sd.next), using the syntax of JavaScript, tests if the object referenced by the variable sd has a value for the next property.

Information Model

As shown in the information design model shown in Figure 2.16, the three kinds of PN nodes are modeled as follows:

1. An entry node consists of a CustomerEntrance object and an associated CustomerArrival event type, which is also associated with a Customer object type, stating that a customer arrival event has two participants: a customer and a customer entrance. A CustomerEntrance object has an attribute for the statistics number of arrived customers.
2. A processing node consists of a ServiceDesk object with a waitingCustomers queue, and an associated ServicePerformance activity type. Every ServiceDesk object is either connected to a next service desk or to an exit node.
3. An exit node consists of a CustomerExit object and an associated CustomerDeparture event type. A CustomerExit object has two attributes for the statistics number of departed customers and cumulative time in system.

Process Model

The process model for a service network based on PN modeling concepts looks very much like the model shown in Figure 2.19, extended by attaching a CustomerEntrance Data Object to the CustomerArrival Event circle and a CustomerExit Data Object to the CustomerDeparture Event circle.