Business process modelling (BPM) notations describe processes using a graphical representation of process-relevant entities and their interplay. Despite the wide literature on the comparison between different modelling languages, the BPM community still lacks an ontological characterisation of process constructs. Purpose of this paper is to start filling this gap by providing a first ontological analysis of the main business process entities. The analysis and the resulting characterisation aim at illustrating the different perspectives that BPM languages implicitly take on business processes, as well as guiding the modellers in making an appropriate choice when selecting among different notations.
Business process modelling (BPM) notations describe processes using a graphical
representation of process-relevant entities and their interplay. If we focus on typical
businessto-consumer (B2C) scenarios, examples of languages include well-known imperative
languages such as the Business Process Model and Notation (BPMN), the Unified
Modeling Language Activity Diagram (UML-AD) and the Event-driven Process Chain (EPC)
as well as declarative notations such as the Case Management Model and Notation
(CMMN) and DECLARE.1 Despite the wide literature on process execution semantics and
on the comparison between the graphical constructs of different languages [
2We will interchangeably use the notions of ‘process model’ and ‘process diagram’. other hand, they are emblematically neglected when explaining or illustrating the very notion of process in the BPM community.
The purpose of the paper is to remove the above paradox, offering an ontological analysis of the various kinds of process participants, with a specific focus on B2C scenarios that will hopefully contribute to the ontological foundations of BPM. The paper is structured as follows. In Section 2, we provide an illustration of different constructs used by imperative and declarative modelling notations; then we identify in Section 3 the constructs referring to process participants, and, after analysing the definition of process in Section 4, we discuss the ontological properties of process participants in Section 5, providing in this way an initial comparison of (some of) the modelling constructs used in different modelling notations (Section 6). This represents a first step toward the illustration of how an ontological analysis enlarged to process participants can support the interpretation of business process diagrams, the comparison between modelling notations, the illustration of the different perspectives that BPM languages implicitly take on business processes, as well as guiding the modellers in making an appropriate choice when selecting among different notations.
In this section we illustrate the graphical elements of the BPM languages taken into account throughout the paper.3 As a starting point, we select five amongst the most popular languages that follow the imperative (BPMN, UML-AD, EPC) and declarative (CMMN and DECLARE) paradigms. To support the presentation, we make use of process diagrams illustrating the simple scenario of a customer buying a flight ticket from a travel agency. For the sake of clarity, we “annotate” the diagrams with speech balloons to explicitly indicate the graphical constructs.
BPMN. It is a standard language, proposed by the Object Management Group (OMG), to design business processes.4 BPMN defines a Business Process Diagram (BPD) which includes a set of graphical constructs divided in: (i) flow objects, (ii) data, (iii) connecting objects, and (iv) swimlanes. Flow objects define the behavior of a business process, as the one reported in Figure 1. They divide into events, activities and gateways. Events represent things that happen during a process; they divide into start, intermediate and end events. An activity is a generic term that is used for work to be performed. It can be either atomic (task) or compound (sub-process). A gateway determines the forking, merging or joining of paths. BPMN 2.0 allows for the explicit modelling of data by means of constructs denoting data objects, data inputs, data output and data stores. Flow objects are inter-linked through connecting objects which are not further discussed here. Swimlanes are used to specify who is responsible for the execution of a certain process.5 Looking at Figure 1, for example, two swimlanes specify that ‘Customer’ and ‘Travel agency’ will carry out the depicted processes.
3Note that our analysis focuses on the graphical elements used to draw models and leave out further notions that may be included in the language specification.
4http://www.omg.org/spec/BPMN/2.0/ 5Because of lack of space we do not introduce the distinction between pools and lanes here. r e tsoum nFeleigdhetd C Pool y c n e g A lve request raT received
Start event
Check travel agency website
Check flight
offer Flight request Make flight offer
Task
Message event offer received
UML-AD. It is one of the diagram families of the OMG standardized UML language6, whose purpose is to describe the control and data flow as a sequence of activity nodes connected by activity edges (see example in Figure 2).
The nodes responsible of describing the control flow are the action nodes and the control nodes. While the former represent atomic steps within an activity, the latter allow for controlling the execution flow by means of the AND, OR or XOR logical operations. Additional control flow nodes are used to depict the initial and final nodes of process models. Object nodes and object flows are the main UML-ADs constructs describing the data flow. The former represent objects at a given point of the flow and, as such, they can also have an associated state. The latter are instead used for connecting object nodes to actions. Activity partitions are a mechanism for grouping activity nodes that have common characteristics. They are mainly used to define organizational units. Finally, the notation allows for specifying activity pre- and post-conditions, for instance, by annotating activity edges with guards.
EPC. It is a modelling language developed in the early 1990s as part of the Architecture
of Integrated Information Systems (ARIS) framework [
Three types of nodes are responsible for describing the control flow: function, event and logical operators (see Figure 3). Function nodes represent atomic activities and can be considered as the “active” part of a control flow; event nodes stand for the states in which a process happens to be and can be therefore considered as the “passive” part of the control flow. Functions and events alternate, capturing the intuition that states lead to activities, while activities generate states. Finally, the XOR, AND and OR logical operators allow for controlling the execution flow.
6http://www.omg.org/spec/UML/
Customer
Event
Client unsatisfied
Logical XOR operation
Customer Reject
Of er Client satisfied
Functions within the control flow can be connected to objects belonging to the other views of an ARIS model, namely the organizational, data, function and product service views. While the exact number of objects differs across different versions of the language,7 the core modeling constructs usually denote: (i) input and output data, material, services or resource objects required or produced by a function; (ii) owners who are responsible for a specific function; (iii) organization units responsible for a specific function (e.g., a department); and (iv) supporting systems upon which a function acts (e.g., a database). Some versions include goals that can be connected to specific functions. CMMN. It is a OMG standard for the declarative representation of process models.8 Its main modelling construct is the case, which is described by a case diagram (see Figure 4). Differently from the previous languages, CMMN follows a declarative approach. Thus, rather than describing all the allowed flows of a process from the start to the end, it models cases as composed of process segments (called stages) and tasks.
A case plan model contains: (possibly discretionary) tasks, stages, milestones, event
listeners, connectors, and sentries. A task is a unit of work. Stages are plan fragments
which can be composite or atomic. A milestone represents an accomplishment which
occurs during the process of a case. Events represent something that can happen to a plan
construct (e.g., a task cancelled) or in general (timer and user event listener). Connectors
7The analysis and diagrams contained in this paper refer to the description provided in [
NOTATION init A k A A A
I B I B
DESCRIPTION
B
if A occurs, then B occurs after A
are used to link different plan items. Finally, sentries represent the entry / exit criteria for
path items and can direct the control flow mimicking the AND and OR logical operators.
Declare. It is one of the most popular declarative languages for modelling business
processes [
We present now a short categorization and comparative summary of the main modelling constructs of the five languages. Modelling constructs are grouped into the three basic categories of process modelling languages, namely the behavioural (BEV) category related to the control flow, the data (DT) category related to the data flow, and the organizational (ORG) category related to process actors. Since the behavioural category is the most articulated, we further describe it in terms of Functional (executable pro-active actions), Event (what happens), Flow (how actions are connected and routed), and State (of the world) categories. The result of this grouping is summarized in Table 2.
First, we can observe that all the imperative languages, namely BPMN, EPC, and UML-AD, provide distinctive constructs to indicate the start and the end of a process.
9Some proposal to extend DECLARE in order to incorporate non-atomic activities and data centric patterns
are presented in [
V E B T D G R O UML-AD Action node Activity Start/End node Accept event action Send signal action Control node Control Flow Object Flow Guard on control node Pre- Post-condition on activity
EPC Function Process path –
Start/End event
Task Stage
DECLARE
–
(I/O) data object
Activity Partition AOrcgtiavnitizyaOtiownner Table 2. A comparison among modelling languages – CMMN specifies only exiting conditions while DECLARE allows (but does not force) to specify only initial activities. Not surprisingly, all five languages have graphical symbols for atomic activities. Instead, subprocesses and generic groups of activities are foreseen in all languages but EPCs and DECLARE. Other common constructs are routing nodes, connectors and data objects. CMMN (DECLARE) does not have explicit construct for routing nodes; nonetheless a combination of sentries and connectors, (DECLARE patterns) can be used to route the control flow mimicking the logical operators. The level of details of connectors can vary. Besides the one used to denote connections of the control flow, common to all languages, BPMN, EPC, and UML-AD provide symbols to denote the connections between actors (data) and activities, or the messages exchanged between different activities. Also, the level of detail of data objects can vary; e.g., EPC is particularly rich in defining a taxonomy of data objects. Alternative (OR, XOR) routing nodes can incorporate guards, i.e., conditions that specify which branch to follow, in all languages but EPC, where this role can be taken by states. Actors and organizational constructs are present in imperative languages, although exploiting different notations.10
A distinction that is present in BPMN (to some extent also in CMMN) is between active tasks, explicitly performed by the actor specified in a corresponding swimlane, and passive events that occur independently from the actor itself. Other distinctive aspects are (i) the explicit presence of pre- (activation) and post-conditions on activities, which is one of the characteristic features of CMMN and is also foreseen in UML-AD; (ii) the explicit presence of a state, which is a characteristic feature of EPCs where states and functions (tasks) have to interleave, and is also present in CMMN in the form of milestones.
Davenport [
From these definitions, it is rather spread the idea of a business process as a set of activities that, together, contribute to achieve a certain goal or, more in general, contribute to transform an input into a desired output. Besides the emphasis on these core aspects, the literature underlines the importance of additional characteristics such as the value brought about from the realisation of a certain goal, as well as the organisational boundaries in which a process is embedded.
Despite this general agreement, the BPM literature does not provide in depth explanations for what a process is or what its components (e.g., activities) are. Let us consider two illustrative examples. First, it remains unclear whether processes are defined at the type or at the instance (execution) level. A process execution happens in time and has a specific duration. Differently, process types are descriptions and do not unfold in time.11 Examples of process types are depicted in process diagrams like the ones in the previous sections that describe how the various activities are connected to produce a goal, which is in turn a description of a desired state (e.g., that a certain ticket is purchased). The carrying out of these activities in real-time (possibly monitored by so-called event logs) provides the execution of the process type. As an example, process models may be only descriptive (and not prescriptive) and process executions non compliant with the process model are often considered executions of that process by people from the BPM community. Indeed all the process mining activities tend to define processes at the execution level more than at the process diagram level.
Second, the BPM literature does not provide in depth explanations of the intended semantics of the various modelling constructs, e.g., what an activity is, what its participants are, and how the latter relate to the former. An emblematic example is the lack of characterisation of the relations that occur between the activities in a process. While a business process is invariably understood as an ordered collection of activities, it remains unclear, e.g., whether such activities are only temporally or also causally related, or whether the effects of activities need to be explicitly represented.
In this section, we provide an analysis of some of the modelling constructs we
encountered in the previous sections, with particular emphasis on (the lack of) an ontological
characterisation of their properties. We rely on previous works (e.g., [
Activities In the BPM literature, activities are understood as (atomic or compound)
actions, consisting of intentional transformations from some initial state (the input) to
some other state (the output). The participants to such actions are the entities that take
part in these transformations. From the ontological point of view, actions are (specific
kinds of) events, while their participants are objects [
A first aspect that needs to be considered concerns the relation between activities, and more in general the way the activities contribute to the achievement of the goal. In general terms, the precedence relation between activities can be a temporal, causal or dependence relation, perhaps depending on the context or scenario to be modelled. For instance, assume that in a slight variation of the example of Section 2, the travel agency splits the activity ‘Make flight offer’ in two subsequent steps ‘Send flight offer to customer’ and ‘Archive offer’ which, for purely organisational reasons, must be executed in this order. This would be a pure temporal relation between the activities in this specific setting and could easily be modified in a revision of the process model. Instead the activity of ‘Paying for a flight’ may be a strong precondition for the ‘Preparation of the ticket’, and so it should necessarily occur before the latter. Nonetheless these relations would be denoted by means of the same connector symbol.
Another aspect that needs to be considered is the (explicit or implicit) representation of the world’s states affected by the designed process. While the definitions of process in Section 4 describe business processes as a way to move from an input (state) to an output (state), they do not specify whether it is desirable to explicitly represent the world’s states affected by the designed process. Nonetheless, the description of intermediate states of affairs can be often found in business process models. Think for instance to functions in EPC diagrams, the status of data objects in BPM and UML-AD, and sentries and milestones in CMMN. Thus, a question that one may ask is whether the (explicit or implicit) representation of the world’s states is necessary to fully characterise a process (model) and what are the characteristics of this representation.
Participants From a general perspective, participants can be physical or non-physical depending on their properties. In fact, the very same activity may involve several types of objects as participants: physical objects (e.g., the knife used to cut a piece of bread); information objects (e.g., personal data involved in submitting a request); agents and/or organizations playing certain roles (e.g., an administrative employee receiving a form).
A physical participant, whenever it exists12, is located in the physical space.
Differently, non-physical participants lack physical locations, although they are present in
time. A person is an example of physical participant, whereas the content of a person’s
ID, which is an information object (see below), is a non-physical participant.
Information objects are rather common in business processes and are represented by means of
data objects modelling constructs. In applied ontology, only a few systems [
Another crucial distinction in BPM is the one between agentive and non-agentive participants. For the purposes of our work, we consider a process participant as agentive depending on whether it has sensors, actuators and the capability to act on itself or on the environment. For instance, a lathe machine is an agent when, e.g., it has sensors by which it acquires data from the objects to be manufactured and acts upon them by elaborating the data through some software. Additionally, we consider a second notion of agentive participant characterising an agent that can be ascribed with intentions, including beliefs or desires. Non-agentive participants that undergo a change during an action are usually called patients of the action. It is easy to see that a process such as the one in Section 2 contains both agentive (e.g., the customer paying for the flight) and non-agentive participants (e.g., the offer whose status changed from created to rejected).
Apart from the classification of participants, we need to spend some words on their roles. From an ontological perspective, the latter are properties that objects only contingently satisfy within certain contexts, e.g., processes (e.g., to be a resource during a drilling process) or organisations (to be professor at MIT). In this sense, an object can loose or acquire a role while remaining the same entity. We assume that roles can be ascribed to any type of participant, including information objects. The ability to constrain the way an object playing a role participates in a process may be also of interest to the BPM field, not only at the execution but also at the type level. Let us focus, for example, on organisational/business roles, which in BPMN are usually described by means of pools, such as the pools ‘customer’ and ‘travel agent’ in Figure 1. While it seems plausible to assume that the customer does not change during the entire duration of the process (otherwise this would be another process instance), the same constraint would not apply to the ‘travel agent’. In fact, any employee of the travel agency playing the ‘travel agent’ role would perfectly fit the specification of this process. Enriching BPM languages with the ability to distinguish between these cases may be useful to constrain and reason on the identity of process instances.
The second column of Table 3 summarises the main characteristics of business processes and of business process constructs described here and in Section 4. In the next section we provide some insights on whether the modelling notations described in Section 2 enable to represent these characteristics, and how. The results are summarised in the right hand side of Table 3.
In this section, we discuss the ontological aspects of business processes presented in Section 5 in the light of the modelling constructs presented in Section 2, with the help of the flight purchase example. The results are summarised in Table 3 DECLARE
Yes Somehow
No
No
No
Yes No UML-AD Yes Yes No Yes No EPC Yes
Yes Somehow Yes No
Yes Somehow Somehow
No
No
By looking at the diagrams, we observe that all the notations enable to represent structured / coordinated sets of activities. This is not surprising: the specification of the control flow is indeed the top priority of a process model. The situation changes as soon as we move to the clear specification of input and output states. Here we observe that all the notations but DECLARE enable / require an explicit initial and final state. Not surprisingly, the imperative modelling languages (BPMN, UML-AD and EPC) strictly require explicit start and end symbols / states. These languages, in fact, model business processes in a prescriptive manner specifying all the allowed flows from a start (the input) to an end (the output) state. Despite its declarative nature, CMMN also facilitates the modellers to specify input and output states by means of input and output sentries and by explicitly asking for exit criteria. Instead, DECLARE is, in our opinion, the weakest language in terms of driving the modeller to explicitly represent input and output states. In fact, it provides a (optional) pattern for the initial activity, and it does not foresee any pattern for the exit / last activity, thus lacking also a way to express - even if implicitly - the goal, or desired state, of a business process. Moving to the specification of the business goal or added value that the business process realises, none of the modelling languages force the modeller to make them explicit. The only language that explicitly contains a ‘goal’ construct is (one of the variants of) EPC. Thus, we can say that most BPM languages leave implicit in the modeller’s (and the reader’s) mind the goal the activities contribute to realise. Finally, organization boundaries can be easily described in notations such as BPMN, UML-AD and EPCs, using notions such as pools/lanes, activity partitions, and organization/activity owner, respectively, while they are absent in CMMN and DECLARE.
Moving to the relation between activities, we can easily notice that almost all the languages only enable a connection between activities without specifying the nature of such connection. A notable exception is DECLARE, whose main focus is indeed the representation of (temporal) relations between activities. While it would be incorrect to say that DECLARE patterns have the aim of specifying the kind of relation existing between different activities, it is also true that some (temporal) patterns may be better suited to model causal vs. temporal vs. dependent relations. As an example, let us consider the ‘response’ and ‘precedence’ patterns in Table 1. While the precedence pattern may be suited to express that an activity happens before another, and therefore can be considered as a pure temporal constraint, the ‘response’ pattern conveys the meaning that B is a consequence of A being true (happening). Thus we may say that, from an ontological perspective, DECLARE somehow guides the modellers to think about the type of relation existing between activities, besides the simple sequencing.
A key difference among the modelling notations we took into account concerns the representation of the (state of the) world in response to a process execution. Figure 3 emphasises this as one of the focuses of EPCs. UML-AD and CMMN lie in the middle by exploiting data objects and sentries for describing how the world is changed because of the process execution. BPMN, instead, only provides (optional) constructs for representing the state of data objects. Finally, DECLARE does not offer any construct at all for representing the status of the world. From an ontological perspective, we would say that, differently from DECLARE and BPMN, EPC drives the modeller to explicitly represent the world’s states affected by the designed process, while UML-AD and CMMN guide the modeller to implicitly represent the world’s states through data objects and sentries.
The participants relevant in the flight purchase example are the customer, the travel agency and various information objects. The process thus includes different types of participants, material and immaterial ones. A first observation we have to make is that DECLARE does not offer any support to the modelling of entities that participate to the activities. It is therefore ignored in the remaining of the discussion. By looking at the diagrams, we observe that no explicit distinction is made between agentive and non-agentive participants. Nonetheless, the specification of activity owners in EPCs seems to suggest that they have the ability to act. Also, pools in BPMN are understood as participants in collaboration, and therefore exhibiting the capability to collaborate. In case of UML-AD, the activity partitions may be used for grouping activities with different purposes, i.e, not only according to the activity performer; however, when used for this purpose, also the UML-AD notation tends to suggest the ability of the performer to act. CMMN, instead, does not seem to distinguish between these types of participants.
In Figures 1–3, Check travel agency website results in the Flight request which is sent to the agency. On the basis of our analysis, one has to distinguish between the request-information-object and the request-support(s); to some extent, the former is more relevant than the latter, since it represents the customer’s information to book the flight. However, one cannot avoid referencing the support. Hence, what the customer sends to the agency is a (copy of a) physical object displaying an information object. The distinction between information object and support is not addressed by the languages we considered; rather, it is blurred in the notion of data object.
No actors appear in CMMN and neither BPMN nor UML-AD specify whether ‘customer’ explicitly refers to a single individual (e.g., John) or to an organisation. In both cases, it reasonably stands for the role of a participant, who desires to book a flight ticket. This consideration reveals, besides the lack of declarative language graphical constructs for specifying actors, the underspecification of both BPMN and UML-AD with respect to our analysis, since pools and activity partitions can be used to refer to different types of participants, but also to their roles.13 Differently, the distinction between single actors and organisations can be explicitly conveyed in EPC, although the difference between participants and their roles is blurred.
To conclude, the analysis of process entities needs to be extended to identify the different modelling approaches in the languages at hand. Once we recognise the ontological assumptions undergoing the different languages, including the lack of characterisation of several properties, we can better understand how to correctly use the language to convey 13Although some support is given in the meta-models of the different languages, what we aim at emphasising here is the lack of support provided by the graphical notations of the different languages. a well characterised meaning. This latter topic however deserves more attention and is left for future work.
Focusing on ontology-based BPM, which is the context of our paper, disparate ontologies
have been proposed to semantically enrich process models. Among these, some
ontologies axiomatise the properties that graphical constructs satisfy according to modelling
notations (see, e.g., [
In the future we plan to extend our preliminary analysis in order to deepen the investigation of the ontological commitments of modelling notations by further inspecting the different perspectives that they implicitly take on business processes and their participants, as well as by providing modellers with guidelines to make an appropriate choice when selecting among different notations. We also aim at extending our analysis including further languages that encompass the B2C view, such as ArchiMate, Petri Nets or the Integrated DEFinition Methods (IDEF) language.
Acknowledgments This research has been partially carried out within the Euregio IPN12 KAOS, which is funded by the “European Region Tyrol-South Tyrol-Trentino” (EGTC) under the first call for basic research projects.