Modeling Dimensions

While there are many other perspectives on process modeling, all of these can be catego- rized into the modeling approaches that have been described in Table 2.1. Although some researchers have focused on the imperative versus declarative dimension [Pic+12; Pre+14; Rei+13], others have focused on the activity-centric versus data-centric dimension [Ev15; Hai+13; Hai+16; van+13]. Additionally, there have also been researchers who have focused on the continuum between structured and unstructured dimensions [di +14], or from simple processes that ordinary workers can perform to complex processes that require experts [MF11]. This section explores these perspectives and their relationships with the six dimensions [SZ92; Zac87].

From Imperative to Declarative

As described in Table 2.1, modeling approaches based on the how dimension [SZ92; Zac87] include imperative, activity-centric, control-flow, declarative, constraint-based, rules-centric, and hybrid process modeling approaches. These modeling approaches can be placed on a continuum from imperative to declarative.

While some researchers focus on the imperative versus declarative dimension [Pic+12; Pre+14; Rei+13], others focus on the continuum that exists between the structured (imperative) and the unstructured (declarative) dimension [di +14]. Barukh and Benatallah [BB14] describe process paradigms as being structured, semi-structured, and unstructured. The distinction between imperative processes and declarative processes has its origins in programming lan- guages. One of the many classifications of programming languages distinguishes between imperative and declarative languages [Aho+07; AM14]. The IEEE [IEE10] utilizes the same dichotomy between imperative and declarative, but uses the term “procedural programming language”, which has a similar meaning to the term “imperative” and “nonprocedural pro- gramming language” which has a similar meaning to the term “declarative”. This classification is commonly used by those researching BPM to classify process models [Pic+12; Pre+14; Rei+13]. In terms of this perspective, activity-centric and control-flow approaches are imper- ative, and constraint-based and rules-centric approaches are declarative. In addition, some researchers have proposed a mix or hybrid that combines the two approaches [CV15; Par+13; WS13].

Imperative processes explicitly define the sequence of steps in the process and their transitions, and strictly prescribe how the system should work [Pv06; Pre+14; Web+09]. Any sequence of steps that is not specified is disallowed [de +15a]. Burattin et al. [Bur+12] classify BPMN, UML AD, EPC, and BPEL as imperative process models. Other imperative business process languages include XPDL. Some authors use the terms “imperative process models” and “procedural process models” interchangeably [Fah+09; Pre+14]. Procedural BPM languages can be reduced to Workflow Net (WF-Net) [van95], which is a type of Petri Net introduced by van der Aalst [van95; van97]. As such, Petri Nets can be considered the theoretical foundation for imperative process models. Figure 2.3.c illustrates an example of an imperative process model that was designed using BPMN.

The activity-centric approach is an imperative approach that uses control-flow as its modeling technique [Ev15; Rus+14]. Chiao et al. [Chi+13] use the terms “activity-driven” and “activity- centric” interchangeably. BPMN and YAWL are considered to be activity-centric approaches [Rus+14] as is UML AD [Ev15].

In declarative processes all of the process steps are allowed unless forbidden by a rule [de +15a]. Therefore, declarative processes define the process based on its constraints [di +15], and not by using the process flow. de Giacomo et al. [de +15a] classify DECLARE [Pes+07; van+09], Guard-Stage-Milestone (GSM) [Hul+11b], and CMMN as declarative process models. Constraint-based modeling is another declarative approach that attempts to increase flexibility [Rus+14]. Constraint-based models describe the activities and the relationships among them using constraints to prohibit undesired behaviors [Rus+14]. DECLARE is considered to be a constraint-based approach [Rus+14].

Researchers have recognized that the distinction between imperative processes and declarative processes is not binary, and that a mixture of approaches is often preferable [de +15a; Pre+14]. Hybrid process models combine the characteristics of both imperative process models and declarative process models [Yu+15] to achieve a balance between the structure of imperative processes and the flexibility of declarative processes. Several hybrid process models and tools have been proposed, including the Case Analytics Workbench [Yu+15], BPMN-D [de +15a], CPN Tools 4 [WS13], CombiS-BP editor [Par+13], and the combination of DECLARE with BPMN [Her14].

From Control-flow to Data-driven

Imperative processes have been the traditional focus of BPM. According to Dumas et al. [Dum+16], the separation of concerns between imperative control-flow and data aspects in BPM has allowed for the creation of foundational theories, but has also limited the theory and methods of BPM that are now under pressure to support ad-hoc and more flexible processes.

This has led to other approaches to BPM that in addition to the declarative processes described above, are being explored. One of these approaches is to explore the continuum between imperative and declarative approaches and data-centric approaches, combining the

how dimension with the what dimension. Although some researchers see this continuum

as running from imperative to data-centric, Marrella et al. [Mar+15c] noticed that in both imperative and declarative approaches data can be relegated to input and output for activities. Therefore, it is more realistic to see this continuum from the how (focus on function) to the

what (focus on data) dimensions.

Meyer et al. [Mey+11] describe a continuum from control-flow to data-driven, as follows: control-flow driven, data-aware control-flow driven, control-flow and data-driven, control- aware data-driven, and finally data-driven. Eshuis and van Gorp [Ev15] developed a hybrid process model that starts with an object-centric design that is later translated into GSM. They use UML AD for the activity-centric portion of the model, and Unified Modeling Language (UML) [OMG09c] state machines to describe the object’s life cycle for the data-centric portion.

From Data-aware to Artifact-centric

As can be seen in Table 2.1 modeling approaches based on the what dimension [SZ92; Zac87] include data-centric, data-driven, artifact-centric, data-aware, object-aware, object-centric, and entity-centric modeling approaches. These modeling approaches can be placed on a continuum from data-aware to artifact-centric. Data-aware means that the process modeling language can accommodate simple data normally used for routing purposes. BPEL is an example of a data-aware approach [Hab+08]. Data-centric processes couple control-flow with data, treating the data as a first class citizen to make the process more flexible [Ev15]. Data-centric processes normally support the Knowledge Intensive Processes (KiP), which is based on a semi-structured approach that is difficult to achieve using activity-centric imperative models [Ev15]. Data-centric approaches use finite-state machines or rules for modeling techniques that describe the data life cycle [Ev15]. A data-centric process is based on the availability of data and its values to evolve the process [Mar+15c]. Similarly, the progress in object-aware processes is based on the processing of business data represented by business objects [Rei12].

Object-aware models treat business objects and business processes as equal entities and allow processes to manipulate business objects [Chi+14; Rei12]. Object-aware processes consider the behavior of individual objects and the interaction between object instances [Chi+14]. The execution of object-aware processes is guided by the availability of object instances and their values [Chi+14].

Object-centric models distribute the process among several interacting components, with each component representing the life cycle of an object [WK08]. In terms of this perspective, a BA is considered to be object-centric. GSM and Data-Centric Dynamic Systems (DCDS) follow the BA’s framework [Cal+13; MC16; Rus+14], where the model allows for the definition of activities that rely on the data changes and states [Rus+14]. In both object-centric and artifact-centric approaches data and behavior are managed together in logical units [Dum+16]. Chiao et al. [Chi+14] use the terms “object-aware” and “object-centric” interchangeably.

From Ordinary Workers to Experts

As shown in Table 2.1, modeling approaches based on the who dimension includes user-driven, KiP, human-centric, people-centric, and collaborative approaches. Some of these modeling approaches can be placed on a continuum based on the type of user that is expected to interact with the executing process. The continuum may range from processes that ordinary workers can perform to complex processes that require experts [MF11]. Approaches like KiP and case management expect expert users that require flexibility and the ability to influence the outcome of the process.

Subject-oriented Business Process Management (S-BPM) [Fle+12] was introduced in 1994 by Fleischmann [Fle94]. S-BPM is based on a decentralized view of the process, where a process is an interaction between subjects [Fle+13]. Traditional BPM processes are based on a token traversing a control-flow, while S-BPM is based on subjects communicating using messages [Kan+16].

Other Dimensions

The why, the where, and the when dimensions presented in Table 2.1 give rise to other process model approaches that will be explored in this section.

Modeling approaches based on the why dimension [SZ92; Zac87] include the goal-oriented modeling approach. Goal-oriented processes focus on what has to be done in order to achieve a goal, and much less on how to perform the process [Küs+14]. Most of the work on goal- oriented processes is based on agents, or requirements. Some goal-oriented process models use a hierarchy of goals and are executed by agents, such as GO-BPMN [CG08] or Go4Flex [Bra+10]. Another approach to goal-oriented processes is based on requirements, and assumes that a business process encodes how the organization achieves its goals, therefore runtime changes to the process must be done in such a way as to preserve the original goals [AR16]. Modeling approaches based on the where dimension [SZ92; Zac87] include context-aware, and context-oriented modeling approaches. Some context-aware modeling approaches only

consider location as the context of the process [Hei+15], but others allow for the modeling of other context events. CAptEvo is a context-aware framework where the context is modeled using a state machine in addition to the process [Buc+11; Buc+12]. Context-Aware Meta Execution-Workflow (C-MEW) is another context-aware workflow environment [Jai+16]. In both, CAptEvo and C-MEW the term “context” refers to more than just location. In C- MEW context information such as the user performing the task and the location is considered external context, but internal context such as task assignments to users and error exceptions can also be handled [Jai+16].

Modeling approaches based on the when dimension [SZ92; Zac87] include the event-driven modeling approach. The event-driven modeling approach uses event-action rules to describe a process [Kap+13] and is normally based on Complex Event Processing (CEP) [Fab+16; Sof12] [Lea09]. The benefit of CEP for process modeling has been widely recognized in the more than 130 papers that Krumeich et al. [Kru+14] found to be relevant in their Systematic Literature Review (SLR). EPC is an example of an event-driven process modeling approach. However, EPC only supports simple events, but has been extended to support CEP by Krumeich et al. [Kru+15].