1.4. Process Modeling with BPMN and DPMN

The Business Process Modeling Notation (BPMN) is an activity-based graphical modeling language for defining business processes following the flow-chart metaphor. In 2011, the Object Management Group has released version 2.0 of BPMN with an optional execution semantics based on Petri-Net-style token flows.

The most important elements of a BPMN process model are listed in .

Name of elementMeaningVisual symbol(s)


Something that 'happens' during the course of a process, affecting the process flow. There are three types of Events, based on when they affect the flow: a Start Event is drawn as a circle with a thin border line, while an Intermediate Event has a double border line and an End Event has a thick border line.


Work that is performed within a Business Process. A Task is an atomic Activity, while a Sub-Process is a composite Activity. A Sub-Process can be either in a collapsed or in an expanded view.


A Gateway is a node for branching or merging control flows. A Gateway with an "X" symbol denotes an Exclusive OR-Split for conditional branching, if there are 2 or more output flows, or an Exclusive OR-Join, if there are 2 or more input flows. A Gateway with a plus symbol denotes an AND-Split for parallel branching, if there are 2 or more output flows, or an AND-Join, if there are 2 or more input flows. A Gateway can have both input and output flows.

Sequence Flow

An arrow expressing the temporal order of Events, Activities, and Gateways. A Conditional Sequence Flow arrow starts with a diamond and is annotated with a condition (in brackets).

Data Object

Data Objects may be associated with Events or Activities, providing a context for reading/writing data. A unidirectional dashed arrow denotes reading, while a bidirectional dashed arrow denotes reading/writing.

A good modeling tool, with the advantages of an online solution, is the Signavio Process Editor, which is free for academic use (www.signavio.com/bpm-academic-initiative).

BPMN process diagrams can be used for making

  1. conceptual process models , e.g., for documenting existing business processes and for designing new business processes;
  2. process automation models for specific process automation platforms (that allow partially or fully automating a business process) by adding platform-specific technical details in the form of model annotations that are not visible in the diagram.

The following diagram shows an example of a BPMN process model.

Figure 1-6. A BPMN Process Diagram for a pizza service company

However, the BPMN process diagram language has several semantic issues and is not expressive enough for making platform-independent process design models that can be used for designing DES models.

Shortcomings of BPMN

Notice the BPMN Boundary Timeout Event circle attached to the take order activity in Figure 1-6 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 task (planned activity), that is the time span during which the task 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 (referring to organizational positions with corresponding resource pools), it does not support modeling other types of resource objects, such as machines or rooms. As a workaround, the model above includes two BPMN Data Objects, ovens and scooters, for representing resource objects. Also, BPMN does not allow specifying resource cardinality constraints (e.g., for stating that making a pizza requires two pizza makers and one oven).

The third, and most severe, issue of the BPMN model is its uniform (semantically overloaded) use of "sequence flow" arrows for sequencing both 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 task is enqueued (and only started when all required resources become available), in the case of the lost order event, the incoming "sequence flow" arrow means that a new event is scheduled to occur immediately.

BPMN has the following issues:

  1. A limited concept of "business processes" as isolated "cases", which does not allow to account for any dependency between business processes (e.g., competing for resources).
  2. Overloading/ambiguity of sequence flow arrows, which represent various kinds of connections, including resource-independent event flows and resource-dependent activity scheduling.
  3. Insufficient integration of the objects that participate in a process.
  4. Insufficient support of resource management. In particular, no other resources except (human) performers can be modeled, and the important concepts of resource cardinality constraints, resource pools, alternative resource types and resource allocation priorities are not supported.
  5. No support of processing activities and processing networks, which are generalized queueing networks where processing objects enter a system via arrival events and then "flow through the system".
  6. No convincing formal semantics. BPMN's execution semantics is defined in terms of an abstract Petri-Net-style "token" flow (following the predominant academic paradigm), which does not match its intuitive semantics based on event flows and resource-dependent activity scheduling.

DPMN solves the issues of BPMN

The Discrete Event Process Modeling Notation (DPMN) is a Discrete Event Simulation modeling language based on Event Graphs (Schruben 1983) and BPMN. It combines the intuitive flowchart modeling style of BPMN with the rigorous semantics provided by the event scheduling arrows of Event Graphs and the event rules of the Object Event Modeling and Simulation (OEM&S) paradigm (Wagner 2017a, Wagner 2018b).

DPMN adapts the language of BPMN Process Diagrams for the purpose of simulation design modeling where a process model must represent a computationally complete process specification. While large parts of BPMN’s vocabulary, visual syntax and informal semantics can be preserved in DPMN, a number of modeling elements need to be modified.

The following diagram shows the DPMN process model corresponding to the BPMN model shown in Figure 1-6 above.

Figure 1-7. A DPMN Process Diagram for a pizza service company

DPMN adopts and adapts the syntax and semantics of BPMN in the following way:

  1. Instead of BPMN's "Sequence Flow" arrows, DPMN has
    1. Event Flow arrows, or Event Scheduling arrows, like in Event Graphs, representing the causation of follow-up events in conceptual process models, corresponding to event scheduling in process design models. For instance, in Figure 1-7, the arrow from the time out event at the "take order" task buffer to the "lost orders" event is an event flow arrow.
    2. Resource-Dependent Activity Scheduling (RDAS) arrows with three bars representing an input task buffer. For instance, in Figure 1-7, "order calls" events and "take order" activities, and "take order" and "make pizza" activities, are connected via an RDAS arrow.
  2. A DPMN Process Diagram has an underlying UML Class Diagram defining its types (including object, event and activity types). These type definitions also include definitions of resource roles, resource cardinality constraints and resource pools, which provide the information needed for resource management in process executions. It's an option to exhibit resource roles and resource cardinality constraints in a DPMN process model, such as in the model of Figure 1-7, which includes
    1. the two (non-performer) resources "ovens" and "scooters" assigned to the activities "make pizza" and "deliver pizza" via resource associations visually indicated by a small black square-shaped dot;
    2. resource cardinality constraints for all activities: (a) for the performer role of "make pizza" activities, the resource cardinality constraint "exactly 2" is expressed with the annotation "[2]" appended to the performer role name "pizza makers", (b) the resource associations for assigning an oven and a scooter to "make pizza" and "deliver pizza" activities are annotated with "1" expressing the constraint that exactly one resource object is required for performing these activities; as a result of the resource association of the "oven" resource object with the "make pizza" activity and the attached resource cardinality constraint "exactly 1" in conjunction with the "pizza makers [2]" performer cardinality constraint, it holds that a "make pizza" activity requires exactly two pizza makers (as performers) and one oven.

A conceptual DPMN process model describes the causal regularities of a real world process, while a DPMN process design model defines event rules that capture causal regularities.