The OMG standard Business Process Model and Notation (BPMN) is well-established in practice and the most widely used process modeling language [1]. Like most traditional activity-centric process modeling approaches, BPMN relies on a single case notion [2], i.e., a specific perspective on the process, to define control flow relations between activities that are relevant for reaching business goals [3]. To represent the interaction of activities with business objects, data objects can be modeled.
The new trend of object-centric process mining proposes a more comprehensive perspective on business processes by identifying relevant business objects and their individual behavior [2]. Based thereon, the different objects can be correlated through activities that operate on sets of objects. Currently, most approaches to define and visualize "object-centric process models" are based on Petri nets [4], while more high-level process modeling approaches have been introduced under the term "data-centric process models". An overview of the latter is presented by Steinau et al. [5]. Van der Aalst [6] already motivates the refinement of BPMN to better capture object-centric behavior. Yet, the current capabilities of BPMN are not analyzed, and possible adjustments are not specified.
This paper analyzes object-centric capabilities of BPMN by referring to requirements and characteristics from literature. Our investigation shows that BPMN lacks flexibility and precise semantics for identifying and correlating data objects. This indicates the need for object-centric BPMN process models (OC-BPMN); an approach that capitalizes on BPMN's comprehensibility and the holistic behavior represented in contemporary object-centric process modeling approaches. To model OC-BPMN process models, this paper proposes a graphical modeling language combining BPMN process fragments with a data model. It bases its concepts on prior work on fragment-based case management [7].
In the remainder of this paper, we first discuss related work in section 2. We analyze the object-centric capabilities of the status quo of BPMN in section 3, before introducing the novel OC-BPMN process models and informally describing their semantics in section 4. Finally, section 5 discusses the proposed approach and concludes the paper.
The object management group defines the standard BPMN 2.0 [8], which is one of the most widely used process modeling approaches [1]. To provide clear execution semantics, Dijkman et al. [9] provide translational semantics of control flow structures to Petri nets without considering data objects at all. Building thereon, mappings to Petri nets considering data objects and states [10] and BPMN input and output sets [11] have been proposed. Making use of the additional expressiveness of colored Petri nets, Ramadan et al. cover more complex BPMN constructs such as subprocesses and multi-instance behavior, but mostly neglect complex data interactions with these elements [12]. Extending on BPMN, Meyer et al. [13] introduce the concept of foreign keys between data objects and translate data pre-and postconditions to SQL queries, thus assigning meaning to data objects and data associations. Kรถnig and Weske provide formal execution semantics for multi-instance behavior on data [14].
Building on the notation of BPMN, Hewelt et al. propose fragment-based case management [7], a hybrid modeling approach that combines imperative control flow between activities and declarative data flow between process fragments. The semantics are formalized as colored Petri nets by Haarmann et al. [15].
Existing high-level process modeling approaches already aim to represent object-centric behavior. Steinau et al. [5] provide an overview and a framework to systematically analyze the capabilities of data-centric process modeling approaches. For instance, Philharmonic Flows [16] define object-centric behavior, which can be transformed into BPMN 2.0 [17].
More recent process modeling approaches extend on Petri nets to represent object-centric processes. Gianola et al. [4] provide an analysis identifying object-centric modeling features. Synchronous Proclets, as presented by Fahland [18], allow describing the behavior of different object types. Transitions referring to events that interact with different object types are associated. Evolving from ๐-Petri nets [19], Petri nets with identifiers (PNID) [20] support the identification of individual objects and their links. In the context of process mining, van der Aalst and Berti propose object-centric Petri nets (OCPN) [21] that define variable arcs to transfer a variable number of tokens at once but lack object identification. Combining the concepts of OCPNs and PNIDs, Gianola et al. [4] propose object-centric Petri nets with identifiers (OPID) that overcome the limitations of the prior Petri net approaches. Analog to PNIDs, they represent object identities and object relations, while variable arcs can transfer a variable number of object identities.
The previous section outlines contemporary object-centric process modeling approaches. To investigate the capabilities of BPMN, we refer to a set of modeling features for object-centric process models as described by Gianola et al. [4]. The results of comparing OCPN [21], PNIDs [20], OPIDs [4], BPMN [8] and the novel OC-BPMN are presented in Table 1. Furthermore, the issues of convergence and divergence [2] are discussed from a process modeling perspective.
Object-centric process models need to allow for object creation and object deletion, e.g., in the order management process, it should be possible to create new orders and also to delete them. The existing Petri net-based data semantics for BPMN [10,11] support object creation. Object deletion can be modeled implicitly through final data states. An order can be considered completed and is therefore unavailable for further processing. The modeling feature multi-object spawning and transfer describes the capability to create and operate on lists of data objects. As described by Kรถnig et al. [14], BPMN is capable of iteratively creating items for an order. They are added to a list, just like in OPIDs. BPMN is not yet able to represent object references to distinguish individual object instances. In existing formalizations, objects are represented as anonymous tokens. In the example, orders and items cannot be identified via IDs. Hence, their links cannot be identified either and object relations are not supported. Synchronization describes the ability to remember the object relations throughout the process. Items of different orders should not be mixed up. As BPMN cannot represent links between objects, there are no means to correlate objects at different points of the process.
Concurrent object flows describe the ability to process objects concurrently and independently of each other. BPMN supports this feature only partially through multi-instance subprocesses. Given a list data object, each element can be processed by a different subprocess instance concurrently. Yet, the parent process needs to wait for the termination of all subprocess instances.
Overview of supported (), unsupported () and partially supported (โผ) modeling features for object-centric process modeling approaches (adapted from [4]).
In addition to the elaborated modeling features, we investigate the issues of convergence and divergence, as described by van der Aalst [2] in the context of process mining.
Divergence occurs in one-to-many relations between the case object, which determines the case notion, and other related objects. As illustrated in Figure 1 (left), the case notion of the order requires a multi-instance behavior for all related items.
Convergence, on the other hand, describes the issue that a case notion is the subject of a many-to-one relation. BPMN cannot concisely represent multiple process instances that share an activity. In the case notion of an item in Figure 1 (right) the activity place order is executed for every item, but from an order perspective, it processes multiple items at once. Traditionally, batch processing [22] aims to address this issue. These limitations stemming from case-centric process models prevent truly concurrent object flows. To overcome the limitations of traditional BPMN, we propose object-centric BPMN (OC-BPMN), which bases its concepts on fragment-based case management (fCM) [7]. In this approach, the traditional monolithic control-flow structure of BPMN is split into process fragments that each represent an individual object perspective. As later shown in Figure 3, the order management process can be modeled as three process fragments, one for the case notion of an order, one for items, and one for routes. During execution, these fragments can run repeatedly and concurrently and are only constrained by the availability of data objects. The use of fragments also overcomes the need for sub-processes to handle divergence and batch activities for convergence.
To overcome the limitations of traditional BPMN as discussed in section 3, we propose object-centric BPMN (OC-BPMN), which bases its concepts on fragment-based case management (fCM) [7]. In this approach, the traditional monolithic control-flow structure of BPMN is split into process fragments that each represent an individual object perspective. For fCM, a translational semantics to colored Petri nets defines object identities, and their correlation [15]. As shown in Figure 3, the order management process can be modeled as three process fragments, one for the case notion of an order, one for items, and one for routes. During execution, these fragments can run repeatedly and concurrently and are only constrained by the availability of data objects. OC-BPMN combines four modeling artifacts: (i) a data model defining the available object types and their associations, (ii) object lifecycles for each object type that describe the states and state transitions of data objects, (iii) process fragments with a BPMN syntax, and (iv) an object diagram as a representation of the current data state of a running OC-BPMN.
Analog to OPIDs and OCELs, OC-BPMN defines a set of possible data object types as a data model. For the example order management process, the UML class diagram [23] on the left-hand side of Figure 2 describes the classes for orders, items, and routes. Additionally, it defines associations between classes. An order can have many items, and many items can be correlated to one route.
In line with OPIDs [4], we restrict our class diagram to binary associations and prohibit many-tomany relations. Many-to-many relations can be represented using association classes and reification. Note that orders, for example, have an implicit many-to-many relation to routes.
Analog to BPMN [13] and fCM [7], OC-BPMN specifies an object lifecycle (OLC) for each data class. An OLC defines a set of states as an abstraction of concrete attributes or processing states. Also, state transitions are defined. According to the OLCs in Figure 2, an order can be new, then placed, invoiced before being paid, and finally completed. In the same manner, the available states and transitions are defined for items and routes. An item can initially be new, placed, picked, in delivery, shipped, and completed. A route is either new, started, or ended.
In OC-BPMN, concurrently running process fragments jointly define the object-centric process. As illustrated in Figure 3, the order management process can be expressed as three fragments. Within a fragment, activities can be connected via traditional control flow, which orders their execution. Additionally, activities read and write data object nodes and list data object nodes that specify a class from the class diagram and a state from its corresponding object lifecycle. Following established BPMN semantics [24], activities can be executed if they are both control flow (cf) and data flow (df) enabled. An activity is cf-enabled without ongoing cf-arcs or if at least one has been enabled by previous activities. It is df-enabled in an execution state if data objects in the specified states exist with the required links.
In the order fragment, start shopping is always enabled and creates a new object instance of Order in state new. Given a set of new items, place order is then enabled for items and the new order. It will change the items and the order into the state placed respectively. Furthermore, the transferred items are all linked to the order to reference them later. Then the order can be invoiced and paid by the fragment. Concurrently, the individual items are processed in the item fragment, and can be correlated to routes and processed further in the routes fragment. In OC-BPMN, we introduce a new notation to specify the required synchronization of related objects. Object nodes can be associated to indicate that the execution of the following activity requires a synchronization of the referenced objects at runtime. For instance, the node for Order[paid] is associated with the list data object node for Item [shipped]. The activity mark as complete can, therefore, only be executed for orders and items in the respective states and only if they have been linked before. After the execution, the links will be preserved. Analogously, end route synchronizes a route with its items.
With OC-BPMN, we also propose a notation for the instance level of an OC-BPMN model. The data state is an instance of the class diagram. It represents objects as class instances with a state attribute of their respective OLC. Objects can be linked, such that each link is an association instance.
In Figure 4, a UML object diagram [23] depicts the data state containing the paid order ๐1 and placed order ๐2, the items ๐1 (shipped), ๐2 (picked), and ๐3 (placed), and the ended route ๐1 and new route ๐2. Also note that ๐1 is linked to multiple items, i.e., ๐1 and ๐2, and ๐2 is linked to ๐3. In the current state, only ๐1 is linked to ๐1. In a future data state, ๐2 could be linked to ๐2 and ๐3, constituting an implicit many-to-many relation between order and route.
An object diagram can be useful to visualize the current state of a running process or to configure an initial data configuration for simulating or executing the OC-BPMN. 2) for the order management process.
This paper investigates the capabilities of BPMN to model object-centric processes. In our analysis of modeling features, we identify limitations for BPMN regarding object identification and missing link semantics. Also, the case notion of BPMN process models leads to the problems of convergence and divergence. To overcome these limitations, we build on concepts from case management to propose the novel modeling paradigm of object-centric BPMN (OC-BPMN).
OC-BPMN models can flexibly combine process fragments that are modeled with different case notions, i.e., object perspectives, allowing to overcome convergence and divergence in process modeling. In the future, we will provide precise execution semantics for OC-BPMN. Object-centric Petri nets with identifiers by Gianola et al. [4] promise a suitable goal formalism, which can be extended with exact synchronization as proposed for Proclets [18]. The resulting formalism will allow for precise correlation mechanisms of linked data objects throughout the process execution.
So far, we only analyzed BPMN and not other contemporary object-centric process modeling approaches that could also provide useful visualizations for object-centric processes. Future studies should investigate their capabilities as well and compare their comprehensibility for users empirically.
In the future, contemporary discovery algorithms for OCPNs can be extended to also allow for discovering the proposed OC-BPMN models. This includes a discovery of the creation of links between objects and their synchronization behavior. On the other hand, OC-BPMN models could also be used and configured to model and refine object-centric simulation models, allowing for the creation of object-centric event logs.
In summary, we propose a novel, object-centric dialect of BPMN with execution semantics based on OPIDs. We believe that OC-BPMN offers a more well-known notation for object-centric processes, making the object-centric paradigm more accessible in practice.