Chapter 3. Discrete Event Processes

A discrete process (DP), or discrete event process, consists of a partially ordered set of events such that each of them causes zero or more 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. A discrete process may be an instance of a discrete process type defined by a discrete process model.

A business process (BP) is a discrete process that involves activities performed by organizational agents qua one of their organizational roles defined by their organizational position. Typically, a business process is an instance of a business process type defined by an organization or organizational unit (as the owner of the business process type) in the form of a business process model.

While there are DPs that do not have an organizational context (like, for instance, message exchange processes in digital communication networks or private conversations among human agents), a BP always happens in the context of an organization.

When a person, as an organizational agent, performs an activity within a BP, the person is a resource (called performer in BPMN) and the type of activity is resource-constrained. When a person performs an activity within a discrete process that is not a BP (e.g., laughing in a conversation), the person is the performer of the activity, but not a resource of it. Consequently, while all business activity types are resource-constrained, there are also activity types that are not resource-constrained.

The performance of a resource-constrained activity is constrained by the availability of the required resources, which may include human resources or other (passive) resource objects, such as rooms or devices. For providing the resources required for performing its business processes, an organization has resource pools.

The dependency of an activity on resources is modeled with the help of resource roles, which are special properties of the activity type. A resource role can be defined in a UML class model in the form of an association between the class representing the activity type and the class representing the resource object type. The multiplicity of the association end at the side of the resource object type defines resource cardinality constraints, while the multiplicity of the association end at the side of the activity type defines a multitasking constraint.

There are two kinds of business process models:

1. BPMN-style Activity Networks (ANs) consisting of event nodes and activity nodes (with task queues) connected by means of event scheduling arrows pointing to event nodes and resource-dependent activity scheduling (RDAS) arrows pointing to activity nodes, such that event and activity nodes may be associated with objects representing their participants. In the case of an activity node, these participating objects include the resources required for performing an activity. Typically, an activity node is associated with a particular resource object representing the activity performer.

2. GPSS/Arena-style Processing Networks (PNs) consisting of entry nodes, processing nodes (with task queues and input buffers) and exit nodes connected by means of processing flow arrows, which combine an RDAS arrow with an object flow arrow. The PN concept is a conservative extension of the AN concept, that is, a PN is a special type of AN.

While in ANs, there is only a flow of events (including activities), in PNs, this flow of events is combined with a flow of processing objects (often called “entities"). Correspondingly, while the activity nodes of an AN only have a task queue (a queue of planned activities), the processing nodes of a PN have both a task queue and a corresponding queue of processing objects (waiting to be processed).

In an AN, all activity nodes have a task queue filled with tasks (or planned activities) waiting for the availability of the required resources. An RDAS arrow from an AN node to a successor activity node expresses the fact that a corresponding activity end event (or plain event) triggers the deferred scheduling of a successor activity start event, corresponding to the creation of a new task in the task queue of the successor activity node.

A PN process is a business process that involves one or more processing objects and includes arrival events, processing activities and departure events. An arrival event for one or more processing objects happens at an entry station, from where they are routed to a processing station where processing activities are performed on them, before they are routed to another processing station or to an exit station where they leave the system via a departure event.

A PN process model defines a PN where each node represents a combination of a spatial object and an event or activity variable:

1. Defining an entry node means defining both an entry station object (e.g., a reception area or a factory entrance) and a variable representing arrival events for arriving processing objects (such as people or manufacturing parts).
2. Defining a processing node means defining both a processing station object (often used as a resource object, such as a workstation or a room) and a variable representing processing activities.
3. Defining an exit node means defining both an exit station object and a variable representing departure events.

In a PN, all processing nodes have a task queue and an input buffer filled with processing objects that wait to be processed. A PN where all processing activities have exactly one abstract resource (often called a "server") is also known as a Queuing Network in Operations Research where processing nodes are called "servers" and processing objects are called "customers" or "jobs" (while they are called "entities" in Arena).

For accommodating resource-constrained activities and Processing Networks, basic OEM and DPMN are extended in two steps. The first extension, OEM/DPMN-A, comprises four new information modeling categories (activity types, resource roles, resource pools, and parallel participation) and one new process modeling element (RDAS arrows), while the second extension, OEM/DPMN-PN, comprises a set of four pre-defined object type categories (processing objects, entry stations, processing stations, exit stations), two pre-defined event type categories (arrival events, departure events), one activity type category (processing activities), three node type categories (entry nodes, processing nodes, exit nodes) and one new process modeling element (object flow arrows).