Deontic BPMN

Softw Syst ModelDOI 10.1007/s10270-013-0329-5

REGULAR PAPER

Deontic BPMN: a powerful extension of BPMN with a trustedmodel transformation

Christine Natschläger · Felix Kossak ·Klaus-Dieter Schewe

Received: 4 April 2012 / Revised: 24 January 2013 / Accepted: 26 February 2013© Springer-Verlag Berlin Heidelberg 2013

Abstract The Business Process Model and Notation(BPMN) is a widely-used standard for process modelling. Adrawback of BPMN, however, is that modality is implicitlyexpressed through the structure of the process flow but notdirectly within the corresponding activity. Thus, an extensionof BPMN with deontic logic has been proposed in previouswork, called Deontic BPMN. Deontic BPMN reduces thestructural complexity of the process flow and increases thereadability by explicitly highlighting obligatory and permis-sible activities. In addition, an algebraic graph transformationfrom a subset of BPMN to Deontic BPMN, called DeonticBpmnGTS, has been defined. The goal of the current researchis to show that DeonticBpmnGTS is terminating and con-fluent, resulting in a globally deterministic transformation.Moreover, the semantic equivalence of BPMN models andthe respective Deontic BPMN models is proven based onAbstract State Machines (ASMs). Thus, DeonticBpmnGTScan be called a trusted model transformation.

Keywords Business process modelling · BPMN · Deonticlogic ·Graph transformation ·Deterministic transformation ·Semantic analysis

Communicated by Prof. Robert France.

C. Natschläger (B) · F. Kossak · K.-D. ScheweSoftware Competence Center Hagenberg, Hagenberg, Austriae-mail: [email protected]

F. Kossake-mail: [email protected]

K.-D. ScheweResearch Institute for Applied Knowledge Processing,Johannes-Kepler-University Linz, Hagenberg, Austriae-mail: [email protected]; [email protected]

1 Introduction

The Business Process Model and Notation (BPMN) is a stan-dard maintained by the Object Management Group (OMG)and addresses business analysts and technical developers (see[34]). BPMN was first published by the Business ProcessManagement Initiative in 2004 and is maintained by theOMG since 2005. The current version, BPMN 2.0, was pub-lished in January 2011. BPMN provides a graphical notationfor business process modelling with five basic categories ofelements: flow objects, data, connecting objects, swimlanesand artifacts.

However, a drawback of BPMN and other business pro-cess modelling languages is that modality is only implicitlyexpressed through the structure of the process flow but notdirectly within the corresponding activity. All activities areobligatory (mandatory) and whenever something should bepermissible (optional), a gateway is used to split the processflow, which offers the possibility to execute the activity orto do nothing. This requires additional modelling elementsto split and merge the process flow and a comprehensiveunderstanding of the whole process to identify obligatory,permissible and alternative activities.

The separation between decision and execution leads tothe following problems:

– Limited readability It is difficult to identify obligatory,permissible and alternative activities at first sight.

– Complex structure Additional elements are necessary toexpress modality and complicate the structure of thediagram.

– Duplication Various agents with different normative con-cepts for the same activity require a duplication of theactivity (e.g., “Attend Conference” might be obligatory

123

C. Natschläger et al.

for the main author of a paper but permissible forco-authors).

Thus, an approach to extend BPMN with deontic logichas been suggested by Natschläger in [29]. Deontic logicis defined as the logical study of the normative use of lan-guage and its subject matter is a variety of normative conceptsincluding obligation (O), prohibition (F), permission (P) andcommitment (conditional obligation) (compare [37]). Theseconcepts can be linked with the logical connectives for nega-tion (¬), conjunction (∧), disjunction (∨) and contravalence(∨̇). While monadic deontic logic considers unconditionalnormative concepts, conditional obligations and permissionsare modelled by dyadic deontic logic (compare [23]). In addi-tion, deontic logic supports the concept of agency and allowsto consider users and roles (see [22]).

We call the extension of BPMN with deontic logic Deon-tic BPMN. Deontic BPMN identifies obligatory, alternativeand permissible activities and improves the readability ofBPMN diagrams by highlighting those types of activities.This further allows to reduce the number of gateways andsequence flows and, thus, the overall structural complex-ity of the diagram. Deontic BPMN permits a fine-granularcapture of rights and obligations.

A preliminary survey showed that Deontic BPMNincreases the understandability of diagrams (see [29,32]).Problems with the intelligibility of implicit modality havealso been observed in an industrial project in which an orderexecution process (see Sect. 3 for a detailed description) anda business travel process were designed. In these processes,several activities were permissible. The resulting BPMN dia-grams were complex, and a distinction of obligatory and per-missible activities would have been advantageous.

Natschläger also suggested an algebraic graph transfor-mation from BPMN to Deontic BPMN in [29]. The goal ofthe current research is to prove that the graph transformationis a trusted model transformation. According to Varró et al.[42], the most important correctness properties of a trustedmodel transformation are termination, uniqueness (conflu-ence), and preservation of semantics. Thus, it will be proventhat the transformation from BPMN to Deontic BPMN is ter-minating and confluent, which implies global determinism,and that the BPMN model and the corresponding DeonticBPMN model are semantically equivalent.

The concept of Deontic BPMN and its motivation and rele-vance have already been introduced in detail in [29] and [32].A generalisation of the concept of explicitly optional activi-ties, suitable for a large class of process modelling languages,was presented in [31]. This article now further establishes thetheoretical foundations for the trustworthiness and usabilityof the associated model transformation.

The remainder of this paper is structured as follows:Related work with a focus on deontic logic in process

modelling, formal descriptions of BPMN and graph transfor-mation is studied in Sect. 2. Section 3 presents the approachto extend BPMN with deontic logic, and Sect. 4 provides anintroduction to the semantics of BPMN and Deontic BPMN.The main part of this research then proves that the algebraicgraph transformation from BPMN to Deontic BPMN is con-fluent, terminating and semantically equivalent (see Sect. 5).Finally, we sum up the results in Sect. 6.

2 Related work

This section provides an overview of related work concerningdeontic logic in process modelling, formal representations ofBPMN and graph transformations.

2.1 Deontic logic in process modelling

Considering deontic logic, an overview of the main applica-tions in computer science is given by Wieringa and Meyer[44]. In addition, Broersen and Van der Torre identified tenproblems of deontic logic and normative reasoning in com-puter science [9]. One of these problems is how to com-bine legal ontologies, normative systems, business processnotations and compliance checking tools. For this purpose,the authors recommend the Semantics of Business Vocab-ulary and Business Rules (SBVR) for interaction betweennorms and business processes. SBVR expresses modalitywith alethic or deontic logic (see [33]); however, it con-siders neither the influence on the process flow (e.g., read-ability or reduction of structural complexity) nor modeltransformation.

Due to Goedertier and Vanthienen [19], most process mod-elling languages such as UML Activity Diagrams, BPMNand BPEL are procedural and only implicitly keep track ofwhy design choices have been made. Therefore, this publica-tion presents a vocabulary for declarative process modellingthat supports business concerns, execution scenarios, execu-tion mechanisms, modality, rule enforcement and commu-nication. Considering modality, procedural modelling onlyspecifies what must be the case, while declarative processmodelling supports must, ought and can based on deon-tic logic. In [18], the same authors introduce a languageto express temporal rules about obligations and permissionsin business interaction, called Penelope. These publicationsprovide a good foundation for the current research. How-ever, the focus of the normative concepts lies more on agentsand temporal constraints, whereas optimization capabilitiesor model transformation are not studied at all.

Other publications focus on formal models of normativereasoning and deontic logic in combination with businessrules and process modelling. Padmanabhan et al. [35] con-sider process modelling and deontic logic. They develop a

123

Deontic BPMN: a powerful extension of BPMN with a trusted model transformation

logical framework based on multi-modal logic to capturethe normative positions among agents in an organizationalsetting. Moreover, Governatori and Milosevic present a lan-guage for expressing contract conditions in terms of deonticconcepts, called Business Contract Language (BCL) [20].However, these publications do not provide a detailed studyof modality, but rather focus on agents and their contractualrelationships.

Further approaches assure business process compliancebased on deontic logic. According to Sadiq et al., processand control modelling are two distinct specifications, butconvergence is necessary to achieve business practices thatare compliant with control objectives [38]. The authors pro-pose a Formal Contract Language (FCL) as a formalism toexpress normative specifications. This language is a combi-nation of defeasible logic and a deontic logic of violations.Ghose and Koliadis [17] present an approach to enhance busi-ness process modelling notations with the capability to detectand resolve compliance-related issues. They define a frame-work for auditing BPMN process models and suggest thatactivity, event and decision inclusion may be defined withdeontic modalities.

Deontic Logic is also used by Asirelli et al. [4] for mod-elling the behavioural variability in product family descrip-tions. According to this publication, deontic logic becamevery popular for formalizing descriptional and behaviouralaspects of systems, since it provides a natural way toformalize concepts such as violation, obligation, permission,and prohibition.

Furthermore, an approach by Weigand et al. [43] pro-vides a bridge between interoperable transactions and busi-ness process models based on deontic logic.

Although several approaches use deontic logic in com-bination with process modelling, none of them studies theinfluence on the process flow (e.g., readability and optimiza-tion capabilities) or considers a model transformation. Thus,an own approach that extends BPMN with deontic logic hasbeen developed by Natschläger and is presented in [29]. Thecore concepts of this approach are summarized in Sect. 3.

2.2 Formal representations of BPMN

This subsection presents several approaches that support aformal or textual representation of BPMN. First of all, theBPMN 2.0 Specification (see [34]) itself provides the meta-model of all BPMN elements in the form of an XML Schema.Consequently, BPMN diagrams can be textually representedin XML, which is used by several modelling tools, e.g., theEclipse BPMN Modeler (see [12]).

Another textual notation for three process modellinglanguages [UML Activity Diagram, BPMN, and Role Activ-ity Diagram (RAD)] is called TN4PM and proposed by

Mogos and Urzica in [27]. The notation is based on entityblocks.

Furthermore, Urzica and Tanase [41] provide a textualnotation for BPMN based on the Backus–Naur Form (BNF).In this notation, every element specifies the outgoing flows,but the incoming flows are omitted. Similarly, DeonticBPMN considers the splitting but neglects the merging gate-ways (see [29]).

According to Dijkman et al. [11], defining the formalsemantics of BPMN is challenging since BPMN integratesconstructs from graph-oriented process definition languageswith features for the concurrent execution of multipleinstances. Nevertheless, this work introduces the formalsemantics of BPMN defined in terms of a mapping to PetriNets.

A formal process semantics for a subset of BPMN is alsoprovided in terms of the process algebra CSP by Wong andGibbons in [45]. The approach presents a Z model of theBPMN syntax and the behavioural semantics in CSP.

A further approach defines the semantics of BPMN interms of abstract state machines (ASMs) (compare Börgerand Sörensen [6] and Börger and Thalheim [8]). ASMs willbe briefly explained in Sect. 4, where we will define thesemantics of both BPMN and Deontic BPMN by means ofASMs, based on the work of Börger and Thalheim [8], inorder to prove semantic equivalence.

2.3 Graph transformation

This subsection provides an overview of graph transforma-tion with a focus on the algebraic approach.

Research on graph transformations started around the1970s; the main idea is the rule-based modification of a graph,where each application of a rule leads to a graph transforma-tion step. Figure 1 shows the transformation of a graph L(left-hand side) to a graph R (right-hand side) based on arule r (also called production). Applying the rule r = (L , R)

means finding a match of L in the source graph and replacingL by R, leading to the target graph of the graph transforma-tion (cf. for this paragraph [16, p. 5f]).

Different approaches for graph transformation have beenproposed like node label replacement, hyperedge replace-ment, or the algebraic approach (see [16, p. 10]). Deontic-BpmnGTS uses the algebraic approach, which was initiated

Fig. 1 Rule-based modification of graphs (source: [16, p. 6, modified])

123


by Ehrig, Pfender (both TU Berlin) and Schneider (Univer-sity of Erlangen) in 1973 (see [13]). The Technical Univer-sity of Berlin is also playing a central role in further researchon graph transformations and the development of a tool forattributed graph grammar systems (AGG). Graph transfor-mations have also been studied by research groups at the Uni-versities of Bremen, Pisa, Rome, Leiden, Paderborn, PortoAllegre and others (compare [16, p. 3]).

AGG is used to define the graph transformation fromBPMN to Deontic BPMN. AGG was introduced by Löweand Beyer [25] and later redesigned and extended by Taentzer[39,40]. In December 2010, AGG was updated to version2.0. AGG is implemented in Java; it can be extended withnew Java classes, and graphs can be attributed by usingJava objects and types (see [2], [16, p. 305]). AGG pro-vides a graphical editor and can be used for specifying graphgrammars with a start graph or for typed attributed graphtransformations like DeonticBpmnGTS. Furthermore, AGGoffers analysis techniques as for consistency checking, criti-cal pair analysis, and termination evaluation. More informa-tion on AGG can be found on the Homepage [3], in the UserManual [2] and in the algebraic graph transformation book([16, chapter 15]).

The algebraic approach is based on pushout constructionsthat are used to model the gluing of graphs. The double-pushout approach (DPO) was introduced by Ehrig et al. [13]and uses two gluing constructions as shown in Fig. 2. A ruleis given by r = (L , K , R), where K is the intersection of Land R and must exist in order to apply the rule. L\K thendescribes the part which has to be deleted, whereas R\K willbe created. In addition, for a graph transformation G ⇒ H , agraph morphism m : L → G, called match, must exist suchthat m is structure-preserving. Rule r and match m have tosatisfy a gluing condition, so that no edges are left dangling.r and m satisfy the gluing condition if all identification points(different nodes or edges in L that are mapped to the sameelement in G by m) and all dangling points [nodes in L whoseimages under m are the source or target of an edge in G thatdoes not belong to m(L)] are also gluing points (nodes andedges in L that are not deleted by r ). The gluing conditionwould be violated, e.g., if a node is deleted within a rule rand the node has incoming or outgoing edges in G whichare not part of L . The resulting graph morphism R → His called the comatch of the graph transformation G ⇒ H(cf. for this paragraph [16, p. 10ff, 44]).

Fig. 2 Double-pushout approach (source: [16, p. 12])

The single-pushout approach (SPO) was initiated byRaoult [36] and fully worked out by Löwe [24]. The SPOapproach differs from the DPO approach concerning the dele-tion of graph elements, since dangling edges might occurafter the deletion and are as well deleted (compare for thisparagraph [16, p. 13f]). Since no edges should be automati-cally and maybe unintentionally removed, the DPO approachis used for DeonticBpmnGTS.

In summary, the main steps of an algebraic graph trans-formation from G to H based on the DPO approach are,according to Ehrig et al. [16, p. 9]:

1. Choose a rule r : L ⇒ R with an occurrence of L in G.2. Check the application conditions of the rule.3. Remove from G that part of L which is not part of R. If

dangling edges would occur after the deletion, then therule cannot be applied. The resulting graph is called D.

4. Glue R to the graph D at the part of L which still has animage in D. The part of R not coming from L is addeddisjointly to D. The resulting graph is called E .

5. If the rule contains an additional embedding relation,then embed R further into the graph E according to thisembedding relation. The resulting graph is called H .

For DeonticBpmnGTS, only the first four steps are relevant,since no embedding relations are defined.

The algebraic approach to graph transformation has beengeneralized to further graph types and high-level structuressuch as typed graphs, labelled graphs, hypergraphs, attributedgraphs, and algebraic specifications. This extension to high-level structures is called high-level replacement (HLR) andwas introduced by Ehrig et al. in [14,15] (cf. for this para-graph [16, p. 14ff]). The graph transformation from BPMNto Deontic BPMN is defined as a typed attributed graph trans-formation system that includes labels.

3 Deontic BPMN

This section provides a summary of the main concepts andgoals of Deontic BPMN presented by Natschläger [29].BPMN is extended with deontic logic to improve the read-ability of the process flow by highlighting obligatory, permis-sible and alternative activities (see Fig. 3). The highlightingof modality in Deontic BPMN allows to reduce the numberof gateways and sequence flows and to identify at first glancewhat is obligatory and what is permissible.

(a) Obligation (b) Permission (c) Alternative

Fig. 3 Deontic activities

123


Highlighting through colours is discussed in [28]. Moodydescribes colour as “one of the most cognitively effec-tive of all visual variables”. He adds, however, that colour“should only be used for redundant coding” to provide forcolour-blind people and print-outs in black-and-white. Con-sequently, we use colour in combination with the respectivemodal operators, “O”, “P”, and “X”.

First, an empty (or Phi) path is defined. A path is called aPhi-path (Φ) whenever a sequence flow directly connects thesplit with the merge and thereby offers the possibility to donothing. If a parallel gateway has a Phi-path, then this pathprovides no additional functionality and can be removed:

A ∧Φ = A A ∧ B ∧Φ = A ∧ B

A Phi-path within a parallel split is executed in parallel withall other paths and does not extend the functionality. Thus,this construct is dispensable and it would be best practice tonot use it at all. However, since this construct is not forbiddenby the BPMN specification, it is also considered in DeonticBPMN.

If the parallel gateway addresses only one other pathbeside the Phi-path, then removing the Phi-path also allowsto remove the surrounding gateways. All other paths that fol-low a parallel gateway are obligatory. In Deontic BPMN,an obligatory activity is highlighted with a red backgroundcolour (or dark grey) and by surrounding the text with O()for obligatory.

In contrast to parallel gateways, exclusive and inclusivegateways define conditions on the outgoing sequence flowsexcept for the default flow (compare [34]). The deontic clas-sification depends on the type of the decision. In the contextof Deontic BPMN, unconditional gateways denote all thosegateways where the user can freely decide. These decisionsare also called User Choice and subsequent tasks might bepermissible or alternative. In contrast, conditional gatewaysdenote all those gateways where the outgoing path is selectedbased on a state, data or rule. In this case, the user is not freeto decide and a subsequent task is obligatory.

In BPMN, a permissible activity as well as an alterna-tive can be expressed with unconditional gateways (exclu-sive, inclusive, complex or event-based) or events (boundaryevents). If an outgoing path is a Phi-path, then all other pathsare called permissible. Otherwise, if no outgoing path is aPhi-path, then, in most cases, the outgoing paths are alterna-tives.

An exclusive gateway (XOR) offers a gating mechanismwhere only one of the outgoing paths can be taken. If oneof the outgoing paths is a Phi-path, then all other paths arepermissible:

A ∨̇ Φ = P(A) A ∨̇ B ∨̇ Φ = P(A) ∨̇ P(B)

In Deontic BPMN, a permissible activity is highlighted witha green background colour (or middle grey) and by surround-

ing the text with P() for permissible. If there is only one otherpath beside the Phi-path, then the surrounding gateways canbe removed. The semantics of a permissible task is that if atoken reaches the task, it can either be executed or not. TheBPMN diagram in Fig. 4a can be transformed to Fig. 4b withthe same semantics.

If the exclusive gateway does not have a Phi-path, then allpaths are alternatives. An alternative is not an independentdeontic concept but derived from obligation and permissionand can be expressed as follows (compare Asirelli et al. [5]):

X (A1, A2) = (O(A1) ∨ O(A2)) ∧ ¬(P(A1) ∧ P(A2))

In Deontic BPMN, both activities can be marked separately(X(A) ∨̇X(B)) and are highlighted with a yellow backgroundcolour (or light grey). The semantics of an alternative taskis that it is obligatory to execute the task if no alternativetask will be executed and forbidden otherwise. The BPMNdiagram in Fig. 5a can be transformed to Fig. 5b with thesame semantics.

An inclusive gateway (OR), where at least one outgoingpath is taken, can be defined as: A O R B ≡ (A ∨̇ B) ∨̇ (A∧B). If one of the outgoing paths is a Phi-path, then the struc-ture (A OR B OR Φ) can be transformed as follows:

φ ∨̇ A ∨̇ B ∨̇ (A ∧ B) ∨̇ (A ∧ φ) ∨̇ (B ∧ φ)

∨̇ (A ∧ B ∧ φ)

≡ φ ∨̇ A ∨̇ B ∨̇ (A ∧ B)

≡ P(A ∨̇ B ∨̇ (A ∧ B))

≡ P(A ∨ B)

If “A or B” is permitted, then certainly at least either A orB must be permitted, for if neither was performed, “A or B”could not be performed. But the performance of “A or B”does not rule out that both A and B are performed either, sofrom P(A ∨ B) follows P(A) ∨ P(B).

If no outgoing path is a Phi-path, then the structure (A ORB OR C) can be transformed as follows:

(a) BPMN (b) Deontic BPMN

Fig. 4 Exclusive gateway with Phi


Fig. 5 Exclusive gateway without Phi

123


(P(A) ∧ O(A|¬B ∧ ¬C)) ∨ (P(B) ∧ O(B|¬A ∧ ¬C))

∨ (P(C) ∧ O(C |¬A ∧ ¬B)

This definition requires for the first time the concept of pre-conditions defined within dyadic deontic logic (see [23]).The notation is O(A|B) or P(A|B) with A being obliga-tory/permissible under the precondition that B has been exe-cuted (several preconditions can be concatenated with ∧or ∨).

Another example for the necessity of preconditions is thecase of nested gateways as shown in Fig. 6a. In this example,task B is permissible but can only be executed if task A wasexecuted before. Therefore, task A is specified as precondi-tion in Fig. 6b.

Preconditions are also necessary for situations where auser is not free to select the outgoing path. This is the case ifconditions or events are involved. Fig. 7a shows an exclusivegateway with the decision “Has Errors?” and two outgoingflows. The first flow represents “Yes” and leads to a task “Cor-rect Errors”. The second flow represents “No” and nothing(Φ) has to be done. However, the task “Correct Errors” is notpermissible, but obligatory under the precondition that errorsexist and forbidden otherwise: [O(CorrectErrors|HasErrors)∧ F(CorrectErrors|¬HasErrors)]. Furthermore, we specifythat everything that is not explicitly permitted is forbidden.Thus, the forbidden part can be omitted (see Fig. 7b).

Furthermore, an activity may have multiple deontic clas-sifications in case of unstructured diagrams. For example, inFig. 8, task A is addressed by different split gateways. Thus,task A is marked as alternative and as permissible (X(A)∧ P(A)). The gateways of the permissible structure can beremoved if preconditions are used (X(A|¬B) ∧ P(A|B)).

We now present an example which is taken from a real-life industrial project in which we were involved. The processdescribes a typical order execution as it can be found in manycompanies (with certain variations). The BPMN diagram ofthe order execution process is shown in Fig. 9. The processcomprises the following tasks: create request (CR), modify


Fig. 6 Nested gateways


Fig. 7 Conditional gateway


Fig. 8 Multiple deontic classification

request (MR), delete request (DR), reject request (RJR),approve order (AO), create/modify appointment (CMA),remove appointment (RA), approve appointment (AA), rejectappointment (RJA), order in progress (OP), execute order(EO), create report (RC), modify report (RM), formally cor-rect report (RFC), formally incorrect report (RFI), and closeorder (CO). These tasks are specified within three lanes thatdescribe the roles Assistant, Consultant, and Approver.

Essentially, the order execution process defines that arequest can be created by any of the three roles. If an assis-tant or consultant creates the request, then this request can bemodified by the consultant and is afterwards either deleted orsent to the approver for approval. However, if the approvercreates a request, then this request is automatically approved.The approved order is then sent to the consultant who maydefine an appointment or specify that the order is in progress.Subsequently, every order must be executed by the consul-tant. The consultant can then create and modify a reportwhich might be sent to the approver for approval. Finally,the consultant closes the order.

Considering the order execution process, all splittinggateways provide user choices and do not depend on anystates or data. The entire diagram consists of 26 gate-ways and 64 sequence flows and is quite complex. Thus,it is difficult to identify the permissible and obligatorytasks.

The corresponding Deontic BPMN diagram is shown inFig. 10. The Deontic BPMN diagram highlights that it isobligatory to create a request and to approve, execute andclose the order. In addition, it defines that the two tasksdelete request (DR) and reject request (RJR) are alternativesto the main flow. All other tasks are permissible. It is furthernecessary to deontically classify two sequence flows, sincea report may only be modified or sent for approval, if it hasbeen created before. This classification, however, highlightsthat the two tasks formally correct report (RFC) and for-mally incorrect report (RFI) are alternatives in a permissiblestructure.

The Deontic BPMN diagram provides two advantageswith respect to understandability. First, the resulting Deon-tic BPMN diagram only consists of 18 gateways and 49sequence flows. So it was possible to remove 8 gatewaysand 15 sequence flows and thereby reduce the structuralcomplexity of the process flow. Secondly, obligatory andpermissible tasks can be distinguished at first sight based

123


Fig. 9 Order execution process: BPMN diagram. Explanation: CRcreate request, MR modify request, DR delete request, RJR rejectrequest, AO approve order, CMA create/modify appointment, RAremove appointment, AA approve appointment, RJA reject appointment,

OP order in progress, EO execute order, RC create report, RM modifyreport, RFC formally correct report, RFI formally incorrect report, COclose order

on the colored highlighting. It is still necessary to decidewhether a permissible task is executed or not but insteadof describing this decision through separate gateways andalternative paths, the decision is described within the cor-responding task. The advantages are accompanied by addi-tional deontic constructs requiring a basic understanding bythe user. However, the complex constructs (e.g., precondi-tions) are only relevant for a more detailed understanding ofthe process.

The reduction in structural complexity comes at thecost of an increased complexity of the language, i.e., ofBPMN: one further attribute with three (or possibly four)possible values has been added [i.e., O, P, and X, andpossibly also F (forbidden)]. We expect that the averagepossible reduction in structural complexity will outweighthis increased language complexity, but only an investiga-tion of a wide range of different, real-life examples (e.g.,with respect to Halstead complexity) will tell. Moreover, thebenefits also depend on the particular use of a diagram, i.e.,how much the deontic aspects are relevant for a particularuser.

4 The Semantics of BPMN and Deontic BPMN

Deontic BPMN is intended to aid the user in designingand understanding business processes while preserving thedesign capacities of BPMN. This will become clear whenwe introduce a graph transformation system from (a subsetof) standard BPMN to (a subset of) Deontic BPMN furtherbelow.

We cannot repeat the semantics of BPMN in this place andrefer the reader to the standard [34] (see also [6] for a for-malisation of BPMN 2.0 beta using abstract state machines;our own formalisation is based on this work by Börger andSörensen). We will explain the differences between (a subsetof) Deontic BPMN and BPMN according to the standard sothat we will subsequently be able to show that the seman-tics of BPMN diagrams (according to the OMG standard)can be preserved when being transformed to Deontic BPMNdiagrams.

We will make use of abstract state machines (ASMs; seee.g., Gurevich [21] and Börger and Stärk [7]) to model seman-tics. We trust that ASMs are easily readable, but we will

123


Fig. 10 Order execution process: deontic BPMN diagram

briefly explain a few constructs to clarify their meaning forthose who are not as yet familiar with the method.

4.1 A few notes on abstract state machines (ASMs)

ASMs can be seen as “a rather intuitive form of abstractpseudo-code”, though based on a precise but minimal math-ematical theory of algorithms, but also as “Virtual Machineprograms working on abstract data” (compare [7, p. 2, 5]).

The main constructs we will use are rules and derivedfunctions. A rule describes a state transition of the machine(automaton). A state is determined by particular values ofarbitrary data structures. Those data structures are describedby “functions”, e.g., tokenType. If a function is givenspecific parameters, we speak of a ”location”—e.g., tokenType(t), where t is a particular token. If the value of at leastone location is changed (updated), the state of the machinechanges. Such updates are described by rules, of which sev-eral may execute in parallel.

Whether a rule fires in a particular state or not is deter-mined by a “guard” or condition in the form of an if…then …statement. This guard will typically query thevalue of one or more functions. If the query is more com-plex, or we want to leave it abstract for the time being, wecan use “derived functions”, which combine the values ofother functions through an arbitrary statement. An example

is controlCondition(flowNode), which determineswhether there are enough tokens at the incoming sequenceflows of a given flow node for it to fire. Derived functionshave no effect on the state of the machine.

For clarity, we will mark rule definitions and derived func-tions with the keywords “rule” and “derived”, respec-tively.

Monitored functions are controlled by the environment;they can, e.g., be used to model user input.

Nesting of expressions will be expressed by indentationonly.

Refinement of abstract rules will often be indicated by thekeyword “where”, after which subrules and derived func-tions previously left abstract will be defined.

A “choose” statement models an arbitrary choice of anelement of a given set. We trust that all other keywords andconstructs are easy to grasp.

4.2 BPMN and Deontic BPMN serve different abstractionlayers

Deontic BPMN is intended for a different level of abstractionthan (standard) BPMN is.

In standard BPMN, the level of abstraction is such thatthe resulting models can be executed by a business process

123


engine. This entails that models are supposed to be determin-istic in every detail.

Deontic BPMN, however, takes the viewpoint of the(human) user, who is not seen as a deterministically operat-ing machine, but as an agent who is capable of autonomouslytaking decisions and also authorised to take decisions.

Consequently, Deontic BPMN leaves choices open tothe user. Such choices are modelled as permitted tasks (or“P(task)”).

Note that such a permitted task, with its indeterminism,does not have a direct correspondence in standard BPMN. InBPMN, every task must be seen as mandatory (correspondingto an obligatory task (or “O(task)”) in Deontic BPMN) assoon as the firing (or activation) conditions are met, e.g., bya token on the incoming sequence flow.

To be able to compare standard BPMN and DeonticBPMN, we have to transform Deontic BPMN models to thelevel of abstraction relevant for a process engine.

In particular, in order to establish a relation between apermitted task and a standard BPMN task, we translate apermitted task to a conditionally obligatory task, where thecondition (subsequently called “precondition”) is determinedby user input - or, in terms of the ASM formalism, through amonitored function. Note that this does not mean that ”per-mission” and ”conditional obligation” would be equivalent inour deontic logic (they are not). ”Permission” is a concept ofthe level of abstraction of Deontic BPMN, while ”conditionalobligation” here is the translation to the level of abstractionof BPMN, where user choice as such cannot be modelled(except in ad hoc sub-processes, which we do not considerhere).

As also a conditionally obligatory task is a deontic task(and not an element of the BPMN standard), this translationof a permitted task is performed within the Deontic BPMNframework. However, with this translation we can make thestep down to the abstraction level of BPMN. The precon-dition “UserChoice” will then have to be matched with thefiring condition of the respective outgoing sequence flow ofa splitting gateway which leads to the task in question, as wewill show in more detail further below.

It should also be noted that due to the different layersaddressed, Deontic BPMN models may show a certain redun-dancy where user-centric and process-engine-centric con-cepts overlap. For instance, the information that a particulartask is obligatory may be derived from the context of thetask alone in certain (but not in all) cases. We assert that thisredundancy is very helpful from the user’s point of view.

4.3 Criteria for comparing standard BPMN and DeonticBPMN semantically

In order to show that a Deontic BPMN diagram generated bytransformation of a standard BPMN diagram has the same

semantics as the latter, we assert that there is a bijective map-ping between tasks before the transformation and deontictasks after the transformation. Then we have to show that

1. Whenever a particular task would have been performedin the original diagram, also the corresponding deontictask is performed after transformation; and

2. A partial order with respect to the performance of tasksin time is preserved (i.e., where relevant, tasks areperformed in the same order one after the other).

When we look at particular graph transformation rulesfurther below, it will suffice to consider only the subdiagramsaffected by particular graph transformation steps.

A final note may be due on a certain issue of performancetime. We will introduce graph transformation rules whichdispose of gateways. One might assume that with two flownodes less (a splitting and a merging gateway), the switch-ing time of those gateways would now be missing and thusthe overall time consumption of the subdiagram in questionwould be sped up. One can construct examples where differ-ent speeds in different branches may lead to different deci-sions later on and thus change the overall behaviour of thediagram at runtime.

However, relevant for this is only the time consumption ofthe whole subdiagram that is being transformed. First of all,the necessary decision is not eliminated—it is just transferredfrom the splitting gateway to the deontic task; secondly, inour considerations presented here, we only deal with userchoices, waiting for which will not change in either way; andthirdly, any potentially remaining variation in time due to thiswill be extremely small compared with the performance oftasks, and with variations in performances of tasks. Thereforewe think that this potential problem can be safely ignored.

To put it in ASM language, such a (sub)graph transforma-tion constitutes an n:m-refinement which affects only inter-mediate steps of “threads” of the machine in between twopoints of interest for synchronisation.

4.4 General semantic differences between standard BPMNand Deontic BPMN

Börger and Thalheim model the semantics of a BPMN flownode as follows [8]:

rule WorkflowTransition(flowNode) =if eventCondition(flowNode) and

controlCondition(flowNode) anddataCondition(flowNode) andresourceCondition(flowNode) then

EventOperation(flowNode)ControlOperation(flowNode)DataOperation(flowNode)ResourceOperation(flowNode)

123


That is, in order for a flow node (e.g., a task or agateway) to “fire” and thereby to do something, it mayhave to wait for an event to happen, for a token to arrive(controlCondition), for a data-based condition to betrue or for data to be available in the first place, and/orfor resources to be available. Then it may itself fire events,pass on or newly create tokens, manipulate data, and occupyand/or release resources. (Note that we use the conven-tion to capitalise the operations, which refer to (abstract)subrules, while we write the conditions—(abstract) derivedfunctions—with small letters.)

For the purposes of this paper, we can summarise the oper-ations by a single “PerformanceOperation”. Further-more, we only need to distinguish between two kinds of con-ditions, namely “controlFlowCondition” (consistingof controlCondition and possibly eventCondi-tion) and “performanceCondition” (consisting ofdataCondition, resourceCondition, and possiblyeventCondition). This leads to the following, simplifiedrule:rule WorkflowTransition(flowNode) =if controlFlowCondition(flowNode) and

performanceCondition(flowNode) thenPerformanceOperation(flowNode)

In the case of certain deontic tasks, however, we haveto provide for the possibility that they are not supposedto perform the PerformanceOperation under cer-tain conditions, but still pass tokens on along their out-going sequence flows. This is the case with “conditional”tasks—e.g., permissible tasks (which we translate to con-ditionally obligatory tasks): if such a task gets a token(i.e., controlCondition is fulfilled), and the other con-ditions are not relevant, the user may still decide whether thetask shall be performed or not; yet if it is not performed, itstill has to pass on a token towards other activities or towardsa gateway waiting for it.

Consequently we have to introduce a new “choice-Condition” to model this behaviour:

rule WorkflowTransitionDeontic(flowNode) =if choiceCondition(flowNode) then

if controlFlowCondition(flowNode) andperformanceCondition(flowNode) then

PerformanceOperation(flowNode)else

if controlFlowCondition(flowNode) thenControlFlowOperation(flowNode)

where ControlFlowOperation simply passes atoken on to outgoing sequence flows (while ControlOp-eration may in fact be more complex).

In the above formulation, it can be easily seen thatWorkflowTransitionDeontic is a conservative exten-sion of WorkflowTransition (the original code is

retained and just nested into a more complex rule). However,we can reformulate this in a logically equivalent way:rule WorkflowTransitionDeontic(flowNode) =if controlFlowCondition(flowNode) thenif choiceCondition(flowNode) then

if performanceCondition(flowNode) thenPerformanceOperation(flowNode)

elseskip

elseControlFlowOperation(flowNode)

where we think that the actual behaviour can be identi-fied a bit easier. (For instance, we can now easily see thatthe user’s choice is only relevant and asked for once thecontrolFlowCondition has become true.) Note thatit is still obvious that we can model standard BPMN flownodes with WorkflowTransitionDeontic by settingchoiceCondition := true for all flow nodes. Wewill use this last formulation in our following considerations.

If choiceCondition is true for all standard but notfor all deontic tasks, we will not be able to achieve the samesemantics unless we can match choiceCondition withsome other feature in standard BPMN. To this end, we can-not simply compare a standard task with its correspondingdeontic task, but we have to look at whole subdiagrams.

We assert that a deontic task where choiceConditionis relevant, in particular a permissible task, will always bein a place where the corresponding standard task is down-stream of an exclusive or inclusive gateway (the graph trans-formation rules which we introduce in the next section ful-fil this assertion). Each outgoing sequence flow of such agateway (except from a default sequence flow) is associatedwith a condition which determines whether, upon firing, thissequence flow will get a token or not. We will show that wecan match this condition with the choiceCondition ofthe respective deontic task. To this end, we will first take alook at the semantics of gateways.

4.5 The semantics of gateways

We will only skirt the semantics of gateways as much as weneed it for the purposes of this paper. The semantics of gate-ways is the same in standard BPMN and in Deontic BPMN.

We differentiate between splitting and merging gateways.According to the BPMN standard, one gateway can be bothsplitting and merging, but with the exception of complexgateways, which we do not treat here, a gateway which isboth splitting and merging can always be simulated by sepa-rate splitting and merging gateways. That way the semanticsis easier to understand.

We start with splitting gateways:

rule WorkflowTransitionSplit(gateway) =choose incomingSequenceFlow in

123


incomingSequenceFlows(gateway) do// assert: there is only one element in// incomingSequenceFlows(gateway), thus// incomingSequenceFlow is chosen// deterministicallyWorkflowTransitionDeontic(gateway)

where

derived controlFlowCondition(gateway) =tokens(incomingSequenceFlow) != {}

rule PerformanceOperation(gateway) =let chosenSequenceFlows =

selectOutgoingSequenceFlows(gateway) in

choose token intokens(incomingSequenceFlow) do

Consume(incomingSequenceFlow,token)

forall outgoingSequenceFlow inchosenSequenceFlows(gateway) do

Produce(outgoingSequenceFlow,NewToken(tokenType(token))

Based on the “where” statement, we say that Work-flowConditionDeontic is refined by specifyingcon-trolFlowCondition as well as PerformanceOperation (in particular, ControlOperation in theoriginal definition of WorkflowTransition).

Parallel, exclusive and inclusive gateways only differ inthe way they choose outgoing sequence flows for passing ontokens, i.e., in the definition of chosenSequenceFlows:

rule WorkflowTransitionParallelSplit(gateway) =WorkflowTransitionSplit( gateway )

where

derived chosenSequenceFlows(gateway) =outgoingSequenceFlows(gateway)

i.e., all outgoing Sequence Flows are chosen.

rule WorkflowTransitionExclusiveSplit(gateway) =WorkflowTransitionSplit( gateway )

where

derived chosenSequenceFlows(gateway) ={ choose sequenceFlow in

outgoingSequenceFlows(gateway) withfiringCondition(sequenceFlow) = true

}

where we takefiringCondition to be a monitored func-tion (as we do not treat data-based conditions in this paper).A set with only one element is returned.

rule WorkflowTransitionInclusiveSplit(gateway) =WorkflowTransitionSplit( gateway )

where

derived chosenSequenceFlows(gateway) ={ sequenceFlow in outgoingSequenceFlows(

gateway) | firingCondition(sequenceFlow) = true }

i.e., we choose all outgoing sequence flows where firing-Condition = true.

The monitored function firingCondition is exactlythe above-mentioned condition which we will be able tomatch with the choiceCondition of deontic tasks.

We will not go into the details of merging gatewayshere. For our purposes, it suffices to know that, with the“bracketing gateways” assumption made for this paper,they merge the different paths created by splitting gate-ways into a single path, and that they somehow have towait for all the tokens created by the latter before they canfire.

4.6 The semantics of tasks

For the semantics of standard BPMN tasks (with our presentsimplifications), we can use WorkflowTransition-Deontic with the constraints that

1. choiceCondition is always true,2. there is exactly one incoming and one outgoing sequence

flow, and3. when “something” has been performed, a token is passed

on to the outgoing sequence flow.

For Deontic BPMN (the subset introduced here), we dis-tinguish five different types of tasks:

– obligatory tasks,– permissible tasks,– alternative tasks,– conditionally obligatory tasks with the possible precon-

ditions

– “PreviousTask”– “NOT(AlternativeTask(s))”– “UserChoice”, and

– permissible and conditionally obligatory tasks with pre-condition “NOT(AlternativeTask(s))”.

Obligatory tasks have exactly the same semantics as stan-dard BPMN tasks: they only pass a token on when they areperformed.

Permissible tasks can be seen as conditionally obligatorytasks with precondition “UserChoice”.

123


Alternative tasks can also be seen as conditionally obliga-tory tasks but with precondition “NOT(AlternativeTask(s))”.

Thus, all that remains is to look at conditionally obligatorytasks, which we have to do separately for the three differentpreconditions, and permissible and conditionally obligatorytasks. We now treat all those in more detail.

4.7 Conditionally obligatory tasks with precondition“PreviousTask”

We assert that the source of the incoming sequence flow ofsuch a task is also some kind of task. Then if the previous taskwas indeed performed, also the task in question will performonce it receives a token. In that case the behaviour is the sameas that of a standard task.

If the task in questions receives a token, but the previoustask (which passed this token on) was not performed, thenthat previous task must also be a conditionally obligatory task(as neither a standard task nor an (unconditionally) obliga-tory task can behave in this way). Now we can assume thata chain of conditionally obligatory tasks with precondition“PreviousTask” has a beginning, i.e., there exists a condition-ally obligatory task with another precondition in front of sucha chain. So the task in question will behave like this “start-ing” task: once it gets a token, it will perform if the “starting”task did and not perform if the “starting” task did not. (Wedefine that whenever a task is not explicitly permitted, it isforbidden.)

We can assert that both possible candidates for such a“starting” task (with preconditions “UserChoice” or “NOT(AlternativeTask(s))”) are only used if the correspond-ing standard task came after a splitting gateway (as wewill see later). Thus, the task in question will lie ona (not further branched) path in between two gatewaysand will perform or not perform like the other tasks onthat path—which is exactly the behaviour we expect andwhich is achieved in standard BPMN by means of tokensalone.

4.8 Conditionally obligatory tasks with precondition“NOT(AlternativeTask(s))”

We assert that such tasks are only used in between exclusivegateways, and that those gateways are retained, for other-wise there would not exist any alternative tasks (this assertionholds for the graph transformation rules introduced below).

Then choiceCondition will be true if the task getsa token, i.e., if firingCondition of the respective out-going sequence flow of the splitting gateway is true, andchoiceCondition will be false if firingCondi-tion isfalse. So the value of choiceCondition turnsout to be redundant, and such a task behaves exactly like astandard BPMN task.

4.9 Conditionally obligatory tasks with precondition“UserChoice”

We assert that such a task is only used in the place of astandard BPMN task which comes after a splitting exclusiveor inclusive gateway, because these are the only places wherea choice is possible in a standard BPMN model. Then we canmatch firingCondition of the outgoing sequence flowof the splitting gateway which leads to the task in questionwith choiceCondition of this task.

A permissible task (i.e., a conditionally obligatory taskwith precondition “UserChoice”) may make the enclos-ing gateways redundant (in particular, when an empty path(�) would have been the only alternative). In this casechoiceCondition(task) will replace firingCon-dition(gateway). The eliminated empty path will besimulated by settingchoiceCondition to false, wherebythe task will not be performed but a token will still bepassed on.

If the enclosing gateways are retained (because there areother alternatives), then choiceCondition will be for-mally redundant, because the task will get a token if and onlyif choiceCondition = true (by way of the couplingof firingCondition(gateway) and choiceCon-dition(task)).

4.10 Permissible and conditionally obligatory tasks withprecondition “NOT(AlternativeTask(s))”

Depending on the runtime evaluation of the precondition,such a task behaves either like a conditionally obligatorytask with precondition “NOT(AlternativeTask(s))”, if theprecondition evaluates to true, or else like a permissible task(i.e., a conditionally obligatory task with precondition “User-Choice”). Both of these tasks have been treated before; itremains to show, for each situation where such a task can beemployed, that in both cases the initial behaviour is retained.We will do this in Sect. 5.

5 Graph transformation from BPMN to Deontic BPMN

This section describes an algebraic graph transformationfrom BPMN to Deontic BPMN called DeonticBpmnGTS.After an introduction to the foundations of graph transforma-tion, DeonticBpmnGTS is presented including the type graphand several transformation rules. The source and target graphof every transformation rule are proven to be semanticallyequivalent. Furthermore, it is shown that DeonticBpmnGTSis strictly AC-confluent and terminating, which implies thatthe transformation is globally deterministic. This sectionconcludes with a discussion of the results.

123


5.1 Foundations of graph transformation

A basic overview of graph transformation together withrelated work is provided in Sect. 2. In the following, the mostimportant definitions concerning algebraic graph transforma-tion such as graph, type graph, and confluence are presented.Further definitions can be found in Ehrig et al. [16].

The first definition specifies a graph consisting of nodesand directed edges.

Definition 1 [Directed] Graph (source: [16, p. 21]):

“A [directed] graph G = (V, E, s, t) consists of a setV of nodes (also called vertices), a set E of edges, andtwo functions s, t : E → V , the source and targetfunctions.”

The concept of graph morphism then specifies how twographs are related by defining a mapping between the nodesand edges of the graphs (see [16, p. 22]).

Further important definitions are those of a type graph anda typed graph. A type graph specifies node and edge typesand the relationships between them. A specific graph withnodes and edges based on types is called a typed graph.

Definition 2 Type Graph and Typed Graph (Source: [16,p. 22f]):

“A type graph is a distinguished graph T G = (VT G, ET G ,

sT G, tT G). VT G and ET G are called the vertex and theedge type alphabets, respectively.A tuple (G, type) of a graph G together with a graphmorphism t ype : G → T G is then called a typedgraph.”

An important extension of typed graphs are attributedtyped graphs over an attributed type graph (ATG). This exten-sion requires the definition of an E-graph, which has twokinds of nodes [graph (VG ) and data nodes (VD)] and threekinds of edges [usual graph edges (EG) and special edgesfor node (EN A) and edge attribution (EE A)]. An attributedgraph is then defined to be an E-graph combined with analgebra over a data signature DSI G with attribute value sortsS′D ⊆ SD (cf. for this paragraph [16, p. 171ff]).

Since DeonticBpmnGTS defines abstract nodes and inher-itance relations within the type graph, the definition of anattributed type graph with inheritance (ATGI) is necessary.

Definition 3 Attributed type graph with inheritance (source:[16, p. 260f]):

“An attributed type graph with inheritance AT G I =(T G, Z , I, A) consists of an attributed type graphAT G= (T G, Z) [...], where T G is an E-graph T G=(T GVG , T GVD , T G EG , T G EN A , T G EE A , (sourcei ,

targeti )i ∈{G,N A,E A}) with T GVG = S′D and final DSIG-algebra Z ; an inheritance graph I = (IV , IE , s, t) with

IV = T GVG ; and a set A ⊆ IV , called the abstractnodes. For each node n ∈ IV , the inheritance clan isdefined by clanI (n)={n′ ∈ IV |∃pathn′ ∗→ n inI } ⊆IV with n ∈clanI (n).”

So an attributed type graph (ATG) consists of a type graphTG that is an E-graph and a final DSIG-algebra Z . A DSIG-algebra Z is called final, if it is “the unique (up to iso-morphism) final algebra in the category Alg(Σ)” (cf. [16,p. 357]). An ATGI further comprises an inheritance graphI and a set of abstract nodes A. Furthermore, the inheri-tance clan of a node represents all its subnodes (compare[16, p. 260]).

An ATGI can be flattened to an ATG in order to benefitfrom the definitions of typed attributed graph transformation(compare [16, p. 261f]). The equivalence of typed attributedgraph grammars with and without inheritance is shown byEhrig et al. in [16, p. 278f].

According to Ehrig et al. (see [16, p. 23f]), a further con-cept of algebraic graph transformation is that of a labelledgraph, which consists of a label alphabet L with node labelsLV and edge labels L E (L = (LV , L E )). A labelled graphcorresponds to the type graph as follows (see [16, p. 24]):

– VT G = LV ,– ET G = LV × L E × LV ,– sT G : ET G → VT G : (a, x, b) �→ a,– tT G : ET G → VT G : (a, x, b) �→ b.

Since every node type must have a distinct label, the nodelabel corresponds to the node type. However, one edge labelcan be used for different combinations of nodes whereas anedge type is restricted to the defined source and target node.For example, in DeonticBpmnGTS, one edge label with thename SF is reused for all combinations of nodes.

A further important definition for graph transformationis that of a graph rule (also called graph production). Theapplication of a rule to a graph is called a direct graph trans-formation.

Definition 4 Graph production (source: [16, p. 37]):

“A (typed) graph production p = (Ll← K

r→ R) con-sists of (typed) graphs, L , K , and R, called the left-handside, gluing graph, and the right-hand side, respectively,and two injective (typed) graph morphisms l and r .”

A sequence G0 ⇒ G1 ⇒ · · · ⇒ Gn of direct graphtransformations is called a graph transformation (G0

∗⇒ Gn)and a graph transformation system (GTS) consists of a set ofgraph rules. A GTS can be nondeterministic if, for a givenrule, several matches are possible and one has to be chosen,or if several rules are applicable and one is chosen arbitrarily(cf. for this paragraph [16, p. 9f, 37f]).

123


The overall goal is to prove global determinism of Deon-ticBpmnGTS, even if there is local nondeterminism. Globaldeterminism means that the target graphs H1 and H2 of everyterminating graph transformation G

∗⇒ H1 and G∗⇒ H2

are isomorphic (cf. [16, p. 59]); so regardless of the chosenmatch or the order of the rule application, the resulting graphis always the same.

According to Ehrig et al. [16, p. 59], every confluent GTSis globally deterministic. A GTS is confluent if for all graphtransformations G

∗⇒ H1 and G∗⇒ H2, there exists a graph

X with graph transformations H1∗⇒ X and H2

∗⇒ X . Hence,confluence implies the uniqueness of X (cf. [10, p. 198f]).In order to prove confluence, it is either necessary to showthat each rule pair is parallel independent for all possiblematches or, in case of parallel dependent rules, that the GTS isterminating and locally confluent. A GTS is locally confluentif all its critical pairs (parallel dependent and minimal) arestrictly confluent (see definition in Sect. 5.4) (cf. for thisparagraph [16, p. 59ff, 144]).

Tackling the question whether two rules can be applied inarbitrary order requires the definition of parallel and sequen-tial independence. Two rules are parallel independent if allnodes and edges in the intersection of the two matches aregluing items, i.e., are not deleted by the rule, for both trans-formations. This means that no element of graph G that is partof both matches must be deleted by any of the two rules. Twoconsecutively applied rules are sequentially independent if allnodes and edges in the intersection of the comatch R1 → H1

and the second rule’s match are gluing items with respect toboth transformations (cf. for this paragraph [16, p. 44f, 47ff]).So no element that is part of the comatch R1 → H1 of thefirst rule and match L2 → G of the second rule must bedeleted by one of the two rules. The dependency betweenparallel and sequential independence is defined by the localChurch–Rosser theorem.

Theorem 1 Local Church–Rosser theorem for GTSs(source: [16, p. 50f]):

“Given two parallel independent direct (typed) graph

transformations Gp1,m1⇒ H1 and G

p2,m2⇒ H2, there isa (typed) graph G ′ together with direct (typed) graph

transformations H1p2,m′2⇒ G ′ and H2

p1,m′1⇒ G ′ such

that Gp1,m1⇒ H1

p2,m′2⇒ G ′ and Gp2,m2⇒ H2

p1,m′1⇒ G ′ aresequentially independent.Given two sequentially independent direct (typed)

graph transformations Gp1,m1⇒ H1

p2,m′2⇒ G ′, there area (typed) graph H2 and direct (typed) graph transfor-

mations Gp2,m2⇒ H2

p1,m′1⇒ G ′ such that Gp1,m1⇒ H1

and Gp2,m2⇒ H2 are parallel independent:”

So the local Church–Rosser theorem states that two paral-lel independent graph transformations can be applied in arbi-trary order. If each pair of rules is parallel independent for allpossible matches, then this implies that the GTS is confluent.However, for all parallel dependent rules, a critical pair canbe identified, and local confluence has to be proven. A GTS islocally confluent if each pair of direct graph transformationsG ⇒ H1 and G ⇒ H2 is strictly confluent (see Fig. 11)(cf. for this paragraph [16, p. 59f, 144]).

Critical pairs, strict (local) confluence and termination willbe explained in more detail in the corresponding Sect. 5.4and 5.5.

5.2 DeonticBpmnGTS: an overview

The following sections describe a graph transformation fromBPMN to Deontic BPMN. The transformation is calledDeonticBpmnGTS and defines an attributed type graph withinheritance. The overall graph transformation system con-sists of 18 rules with application conditions distributed across4 layers. However, in this paper, an extract is presented, whichcomprises 11 rules defined within the third layer. Neverthe-less, confluence, termination and semantic equivalence wereproven for all rules.

Two hypotheses are posed for DeonticBpmnGTS and willbe discussed in Sect. 5.6.3:

1. The highlighting of modality with deontic logic reducesthe structural complexity of the process flow. The numberof gateways and/or sequence flows in a Deontic BPMNdiagram is equal to or smaller than the original BPMNdiagram.

2. The transformation from BPMN to Deontic BPMN islocally confluent and terminating, resulting in a globallydeterministic transformation. In addition, the source andtarget graphs are semantically equivalent.

In DeonticBpmnGTS, specific BPMN models are takenas input and transformed to Deontic BPMN models, thereby

Fig. 11 Confluence and local confluence (source: [16, p. 59])

123


highlighting the deontic concepts. The GTS comprises thebasic transformations described in Sect. 3, but is limited to:

– Structured diagrams The gateways are defined in abracket structure.

– Basic set of BPMN elements DeonticBpmnGTS supportssequence flows, parallel, exclusive and inclusive gate-ways with user choice, start/end events and tasks. Allsupported node and edge types are shown in Sect. 5.3.

– One task per path DeonticBpmnGTS is limited to onetask per path following a splitting gateway and is alsoprohibiting most types of nested gateways.

Not allowed are also mixed gateways as well as sev-eral uncontrolled or conditional sequence flows. In mostcases, these constructs can synonymically be expressedwith an additional gateway except in some rare casesin which, for example, uncontrolled incoming sequenceflows generate new process instances. In addition, dif-ferent markers used for tasks or events are not relevantfor the current deontic classification and thus not distin-guished.

5.3 Type graph and rules

This section presents the type graph of DeonticBpmnGTSwith all node and edge types as well as the 11 trans-formation rules of the third layer. Afterwards an exam-ple demonstrates a transformation from BPMN to DeonticBPMN.

First, the node types and one edge label of the graphtransformation system are defined. DeonticBpmnGTS pro-vides four node types for gateways (Gateway, Parallel-

Gateway, InclusiveGateway and ExclusiveGateway), two forBPMN tasks (BpmnTask and Task), eight for Deontic BPMNtasks (DeonticTask, O(Task), X(Task), P(Task), O(Task|Pre-condition), X(Task|Precondition), P(Task|Precondition) andP(Task) and O(Task|Precondition)) and three for events(Event, StartEvent and EndEvent). One further node type iscalled MeasuredValues and used to store meta-informationlike the number of gateways and sequence flows in order tostudy the reduction of structural complexity. This node is notrelevant for the deontic transformation and, thus, excludedfrom the critical pair analysis. In addition, DeonticBpmnGTSprovides one edge label called SF for sequence flows repre-senting several edge types.

In a second step, the type graph is specified, which definesthe generalization and dependency relationships between thenode types. For DeonticBpmnGTS, an attributed type graphwith inheritance is defined. Figure 12 shows this type graphin a screen shot from the graph transformation tool AGG,which was used in our research. The basic element of the typegraph is Node with the derived types Gateway, DeonticTask,BpmnTask and Event.

The type graph of DeonticBpmnGTS includes the follow-ing information:

– Abstract and concrete node types Five node types(Node, Event, BpmnTask, DeonticTask, and Gateway) areabstract and are highlighted by curly brackets and italicfont. All other elements represent concrete node types.

– Attributes Some node types define attributes such aspreconditions or the number of gateways and sequenceflows. These attributes may change during a transforma-tion step.

Fig. 12 Type graph of DeonticBpmnGTS

123


– Generalization relationships The ATGI definition per-mits generalization relationships between different nodetypes and multiple inheritance as used for node typeP(Task) and O(Task|Precondition). The attributes speci-fied within a superclass are inherited by all subclasses.

– Dependency relationships with multiplicity The source,target, and cardinality of a sequence flow is specifiedby dependency relationships. Although all edges arelabelled as SF, every dependency relationship representsa distinct edge type.

In the following, the 11 transformation rules of the thirdlayer together with their application conditions are intro-duced. The rules cover parallel, exclusive and inclusive gate-ways with user choice. The rules for exclusive and inclu-sive gateways are very similar and only slightly differentfrom those of parallel gateways. Sequences and iterationsare addressed within the other layers. Layering offers a kindof ordering, since all rules of one layer are applied as long aspossible before the next layer is considered. A set of rules Ris defined to be layered, if for each rule r ∈ R, there is a rulelayer rl(r) with 0 ≤ rl(r) ≤ k0, where k0 + 1 is the numberof layers (compare [16, p. 250]). Note that layer 0 is calledthe first layer, layer 1 the second layer and so on.

The application of rules is restricted by application con-ditions (AC), which can either be positive or negative. Anegative application condition (NAC) of the form NAC(x)

with graph morphism x : L → X is satisfied by a graphmorphism m : L → G if there does not exist an injectivegraph morphism p : X → G with p ◦ x = m. This meansthat if there is an occurrence of the left-hand side L in G,then the NAC is satisfied if X is not also part of that match inG. A positive application condition (PAC) is the counterpartto a NAC and satisfied if such an injective graph morphismexists. ACs are further allowed to contain L only partially(s : L Sub → L and x : L Sub → X ). In the following ruledescriptions, the NACs and PACs do not include the Mea-suredValues element (cf. for this paragraph [16, p. 64, 67ff,309]).

5.3.1 ParallelWithPhiDualRule

This rule replaces every occurrence of a parallel gatewayaddressing one task and one Phi-path with an obligatory taskas shown in Fig. 13. The NAC forbids that the splitting gate-way references further nodes and thereby avoids danglingedges. If further nodes exist, then the rule ParallelRule maybe used.

The intersection K of the left- and right-hand sides (K =LHS ∩ RHS) consists for the given rule of the two Nodesand the element MeasuredValues. In general, it can be saidthat all elements with a preceding number on the RHS aredefined on both sides and, thus, part of K , whereas all other

(a) LHS

(b) RHS

(c) NAC: NoFurtherNode

Fig. 13 ParallelWithPhiDualRule

elements are either created or deleted by the rule. The ele-ment MeasuredValues shows that the transformation leads toa reduction of two gateways and three sequence flows.

Since a task on the only non-empty path will have to beperformed under all circumstances once the splitting gatewayfires, the semantics does not change if a standard task isreplaced by an obligatory task. Furthermore, the empty pathhas no additional meaning and can be removed.

5.3.2 ParallelRule

The rule ParallelRule can be applied several times to classifyan arbitrary number of tasks being referenced by a parallelgateway as obligatory as shown in Fig. 14. The PAC speci-fies that at least one further node is referenced. This appli-cation condition assures that the first gateway addresses notonly one further Phi-path (ParallelWithPhiDualRule shouldbe used) and that it is not a merging gateway with a sub-sequent task followed by a splitting gateway. According tothe MeasuredValues element, this rule does not reduce thenumber of gateways and sequence flows.

Every task in between two parallel gateways must be per-formed once the splitting gateway fires. Consequently, thesemantics do not change if a task between two parallel gate-ways is replaced by (i.e., classified as) an obligatory task.

5.3.3 ParallelRuleFinish

After all tasks have been classified as obligatory, the ruleParallelRuleFinish removes a possible Phi-path. This rule isapplied if at least two tasks are classified as obligatory andno further BPMN task exists as defined by the NAC. The

123


(a) LHS

(b) RHS

(c) PAC: FurtherNode

Fig. 14 ParallelRule

(a) LHS

(b) RHS

(c) NAC: NoFurtherTask

Fig. 15 ParallelRuleFinish

transformation leads to a reduction of one sequence flow(Fig. 15).

A Phi-path within a parallel split does not extend thefunctionality and is executed in parallel with all other paths.Therefore, this construct is dispensable and it would be bestpractice to not use it at all. However, since this construct isnot forbidden by the BPMN standard, a transformation ruleis necessary.

5.3.4 ExclusiveWithPhiDualRule

The rule ExclusiveWithPhiDualRule takes an exclusive gate-way with a task and a Phi-path and transforms it to a permis-sible task (see Fig. 16). The NAC forbids further alternativenodes and thereby avoids dangling edges. The rule Exclu-siveWithPhiRule may be used in case of further tasks. Thetransformation leads to a reduction of two gateways and threesequence flows.

In order to check that the semantics are preserved by thisrule, as explained before, we have to transform the new per-missible task into a conditionally obligatory task with pre-condition “UserChoice” before we can compare the diagramsbefore and after the transformation.

The precondition “UserChoice” is reflected in the booleanfunction choiceCondition(task) in our ASM model.Let sf7 and sf9 be the sequence flows marked in Fig. 16 with“7: SF” and “9: SF”, respectively, and let task3 be the taskmarked with “3: Task” and pTask the resulting conditionallyobligatory task. We distinguish two cases.

Case 1: In the standard model (LHS of the transformationrule), selectOutgoingSequenceFlows(splitGateway) yields sf7 at runtime (i.e., sf7 was chosenby the user, i.e., firingCondition(sf7) = true).Then task3 received a token, thus it is performed (aschoiceCondition(flow Node) is true for all non-deontic tasks) and passes a token on.

After the graph transformation, choiceCondition(pTask) will be true, thus pTask will behave like task3,i.e., it will be performed and pass a token on.

Case 2: In the standard model, selectOutgoing-SequenceFlows(splitGateway) yields sf9. In thiscase task3 is not performed, and the merging gatewayreceives a token via sf9.

(a) LHS

(b) RHS


Fig. 16 ExclusiveWithPhiDualRule

123


After the graph transformation, choiceCondition(pTask) will be false, therefore pTask will not be per-formed (like task3), yet will pass on a token towards themerging gateway. Thus, the behaviour of the subdiagram isagain the same.

5.3.5 ExclusiveWithPhiRule

The rule ExclusiveWithPhiRule transforms a task of an exclu-sive gateway with a Phi-path into a permissible task (seeFig. 17). The rule can be applied several times to classify anarbitrary number of tasks. The PAC specifies that a furthernode exists; otherwise the rule ExclusiveWithPhiDualRuleshould be used. This rule does not reduce the number ofgateways and sequence flows.

Here the conditions associated with the outgoing sequenceflows of the splitting gateway are retained. We name sequenceflows and tasks as with the previous rule.

pTask could now be treated as an ordinary obligatorytask (with choiceCondition(pTask) = true in allcases), as it will only get a token when its incoming sequenceflow sf gets a token, based on the value of firingCon-dition(sf). However, in order to be consistent withour treatment of the previous rule, we prefer to assumethat choiceCondition(pTask) = firingCondi-tion(sf) = firingCondition(sf5) (even if itconstitutes a redundancy). In any case, it is easy to see that

(a) LHS

(b) RHS

(c) PAC: FurtherNodea

Fig. 17 ExclusiveWithPhiRule

pTask performs whenever task2 performs and that token flowis unaffected.

5.3.6 ExclusiveWithPhiRuleFinish

The rule ExclusiveWithPhiRuleFinish is applied after the ruleExclusiveWithPhiRule and removes the Phi-path as shown inFig. 18. The left-hand side of the rule requires two permissi-ble tasks as well as a Phi-path, and the NAC forbids furthernot transformed tasks. The transformation leads to a reduc-tion of one sequence flow.

Again, in order to compare the semantics before and afterthe graph transformation, we treat pTask3 and pTask4 as con-ditionally obligatory tasks with precondition “UserChoice”.We distinguish two cases:

Case 1: Some P(Task) is chosen. This can be done beforeand after the graph transformation alike, to the same effects.

Case 2: In the diagram before the graph transformation,the empty path sf is chosen, i.e.,firingCondition(sf)= true. This means that neither pTask3 nor pTask4 areperformed, but a token is passed on directly to the merginggateway.

In the diagram after the graph transformation, the usermay choose any of the remaining paths—e.g., the path topTask3—and then they can choose not to perform pTask3.Then no task is performed, but still a token is passed on tothe merging gateway. Thus, it is possible to achieve the samebehaviour. More formally, the same behaviour is achieved if

(a) LHS

(b) RHS


Fig. 18 ExclusiveWithPhiRuleFinish

123


(a) LHS

(b) RHS

(c) NAC: NoMixedStartGateway

(d) NAC: NoMixedEndGateway

(e) NAC: NoPhiPath

(f) PAC: FurtherNode

Fig. 19 ExclusiveWithoutPhiRule

(firingCondition(sf) = true) ->((firingCondition(sf6’) = true) and

(choiceCondition(pTask3’) = false))or((firingCondition(sf8’) = true) and

(choiceCondition(pTask4’) = false))

(where “primes” refer to elements after graph transformation;additional P(Task)s could be added by disjunction accord-ingly). The relevant settings of firingCondition andchoiceCondition have to be performed by the transfor-mation rule.

5.3.7 ExclusiveWithoutPhiRule

The rule ExclusiveWithoutPhiRule classifies the task of anexclusive gateway without a Phi-path as an alternative task(see Fig. 19). This rule can be applied several times to trans-form an arbitrary number of tasks. Three NACs define thatneither the first nor the second gateway has multiple incom-ing and outgoing sequence flows and that no Phi-path exists.A further PAC specifies that at least one other node exists inparallel to the task in question, which ensures that the first

(a) LHS

(b) RHS


Fig. 20 InclusiveWithPhiDualRule

gateway is a splitting gateway. The transformation does notreduce the number of gateways and sequence flows as shownby the MeasuredValues element.

When we considered alternative tasks, and subsequentlyconditionally obligatory tasks with precondition “NOT(AlternativeTask(s))”, which can be thought to represent theformer, we have seen that they actually behave like uncondi-tional obligatory tasks under the given conditions, and thusjust like standard BPMN tasks. Thus, the semantics is unaf-fected by this transformation step.

5.3.8 InclusiveWithPhiDualRule

This rule transforms an inclusive gateway with one task and aPhi-path into a permissible task as shown in Fig. 20. The NACforbids further nodes and thereby avoids dangling edges.In addition, the element MeasuredValues highlights that thetransformation leads to a reduction of two gateways and threesequence flows.

For comparing the semantics before and after the transfor-mation, we consider three cases according to possible userchoices:

Case 1: At the splitting inclusive gateway, they can choosethe path with the task, but not the Phi-path. This option isfully retained after graph transformation by choosing to per-form the resulting P(Task), i.e., by setting choiceCondi-tion(pTask) = firingCondition(sf7).

Case 2: Users can choose the Phi-path, but not thepath with the task. Also this option is fully retained aftergraph transformation by choosing not to perform P(Task),i.e., choiceCondition(pTask) = false.

Case 3: Users can choose both paths. However, this hasthe same effect as choosing only the path with the task: thetask will be performed, and the merging gateway will be able

123


to fire afterwards without delay, as the additional token onthe Phi-path will already be there when the task has beencompleted. So this case is actually also covered by Case 1.

So the behaviour remains the same in each possible casebefore and after the graph transformation.

5.3.9 InclusiveWithPhiRule

The rule InclusiveWithPhiRule converts a task of an inclusivegateway with a Phi-path into a permissible task (see Fig. 21).The rule can be applied several times to classify an arbitrarynumber of tasks. The PAC specifies that a further node exists,since otherwise the rule InclusiveWithPhiDualRule should beused to remove the gateways. This rule does not reduce thenumber of gateways and sequence flows.

As the inclusive gateways as well as all paths are retainedby this rule, control flow is unaffected.

In order for each P(Task) pTask which is created bythe rule to perform whenever the corresponding stan-dard BPMN task would have performed, we just haveto make sure in the course of graph transformation thatchoiceCondition(pTask) = firingCondition(sf6).

Again, the information that the task is permissible is actu-ally redundant, but useful for the user.

(a) LHS

(b) RHS

(c) PAC:FurtherNode

Fig. 21 InclusiveWithPhiRule

5.3.10 InclusiveWithPhiRuleFinish

The rule InclusiveWithPhiRuleFinish is applied after the ruleInclusiveWithPhiRule and removes the Phi-path as shownin Fig. 22. The rule requires at least two permissible tasksaddressed by inclusive gateways as well as a Phi-path. TheNAC forbids further not transformed tasks. The transforma-tion leads to a reduction of one sequence flow.

As with InclusiveWithPhiDualRule, we can distinguishthree cases, depending on possible user choices before thegraph transformation:

Case 1: At the splitting gateway, users choose at least onepath with a task, but not the Phi-path (which is eliminatedby the rule). This choice is not affected by the elimination ofthe Phi-path.

Case 2: Users choose the Phi-path, but no other path. Aftergraph transformation, users can choose any of the remainingpaths and then choose not to perform the P(Task) there, tothe same effect.

Case 3: Users choose the Phi-path plus at least one otherpath. In this case, the Phi-path is redundant, as alreadyexplained for InclusiveWithPhiDualRule.

So again, the behaviour of the subdiagram is not changedin any possible case.

5.3.11 InclusiveWithoutPhiRule

This rule classifies a task of an inclusive gateway without aPhi-path as a permissible task that is obligatory under the

(a) LHS

(b) RHS


Fig. 22 InclusiveWithPhiRuleFinish

123


(a) LHS

(b) RHS

(c) NAC: NoMixedStartGateway

(d) NAC: NoMixedEndGateway

(e) NAC: NoPhiPath

(f) PAC: FurtherNode

Fig. 23 InclusiveWithoutPhiRule

precondition that no alternative task will be executed (seeFig. 23). In fact, the precondition should address all tasksindividually, e.g.,: P(A)∧O(A|¬B∧¬C). However, since thetasks in DeonticBpmnGTS are currently not named, the pre-condition “NOT(AlternativeTask(s))” is used instead. Thisrule can be applied several times to transform an arbitrarynumber of tasks. Three NACs define that neither the firstnor the second gateway has multiple incoming and outgoingsequence flows and that no Phi-path exists.

A further PAC specifies that at least one other node exists.The transformation does not reduce the number of gatewaysand sequence flows.

As the inclusive gateways are retained by this rule, alsothe behaviour is fully retained thereby. As we will see, thechanges made by this rule are only of ”optical” relevance forthe user. We can distinguish two cases:

Case 1: Before the graph transformation, the userswould have chosen only one path. Then the task on thispath will become an obligatory task, as the precondition“NOT(AlternativeTask(s))” is true. We have already shownabove that an obligatory task behaves just like a standardBPMN task.

Case 2: The users want to choose more than one path.Then each task on a chosen path becomes a permissi-ble task, as the precondition for becoming an obliga-tory task is false. As shown before, a permissible taskpTask can be thought of as a conditionally obligatory taskwith the precondition “UserChoice”. By setting choice-Condition(pTask) = firingCondition(sf) (sfbeing the outgoing sequence flow of the splitting gatewaywhich leads to pTask) in the course of the transformation,pTask again becomes an obligatory task (if sf is a chosenpath and thus firingCondition(sf) = true), andso it also behaves like a standard BPMN task.

So also this rule does not change the behaviour of thesubdiagram in question.

5.3.12 Example

After defining the rules, a typed graph can be created for aspecific BPMN model and is then transformed to DeonticBPMN. This is demonstrated by an example whose BPMNmodel is shown in Fig. 24. The gateways are displayed in theirimage view. According to the MeasuredValues element, theBPMN model consists of eight gateways and twenty-ninesequence flows.

The graph transformation in AGG can be executednon-deterministically (NT), by rule layers (LT), rule pri-orities (PT) or rule sequences (ST). Every transforma-tion in DeonticBpmnGTS is executed based on the rulelayers.

After starting the transformation, every rule of the firstlayer may be executed followed by the rules of the secondlayer. Afterwards the third layer is taken into account andthe following rules are applied: ParallelRule (2x), Exclu-siveWithPhiDualRule (1x), ExclusiveWithoutPhiRule (2x),InclusiveWithPhiRule (4x) and InclusiveWithPhiRuleFinish(1x). Finally, the rules of the fourth layer are executed. Theorder of the rule application within a layer is arbitrary but

Fig. 24 Example: BPMN Model

123


Fig. 25 Example: Deontic BPMN model

restricted by the matching of the LHS of a rule and its appli-cation conditions.

The resulting Deontic BPMN model is shown in Fig. 25.The transformation leads to a reduction of two gateways andfive sequence flows. In addition, the obligatory, alternativeand permissible tasks can be distinguished on first sight basedon their prefix and background colour.

5.4 Strict AC-confluence

This section starts with the foundations and main definitionsof strict AC-confluence. Afterwards the critical pair analysis(CPA) of DeonticBpmnGTS is presented, followed by theproof that DeonticBpmnGTS is locally confluent.

Proving confluence requires in a first step the identifica-tion of all critical pairs. A critical pair is defined as a pairof direct graph transformations that are parallel dependentand minimal. Two direct graph transformations are paralleldependent if they are not parallel independent as defined inSect. 5.1. In addition, a pair of graph transformations is mini-mal if each item in K has a preimage in the left-hand side L ofone of the two graph transformations (cf. for this paragraph[16, p. 47f, 60]).

If no critical pairs are identified, then the GTS is alreadylocally confluent. Otherwise strict AC-confluence must beproven for each critical pair. A critical pair P1 ⇐ K ⇒ P2

is confluent if a graph K ′ together with graph transformationsP1∗⇒ K ′ and P2

∗⇒ K ′ exists. Furthermore, the confluenceis called strict if the largest common subgraph N of K , P1

and P2 is preserved by P1∗⇒ K ′ and P2

∗⇒ K ′ (cf. for thisparagraph [16, p. 60f]).

In addition, the application conditions must be considered.This means that if every NAC is satisfied by the two givengraph transformations, then it must not be possible to violatea NAC in the further transformations P1

∗⇒ K ′ and P2∗⇒ K ′

(strict NAC-confluence). Otherwise, a graph transformationto K ′ might exist but cannot be applied due to a NAC. StrictAC-confluence is an extension of strict NAC-confluence andrequires that all ACs, both NACs and PACs, are satisfiedduring further graph transformations. According to Ehrig etal. [16, p. 314], critical pairs for rules with NACs (but not forPACs) are already implemented in AGG.

CPA is supported by the tool AGG, which identifies allconflicting rule applications by computing the minimal crit-ical graphs to which rules can be applied in a conflictingway (compare [16, p. 314]). CPA distinguishes two types ofcritical pairs (compare [2, p. 54]):

– Conflicts in case of parallel dependent rule applicationsand

– Dependencies in case of sequential dependent rule appli-cations.

For proving local confluence of DeonticBpmnGTS, onlyparallel dependent rule applications must be considered.AGG computed 45 conflicts which are shown in Table 1. Thelayers are taken into account and CPs are only calculated forrules of the same layer. If the rules are defined on differentlayers, then the cell in the table is left empty. Otherwise thenumber of critical pairs is displayed.

The CPA computed 13 duplicate critical pairs. Further-more, the 3 critical pairs identified for the rule combinationsWithPhiRule/WithPhiDualRule are invalid, since the corre-sponding first rule defines a PAC FurtherNode, which is notconsidered by the AGG tool. The remaining 29 critical pairshave been studied in detail.

As can be seen in Table 1, the number and alignment ofthe conflicts identified for the three different gateways inthe third layer are similar. Especially the conflicts for exclu-sive and inclusive gateways are almost the same and onlyslightly different from those of parallel gateways, which donot distinguish transformation rules with and without Phi-paths. In addition, the graphs of all CPs identified within thethird layer are isomorphic. Thus, strict AC-confluence can beconcluded based on the isomorphism as shown for the criticalpair ParallelWithPhiDualRule/ParallelWithPhiDualRule. Inthe following, graph G denotes the original graph, graphs H1

and H2 show the resulting graphs after an application of thetwo parallel dependent rules, and graph X presents the finalgraph that is achieved through extended transformations toprove confluence.

5.4.1 ParallelWithPhiDualRule/ ParallelWithPhiDualRule

One critical pair has been identified by AGG for the parallelapplication of the rule ParallelWithPhiDualRule as shown in

123


Table 1 CPA: parallel dependent rule applications

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

1 2 1 0 0

2 0 1 0 0

3 0 0 2 1

4 0 0 1 1

5 1

6 1 0 0 0 0 0 0 0 0 0 0

7 1 1 0 0 0 0 0 0 0 0 0

8 0 0 7 0 0 0 0 0 0 0 0

9 0 0 0 1 0 0 0 0 0 0 0

10 0 0 0 1 1 0 0 0 0 0 0

11 0 0 0 0 0 7 0 0 0 0 0

12 0 0 0 0 0 0 1 0 0 0 0

13 0 0 0 0 0 0 0 1 0 0 0

14 0 0 0 0 0 0 0 1 1 0 0

15 0 0 0 0 0 0 0 0 0 7 0

16 0 0 0 0 0 0 0 0 0 0 1

17 1 0

18 1 1

1. SeveralPhiReductionRule2. IterationRepeatUntilRule3. SequenceRuleBase4. SequenceRuleExtended5. SequenceRuleFinish6. ParallelWithPhiDualRule7. ParallelRule8. ParallelRuleFinish9. ExclusiveWithPhiDualRule10. ExclusiveWithPhiRule11. ExclusiveWithPhiRuleFinish12. ExclusiveWithoutPhiRule13. InclusiveWithPhiDualRule14. InclusiveWithPhiRule15. InclusiveWithPhiRuleFinish16. InclusiveWithoutPhiRule17. SequenceBpmnRulePragmatic18. SequenceDeonticRulePragmatic

Fig. 26 CP:ParallelWithPhiDualRule/ParallelWithPhiDualRule

Fig. 26. Both rule applications replace the gateways and thetask with a deontically classified task prohibiting a furtherapplication of the corresponding other rule.

Since the resulting graphs (H1, H2) are isomorphic, nofurther transformation is necessary to prove confluence andno application conditions may be violated (see Fig. 27).Furthermore, every parallel application of rules resulting in

isomorphic graphs is also strict, since the largest subgraphN (marked by a dashed line) is equal to the resulting graphs(N = H1 = H2 = X ). Thus, the CP is strictly AC-confluent.

Fig. 27 Strict AC-confluence of CP shown in Fig. 26

123


However, non-isomorphic CPs emerged in the other layersand strict AC-confluence had to be proven as shown for thecritical pair SequenceRuleBase/SequenceRuleExtended. Theproof for the other non-isomorphic critical pairs is likewise.

5.4.2 SequenceRuleBase/SequenceRuleExtended

The graph transformation rules SequenceRuleBase (seeFig. 28) and SequenceRuleExtended (see Fig. 29) are paralleldependent as shown by the CP in Fig. 30. SequenceRuleBasetransforms 2:Task resulting in graph H1, whereas Sequence-RuleExtended deontically classifies 1:Task leading to graphH2.

The resulting graphs H1 and H2 are different and strictAC-confluence must be proven. After the application ofSequenceRuleBase leading to graph H1, the respective otherrule SequenceRuleExtended can be applied resulting in graphX as shown in Fig. 31. However, an extended transforma-tion of graph H2 is more complex, since SequenceRuleBasecannot be applied anymore. Instead, the rule SequenceRule-Extended is used for the transformation H2 ⇒ X . Thus, thetransformation is confluent. The transformation is also AC-confluent due to the fact that neither SequenceRuleBase norSequenceRuleExtended specifies any application conditions.Moreover, the largest subgraph N of G, H1 and H2 consistsof the first task and the node and is also preserved by graph X .

Local Confluence: Since it can be proven that all CPs arestrictly AC-confluent, it can be concluded that DeonticBpm-nGTS is locally confluent.

(a) LHS (b) RHS

Fig. 28 Rule: SequenceRuleBase

(a) LHS

(b) RHS

Fig. 29 Rule: SequenceRuleExtended

Fig. 30 CP: SequenceRuleBase/SequenceRuleExtended

5.5 Termination

In order to show confluence and consequently global deter-minism of a GTS, it is necessary to prove termination.After an introduction to the foundations of termination anda description of the inheritance problem, this section provestermination of DeonticBpmnGTS.

A graph transformation G∗⇒ H is called terminating if

no further transformation rule is applicable to H anymore,so that there is no infinite sequence of graph transformations(cf. [16, p. 59f]). In order to prove termination of Deon-ticBpmnGTS, the theorem for termination of layered typedgraph grammars with layer conditions is required. The layersare divided into deletion and nondeletion layers. Every dele-tion layer deletes at least one element, whereas nondeletionlayers do not delete anything, but provide NACs to prohibitan infinite application of the same rule (cf. for this paragraph[16, p. 63]).

Theorem 2 Termination of layered typed graph grammars(source: [16, p. 63f]):

“Every layered typed graph grammar GG = (T G, P, G0)

with injective matches terminates, provided that it islayered in the following sense:

1. P is layered, i.e., for each p ∈ P there is a produc-tion layer pl(p) with 0 ≤ pl(p) ≤ k0(pl(p), k0 ∈N), where k0+1 is the number of layers of GG, andeach typed graph production p ∈ P has a set NACp

of negative application conditions NAC(n : L →N ) [...]; the latter is abbreviated as n ∈ NACp.

2. The type set TYPE of GG is given by all graph nodesand edges of the type graph TG, i.e., T Y P E =VTG∪̇ET G

3. GG is finite4. For each type t ∈ TYPE there is a creation layer

cl(t) ∈ N and a deletion layer dl(t) ∈ N, andeach production layer k is either a deletion layer ora nondeletion layer, satisfying the following layerconditions for all p ∈ Pk:” [see Table 2]

A layered graph grammar defines, for each rule r , a rulelayer rl(r) = k and for each type t , a creation layer cl(t) anda deletion layer dl(t) (compare [2, p. 79]). The creation anddeletion layers are calculated as follows:

123


Fig. 31 Strict AC-confluence of CP shown in Fig. 30

Table 2 Termination: layer conditions (source: [16, p. 64], slightly modified)

Deletion layer conditions Nondeletion layer conditions

1. p deletes at least one item 1. p is nondeleting, i.e., K = L such that p is given by r : L → R injective

2. 0 ≤ cl(t) ≤ dl(t) ≤ k0 + 1 for all t ∈ TYPE 2. p has n ∈ N AC p with n : L → N , and there is an injective n′ : N → R with n′ ◦ n = r

3. p deletes an item of type t ⇒ dl(t) ≤ pl(p) 3. x ∈ L with t ype(x) = t ⇒ cl(t) ≤ pl(p)

4. p creates an item of type t ⇒ cl(t) > pl(p) 4. p creates an item of type t ⇒ cl(t) > pl(p)

Definition 5 Layer assignments (source: [16, p. 253]):

“cl(t) = if t ∈ T0 then 0else max{pl(p)|pcreatest} + 1,

dl(t) = if tisdeletedbysomepthen min{pl(p)|pdeletest}elsek0 + 1.”

The termination of GTSs is in general undecidable, buttermination can be concluded if suitable termination crite-ria as defined in the termination theorem are met (cf. [16,p. 318]). The tool AGG provides a termination analysis forlayered graph transformation systems. The rule layers for thetermination proof can either be set by the user or generatedby AGG. All creation and deletion layers are then calculatedby AGG so that the layer conditions are fulfilled if possible(cf. for this paragraph [16, p. 318]). However, the termina-tion analysis is restricted to GTSs without abstract nodesand inheritance relationships in the type graph. Accordingto Varró et al. [42], the termination criteria can be used forGTSs with node type inheritance if the inheritance graphis flattened. Since AGG does not support a flattening ofthe type graph, Natschläger and Schewe suggested a flat-tening algorithm in [30]. The flattening algorithm consid-ers abstract nodes, inheritance relationships, multiple inher-itance, attributes and application conditions. Based on theflattening algorithm, a concrete prototype was developed andused to flatten the type graph of DeonticBpmnGTS, resultingin 822 rules and 10.170 ACs. For example, the flattening of

the rule ParallelWithPhiDualRule leads to 169 concrete rulesin which the two abstract nodes Node are replaced in anycombination. In the flattened type graph of DeonticBpmn-GTS, all abstract nodes and inheritance relationships wereremoved and attributes were copied.

After flattening DeonticBpmnGTS, the termination analy-sis (TA) is executed manually and by the tool AGG. Ina first step, the rule layers are calculated as shown inTable 3. The layers are based on the ordering describedin Sect. 5.2 and refined to fulfil the termination crite-ria. The rules SequenceBpmnRulePragmatic and Sequence-DeonticRulePragmatic span two layers (3–4), since theflattened rules defined within layer 3 delete a node of typeO(Task|Precondition) whereas the flattened rules in layer 4delete a node of the subtype P(Task) and O(Task|Precondition). The third column of Table 3 specifies the reductiontype, since each rule in a deletion layer must decrease thenumber of graph items in general or of one special type.

Afterwards the creation and deletion layers for all nodetypes and for the edge label are calculated as presented inTable 4.

The adapted second deletion layer condition (0 ≤ cl(l) ≤dl(l) ≤ k0+1) is fulfilled by all node types and the edge labelas can be seen in the table. The remaining deletion layer con-ditions (1, 3–4) are proven for each rule. As an example, weshow the termination proof for the rule ParallelWithPhiDu-alRule:

123


Table 3 Termination analysis ofDeonticBpmnGTS: rule layers Rule Layer Reduction

SeveralPhiReductionRule 0 General Reduction

IterationRepeatUntilRule 0 Reduction of Tasks

SequenceRuleBase 0 Reduction of Tasks

SequenceRuleExtended 0 Reduction of Tasks

SequenceRuleFinish 1 Reduction of Tasks

ParallelWithPhiDualRule 2 General Reduction

ParallelRule 2 Reduction of Tasks

ParallelRuleFinish 2 General Reduction

ExclusiveWithPhiDualRule 2 General Reduction

ExclusiveWithPhiRule 2 Reduction of Tasks

ExclusiveWithPhiRuleFinish 2 General Reduction

ExclusiveWithoutPhiRule 2 Reduction of Tasks

InclusiveWithPhiDualRule 2 General Reduction

InclusiveWithPhiRule 2 Reduction of Tasks

InclusiveWithPhiRuleFinish 2 General Reduction

InclusiveWithoutPhiRule 2 Reduction of Tasks

SequenceBpmnRulePragmatic 3 Reduction of O(Task|Precondition)

4 and P(Task) and O(Task|Precondition)

SequenceDeonticRulePragmatic 3 Reduction of O(Task|Precondition)

4 and P(Task) and O(Task|Precondition)

1. The rule deletes one node of type Task, two nodes of typeParallelGateway and three edges of type SF.

3. dl(T ask) = 0 ≤pl(ParallelWith Phi Dual Rule) = 2

dl(ParallelGateway) = 2 ≤

Table 4 Termination analysis of DeonticBpmnGTS: node types andedge label

Type cl(t) dl(t)

ParallelGateway 0 2

ExclusiveGateway 0 2

InclusiveGateway 0 2

O(Task) 5 5

O(Task|Precondition) 1 3

X(Task) 3 5

X(Task|Precondition) 0 5

P(Task) 3 5

P(Task|Precondition) 0 5

P(Task) and O(Task|Precondition) 3 4

Task 0 0

StartEvent 0 5

EndEvent 0 5

MeasuredValues 0 5

SF 0 0

pl(ParallelWith Phi Dual Rule) = 2dl(SF) = 0 ≤ pl(ParallelWith Phi Dual Rule) = 2

4. cl(O(T ask)) = 5 >

pl(ParallelWith Phi Dual Rule) = 2

Since all deletion layer conditions, and consequently thetermination criteria, are fulfilled, it is proven that Deon-ticBpmnGTS is terminating.

5.6 Discussion

After proving that DeonticBpmnGTS is locally confluent andterminating, further results and conclusions are presented inthis section.

Although the transformation from BPMN to DeonticBPMN is unique, the opposite direction may be ambiguous.Nevertheless, it can be concluded that DeonticBpmnGTS isglobally deterministic. Moreover, every transformation leadsto a semantically equivalent target graph. Thus, the secondhypothesis in Sect. 5.2 can be confirmed. In addition, thefirst hypothesis is proved as shown by the MeasuredValueselement.

5.6.1 Unidirectional uniqueness

The transformation from BPMN to Deontic BPMN is locallyconfluent and terminating, thus the result is unique. However,

123


transforming in the other direction from Deontic BPMN toBPMN might be ambiguous, since the two rules Exclusive-WithPhiDualRule (Fig. 16) and InclusiveWithPhiDualRule(Fig. 20) transform to the same RHS. Thus, whenever a per-missible task is part of the normal flow, the transformation toBPMN can result in either surrounding exclusive or inclusivegateways.

5.6.2 Global determinism

DeonticBpmnGTS is locally nondeterministic since severalrules might be applicable to a given graph, and for a givenrule, several matches might be possible. Nevertheless, Deon-ticBpmnGTS is globally deterministic, since the proven localconfluence and termination imply confluence, which in turnallows to conclude that DeonticBpmnGTS is globally deter-ministic. This means that for each pair of direct graph trans-formations G

∗⇒ H1 and G∗⇒ H2, the resulting graphs H1

and H2 are isomorphic, and the overall result of the graphtransformation is unique (cf. for this paragraph [16, p. 59-62]).

5.6.3 Validation of hypotheses

The first hypothesis states that the transformation fromBPMN to Deontic BPMN leads to equally many or fewergateways and sequence flows. This hypothesis can be val-idated for all transformations of DeonticBpmnGTS. Everytransformation rule in DeonticBpmnGTS comprises a Mea-suredValues element, which counts the number of gatewaysand sequence flows. Since every rule leads to equally manyor fewer gateways and sequence flows, it can be concludedthat the whole transformation also results in equally many orfewer gateways and sequence flows.

The second hypothesis states that the transformation fromBPMN to Deontic BPMN is locally confluent and terminat-ing, resulting in a globally deterministic transformation. Thishypothesis can also be validated for the transformations ofDeonticBpmnGTS. The local confluence of DeonticBpm-nGTS has been proven in Sect. 5.4, followed by the ter-mination proof in Sect. 5.5. Based on these proofs, globaldeterminism can be concluded.

5.6.4 Semantic equivalence

The semantic equivalence of every transformation rule isproven in Sect. 5.3. Although the combination of deonticlogic and BPMN changes the display format, the meaningand behaviour of the flow remain the same.

Furthermore, the cyclomatic complexity according toMcCabe [26], which measures the complexity of a model’sdecision structure, is unaffected, since even if a task is

permissible, the user must decide whether to execute the taskor not.

It should further be noted that in the resulting DeonticBPMN diagrams, all the inclusive and exclusive gatewayscould be replaced by parallel gateways, so that we wouldend up with a single gateway type. Thereby, the decisionsemantics would not be redundant any more, as decisions atthe exits of gateways would be dropped, and also the order ofoutgoing sequence flows of gateways would not be relevantany more.

However, in the case of conditional gateways, the result-ing deontic expressions would be more complex, since itmust also be specified when a task is forbidden. The result-ing deontic expressions are hard to understand for humans,but would simplify the execution by a process engine.

5.6.5 Trusted model transformation

According to Varró et al. (see [42]), the most important cor-rectness properties of a trusted model transformation aretermination, uniqueness (confluence), and behaviour preser-vation. All three properties have been proven for Deon-ticBpmnGTS, so that this transformation can be called atrusted model transformation.

5.6.6 Performance aspects

In each transformation step, either one standard (non-deontic) task is replaced by a deontic task, or a pair ofgateways is removed, or one sequence flow (Phi-path) isremoved, or a combination of these actions is performed(see e.g., ExclusiveWithPhiDualRule). A Phi-path can onlybe removed in between two gateways. Therefore, for eachstep of the graph transformation, non-deontic tasks and pairsof gateways must be checked for the applicability of a rule.Consequently, each step has linear complexity with respectto the number of non-deontic tasks and splitting gateways.

Each step reduces either the number of non-deontic tasks,or the number of splitting gateways, or the number of Phi-paths, or a combination of those; no step increases the numberof non-deontic tasks, or the number of splitting gateways,or the number of Phi-paths. Therefore the number of stepsof a complete transformation is, in the worst case, linearwith respect to the number of tasks, splitting gateways, andPhi-paths.

In summary, simplified, a complete graph transformationhas an order of complexity of O((t, g, φ)2), where t is thenumber of tasks, g is the number of gateways, and φ is thenumber of Phi-paths.

123


6 Conclusion

In this paper, we presented an extension of BPMN with deon-tic logic, called Deontic BPMN, and studied the semantics ofBPMN and Deontic BPMN based on abstract state machines(ASMs). We defined the graph transformation system De-onticBpmnGTS and identified all parallel dependent ruleapplications within the critical pair analysis. Afterwards weshowed, for every critical pair, that it is strictly AC-confluent,so the overall transformation is locally confluent. In order toprove that DeonticBpmnGTS is terminating, we had to flattenthe type graph and the transformation rules. We then showedthat every rule fulfils the deletion layer conditions. Since thegraph transformation is locally confluent and terminating, theGTS is confluent, and every BPMN diagram is transformed toa unique Deontic BPMN diagram. So although DeonticBpm-nGTS is locally nondeterministic, the whole transformationis globally deterministic. Moreover, we used ASMs to provethat the left- and right-hand sides of every transformationrule are semantically equivalent. Thus, we proved that Deon-ticBpmnGTS is a trusted model transformation.

Further goals are (I) to extend the graph transformationfrom BPMN to Deontic BPMN beyond the afore mentionedlimitations, (II) to increase the support for actor modelling inBPMN based on deontic logic and (III) to support other busi-ness process modelling languages by extending the WorkflowPatterns (see [1]) with deontic logic.

Acknowledgments The project Vertical Model Integration is sup-ported within the program “Regionale Wettbewerbsfähigkeit OÖ 2007–2013” by the European Fund for Regional Development as well as theState of Upper Austria.

References

1. van der Aalst, W., ter Hofstede, A., Kiepuszewski, B., Barros, A.:Workflow patterns. Distrib. Parallel Database 14, 5–51 (2003)

2. AGG The AGG 1.5.0 Development Environment–The UserManual. http://user.cs.tu-berlin.de/~gragra/agg, (2006). AccessedMarch 2013

3. AGG.: AGG Homepage. http://user.cs.tu-berlin.de/~gragra/agg(2011). Accessed March 2012

4. Asirelli, P., ter Beek, M.H., Gnesi, S., Fantechi, A.: Deonticlogics for modeling behavioural variability. In: Benavides, D.,Metzger, A., Eisenecker, U.W. (eds.) VaMoS’09, UniversitätDuisburg-Essen, 29, pp. 71–76. ICB Research, Report (2009)

5. Asirelli, P., ter Beek, M.H., Gnesi, S., Fantechi, A.: A deon-tic logical framework for modelling product families. In: Bena-vides, D., Batory, D.S., Grünbacher, P. (eds.) 4th InternationalWorkshop on Variability Modelling of Software-intensive Systems(VaMoS’10), Universität Duisburg-Essen, ICB-Research. Report37, 37–44 (2010)

6. Börger, E., Sörensen, O.: BPMN core modeling concepts:Inheritance-based execution semantics. In: Embley, D., Thalheim,B. (eds.) Handbook of Conceptual Modeling: Theory, Practiceand Research Challenges. Springer, Heidelberg (2011)

7. Börger, E., Stärk, R.: Abstract State Machines–A Method for High-Level System Design and Analysis. Springer Verlag, New York(2003)

8. Börger, E., Thalheim, B.: A method for verifiable and validatablebusiness process modeling. Adv. Softw. Eng. LNCS 5316, 59–115(2008)

9. Broersen, J., Van der Torre, L.: Ten problems of deontic logicand normative reasoning in computer science. European SummerSchool of Logic, Language and Information (ESSLLI), Germany(2010)

10. Broy, M.: Informatik-Eine grundlegende Einführung, vol 2-Systemstrukturen und Theoretische Informatik, 2nd edn. SpringerVerlag, New York (1998)

11. Dijkman, R., Dumas, M., Ouyang, C.: Formal semantics and auto-mated analysis of BPMN process models. Queensland Universityof Technology, Faculty of Science and Technology, Tech. rep., Bris-bane (2007)

12. Eclipse: BPMN Modeler. www.eclipse.org/bpmn (2011).Accessed August 2011

13. Ehrig, H, Pfender, M, Schneider, H.J.: Graph-grammars: an alge-braic approach. In: Proceedings of FOCS 1973, IEEE, pp 167–180(1973)

14. Ehrig, H., Habel, A., Kreowski, H.J., Parisi-Presicce, F.:From graph grammars to high level replacement systems.In: Ehrig, H., Kreowski, H.J., Rozenberg, G., (eds.) GraphGrammars and Their Application to Computer Science, Lec-ture Notes in Computer Science, vol 532. Springer Verlag,New York, pp. 269–291 (1991)

15. Ehrig, H., Habel, A., Kreowski, H.J., Parisi-Presicce, F.: Paral-lelism and concurrency in high-level replacement systems. Math.Struct. Comput. Sci. 1, 361–404 (1991)

16. Ehrig, H., Ehrig, K., Prange, U., Taentzer, G.: Fundamen-tals of Algebraic Graph Transformation. Springer, New York(2006)

17. Ghose, A., Koliadis, G.: Auditing business process compliance. In:Service-Oriented Computing (ICSOC), Lecture Notes in ComputerScience, vol 4749. Springer, Berlin, pp. 169–180 (2007)

18. Goedertier, S., Vanthienen, J.: Designing compliant businessprocesses with obligations and permissions. In: Eder, J., Dustdar,S., (eds.) Business Process Management Workshops, Lecture Notesin Computer Science, vol 4103, Springer, New York, pp. 5–14(2006)

19. Goedertier, S., Vanthienen, J.: Declarative process modeling withbusiness vocabulary and business rules. In: Meersman, R., Tari,Z., Herrero, P. (eds.) On the Move to Meaningful Internet Systems2007: OTM 2007 Workshops, Lecture Notes in Computer Science,vol 4805, Springer, Berlin, pp. 603–612 (2007)

20. Governatori, G., Milosevic, Z.: A formal analysis of a businesscontract language. Intern. J. Co-op. Inform. Syst. (IJCIS) 15(4),659–685 (2006)

21. Gurevich, Y.: Sequential abstract state machines capture sequen-tial algorithms. ACM Trans. Comput. Logic 1(1), 77–111(2000)

22. Horty, J.: Agency and Deontic Logic. Oxford University Press,New York (2001)

23. Lewis, D.: Semantic analyses for dyadic deontic logic. In: Stenlund,S. (ed.) Logical Theory and Semantic Analysis: Essays Dedicatedto Stig Kanger on His Fiftieth Birthday, Reidel Publishing Co,Boston, pp. 1–14 (1974)

24. Löwe, M.: Extended algebraic graph transformation. PhD thesis,TU Berlin (1990)

25. Löwe, M., Beyer, M.: AGG–an implementation of algebraic graphrewriting. In: Rewriting Techniques and Applications, Springer,Berlin (1993)

26. McCabe, T.J.: McCabe Metrics. http://www.mccabe.com/iq_research_metrics.htm (2011). Accessed March 2012

123

http://user.cs.tu-berlin.de/~gragra/agg

http://user.cs.tu-berlin.de/~gragra/agg

www.eclipse.org/bpmn

http://www.mccabe.com/iq_research_metrics.htm

http://www.mccabe.com/iq_research_metrics.htm


27. Mogos, A.H., Urzica, A.: TN4PM: A textual notation for processmodelling. In: Papadopoulos, G., Badica, C. (eds.) IntelligentDistributed Computing III, Studies in Computational Intelligence,vol 237, pp. 263–268. Springer, Berlin (2009)

28. Moody, D.L.: The ”physics” of notations: Towards a scientific basisfor constructing visual notations in software engineering. IEEETrans. Softw. Eng. 35(5), 756–778 (2009)

29. Natschläger, C.: Deontic BPMN. In: Hameurlain, A., Liddle, S.,Schewe, K.D., Zhou, X. (eds.) Database and Expert Systems Appli-cations, Lecture Notes in Computer Science, vol 6861. Springer,Berlin, pp 264–278 (2011)

30. Natschläger, C., Schewe, K.D.: A flattening approach for attributedtype graphs with inheritance in algebraic graph transformation. In:Fish, A., Lambers, L. (eds.) Local Proceedings of GT-VMT (2012),Electronic Communications of the EASST, pp 160–173 (2012)

31. Natschläger, C., Geist, V., Kossak, F., Freudenthaler. B.: Optionalactivities in process flows. In: Rinderle-Ma, S., Weske, M.(eds.) EMISA 2012: Der Mensch im Zentrum der Modellierung,Gesellschaft für Informatik, Bonn, Lecture Notes in Informatics,vol P-206, pp 67–80 (2012)

32. Natschläger-Carpella, C.: Extending BPMN with Deontic Logic.Logos, Berlin (2012)

33. OMG.: Semantics of business vocabulary and business rules(SBVR), v1.0. http://www.omg.org/spec/SBVR/1.0 (2008).Accessed August 2011

34. OMG.: Business process model and notation (BPMN), v2.0. www.omg.org/spec/BPMN/2.0 (2011). Accessed August 2011

35. Padmanabhan, V., Governatori, G., Sadiq, S., Colomb, R., Rotolo,A.: Process modelling: The deontic way. In: Proceedings of the3rd Asia-Pacific Conference on Conceptual Modelling, AustralianComputer Society, Inc., Darlinghurst, Australia, vol 53, pp. 75–84(2006)

36. Raoult, J.C.: On graph rewritings. Theoret. Comput. Sci. 32, 1–24(1984)

37. Åqvist, L.: Deontic Logic, pp. 147–264. Kluwer Academic,Dordrecht (2002)

38. Sadiq, S., Governatori, G., Namiri, K.: Modeling control objectivesfor business process compliance. In: Alonso, G., Dadam, P., Rose-mann, M. (eds.) Business Process Management, Lecture Notes inComputer Science, vol 4714, Springer, Berlin, pp. 149–164 (2007)

39. Taentzer, G.: AGG: A tool environment for algebraic graph trans-formation. In: Applications of Graph Transformations with Indus-trial Relevance (AGTIVE), Lecture Notes in Computer Science,Springer, Berlin, pp. 481–488 (2000)

40. Taentzer, G.: AGG: A graph transformation environment for mod-eling and validation of software. In: Pfaltz, J., Nagl, M., Böhlen, B.(eds.) Applications of Graph Transformations with Industrial Rel-evance (AGTIVE), Lecture Notes in Computer Science, vol 3062,Springer, Berlin, pp. 446–453 (2004)

41. Urzica, A., Tanase, C.: Mapping BPMN to AUML: Towards anautomatic process. In: 17th International Conference of Con-trol Systems and Computer Science, MASTS 2009 Workshop,Germany, pp. 539–547 (2009)

42. Varró, D., Varró-Gyapay, S., Ehrig, H., Prange, U., Taentzer, G.:Termination analysis of model transformations by petri nets. In:Corradini, A., Ehrig, H., Montanari, U., Ribeiro, L., Rozenberg, G.(eds.) Graph Transformations, Lecture Notes in Computer Science,vol 4178, Springer, Berlin, pp. 260–274 (2006)

43. Weigand, H., Verharen, E., Dignum, F.: Interoperable transactionsin business models–a structured approach. In: Constantopoulos,P., Mylopoulos, J., Vassiliou, Y. (eds.) Advanced Information Sys-tems Engineering, Lecture Notes in Computer Science, vol 1080,Springer, Berlin, pp. 193–209 (1996)

44. Wieringa, R., Meyer, J.J.: Applications of deontic logic in com-puter science: A concise overview. In: Deontic Logic in Computer

Science: Normative System Specification, Wiley, New York, pp.17–40 (1993)

45. Wong, P., Gibbons, J.: A process semantics for BPMN. In: Liu, S.,Maibaum, T., Araki, K. (eds.) Formal Methods and Software Engi-neering, Lecture Notes in Computer Science, vol 5256, Springer,Berlin, pp. 355–374 (2008)

Author Biographies

Christine Natschläger is anindustrial researcher at SCCH,working primarily in processontologies and deontic constraintmodelling in process-orientedsystems. She holds an M.Sc. andan M.A. in Computer Sciencefrom the University of AppliedSciences of Upper Austria, andrecently finished her Ph.D. atthe Johannes-Kepler-UniversityLinz. She is involved in theEFRE-funded project “VerticalModel Integration” at SCCH,dealing with deontic rules inprocess-oriented systems.

Felix Kossak is an industrialresearcher at SCCH, workingprimarily in the field of rigorousmethods and process models. Heholds a degree in Software Engi-neering from the University forApplied Sciences of Upper Aus-tria. He is involved in the EFRE-funded project “Vertical ModelIntegration” at SCCH, with hismain interest on rigorous speci-fication and process modelling.

Klaus-Dieter Schewe (born1958) is the scientific direc-tor of the Software CompetenceCenter Hagenberg (SCCH), anon-profit research institutionfunded mainly by the AustrianCOMET programme. He is atthe same time honorary profes-sor at Johannes-Kepler Univer-sity Linz (JKU) and directorof the Christian-Doppler labora-tory for client-centric cloud com-puting (CDCC). Before joiningSCCH he held the position of fullprofessor for Information Sys-tems at Massey University, New

Zealand from 2000 to 2008, and he was the director of the InformationScience Research Centre (ISRC) in New Zealand from 2002 to 2010.At Massey University he received twice an award as DistinguishedResearcher. He holds a PhD in Pure Mathematics from the Universityof Bonn (1985) and a DSc in Theoretical Computer Science from Bran-denburg University of Technology Cottbus (1995).

123

http://www.omg.org/spec/SBVR/1.0

www.omg.org/spec/BPMN/2.0

www.omg.org/spec/BPMN/2.0

Deontic BPMN

Documents

Transcript of Deontic BPMN