The OES formalism

The OEM&S paradigm is based on the OES formalism presented in (Wagner 2017a), which is summarized below.

A set of object types OT defines a predicate-logical signature as the basis of a logical expression language L_OT: each object type defines a unary predicate, and its properties define binary predicates. A state change language C_OT based on OT defines state change statements expressed with the help of the object type names and property names defined by OT. In the simplest case, state change statements are property value assignments like o.p₁ := 4 or o.p₁ := o.p₂ where o is an object variable and p₁, p₂ are property names.

A set of objects O = {o₁, o₂, ...o_n} where each of them has a state in the form of a set of slots (property-value pairs) represents a system state, that is a state of the real-world system being modeled and simulated. A system state O can be updated by a set of state changes (or, more precisely, state change statements) Δ ⊆ C_OT with the help of an update operation Upd. For instance, for a system state O₁ = {o₁} with o₁ = { p₁: 2, p₂: 5} and a set of state changes Δ₁ = { o₁.p₁ := o₁.p₂ } we obtain

An event expression is a term E(x)@t where

1. E is an event type,
2. x is a (possibly empty) list of event parameters x₁, x₂, …, x_n according to the signature of the event type E,
3. t is a parameter for the occurrence time of events.

For instance, PartArrival(ws)@t is an event expression for describing part arrival events where the event parameter ws is of type WorkStation, and t denotes the arrival time. An individual event of type E is a ground event expression, e = E(v)@i, where the event parameter list x and the occurrence time parameter t have been instantiated with a corresponding value list v and a specific time instant i. For instance, PartArrival(ws1)@1 is a ground event expression representing an individual PartArrival event occurring at workstation ws1 at time 1.

An event routine is a procedure that essentially computes state changes and follow-up events, possibly based on conditions on the current state. In practice, state changes are often directly performed by immediately updating the objects concerned, and follow-up events are immediately scheduled by adding them to the FEL. For the OES formalism, we assume that an event routine is a pure function that computes state changes and follow-up events, but does not apply them, as illustrated by the examples in the following table.

An event rule associates an event expression with an event routine F:

where the event expression E(x)@t specifies the type E of events that trigger the rule, and F( t, x) is a function call expression for computing a set of state changes and a set of follow-up events, based on the event parameter values x, the event's occurrence time t and the current system state, which is accessed in the event routine F for testing conditions expressed in terms of state variables.

An OE model based on a state change language C_OT and a corresponding update operation Upd is a triple ⟨OT, ET, R⟩, consisting of a set of object types OT, event types ET and event rules R.

An event rule r = ON E(x)@t DO F( t, x) can be considered as a 2-step function that, in the first step, maps an event e = E(v)@i to a parameter-free state change function r_e = F( i, v), which maps a system state O to a pair ⟨ Δ, FE ⟩ of system state changes Δ ⊆ C_OT and follow-up events FE. When the parameters t and x of F( t, x) are replaced by the values i and v provided by a ground event expression E(v)@i, we also simply write F_i,v instead of F( i, v) for the resulting parameter-free state change function.

We say that an event rule r is triggered by an event e when the event's type is the same as the rule's event type. When r is triggered by e, we can form the state change function r_e = F_i,v and apply it to a system state O by mapping it to a set of state changes and a set of follow-up events:

We can illustrate this with the help of our workstation example. Consider the rule r_PA defined in the table above triggered by the event PartArrival(ws1)@1 in state O₀ = {ws1.status: AVAILABLE, ws1.waitingParts: []}. We obtain

with Δ₁ = { ws1.waitingParts.push( a.part)} and FE₁ = {ProcessingStart@2}.

An OE model defines a state transition system where

1. A state is a simulation state S = ⟨t, O, E⟩.

2. A transition of a simulation state S consists of

   1. advancing t to the occurrence time t' of the next events NE ⊆ E, which is the set of all imminent events with minimal occurrence time;

   2. processing all next events e ∈ NE by applying the event rules r ∈ R triggered by them to the current system state O according to

      r_e( O ) = ⟨ Δ_e , FE_e ⟩

      resulting in a set of state changes Δ = ∪ {Δ_e | e ∈ NE } and a set of follow-up events FE = ∪ {FE_e | e ∈ NE }.

   such that the resulting successor simulation state is S' = ⟨ t', O', E' ⟩ with O' = Upd( O, Δ) and E' = E − NE ∪ FE.

Notice that the OES formalism first collects all state changes brought about by all the simultaneous next events (from the set NE) of a simulation step before applying them. This prevents the state changes brought about by one event from NE to affect the application of event rules for other events from NE, thus avoiding the problem of non-determinism through the potential non-confluence (or non-serializability) of parallel events.

OE simulators are computer programs that implement the OES formalism. Typically, for performance reasons, discrete event simulators do not first collect all state changes brought about by all the simultaneous next events (the set NE) of a simulation step before applying them, but rather apply them immediately in each triggered event routine. However, this approach takes the risk of an unreliable semantics of certain simulation models in favor of performance.

OESjs – a JavaScript-based OE simulator

The OESjs simulator presented in (Wagner 2017b) implements the OES formalism by implementing (1) object types as classes extending the pre-defined class oBJECT, (2) event types as classes extending the pre-defined class eVENT, and (3) event rules as onEvent methods of event classes.

The OESjs simulator is available from the educational simulation website sim4edu.com.

A. Discrete Event Processes and Event Graphs

A discrete event process consists of a partially ordered set of events that cause a corresponding sequence of discrete state changes of affected objects. When two or more events within such a process have the same order rank, this means that they occur simultaneously.

As an example of a discrete event process we consider a manufacturing process with a workstation and three types of events: PartArrival events, ProcessingStart events and ProcessingEnd events.

The example process is described by the following list of event expressions: PartArrival@1, ProcessingStart@1.01, PartArrival@5.4, PartArrival@6.5, ProcessingEnd@8.47, ProcessingStart@8.48, ProcessingEnd@11.95, ProcessingStart@11.96, ProcessingEnd@17.48, where an expression E@t represents an event of type E occurring at time t.

How this process unfolds in time is illustrated by the following process log:

The events of a real-world discrete event process happen in a coherent spatio-temporal region determined by the locations of the events' participants. In a simulation model, one may abstract away from the aspect of space and model objects without locations, implying that events and processes happen in time, but not in space.

A discrete event process, also known more simply as a discrete process, may be an instance of a discrete process type defined by a discrete process model. A discrete event process pattern can be modeled in the form of a basic DPMN process diagram, which is an extended Event Graph.

The Event Graph modeling language proposed by Schruben (1983) defines directed graphs where the nodes are Event circles (representing typed event variables) annotated with state change statements in the form of state variable assignments, and the edges are arrows representing event flows. In the case of a conceptual process model, event flow arrows express the causation of follow-up events. In the case of a process simulation design model, event flow arrows express the scheduling of follow-up events according to the event scheduling paradigm of Discrete Event Simulation.

Basic DPMN extends the Event Graph diagram language by adding object rectangles containing declarations of typed object variables and state change statements, as well as gateway diamonds for expressing conditional and parallel branching.

The following basic DPMN diagram is an extended Event Graph defining a process pattern that is instantiated by the above discrete event process example.

This process model is based on the following Object Event (OE) class model:

A DPMN process design model specifies a set of chained event rules, one rule for each Event circle of the model. The above model specifies the following three event rules:

1. On each PartArrival event, the inputBufferLength attribute of the associated WorkStation object is incremented and if the workstation's status attribute has the value AVAILABLE, then a new ProcessingStart event is scheduled to occur immediately.
2. When a ProcessingStart event occurs, the associated WorkStation object's status attribute is changed to BUSY and a ProcessingEnd event is scheduled with a delay provided by invoking the processingTime function defined in the ProcessingStart event class.
3. When a ProcessingEnd event occurs, the inputBufferLength attribute of the associated WorkStation object is decremented and if the inputBufferLength attribute has the value 0, the associated WorkStation object's status attribute is changed to AVAILABLE. If the inputBufferLength attribute has a value greater than 0, a new ProcessingStart event is scheduled to occur immediately.

The formal (transition system) semantics of basic DPMN diagrams, based on the semantics of event rules as transition functions, has been presented in (Wagner 2017a). It can be shown that the basic DPMN diagram language is a conservative extension of the Event Graph diagram language by means of a homomorphic embedding of Event Graphs in DPMN diagrams.

B. Business Processes and Activity Networks

An activity is a composite event that is composed of, and temporally framed by, a pair of start and end events.

A business process of an organization is a discrete event process that includes activities performed by actors of the organization for serving certain business purposes of the organization. In addition to its performer, an activity may involve further resources, and allocating the required resources from resource pools during the course of a business process is essential for keeping it going.

As an example of a business process we consider a manufacturing process with a workstation and three types of events: PartArrival events, Processing-Activity-Start events and Processing-Activity-End events.

The example business process is described by the following list of event expressions: PartArrival@1, Processing-Activity-Start@1.01, PartArrival@5.4, PartArrival@6.5, Processing-Activity-End@8.47, Processing-Activity-Start@8.48, Processing-Activity-End@11.95, Processing-Activity-Start@11.96, Processing-Activity-End@17.48, where an expression E@t represents an event of type E occurring at time t.

How this process unfolds in time is illustrated by the following process log:

Notice that, as opposed to the process log shown in Table 1-1,

1. the workstation with ID 1 is a (performer) resource for Processing activities having either the status 1 (being available) or 2 (being busy), and
2. there is a pool of available resources ("av. workStations").

Typically, a business process is an instance of a business process type defined by an organization (or organizational unit), which is the owner of the business process type, in the form of a business process model. The above example business process is an instance of the following model:

A business process model defines an Activity Network (AN), which provides a pattern for business processes. An AN specifies a set of chained event rules with typed object, event and activity variables, based on an OE class model defining object, event and activity types. By convention, activity classes have a duration function that is invoked for getting the duration of newly created instances of the activity class. In a simulation design model, these functions typically define random variate sampling functions (like the service time concept in queuing theory).

Event circles and Activity rectangles may be connected via event flow arrows, as shown above in Figure 1-9, or via resource-dependent activity scheduling arrows, as shown below in Figure 1-10.

The AN shown in Figure 1-9 defines the following event rules:

1. On each PartArrival event, if the associated WorkStation object's status attribute has the value AVAILABLE, then it is set to BUSY and the rule variable wsAllocated is set to true; otherwise the inputBufferLength attribute of the associated WorkStation object is incremented. If wsAllocated holds, then a new Processing activity is scheduled to start immediately with a duration provided by invoking the duration function defined in the Processing activity class.
2. When a Processing activity ends, if the inputBufferLength attribute of the associated WorkStation object has the value 0, then the WorkStation object's status attribute is set to AVAILABLE; otherwise the rule variable wsAllocated is set to true and the WorkStation object's inputBufferLength attribute is decremented. If wsAllocated holds, then a new Processing activity is scheduled to start immediately with a duration provided by invoking the duration function defined in the Processing activity class.

Since the resource management logic concerning the workstation as a resource for Processing activities follows a general pattern, a new modeling language element can be introduced for capturing this pattern. Using resource-dependent activity start arrows, we can express the process model of Figure 1-9 more simply as in the following diagram:

Notice that in this model, we have expressed that we no longer have to take care of setting the status of the workstation as a resource, nor do we have to update the queue/buffer length. This is now expressed implicitly by the semantics of the resource-dependent activity scheduling (RDAS) arrow and has to be handled in a generic way by a simulator supporting DPMN-A models.

The following diagram shows a model containing both event scheduling arrows and RDAS arrows:

In this model, activities are initiated (1) by an RDAS arrow when they may have to wait for the availability of required resources, or (2) by an event scheduling arrow when no other resources are required. For instance, a new Load activity can only be started, when a wheel loader (as a performer) is available, while a Haul activity can be started immediately after the completion of a Load activity because it's performed by the loaded truck, and no other resources are required.

The most widely used language for defining ANs is the Business Process Modeling Notation (BPMN). However, in BPMN there is only one type of arrow, called "Sequence Flow", which is semantically overloaded with both meanings: it can represent an event flow arrow or a resource-dependent activity start arrow.

The concept of ANs includes business system processes, where many business actors perform activities for handling many business cases in parallel. Consequently, it is more general than the common concept of a business process as a case-handling process.

Normally all activity nodes of an AN have a queue of planned activities ("tasks") waiting for the availability of required resources (in particular, their performer). Only if a successor activity node does not require additional or different resources, it does not have a (resource allocation) queue and can be started right away whenever a predecessor activity has completed, as indicated by an event flow arrow.

When all activity nodes of an AN only have a single resource (the performer of the activity), and each of them has a different performer, then the AN corresponds to a Queuing Network in the sense of Operations Research.

A DPMN process design model (like the one shown in Figure 1-12) 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 1-14 below) 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), resource cardinality constraints, alternative resources, and task priorities. The following model shows an enriched version of Figure 1-12:

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 1-13 above implicitly defines the following OE class model:

C. Processing Processes and Processing Networks

T.B.D.

Extending basic OEM information design models by adding activity types

In the case of an information design model, this replacement pattern implies allocating all features (attributes, associations and operations) of the classes defining the start and the end event type in the class defining the corresponding activity type, possibly with renaming some of them. In the example of Figure 2-3, there is only one such feature: the class-level operation ProcessingStart::processingTime, which is allocated to Processing and renamed to time.

Extending basic DPMN process design diagrams by adding Activity rectangles

In the case of a process design model, the replacement pattern implies that an Event circle pair consisting of an Event circle intended to represent activity start events and an Event circle intended to represent related activity end events, with an event scheduling arrow from the start to the end Event circle annotated by a delay expression, is replaced by an Activity rectangle such that:

1. All Data Objects attached to the end Event circle get attached to the Activity rectangle (since an activity occurs when it it is completed).
2. All event scheduling arrows going out from the end Event circle are turned into event scheduling arrows going out from the Activity rectangle.
3. All start event scheduling arrows are replaced with corresponding activity scheduling arrows having an additional creation parameter assignment for the duration of a scheduled activity, which is set to the delay expression defined for the end event scheduling arrow. In the example above, the duration parameter in the annotation of the two activity scheduling arrows is set to Processing::time() in the target diagram, which is the same as the delay ProcessingStart::processingTime in the source diagram.
4. When the start Event circle has one or more attached Data Objects or any outgoing event scheduling arrow that does not go to the end Event circle, then a start Event circle has to be included in the Activity rectangle for attaching the Data Object(s) and as the source of the outgoing event scheduling arrow(s).

This Activity-Start-End Rewrite Pattern, which can also be applied in the inverse direction, replacing an Activity rectangle with an Event circle pair, defines the meaning of an Activity rectangle in a DPMN diagram. It allows reducing a DPMN-A diagram with Activity rectangles to a basic DPMN diagram without Activity rectangles.

Notice that, like the source model, also the target model of Figure 2-4 specifies three event rules:

1. On each PartArrival event, the arrived part is added to the workstation's input buffer and if the workstation's status is AVAILABLE, then a new Processing activity is scheduled to start immediately with a duration provided by invoking the time function defined in the Processing activity class.
2. When a Processing activity starts, the workstation's status is changed to BUSY.
3. When a Processing activity ends, the processed part is removed from the input buffer and, if the input buffer is not empty, a new Processing activity is scheduled to start immediately, otherwise (if the input buffer is empty) the workstation's status is changed to AVAILABLE.

An alternative process design model of the single workstation system

Based on the same information design model, shown in Figure 2-3, we can make another process design model of the single workstation system as an alternative to the target model of Figure 2-4. This alternative model makes it more clear that a workstation is, in fact, an exclusive resource of its processing activity. The concepts of resources and resource-constrained activities are discussed in the following sections, and in Section 3.2, it is shown how to simplify the basic DPMN model of Figure 2-5 by using the higher-level modeling elements introduced in DPMN-A.

Resource roles, process owners and resource pools

As an illustrative example, we consider a hospital consisting of medical departments where patients arrive for getting a medical examination performed by a doctor. A medical examination, as an activity, has three participants: a patient, a medical department, and a doctor, but only one of them plays a resource role: doctors. This can be indicated in an OE Class Diagram by using the stereotype «resource role» for categorizing the association ends that represent resource roles, as shown in Figure 3-3.

Notice that both the event type patient arrivals and the activity type examinations have a (mandatory functional) reference property process owner. This implies that both patient arrival events and examination activities happen at a specific medical department, which is their process owner in the sense that it owns the process types composed of them. A process owner is called "Participant" in BPMN (in the sense of a collaboration participant) and visually rendered in the form of a container rectangle called "Pool".

In Figure 3-3, the resource role of doctors corresponds to the performer role. In BPMN, Performer is considered to be a special type of resource role. According to (BPMN 2011), a performer can be "a specific individual, a group, an organization role or position, or an organization".[1]In BPMN, the performer role is specialized into the HumanPerformer of an activity, which is, in turn, specialized into PotentialOwner denoting the "persons who can claim and work" on an activity of a given type. "A potential owner becomes the actual owner [...] by explicitly claiming" an activity. Allocating a human resource to an activity by leaving the choice to those humans that play a suitable resource role is characteristic for workflow management systems, while in traditional DES approaches to resource handling, as in Arena and AnyLogic, (human) resources are assigned to a task (as its performer) based on certain policies.

One of the main reasons for considering certain objects as resources is the need to collect utilization statistics (either in an operational information system, like a workflow management system, or in a simulation model) by recording the use of resources over time (their utilization) per activity type. By designating resource roles in information models, these models provide the information needed in simulations and information systems for automatically collecting utilization statistics.

In the hospital example, a medical department, as the process owner, is the organizational unit that is responsible for reacting to certain events (here: patient arrivals) and managing the performance of certain processes and activities (here: medical examinations), including the allocation of resources to these processes and activities. For being able to allocate resources to activities, a process owner needs to manage resource pools, normally one for each resource role of each type of activity (if pools are not shared among resource roles). A resource pool is a collection of resource objects of a certain type. For instance, the three X-ray rooms of a diagnostic imaging department form a resource pool of that department.

Resource pools can be modeled in an OE Class Diagram by means of special associations between object classes representing process owners (like medical departments) and resource classes (like doctors), where the association ends, corresponding to collection-valued properties representing resource pools, are stereotyped with «resource pool», as shown in Figure 3-3. At any point in time, the resource objects of a resource pool may be out of order (like a defective machine or a doctor who is not on schedule), busy or available.

A process owner has special procedures for allocating available resources from resource pools to activities. For instance, in the model of Figure 3-3, a medical department has the procedure "allocate a doctor" for allocating a doctor to a medical examination. These resource allocation procedures may use various policies, especially for allocating human resources, such as first determining the suitability of potential resources (e.g., based on expertise, experience and previous performance), then ranking them and finally selecting from the most suitable ones (at random or based on their turn). See also (Arias et al 2018).

The conceptual process model shown in Figure 3-4 is based on the information model above. It refers to a medical department as the process owner, visualized in the form of a Pool container rectangle, and to doctor objects, as well as to the event type patient arrivals and to the activity type examinations.

This process model describes two causal regularities in the form of the following two event rules, each stated with two bullet points: one for describing all the state changes and one for describing all the follow-up events brought about by applying the rule.

1. When a new patient arrives:

   • if a doctor is available, then she is allocated to the examination of that patient; otherwise, a new planned examination is queued up;
   • if a doctor has been allocated, then start an examination of the patient.

2. When an examination is completed by a doctor:

   • if the queue of planned examinations is empty, then the doctor is released;
   • otherwise, the next planned examination by that doctor is scheduled to start immediately.

These conceptual event rules describe the real-world dynamics of a medical department according to business process management decisions. Changes of the waiting line and (de-)allocations of doctors are considered to be state changes (in the, not necessarily computerized, information system) of the department, as they are expressed in Data Object rectangles, which represent state changes of affected objects caused by an event in DPMN.

Notice that the model of Figure 3-4 abstracts away from the fact that after allocating a doctor, patients first need to walk to the room before their examination can start. Such a simplification may be justified if the walking time can be neglected or if there is no need to maximize the productive utilization of doctors who, according to this process model, have to wait until the patient arrives at the room. Below, this model is extended for allowing to allocate rooms and doctors such that patients have to wait for doctors, and not the other way around.

Switching roles: doctors as patients

The same person who is a doctor at a diagnostic imaging department may be treated as a patient of that department. It's a well-known fact that in the real world people may switch roles and may play several roles at the same time, but many modeling approaches/platforms fail to admit this. For instance, the simulation language (SIMAN) of the well-known DES modeling tool Arena does not treat resources and processing objects ("entities") as roles, but as strictly separate categories. This language design decision was a meta-modeling mistake, as admitted by Denis Pegden, the main creator of SIMAN/Arena, in (Drogoul et al 2018) where he says "it was a conceptualization mistake to view Entities and Resources as different constructs".

In Figure 3-5, the above model is extended by categorizing the classes doctors and patients as «role type» classes and adding the «kind» class people as a supertype of doctors and patients, we create the possibility that a person may play both roles: the role of a doctor and the role of a patient, albeit not at the same time. The object type categories «kind» and «role type» have been introduced to conceptual modeling by Guizzardi (2005).

Queueing planned activities

Whenever an activity is to be performed but cannot start due to a required resource not being available, the planned activity is placed in a queue as a waiting job. Thus, in the case of a medical examination of a patient, as described in the model of Figure 3-5, the waiting line represents, in fact, a queue of planned examinations (involving patients), and not a queue of waiting patients.

This consideration points to a general issue: modeling resource-constrained activities implies modeling queues of planned activities, while there is no need to consider (physical) queues of (physical) objects. Consequently, even if a real-world system includes a physical queue (of physical objects), an OEM-A model may abstract away from its physical character and consider it as a queue of planned activities (possibly including pre-allocated resources). While a physical queue implies that there is a maximum capacity, a queue of planned activities does not imply this. For instance, when a medical department does not require patients to queue up in a waiting area for obtaining an examination, but accepts their registration for an examination by phone, the resulting queue of waiting patients is not a physical queue (but rather a queue of planned examinations) and there is no need to limit the number of waiting patients in the same way as in the case of queuing up in a waiting area with limited space.

A planned activity can only start, when all required resources have been allocated to it. Thus, a planned examination of a patient can only start, when both a room and a doctor have been allocated to it. Let's assume that when a patient p arrives, only a room is available, but not a doctor. In that case, the available room is allocated to the planned examination, which is then placed in a queue since it still has to wait for the availability of a doctor. Only when a doctor becomes available, e.g., via the completion of an examination of another patient or via an arrival of a doctor, the doctor can be allocated as the last resource needed to start the planned examination of patient p.

As a consequence of these considerations, the waiting line of a medical department modeled in Figure 3-5 as an ordered collection of patients is renamed to planned walks in Figure 3-6. In addition, a property planned examinations, which holds an ordered collection of patient-room pairs, is added to the class medical departments. These model elements reflect the hospital's business process practice to maintain a list of patients waiting for the allocation of a room to walk to and a list of planned examinations, each with a patient waiting for a doctor in an examination room.

Decoupling the allocation of multiple resources

For being more realistic, we consider the fact that patients first need to be walked by nurses to the room allocated to their examination before the examination can start. Thus, in the model of Figure 3-6, we add a second activity type, walks to room, involving people (typically, nurses and patients) walking to an examination room.

This process model describes three causal regularities in the form of the following three event rules:

1. When a new patient arrives:

   • if a room and a nurse are available, they are allocated to the walk of that patient to that room, otherwise a new planned walk is placed in the corresponding queue;
   • if a room has been allocated, then the nurse starts walking the patient to the room.

2. When a walk of a patient and nurse to a room is completed:

   • if there is still a planned walk in the queue and a room is available, then the room is allocated and the nurse is re-allocated to the walk of the next patient to that room.
     if a doctor is available, she is allocated to the examination of that patient, else a new planned examination of that patient is queued up;
   • if a doctor has been allocated, then the examination of that patient starts
     if the nurse has been re-allocated, she starts walking the next patient to the allocated room.

3. When an examination of a patient is completed by a doctor in a particular room:

   • if there is still a planned examination (of another patient in another room), then re-allocate the doctor to that planned examination, else release the doctor;
     if the waiting line is not empty, re-allocate the room to the next patient, else release the room;
   • if the doctor has been re-allocated to a planned examination, that examination starts;
     if the room has been re-allocated to another patient, that patient starts walking to the room.

Notice that the process type described in Figure 3-7 does not consider the fact that doctors have to walk to the examination room too, which could be modeled by adding a doctors' walks to room Activity rectangle after the patients' walks to room Activity rectangle.

For being able to collect informative utilization statistics, it is required to distinguish the total time a resource is allocated (its 'gross utilization') from the time it is allocated for productive activities (its 'net utilization'). Thus, only examinations would be classified as productive activities, while walks to room would rather be considered a kind of set-up activities.

Re-engineering the process type by centralizing the re-allocation of resources

In the process type described in Figure 3-7, the re-allocation of released resources is handled in the event rules of activity end events:

• when a nurse's and patient's walk to a room ends, the nurse is free to be re-allocated; so if there is another planned walk and a room is available, the nurse is re-allocated to a walk of the next patient to that room;
• when an examination ends, its resources (a doctor and a room) are re-allocated, if planned activities are waiting for them.

This approach requires that the same re-allocation logic is repeated in the event rules of all activity types associated with that type of resource, implying that all performers involved would have to know and execute the same re-allocation logic. It is clearly preferable to centralize this logic in a single event rule, which can be achieved by introducing release resource request events following activities that do not need to keep resources allocated, as shown in Figure 3-8 where the re-allocation of doctors and rooms is decoupled from the examination activities and centralized (e.g., in a special resource management unit) by adding the two event types room release requests and doctor release requests modeling simultaneous events that follow examinations.

This process model describes an improved business process with six event rules:

1. When a new patient arrives:

   • if a room and a nurse are available, they are allocated to the walk of that patient to that room, otherwise a new planned walk is placed in the corresponding queue;
   • if a room has been allocated, then the nurse starts walking the patient to the room.

2. When a walk of a patient and nurse to a room is completed:

   • if a doctor is available, she is allocated to the examination of that patient, else a new planned examination of that patient is queued up;
   • if a doctor has been allocated, then the examination of that patient starts; in addition, a nurse release request is issued.

3. When a nurse release request has been issued:

   • if the waiting line is not empty and a room is available, allocate the room and re-allocate the nurse to the next patient, else release the nurse;
   • if the nurse has been re-allocated to another patient, she starts walking that patient to the room.

4. When an examination is completed:

   • [no state change]
   • a room release request is issued (e.g., by notifying a resource management clerk or the department's information system), and, in parallel, a doctor release request is issued.

5. When a room release request is received by a resource manager:

   • if the waiting line is not empty and a nurse is available, allocate the nurse and re-allocate the room to the next patient, else release the room;
   • if the room has been re-allocated to another patient, the nurse starts walking that patient to the room.

6. When a doctor release request is received by a resource manager:

   • if there is still a planned examination (of another patient in another room), then re-allocate the doctor to that planned examination, else release the doctor;
   • if the doctor has been re-allocated to a planned examination, that examination starts.

Notice that, in the general case, instead of scheduling several simultaneous release requests, each for a single resource, when an activity completes, a single joint release request for all used resources should be scheduled, allowing to re-allocate several of the released resources jointly.

Displaying the process owner and activity performers

The process owner and the involved performers can be displayed in an OEM process model by using a rectangular Pool container for the process owner and Pool partitions called Lanes for the involved activity performers, as shown in Figure 3-9. Notice that, as opposed to BPMN, where lanes do not have a well-defined meaning, but can be used for any sort of arranging model elements, DPMN Lanes represent organizational actors playing the resource role of performer.

Non-exclusive resources

In OEM, a resource is exclusive by default, that is, it can be used in at most one activity at the same time, if no parallel participation multiplicity is specified. For instance, in all information models above (e.g., in Figure 3-3), the participation associations between the resource classes rooms and doctors and the activity classes walks to room and examinations do not specify any parallel participation multiplicity (for the association end at the side of the activity class), but just the common (historical participation) multiplicity of "*" expressing that resources participate in zero or more activities over time (without an upper bound).

OEM extends UML Class Diagrams by adding the association end stereotype «parallel» for expressing parallel participation multiplicities.

A non-exclusive resource can be simultaneously used in more than one activity. The maximum number of activities, in which a non-exclusive resource can participate at the same time, is normally specified at the type level for all resource objects of that type using the upper bound of a parallel participation multiplicity. In general, there may be cases where it should be possible to specify this at the level of individual resource objects. For instance, larger examination rooms may accommodate more examinations than smaller ones.

A resource can be exclusive with respect to all types of activities (which is the default case) or it can be exclusive with respect to specific types of activities. For instance, in the model of Figure 3-10, a parallel participation multiplicity of 0..1 is defined both for the participation of rooms in walks and in examinations. This means a room can participate in at most one walk and in at most one examination at the same time, which is a different business rule, allowing to walk patients to a room even if it is currently used for an examination, compared to the model of Figure 3-3, allowing to walk patients to a room only if it is currently not being used for an examination.

A simple model with resource counters

Using the conceptual information model shown in Figure 3-3 as a starting point, we first rename all classes and properties according to OO naming conventions and replace each of the two (conceptual) operations allocate a room and allocate a doctor with a triple of isAvailable/allocate/release operations for the two resource object classes Room and Doctor in the MedicalDepartment class, where we also add the counter attributes nmrOfRooms and nmrOfDoctors. Then, the two resource object classes Room and Doctor are dropped. The result of this elaboration is the information design model shown in Figure 3-11.

Using the conceptual process model shown in Figure 3-4 as a starting point and based on the type definitions of the information design model of Figure 3-11, we get the following process design.

This process model defines the following two event rules.

Notice that the event scheduling arrows of Figure 3-12, and also the SCHEDULE statements of the corresponding event rule tables, do not contain assignments of the duration of activities, since it is assumed that, by default, whenever an activity type has an operation duration(), the duration of activities of this type are assigned by invoking this operation.

A general model with resource objects as members of resource pools

In a more general approach, instead of using resource counter attributes, explicitly modeling resource object classes (like Room and Doctor) allows representing resource roles (stereotyped with «res») and resource pools (stereotyped with «pool») in the form of collections (like md.rooms and md.doctors) and modeling various forms of non-availability of resources (such as machines being defective or humans not being in the shift plan) with the help of corresponding resource status values (such as OUT_OF_ORDER). The result of this elaboration is the information design model shown in Figure 3-13.

For an OEM-A class model, like the one shown in Figure 3-13, the following completeness constraint must hold: when an object type O (like Doctor) participates in a «res» association (a resource role association) with an activity type A (like Examination), the process owner object type of A (MedicalDepartment) must have a «pool» association with O.

Extending OE Class Diagrams by adding a «resource type» category

The information design model of Figure 3-13 contains two object types, Room and Doctor, which are the range of resource role and resource pool properties (association ends stereotyped «res» and «pool»). Such object types can be categorized as «resource type» with the implied meaning that they inherit a resource status attribute from a pre-defined class Resource, as shown in Figure 3-16.

The introduction of resource types to OEM class models allows simplifying models by dropping the following modeling items from OEM-A class models, making them part of the implicit semantics:

1. the status attributes of object types representing resource types, which are implicitly inherited;
2. the pre-defined enumeration ResourceStatusEL;
3. the resource management operations isAvailable, allocate and release, which are implicitly inherited by any resource type; and
4. the planned activity queues may possibly be implicitly represented for any resource-constrained activity type in the form of ordered multi-valued reference properties of its process owner object type.

Revisiting the manufacturing workstation example

A manufacturing workstation, or a "server" in the terminology of Operation Research, represents a resource for the processing activities performed at/by it. This was left implicit in the OEM-A class model shown on the right-hand side of Figure 2-3. Using the new modeling elements (resource types, resource roles and resource pools), the processing activities of a workstation can be explicitly modeled as resource-constrained activities, leading to the OEM-A class model shown in Figure 3-17 and to a more high-level and more readable process model compared to the process model of Figure 2-4.

Decoupling the allocation of multiple resources

In a simplified simulation design for the extended scenario (with patients and nurses first walking to examination rooms before doctors are allocated for starting the examinations) described by the conceptual models of Figure 3-6 and Figure 3-9, we do not consider the walks of doctors, but only the walks of nurses and patients. For simplicity, we drop the superclass people and associate the activity type WalkToRoom with the Patient and Nurse classes. The result of this elaboration is the information design model shown in Figure 3-18.

This process design model defines three event rules. Notice that the Examination event rule either re-allocates the doctor to the next planned examination and schedules it, if there is one, or it releases the doctor and re-allocates the room to the next planned walk-to-room and schedules it, if there is one.

Centralizing the re-allocation of resources

As shown before, in the conceptual process models of Figure 3-8 and Figure 3-9, the re-allocation of resources can be centralized with the help of resource release request events and the process owner and the involved performers can be displayed by using a Pool that is partitioned into Lanes for the involved activity performers, resulting in the model shown in Figure 3-20.

New modeling elements for expressing the Allocate-Release Modeling Pattern

Since the Allocate-Release Modeling Pattern defines a generic algorithm for allocating and releasing resources, its (pseudo-)code does not have to be included in a DPMN Process Diagram, but can be delegated to an OE simulator supporting the resource-dependent scheduling of resource-constrained activities according to this pattern. This approach allows introducing new DPMN modeling elements for expressing the Allocate-Release Modeling Pattern in a concise way, either leaving allocate-release steps completely implicit, as in the DPMN Process Diagram of Figure 3-22, or explicitly expressing them, as in Figure 3-23.

The most important new DPMN modeling element introduced are resource-dependent causation (resp., activity start) arrows pointing to resource-constrained activities, as in Figure 3-22. These arrows are high-level modeling elements representing the implicit allocate-release logic exhibited in Figure 3-21. Thus, the meaning of the model of Figure 3-22 is provided by the model of Figure 3-21.

It is an option to display the implicit allocate-release steps with Allocate and Release rectangles together with simple control flow arrows, as between the start event circle and the Allocate R1 rectangle in Figure 3-23.

The meaning of the model of Figure 3-23 is the same as that of Figure 3-22, which is provided by the model of Figure 3-21. The fact that, using resource-dependent activity start arrows, the allocate-release logic of resource-constrained activities does not have to be explicitly modeled and displayed in an OEM process model shows the power of founding a process model on an information model, since the entire resource management logic can be expressed in terms of resource roles, constraints and pools in an OEM information model. This is in contrast to the common approach of industrial simulation tools, such as Simio and AnyLogic, which require defining resource roles, constraints and pools as well as explicit allocate-release steps in the process model, in a similar way as shown in Figure 3-23.

Using resource-dependent activity start arrows in a process model implies using their standard allocate-release logic according to which required resources that have not been allocated before are allocated immediately before an activity requiring them is started and released immediately after this activity is completed if they are not required by the next activity. Whenever another (non-standard) resource allocation logic is needed, it has to be expressed explicitly using ordinary event scheduling arrows.

Simplifying the workstation process model

We can now simplify the workstation model using the resource type category for WorkStation in the OEM class model and a resource-dependent activity start arrow from the arrival event to the processing activity in the DPMN process model. The resulting class model is shown in Figure 3-26.

The simplification of the process model of Figure 2-5 results in the model of Figure 3-25.

Simplifying the medical department process model

We can now simplify the medical department model using the resource type category for Doctor, Room and Nurse in the OEM class model and resource-dependent activity start arrows in the DPMN process model. The resulting class model is shown in Figure 3-26.

The simplification of the rather complex process model of Figure 3-20 by using resource-dependent activity start arrows results in the model of Figure 3-27.

An example of a conceptual PN model: Department of Motor Vehicles

As a simple example of a PN simulation model we consider a Department of Motor Vehicles (DMV) with two consecutive service desks: a reception desk and a case handling desk. When a customer arrives at the DMV, she first has to queue up at the reception desk where data for her case is recorded. The customer then goes to the waiting area and waits for being called by the case handling desk where her case will be processed. After completing the case handling, the customer leaves the DMV via the exit.

Customer arrivals are modeled with an «entry node» element (with name “DMV entry”), the two consecutive service desks are modeled with two «processing node» elements, and the departure of customers is modeled with an «exit node» element (with name “DMV exit”).

DPMN is extended by adding the new modeling elements of PN Node rectangles, representing node objects, and PN Object Flow arrows, representing combined object-event flows. PN Node rectangles take the form of stereotyped UML object rectangles, while PN Object Flow arrows have a special arrow head consisting of a circle and three bars, as shown in Figure 4-3.

Using both Object Flow arrows and Event Scheduling arrows

While an Object Flow arrow between two nodes implies both a flow of the processing object to the successor node and the resource-dependent scheduling of the next processing activity, an Event Scheduling arrow from a processing node to an Event circle represents an event flow where a processing activity end event causes/schedules another event, as illustrated in the example of Figure 4-4.

PN example 1: a single workstation

Part arrivals are modeled with an «entry node» element (with name “partEntry”), the workstation is modeled with a «processing node» element, and the departure of parts is modeled with an «exit node» element (with name “partExit”).

DPMN is extended by adding the new modeling elements of PN Node rectangles, representing node objects with associated event types, and PN Flow arrows, representing combined object-event flows. PN Node rectangles take the form of stereotyped UML object rectangles, while PN Flow arrows have a special arrow head, as shown in Figure 4-6.

PN example 2: a workstation may have to rework parts

Parts that turn out to be defective after being processed need to be reworked. This can be modeled by adding an attribute percentDefective to the object type Workstation and suitable logic to the Processing activity end event rule such that in percentDefective % of all cases a processed part cannot depart the system (i.e., is not removed from the input buffer), but is being reworked by another Processing activity.

PN example 3: Department of Motor Vehicles

A Department of Motor Vehicles (DMV) has two consecutive service desks: a reception desk and a case handling desk. When a customer arrives at the DMV, she first has to queue up at the reception desk where data for her case is recorded. The customer then goes to the waiting area and waits for being called by the case handling desk where her case will be processed. After completing the case handling, the customer leaves the DMV via the exit.

Customer arrivals are modeled with an «entry node» element (with name “dmvEntry”), the two consecutive service desks are modeled with two «processing node» elements, and the departure of customers is modeled with an «exit node» element (with name “dmvExit”).