Deontic BPMN

Softw Syst Model DOI 10.
1007/s10270-013-0329-5
REGULAR PAPER
Deontic BPMN: a powerful extension of BPMN with a trusted model transformation

Christine Natschlger 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. A drawback of BPMN, however, is that modality is implicitly expressed through the structure of the process ow but not directly within the corresponding activity. Thus, an extension of BPMN with deontic logic has been proposed in previous work, called Deontic BPMN. Deontic BPMN reduces the structural complexity of the process ow and increases the readability by explicitly highlighting obligatory and permissible activities. In addition, an algebraic graph transformation from a subset of BPMN to Deontic BPMN, called Deontic BpmnGTS, has been dened. The goal of the current research is to show that DeonticBpmnGTS is terminating and conuent, resulting in a globally deterministic transformation. Moreover, the semantic equivalence of BPMN models and the respective Deontic BPMN models is proven based on Abstract State Machines (ASMs). Thus, DeonticBpmnGTS can be called a trusted model transformation. Keywords Business process modelling BPMN Deontic logic Graph transformation Deterministic transformation Semantic analysis
1 Introduction The Business Process Model and Notation (BPMN) is a standard maintained by the Object Management Group (OMG) and addresses business analysts and technical developers (see [34]). BPMN was rst published by the Business Process Management Initiative in 2004 and is maintained by the OMG since 2005. The current version, BPMN 2.0, was published in January 2011. BPMN provides a graphical notation for business process modelling with ve basic categories of elements: ow objects, data, connecting objects, swimlanes and artifacts. However, a drawback of BPMN and other business process modelling languages is that modality is only implicitly expressed through the structure of the process ow but not directly within the corresponding activity. All activities are obligatory (mandatory) and whenever something should be permissible (optional), a gateway is used to split the process ow, which offers the possibility to execute the activity or to do nothing. This requires additional modelling elements to split and merge the process ow and a comprehensive understanding of the whole process to identify obligatory, permissible and alternative activities. The separation between decision and execution leads to the following problems:
Communicated by Prof. Robert France. C. Natschlger (B) F. Kossak K.-D. Schewe Software Competence Center Hagenberg, Hagenberg, Austria e-mail: Christine.Natschlaeger@scch.at F. Kossak e-mail: felix.kossak@scch.at K.-D. Schewe Research Institute for Applied Knowledge Processing, Johannes-Kepler-University Linz, Hagenberg, Austria e-mail: kd.schewe@scch.at; kd.schewe@cdcc.faw.jku.at
Limited readability It is difcult to identify obligatory, permissible and alternative activities at rst sight. Complex structure Additional elements are necessary to express modality and complicate the structure of the diagram. Duplication Various agents with different normative concepts for the same activity require a duplication of the activity (e.g., Attend Conference might be obligatory
123
C. Natschlger et al.
for the main author of a paper but permissible for co-authors). Thus, an approach to extend BPMN with deontic logic has been suggested by Natschlger in [29]. Deontic logic is dened as the logical study of the normative use of language and its subject matter is a variety of normative concepts including obligation (O), prohibition (F), permission (P) and commitment (conditional obligation) (compare [37]). These concepts can be linked with the logical connectives for negation (), conjunction (), disjunction () and contravalence ). While monadic deontic logic considers unconditional ( normative concepts, conditional obligations and permissions are modelled by dyadic deontic logic (compare [23]). In addition, deontic logic supports the concept of agency and allows to consider users and roles (see [22]). We call the extension of BPMN with deontic logic Deontic BPMN. Deontic BPMN identies obligatory, alternative and permissible activities and improves the readability of BPMN diagrams by highlighting those types of activities. This further allows to reduce the number of gateways and sequence ows and, thus, the overall structural complexity of the diagram. Deontic BPMN permits a ne-granular capture of rights and obligations. A preliminary survey showed that Deontic BPMN increases the understandability of diagrams (see [29,32]). Problems with the intelligibility of implicit modality have also been observed in an industrial project in which an order execution process (see Sect. 3 for a detailed description) and a business travel process were designed. In these processes, several activities were permissible. The resulting BPMN diagrams were complex, and a distinction of obligatory and permissible activities would have been advantageous. Natschlger also suggested an algebraic graph transformation from BPMN to Deontic BPMN in [29]. The goal of the current research is to prove that the graph transformation is a trusted model transformation. According to Varr et al. [42], the most important correctness properties of a trusted model transformation are termination, uniqueness (conuence), and preservation of semantics. Thus, it will be proven that the transformation from BPMN to Deontic BPMN is terminating and conuent, which implies global determinism, and that the BPMN model and the corresponding Deontic BPMN model are semantically equivalent. The concept of Deontic BPMN and its motivation and relevance have already been introduced in detail in [29] and [32]. A generalisation of the concept of explicitly optional activities, suitable for a large class of process modelling languages, was presented in [31]. This article now further establishes the theoretical foundations for the trustworthiness and usability of 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 transformation is studied in Sect. 2. Section 3 presents the approach to extend BPMN with deontic logic, and Sect. 4 provides an introduction to the semantics of BPMN and Deontic BPMN. The main part of this research then proves that the algebraic graph transformation from BPMN to Deontic BPMN is conuent, 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 concerning deontic logic in process modelling, formal representations of BPMN and graph transformations. 2.1 Deontic logic in process modelling Considering deontic logic, an overview of the main applications in computer science is given by Wieringa and Meyer [44]. In addition, Broersen and Van der Torre identied ten problems of deontic logic and normative reasoning in computer science [9]. One of these problems is how to combine legal ontologies, normative systems, business process notations and compliance checking tools. For this purpose, the authors recommend the Semantics of Business Vocabulary and Business Rules (SBVR) for interaction between norms and business processes. SBVR expresses modality with alethic or deontic logic (see [33]); however, it considers neither the inuence on the process ow (e.g., readability or reduction of structural complexity) nor model transformation. Due to Goedertier and Vanthienen [19], most process modelling languages such as UML Activity Diagrams, BPMN and BPEL are procedural and only implicitly keep track of why design choices have been made. Therefore, this publication presents a vocabulary for declarative process modelling that supports business concerns, execution scenarios, execution mechanisms, modality, rule enforcement and communication. Considering modality, procedural modelling only species what must be the case, while declarative process modelling supports must, ought and can based on deontic logic. In [18], the same authors introduce a language to express temporal rules about obligations and permissions in business interaction, called Penelope. These publications provide a good foundation for the current research. However, the focus of the normative concepts lies more on agents and temporal constraints, whereas optimization capabilities or model transformation are not studied at all. Other publications focus on formal models of normative reasoning and deontic logic in combination with business rules and process modelling. Padmanabhan et al. [35] consider process modelling and deontic logic. They develop a
123
logical framework based on multi-modal logic to capture the normative positions among agents in an organizational setting. Moreover, Governatori and Milosevic present a language for expressing contract conditions in terms of deontic concepts, called Business Contract Language (BCL) [20]. However, these publications do not provide a detailed study of modality, but rather focus on agents and their contractual relationships. Further approaches assure business process compliance based on deontic logic. According to Sadiq et al., process and control modelling are two distinct specications, but convergence is necessary to achieve business practices that are compliant with control objectives [38]. The authors propose a Formal Contract Language (FCL) as a formalism to express normative specications. This language is a combination of defeasible logic and a deontic logic of violations. Ghose and Koliadis [17] present an approach to enhance business process modelling notations with the capability to detect and resolve compliance-related issues. They dene a framework for auditing BPMN process models and suggest that activity, event and decision inclusion may be dened with deontic modalities. Deontic Logic is also used by Asirelli et al. [4] for modelling the behavioural variability in product family descriptions. According to this publication, deontic logic became very popular for formalizing descriptional and behavioural aspects of systems, since it provides a natural way to formalize concepts such as violation, obligation, permission, and prohibition. Furthermore, an approach by Weigand et al. [43] provides a bridge between interoperable transactions and business process models based on deontic logic. Although several approaches use deontic logic in combination with process modelling, none of them studies the inuence on the process ow (e.g., readability and optimization capabilities) or considers a model transformation. Thus, an own approach that extends BPMN with deontic logic has been developed by Natschlger and is presented in [29]. The core concepts of this approach are summarized in Sect. 3.
Mogos and Urzica in [27]. The notation is based on entity blocks. Furthermore, Urzica and Tanase [41] provide a textual notation for BPMN based on the BackusNaur Form (BNF). In this notation, every element species the outgoing ows, but the incoming ows are omitted. Similarly, Deontic BPMN considers the splitting but neglects the merging gateways (see [29]). According to Dijkman et al. [11], dening the formal semantics of BPMN is challenging since BPMN integrates constructs from graph-oriented process denition languages with features for the concurrent execution of multiple instances. Nevertheless, this work introduces the formal semantics of BPMN dened in terms of a mapping to Petri Nets. A formal process semantics for a subset of BPMN is also provided in terms of the process algebra CSP by Wong and Gibbons in [45]. The approach presents a Z model of the BPMN syntax and the behavioural semantics in CSP. A further approach denes the semantics of BPMN in terms of abstract state machines (ASMs) (compare Brger and Srensen [6] and Brger and Thalheim [8]). ASMs will be briey explained in Sect. 4, where we will dene the semantics of both BPMN and Deontic BPMN by means of ASMs, based on the work of Brger and Thalheim [8], in order to prove semantic equivalence. 2.3 Graph transformation This subsection provides an overview of graph transformation with a focus on the algebraic approach. Research on graph transformations started around the 1970s; the main idea is the rule-based modication of a graph, where each application of a rule leads to a graph transformation step. Figure 1 shows the transformation of a graph L (left-hand side) to a graph R (right-hand side) based on a rule r (also called production). Applying the rule r = ( L , R ) means nding a match of L in the source graph and replacing L by R , leading to the target graph of the graph transformation (cf. for this paragraph [16, p. 5f]). Different approaches for graph transformation have been proposed like node label replacement, hyperedge replacement, or the algebraic approach (see [16, p. 10]). DeonticBpmnGTS uses the algebraic approach, which was initiated
2.2 Formal representations of BPMN This subsection presents several approaches that support a formal or textual representation of BPMN. First of all, the BPMN 2.0 Specication (see [34]) itself provides the metamodel of all BPMN elements in the form of an XML Schema. Consequently, BPMN diagrams can be textually represented in XML, which is used by several modelling tools, e.g., the Eclipse BPMN Modeler (see [12]). Another textual notation for three process modelling languages [UML Activity Diagram, BPMN, and Role Activity Diagram (RAD)] is called TN4PM and proposed by
Fig. 1 Rule-based modication of graphs (source: [16, p. 6, modied])
123
by Ehrig, Pfender (both TU Berlin) and Schneider (University of Erlangen) in 1973 (see [13]). The Technical University of Berlin is also playing a central role in further research on graph transformations and the development of a tool for attributed graph grammar systems (AGG). Graph transformations have also been studied by research groups at the Universities of Bremen, Pisa, Rome, Leiden, Paderborn, Porto Allegre and others (compare [16, p. 3]). AGG is used to dene the graph transformation from BPMN to Deontic BPMN. AGG was introduced by Lwe and Beyer [25] and later redesigned and extended by Taentzer [39,40]. In December 2010, AGG was updated to version 2.0. AGG is implemented in Java; it can be extended with new Java classes, and graphs can be attributed by using Java objects and types (see [2], [16, p. 305]). AGG provides a graphical editor and can be used for specifying graph grammars with a start graph or for typed attributed graph transformations like DeonticBpmnGTS. Furthermore, AGG offers analysis techniques as for consistency checking, critical pair analysis, and termination evaluation. More information on AGG can be found on the Homepage [3], in the User Manual [2] and in the algebraic graph transformation book ([16, chapter 15]). The algebraic approach is based on pushout constructions that are used to model the gluing of graphs. The doublepushout approach (DPO) was introduced by Ehrig et al. [13] and uses two gluing constructions as shown in Fig. 2. A rule is given by r = ( L , K , R ), where K is the intersection of L and R and must exist in order to apply the rule. L \ K then describes the part which has to be deleted, whereas R \ K will be created. In addition, for a graph transformation G H , a graph morphism m : L G , called match, must exist such that m is structure-preserving. Rule r and match m have to satisfy a gluing condition, so that no edges are left dangling. r and m satisfy the gluing condition if all identication points (different nodes or edges in L that are mapped to the same element in G by m ) and all dangling points [nodes in L whose images under m are the source or target of an edge in G that does not belong to m ( L )] are also gluing points (nodes and edges in L that are not deleted by r ). The gluing condition would be violated, e.g., if a node is deleted within a rule r and the node has incoming or outgoing edges in G which are not part of L . The resulting graph morphism R H is called the comatch of the graph transformation G H (cf. for this paragraph [16, p. 10ff, 44]).
The single-pushout approach (SPO) was initiated by Raoult [36] and fully worked out by Lwe [24]. The SPO approach differs from the DPO approach concerning the deletion of graph elements, since dangling edges might occur after the deletion and are as well deleted (compare for this paragraph [16, p. 13f]). Since no edges should be automatically and maybe unintentionally removed, the DPO approach is used for DeonticBpmnGTS. In summary, the main steps of an algebraic graph transformation 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 the rule cannot be applied. The resulting graph is called D . 4. Glue R to the graph D at the part of L which still has an image in D . The part of R not coming from L is added disjointly 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 this embedding relation. The resulting graph is called H . For DeonticBpmnGTS, only the rst four steps are relevant, since no embedding relations are dened. The algebraic approach to graph transformation has been generalized to further graph types and high-level structures such as typed graphs, labelled graphs, hypergraphs, attributed graphs, and algebraic specications. This extension to highlevel structures is called high-level replacement (HLR) and was introduced by Ehrig et al. in [14,15] (cf. for this paragraph [16, p. 14ff]). The graph transformation from BPMN to Deontic BPMN is dened as a typed attributed graph transformation system that includes labels.
3 Deontic BPMN This section provides a summary of the main concepts and goals of Deontic BPMN presented by Natschlger [29]. BPMN is extended with deontic logic to improve the readability of the process ow by highlighting obligatory, permissible and alternative activities (see Fig. 3). The highlighting of modality in Deontic BPMN allows to reduce the number of gateways and sequence ows and to identify at rst glance what is obligatory and what is permissible.
(a) Obligation
Fig. 2 Double-pushout approach (source: [16, p. 12]) Fig. 3 Deontic activities
(b) Permission
(c) Alternative
123
Highlighting through colours is discussed in [28]. Moody describes colour as one of the most cognitively effective of all visual variables. He adds, however, that colour should only be used for redundant coding to provide for colour-blind people and print-outs in black-and-white. Consequently, we use colour in combination with the respective modal operators, O, P, and X. First, an empty (or Phi) path is dened. A path is called a Phi-path ( ) whenever a sequence ow directly connects the split with the merge and thereby offers the possibility to do nothing. If a parallel gateway has a Phi-path, then this path provides no additional functionality and can be removed: A = A A B = A B
ing the text with P() for permissible. If there is only one other path beside the Phi-path, then the surrounding gateways can be removed. The semantics of a permissible task is that if a token reaches the task, it can either be executed or not. The BPMN diagram in Fig. 4a can be transformed to Fig. 4b with the same semantics. If the exclusive gateway does not have a Phi-path, then all paths are alternatives. An alternative is not an independent deontic concept but derived from obligation and permission and 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(B)) and are highlighted with a yellow background (X(A) colour (or light grey). The semantics of an alternative task is that it is obligatory to execute the task if no alternative task will be executed and forbidden otherwise. The BPMN diagram in Fig. 5a can be transformed to Fig. 5b with the same semantics. An inclusive gateway (OR), where at least one outgoing B) (A path is taken, can be dened as: A O R B ( A B ). If one of the outgoing paths is a Phi-path, then the structure (A OR B OR ) can be transformed as follows: A B ( A B) ( A ) ( B ) ( A B ) A B ( A B) B ( A B )) P(A P ( A B) If A or B is permitted, then certainly at least either A or B 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, so from P ( A B ) follows P ( A) P ( B ). If no outgoing path is a Phi-path, then the structure (A OR B OR C) can be transformed as follows:
A Phi-path within a parallel split is executed in parallel with all other paths and does not extend the functionality. Thus, this construct is dispensable and it would be best practice to not use it at all. However, since this construct is not forbidden by the BPMN specication, it is also considered in Deontic BPMN. If the parallel gateway addresses only one other path beside the Phi-path, then removing the Phi-path also allows to remove the surrounding gateways. All other paths that follow a parallel gateway are obligatory. In Deontic BPMN, an obligatory activity is highlighted with a red background colour (or dark grey) and by surrounding the text with O() for obligatory. In contrast to parallel gateways, exclusive and inclusive gateways dene conditions on the outgoing sequence ows except for the default ow (compare [34]). The deontic classication depends on the type of the decision. In the context of Deontic BPMN, unconditional gateways denote all those gateways where the user can freely decide. These decisions are also called User Choice and subsequent tasks might be permissible or alternative. In contrast, conditional gateways denote all those gateways where the outgoing path is selected based on a state, data or rule. In this case, the user is not free to decide and a subsequent task is obligatory. In BPMN, a permissible activity as well as an alternative can be expressed with unconditional gateways (exclusive, inclusive, complex or event-based) or events (boundary events). If an outgoing path is a Phi-path, then all other paths are called permissible. Otherwise, if no outgoing path is a Phi-path, then, in most cases, the outgoing paths are alternatives. An exclusive gateway (XOR) offers a gating mechanism where only one of the outgoing paths can be taken. If one of the outgoing paths is a Phi-path, then all other paths are permissible: = P ( A) A B = P ( A) P (B) A
(a) BPMN
(b) Deontic BPMN
Fig. 4 Exclusive gateway with Phi
(a) BPMN
(b) Deontic BPMN
In Deontic BPMN, a permissible activity is highlighted with a green background colour (or middle grey) and by surround-
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 denition requires for the rst time the concept of preconditions dened within dyadic deontic logic (see [23]). The notation is O(A|B) or P(A|B) with A being obligatory/permissible under the precondition that B has been executed (several preconditions can be concatenated with or ). Another example for the necessity of preconditions is the case of nested gateways as shown in Fig. 6a. In this example, task B is permissible but can only be executed if task A was executed before. Therefore, task A is specied as precondition in Fig. 6b. Preconditions are also necessary for situations where a user is not free to select the outgoing path. This is the case if conditions or events are involved. Fig. 7a shows an exclusive gateway with the decision Has Errors? and two outgoing ows. The rst ow represents Yes and leads to a task Correct Errors. The second ow represents No and nothing ( ) has to be done. However, the task Correct Errors is not permissible, but obligatory under the precondition that errors exist and forbidden otherwise: [O(CorrectErrors| HasErrors) F(CorrectErrors|HasErrors)]. Furthermore, we specify that 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 classications in case of unstructured diagrams. For example, in Fig. 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 be removed if preconditions are used (X(A|B) P(A|B)). We now present an example which is taken from a reallife industrial project in which we were involved. The process describes a typical order execution as it can be found in many companies (with certain variations). The BPMN diagram of the order execution process is shown in Fig. 9. The process comprises the following tasks: create request (CR), modify
(a) BPMN
Fig. 8 Multiple deontic classication
(b) Deontic BPMN
(a) BPMN
Fig. 6 Nested gateways
(b) Deontic BPMN
(a) BPMN
Fig. 7 Conditional gateway
(b) Deontic BPMN
request (MR), delete request (DR), reject request (RJR), approve order (AO), create/modify appointment (CMA), remove appointment (RA), approve appointment (AA), reject appointment (RJA), order in progress (OP), execute order (EO), create report (RC), modify report (RM), formally correct report (RFC), formally incorrect report (RFI), and close order (CO). These tasks are specied within three lanes that describe the roles Assistant, Consultant, and Approver. Essentially, the order execution process denes that a request can be created by any of the three roles. If an assistant or consultant creates the request, then this request can be modied by the consultant and is afterwards either deleted or sent to the approver for approval. However, if the approver creates a request, then this request is automatically approved. The approved order is then sent to the consultant who may dene an appointment or specify that the order is in progress. Subsequently, every order must be executed by the consultant. The consultant can then create and modify a report which might be sent to the approver for approval. Finally, the consultant closes the order. Considering the order execution process, all splitting gateways provide user choices and do not depend on any states or data. The entire diagram consists of 26 gateways and 64 sequence ows and is quite complex. Thus, it is difcult to identify the permissible and obligatory tasks. The corresponding Deontic BPMN diagram is shown in Fig. 10. The Deontic BPMN diagram highlights that it is obligatory to create a request and to approve, execute and close the order. In addition, it denes that the two tasks delete request (DR) and reject request (RJR) are alternatives to the main ow. All other tasks are permissible. It is further necessary to deontically classify two sequence ows, since a report may only be modied or sent for approval, if it has been created before. This classication, however, highlights that the two tasks formally correct report (RFC) and formally incorrect report (RFI) are alternatives in a permissible structure. The Deontic BPMN diagram provides two advantages with respect to understandability. First, the resulting Deontic BPMN diagram only consists of 18 gateways and 49 sequence ows. So it was possible to remove 8 gateways and 15 sequence ows and thereby reduce the structural complexity of the process ow. Secondly, obligatory and permissible tasks can be distinguished at rst sight based
123
Fig. 9 Order execution process: BPMN diagram. Explanation: CR create request, MR modify request, DR delete request, RJR reject request, AO approve order, CMA create/modify appointment, RA remove appointment, AA approve appointment, RJA reject appointment,
OP order in progress, EO execute order, RC create report, RM modify report, RFC formally correct report, RFI formally incorrect report, CO close order
on the colored highlighting. It is still necessary to decide whether a permissible task is executed or not but instead of describing this decision through separate gateways and alternative paths, the decision is described within the corresponding task. The advantages are accompanied by additional deontic constructs requiring a basic understanding by the user. However, the complex constructs (e.g., preconditions) are only relevant for a more detailed understanding of the process. The reduction in structural complexity comes at the cost of an increased complexity of the language, i.e., of BPMN: one further attribute with three (or possibly four) possible values has been added [i.e., O, P, and X, and possibly also F (forbidden)]. We expect that the average possible reduction in structural complexity will outweigh this increased language complexity, but only an investigation of a wide range of different, real-life examples (e.g., with respect to Halstead complexity) will tell. Moreover, the benets also depend on the particular use of a diagram, i.e., how much the deontic aspects are relevant for a particular user.
4 The Semantics of BPMN and Deontic BPMN Deontic BPMN is intended to aid the user in designing and understanding business processes while preserving the design capacities of BPMN. This will become clear when we introduce a graph transformation system from (a subset of) standard BPMN to (a subset of) Deontic BPMN further below. We cannot repeat the semantics of BPMN in this place and refer the reader to the standard [34] (see also [6] for a formalisation of BPMN 2.0 beta using abstract state machines; our own formalisation is based on this work by Brger and Srensen). We will explain the differences between (a subset of) Deontic BPMN and BPMN according to the standard so that we will subsequently be able to show that the semantics of BPMN diagrams (according to the OMG standard) can be preserved when being transformed to Deontic BPMN diagrams. We will make use of abstract state machines (ASMs; see e.g., Gurevich [21] and Brger and Strk [7]) to model semantics. We trust that ASMs are easily readable, but we will
123
Fig. 10 Order execution process: deontic BPMN diagram
briey explain a few constructs to clarify their meaning for those 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 abstract pseudo-code, though based on a precise but minimal mathematical theory of algorithms, but also as Virtual Machine programs working on abstract data (compare [7, p. 2, 5]). The main constructs we will use are rules and derived functions. A rule describes a state transition of the machine (automaton). A state is determined by particular values of arbitrary data structures. Those data structures are described by functions, e.g., tokenType. If a function is given specic parameters, we speak of a locatione.g., token Type(t), where t is a particular token. If the value of at least one location is changed (updated ), the state of the machine changes. Such updates are described by rules, of which several may execute in parallel. Whether a rule res in a particular state or not is determined by a guard or condition in the form of an if then statement. This guard will typically query the value of one or more functions. If the query is more complex, or we want to leave it abstract for the time being, we can use derived functions, which combine the values of other functions through an arbitrary statement. An example
is controlCondition(flowNode), which determines whether there are enough tokens at the incoming sequence ows of a given ow node for it to re. Derived functions have no effect on the state of the machine. For clarity, we will mark rule denitions and derived functions with the keywords rule and derived, respectively. Monitored functions are controlled by the environment; they can, e.g., be used to model user input. Nesting of expressions will be expressed by indentation only. Renement of abstract rules will often be indicated by the keyword where, after which subrules and derived functions previously left abstract will be dened. A choose statement models an arbitrary choice of an element of a given set. We trust that all other keywords and constructs are easy to grasp. 4.2 BPMN and Deontic BPMN serve different abstraction layers Deontic BPMN is intended for a different level of abstraction than (standard) BPMN is. In standard BPMN, the level of abstraction is such that the resulting models can be executed by a business process
123
engine. This entails that models are supposed to be deterministic in every detail. Deontic BPMN, however, takes the viewpoint of the (human) user, who is not seen as a deterministically operating machine, but as an agent who is capable of autonomously taking decisions and also authorised to take decisions. Consequently, Deontic BPMN leaves choices open to the 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. In BPMN, every task must be seen as mandatory (corresponding to an obligatory task (or O(task )) in Deontic BPMN) as soon as the ring (or activation) conditions are met, e.g., by a token on the incoming sequence ow. To be able to compare standard BPMN and Deontic BPMN, we have to transform Deontic BPMN models to the level of abstraction relevant for a process engine. In particular, in order to establish a relation between a permitted task and a standard BPMN task, we translate a permitted task to a conditionally obligatory task, where the condition (subsequently called precondition) is determined by user input - or, in terms of the ASM formalism, through a monitored function. Note that this does not mean that permission and conditional obligation would be equivalent in our deontic logic (they are not). Permission is a concept of the level of abstraction of Deontic BPMN, while conditional obligation here is the translation to the level of abstraction of BPMN, where user choice as such cannot be modelled (except in ad hoc sub-processes, which we do not consider here). As also a conditionally obligatory task is a deontic task (and not an element of the BPMN standard), this translation of a permitted task is performed within the Deontic BPMN framework. However, with this translation we can make the step down to the abstraction level of BPMN. The precondition UserChoice will then have to be matched with the ring condition of the respective outgoing sequence ow of a splitting gateway which leads to the task in question, as we will show in more detail further below. It should also be noted that due to the different layers addressed, Deontic BPMN models may show a certain redundancy where user-centric and process-engine-centric concepts overlap. For instance, the information that a particular task is obligatory may be derived from the context of the task alone in certain (but not in all) cases. We assert that this redundancy is very helpful from the users point of view. 4.3 Criteria for comparing standard BPMN and Deontic BPMN semantically In order to show that a Deontic BPMN diagram generated by transformation of a standard BPMN diagram has the same
semantics as the latter, we assert that there is a bijective mapping between tasks before the transformation and deontic tasks after the transformation. Then we have to show that 1. Whenever a particular task would have been performed in the original diagram, also the corresponding deontic task is performed after transformation; and 2. A partial order with respect to the performance of tasks in time is preserved (i.e., where relevant, tasks are performed in the same order one after the other). When we look at particular graph transformation rules further below, it will sufce to consider only the subdiagrams affected by particular graph transformation steps. A nal note may be due on a certain issue of performance time. We will introduce graph transformation rules which dispose of gateways. One might assume that with two ow nodes less (a splitting and a merging gateway), the switching time of those gateways would now be missing and thus the overall time consumption of the subdiagram in question would be sped up. One can construct examples where different speeds in different branches may lead to different decisions later on and thus change the overall behaviour of the diagram at runtime. However, relevant for this is only the time consumption of the whole subdiagram that is being transformed. First of all, the necessary decision is not eliminatedit is just transferred from the splitting gateway to the deontic task; secondly, in our considerations presented here, we only deal with user choices, waiting for which will not change in either way; and thirdly, any potentially remaining variation in time due to this will be extremely small compared with the performance of tasks, and with variations in performances of tasks. Therefore we think that this potential problem can be safely ignored. To put it in ASM language, such a (sub)graph transformation constitutes an n:m-renement which affects only intermediate steps of threads of the machine in between two points of interest for synchronisation. 4.4 General semantic differences between standard BPMN and Deontic BPMN Brger and Thalheim model the semantics of a BPMN ow node as follows [8]: rule WorkflowTransition(flowNode) = if eventCondition(flowNode) and controlCondition(flowNode) and dataCondition(flowNode) and resourceCondition(flowNode) then EventOperation(flowNode) ControlOperation(flowNode) DataOperation(flowNode) ResourceOperation(flowNode)
123
That is, in order for a ow node (e.g., a task or a gateway) to re and thereby to do something, it may have to wait for an event to happen, for a token to arrive (controlCondition), for a data-based condition to be true or for data to be available in the rst place, and/or for resources to be available. Then it may itself re events, pass on or newly create tokens, manipulate data, and occupy and/or release resources. (Note that we use the convention to capitalise the operations, which refer to (abstract) subrules, while we write the conditions(abstract) derived functionswith small letters.) For the purposes of this paper, we can summarise the operations by a single PerformanceOperation. Furthermore, we only need to distinguish between two kinds of conditions, namely controlFlowCondition (consisting of controlCondition and possibly eventCondition) and performanceCondition (consisting of dataCondition, resourceCondition, and possibly eventCondition). This leads to the following, simplied rule:
rule WorkflowTransition(flowNode) = if controlFlowCondition(flowNode) and performanceCondition(flowNode) then PerformanceOperation(flowNode)
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) then if choiceCondition(flowNode) then if performanceCondition(flowNode) then PerformanceOperation(flowNode) else skip else ControlFlowOperation(flowNode)
In the case of certain deontic tasks, however, we have to provide for the possibility that they are not supposed to perform the PerformanceOperation under certain conditions, but still pass tokens on along their outgoing sequence ows. This is the case with conditional taskse.g., permissible tasks (which we translate to conditionally obligatory tasks): if such a task gets a token (i.e., controlCondition is fullled), and the other conditions are not relevant, the user may still decide whether the task shall be performed or not; yet if it is not performed, it still has to pass on a token towards other activities or towards a gateway waiting for it. Consequently we have to introduce a new choiceCondition to model this behaviour:
rule WorkflowTransitionDeontic(flowNode) = if choiceCondition(flowNode) then if controlFlowCondition(flowNode) and performanceCondition(flowNode) then PerformanceOperation(flowNode) else if controlFlowCondition(flowNode) then ControlFlowOperation(flowNode)
where we think that the actual behaviour can be identied a bit easier. (For instance, we can now easily see that the users choice is only relevant and asked for once the controlFlowCondition has become true.) Note that it is still obvious that we can model standard BPMN ow nodes with WorkflowTransitionDeontic by setting choiceCondition := true for all ow nodes. We will use this last formulation in our following considerations. If choiceCondition is true for all standard but not for all deontic tasks, we will not be able to achieve the same semantics unless we can match choiceCondition with some other feature in standard BPMN. To this end, we cannot simply compare a standard task with its corresponding deontic task, but we have to look at whole subdiagrams. We assert that a deontic task where choiceCondition is relevant, in particular a permissible task, will always be in a place where the corresponding standard task is downstream of an exclusive or inclusive gateway (the graph transformation rules which we introduce in the next section full this assertion). Each outgoing sequence ow of such a gateway (except from a default sequence ow) is associated with a condition which determines whether, upon ring, this sequence ow will get a token or not. We will show that we can match this condition with the choiceCondition of the respective deontic task. To this end, we will rst take a look at the semantics of gateways. 4.5 The semantics of gateways We will only skirt the semantics of gateways as much as we need it for the purposes of this paper. The semantics of gateways 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 both splitting and merging, but with the exception of complex gateways, which we do not treat here, a gateway which is both splitting and merging can always be simulated by separate splitting and merging gateways. That way the semantics is easier to understand. We start with splitting gateways:
rule WorkflowTransitionSplit(gateway) = choose incomingSequenceFlow in
where ControlFlowOperation simply passes a token on to outgoing sequence ows (while ControlOperation may in fact be more complex). In the above formulation, it can be easily seen that WorkflowTransitionDeontic is a conservative extension of WorkflowTransition (the original code is
123
incomingSequenceFlows(gateway) do // assert: there is only one element in // incomingSequenceFlows(gateway), thus // incomingSequenceFlow is chosen // deterministically WorkflowTransitionDeontic(gateway) where derived controlFlowCondition(gateway) = tokens(incomingSequenceFlow) != {} rule PerformanceOperation(gateway) = let chosenSequenceFlows = selectOutgoingSequenceFlows( gateway) in choose token in tokens(incomingSequenceFlow) do Consume(incomingSequenceFlow, token) forall outgoingSequenceFlow in chosenSequenceFlows(gateway) do Produce(outgoingSequenceFlow, NewToken(tokenType(token))
where derived chosenSequenceFlows(gateway) = { sequenceFlow in outgoingSequenceFlows( gateway) | firingCondition( sequenceFlow) = true }
i.e., we choose all outgoing sequence ows where firingCondition = true. The monitored function firingCondition is exactly the above-mentioned condition which we will be able to match with the choiceCondition of deontic tasks. We will not go into the details of merging gateways here. For our purposes, it sufces to know that, with the bracketing gateways assumption made for this paper, they merge the different paths created by splitting gateways into a single path, and that they somehow have to wait for all the tokens created by the latter before they can re. 4.6 The semantics of tasks For the semantics of standard BPMN tasks (with our present simplications), we can use WorkflowTransitionDeontic with the constraints that 1. choiceCondition is always true, 2. there is exactly one incoming and one outgoing sequence ow, and 3. when something has been performed, a token is passed on to the outgoing sequence ow. For Deontic BPMN (the subset introduced here), we distinguish ve different types of tasks: obligatory tasks, permissible tasks, alternative tasks, conditionally obligatory tasks with the possible preconditions PreviousTask NOT(AlternativeTask(s)) UserChoice, and permissible and conditionally obligatory tasks with precondition NOT(AlternativeTask(s)). Obligatory tasks have exactly the same semantics as standard BPMN tasks: they only pass a token on when they are performed. Permissible tasks can be seen as conditionally obligatory tasks with precondition UserChoice.
Based on the where statement, we say that WorkflowConditionDeontic is rened by specifying controlFlowCondition as well as Performance Operation (in particular, ControlOperation in the original denition of WorkflowTransition). Parallel, exclusive and inclusive gateways only differ in the way they choose outgoing sequence ows for passing on tokens, i.e., in the denition 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) with firingCondition(sequenceFlow) = true }
where we take firingCondition to be a monitored function (as we do not treat data-based conditions in this paper). A set with only one element is returned.
rule WorkflowTransitionInclusiveSplit( gateway) = WorkflowTransitionSplit( gateway )
123
Alternative tasks can also be seen as conditionally obligatory tasks but with precondition NOT(AlternativeTask(s)). Thus, all that remains is to look at conditionally obligatory tasks, which we have to do separately for the three different preconditions, and permissible and conditionally obligatory tasks. 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 ow of such a task is also some kind of task. Then if the previous task was indeed performed, also the task in question will perform once it receives a token. In that case the behaviour is the same as that of a standard task. If the task in questions receives a token, but the previous task (which passed this token on) was not performed, then that previous task must also be a conditionally obligatory task (as neither a standard task nor an (unconditionally) obligatory task can behave in this way). Now we can assume that a chain of conditionally obligatory tasks with precondition PreviousTask has a beginning, i.e., there exists a conditionally obligatory task with another precondition in front of such a chain. So the task in question will behave like this starting task: once it gets a token, it will perform if the starting task did and not perform if the starting task did not. (We dene that whenever a task is not explicitly permitted, it is forbidden.) We can assert that both possible candidates for such a starting task (with preconditions UserChoice or NOT (AlternativeTask(s))) are only used if the corresponding standard task came after a splitting gateway (as we will see later). Thus, the task in question will lie on a (not further branched) path in between two gateways and will perform or not perform like the other tasks on that pathwhich is exactly the behaviour we expect and which is achieved in standard BPMN by means of tokens alone. 4.8 Conditionally obligatory tasks with precondition NOT(AlternativeTask(s))
4.9 Conditionally obligatory tasks with precondition UserChoice We assert that such a task is only used in the place of a standard BPMN task which comes after a splitting exclusive or inclusive gateway, because these are the only places where a choice is possible in a standard BPMN model. Then we can match firingCondition of the outgoing sequence ow of the splitting gateway which leads to the task in question with choiceCondition of this task. A permissible task (i.e., a conditionally obligatory task with precondition UserChoice) may make the enclosing gateways redundant (in particular, when an empty path ( ) would have been the only alternative). In this case choiceCondition(task) will replace firingCondition(gateway). The eliminated empty path will be simulated by setting choiceCondition to false, whereby the task will not be performed but a token will still be passed on. If the enclosing gateways are retained (because there are other alternatives), then choiceCondition will be formally redundant, because the task will get a token if and only if choiceCondition = true (by way of the coupling of firingCondition(gateway) and choiceCondition(task)). 4.10 Permissible and conditionally obligatory tasks with precondition NOT(AlternativeTask(s)) Depending on the runtime evaluation of the precondition, such a task behaves either like a conditionally obligatory task with precondition NOT(AlternativeTask(s)), if the precondition evaluates to true, or else like a permissible task (i.e., a conditionally obligatory task with precondition UserChoice). Both of these tasks have been treated before; it remains to show, for each situation where such a task can be employed, that in both cases the initial behaviour is retained. We will do this in Sect. 5.
5 Graph transformation from BPMN to Deontic BPMN We assert that such tasks are only used in between exclusive gateways, and that those gateways are retained, for otherwise there would not exist any alternative tasks (this assertion holds for the graph transformation rules introduced below). Then choiceCondition will be true if the task gets a token, i.e., if firingCondition of the respective outgoing sequence ow of the splitting gateway is true, and choiceCondition will be false if firingCondition is false. So the value of choiceCondition turns out to be redundant, and such a task behaves exactly like a standard BPMN task. This section describes an algebraic graph transformation from BPMN to Deontic BPMN called DeonticBpmnGTS. After an introduction to the foundations of graph transformation, DeonticBpmnGTS is presented including the type graph and several transformation rules. The source and target graph of every transformation rule are proven to be semantically equivalent. Furthermore, it is shown that DeonticBpmnGTS is strictly AC-conuent and terminating, which implies that the transformation is globally deterministic. This section concludes with a discussion of the results.
123
5.1 Foundations of graph transformation A basic overview of graph transformation together with related work is provided in Sect. 2. In the following, the most important denitions concerning algebraic graph transformation such as graph, type graph, and conuence are presented. Further denitions can be found in Ehrig et al. [16]. The rst denition species a graph consisting of nodes and directed edges. Denition 1 [Directed] Graph (source: [16, p. 21]): A [directed ] graph G = (V , E , s , t ) consists of a set V of nodes (also called vertices), a set E of edges, and two functions s , t : E V , the source and target functions. The concept of graph morphism then species how two graphs are related by dening a mapping between the nodes and edges of the graphs (see [16, p. 22]). Further important denitions are those of a type graph and a typed graph. A type graph species node and edge types and the relationships between them. A specic graph with nodes and edges based on types is called a typed graph. Denition 2 Type Graph and Typed Graph (Source: [16, p. 22f]): A type graph is a distinguished graph T G = (VT G , E T G , sT G , tT G ). VT G and E T G are called the vertex and the edge type alphabets, respectively. A tuple (G, type) of a graph G together with a graph morphism t ype : G T G is then called a typed graph. An important extension of typed graphs are attributed typed graphs over an attributed type graph (ATG). This extension requires the denition of an E-graph, which has two kinds of nodes [graph (VG ) and data nodes (VD )] and three kinds of edges [usual graph edges ( E G ) and special edges for node ( E N A ) and edge attribution ( E E A )]. An attributed graph is then dened to be an E-graph combined with an algebra over a data signature DS I G with attribute value sorts S D S D (cf. for this paragraph [16, p. 171ff]). Since DeonticBpmnGTS denes abstract nodes and inheritance relations within the type graph, the denition of an attributed type graph with inheritance (ATGI) is necessary. Denition 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 graph AT G = (T G , Z ) [...], where T G is an E-graph T G = (T G VG , T G VD , T G E G , T G E N A , T G E E A , (sourcei , targeti )i {G , N A , E A} ) with T G VG = S D and nal DSIGalgebra Z ; an inheritance graph I = ( I V , I E , s , t ) with
I V = T G VG ; and a set A I V , called the abstract nodes. For each node n I V , the inheritance clan is dened by clan I (n ) = {n I V |pathn n in I } I V with n clan I (n ). So an attributed type graph (ATG) consists of a type graph TG that is an E-graph and a nal DSIG-algebra Z . A DSIGalgebra Z is called nal, if it is the unique (up to isomorphism) nal algebra in the category Alg () (cf. [16, p. 357]). An ATGI further comprises an inheritance graph I and a set of abstract nodes A. Furthermore, the inheritance clan of a node represents all its subnodes (compare [16, p. 260]). An ATGI can be attened to an ATG in order to benet from the denitions of typed attributed graph transformation (compare [16, p. 261f]). The equivalence of typed attributed graph grammars with and without inheritance is shown by Ehrig et al. in [16, p. 278f]. According to Ehrig et al. (see [16, p. 23f]), a further concept of algebraic graph transformation is that of a labelled graph, which consists of a label alphabet L with node labels L V and edge labels L E ( L = ( L V , L E )). A labelled graph corresponds to the type graph as follows (see [16, p. 24]): VT G = L V , ET G = L V L E L V , sT G : E T G VT G : (a , x , b) a , tT G : E T G VT G : (a , x , b) b.
Since every node type must have a distinct label, the node label corresponds to the node type. However, one edge label can be used for different combinations of nodes whereas an edge type is restricted to the dened source and target node. For example, in DeonticBpmnGTS, one edge label with the name SF is reused for all combinations of nodes. A further important denition for graph transformation is that of a graph rule (also called graph production). The application of a rule to a graph is called a direct graph transformation. Denition 4 Graph production (source: [16, p. 37]): A (typed) graph production p = ( L K R ) consists of (typed) graphs, L , K , and R , called the left-hand side, gluing graph, and the right-hand side, respectively, and two injective (typed) graph morphisms l and r . A sequence G 0 G 1 G n of direct graph transformations is called a graph transformation (G 0 G n ) and a graph transformation system (GTS) consists of a set of graph rules. A GTS can be nondeterministic if, for a given rule, 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]).
l r
123
The overall goal is to prove global determinism of DeonticBpmnGTS, even if there is local nondeterminism. Global determinism means that the target graphs H1 and H2 of every terminating graph transformation G H1 and G H2 are isomorphic (cf. [16, p. 59]); so regardless of the chosen match or the order of the rule application, the resulting graph is always the same. According to Ehrig et al. [16, p. 59], every conuent GTS is globally deterministic. A GTS is conuent if for all graph transformations G H1 and G H2 , there exists a graph X with graph transformations H1 X and H2 X . Hence, conuence implies the uniqueness of X (cf. [10, p. 198f]). In order to prove conuence, it is either necessary to show that each rule pair is parallel independent for all possible matches or, in case of parallel dependent rules, that the GTS is terminating and locally conuent. A GTS is locally conuent if all its critical pairs (parallel dependent and minimal) are strictly conuent (see denition in Sect. 5.4) (cf. for this paragraph [16, p. 59ff, 144]). Tackling the question whether two rules can be applied in arbitrary order requires the denition of parallel and sequential independence. Two rules are parallel independent if all nodes and edges in the intersection of the two matches are gluing items, i.e., are not deleted by the rule, for both transformations. This means that no element of graph G that is part of both matches must be deleted by any of the two rules. Two consecutively applied rules are sequentially independent if all nodes and edges in the intersection of the comatch R1 H1 and the second rules match are gluing items with respect to both transformations (cf. for this paragraph [16, p. 44f, 47ff]). So no element that is part of the comatch R1 H1 of the rst rule and match L 2 G of the second rule must be deleted by one of the two rules. The dependency between parallel and sequential independence is dened by the local ChurchRosser theorem.
So the local ChurchRosser theorem states that two parallel independent graph transformations can be applied in arbitrary order. If each pair of rules is parallel independent for all possible matches, then this implies that the GTS is conuent. However, for all parallel dependent rules, a critical pair can be identied, and local conuence has to be proven. A GTS is locally conuent if each pair of direct graph transformations G H1 and G H2 is strictly conuent (see Fig. 11) (cf. for this paragraph [16, p. 59f, 144]). Critical pairs, strict (local) conuence and termination will be explained in more detail in the corresponding Sect. 5.4 and 5.5. 5.2 DeonticBpmnGTS: an overview The following sections describe a graph transformation from BPMN to Deontic BPMN. The transformation is called DeonticBpmnGTS and denes an attributed type graph with inheritance. The overall graph transformation system consists of 18 rules with application conditions distributed across 4 layers. However, in this paper, an extract is presented, which comprises 11 rules dened within the third layer. Nevertheless, conuence, termination and semantic equivalence were proven for all rules. Two hypotheses are posed for DeonticBpmnGTS and will be discussed in Sect. 5.6.3: 1. The highlighting of modality with deontic logic reduces the structural complexity of the process ow. The number of gateways and/or sequence ows in a Deontic BPMN diagram is equal to or smaller than the original BPMN diagram. 2. The transformation from BPMN to Deontic BPMN is locally conuent and terminating, resulting in a globally deterministic transformation. In addition, the source and target graphs are semantically equivalent. In DeonticBpmnGTS, specic BPMN models are taken as input and transformed to Deontic BPMN models, thereby
Theorem 1 Local ChurchRosser theorem for GTSs (source: [16, p. 50f]): Given two parallel independent direct (typed) graph p1 ,m 1 p2 ,m 2 transformations G H1 and G H2 , there is a (typed) graph G together with direct (typed) graph transformations H1
p1 ,m 1 p2 ,m 2
that G H1 2 G and G H2 1 G are sequentially independent. Given two sequentially independent direct (typed) graph transformations G H1 2 G , there are a (typed) graph H2 and direct (typed) graph transformations G H2 1 G such that G H1 p2 ,m 2 and G H2 are parallel independent:
p2 ,m 2 p1 ,m p1 ,m 1 p1 ,m 1 p2 ,m
p2 ,m
G and H2
p2 ,m 2
p1 ,m 1
G such
p1 ,m
Fig. 11 Conuence and local conuence (source: [16, p. 59])
123
highlighting the deontic concepts. The GTS comprises the basic transformations described in Sect. 3, but is limited to: Structured diagrams The gateways are dened in a bracket structure. Basic set of BPMN elements DeonticBpmnGTS supports sequence ows, parallel, exclusive and inclusive gateways with user choice, start/end events and tasks. All supported node and edge types are shown in Sect. 5.3. One task per path DeonticBpmnGTS is limited to one task per path following a splitting gateway and is also prohibiting most types of nested gateways. Not allowed are also mixed gateways as well as several uncontrolled or conditional sequence ows. In most cases, these constructs can synonymically be expressed with an additional gateway except in some rare cases in which, for example, uncontrolled incoming sequence ows generate new process instances. In addition, different markers used for tasks or events are not relevant for the current deontic classication and thus not distinguished. 5.3 Type graph and rules This section presents the type graph of DeonticBpmnGTS with all node and edge types as well as the 11 transformation rules of the third layer. Afterwards an example demonstrates a transformation from BPMN to Deontic BPMN. First, the node types and one edge label of the graph transformation system are dened. DeonticBpmnGTS provides four node types for gateways (Gateway, Parallel-
Gateway, InclusiveGateway and ExclusiveGateway), two for BPMN tasks (BpmnTask and Task), eight for Deontic BPMN tasks (DeonticTask, O(Task), X(Task), P(Task), O(Task|Precondition), X(Task|Precondition), P(Task|Precondition) and P(Task) and O(Task|Precondition)) and three for events (Event, StartEvent and EndEvent). One further node type is called MeasuredValues and used to store meta-information like the number of gateways and sequence ows in order to study the reduction of structural complexity. This node is not relevant for the deontic transformation and, thus, excluded from the critical pair analysis. In addition, DeonticBpmnGTS provides one edge label called SF for sequence ows representing several edge types. In a second step, the type graph is specied, which denes the generalization and dependency relationships between the node types. For DeonticBpmnGTS, an attributed type graph with inheritance is dened. Figure 12 shows this type graph in a screen shot from the graph transformation tool AGG, which was used in our research. The basic element of the type graph is Node with the derived types Gateway, DeonticTask, BpmnTask and Event. The type graph of DeonticBpmnGTS includes the following information:
Abstract and concrete node types Five node types (Node, Event, BpmnTask, DeonticTask, and Gateway) are abstract and are highlighted by curly brackets and italic font. All other elements represent concrete node types. Attributes Some node types dene attributes such as preconditions or the number of gateways and sequence ows. These attributes may change during a transformation step.
Fig. 12 Type graph of DeonticBpmnGTS
123
Generalization relationships The ATGI denition permits generalization relationships between different node types and multiple inheritance as used for node type P(Task) and O(Task|Precondition). The attributes specied within a superclass are inherited by all subclasses. Dependency relationships with multiplicity The source, target, and cardinality of a sequence ow is specied by dependency relationships. Although all edges are labelled as SF, every dependency relationship represents a distinct edge type. In the following, the 11 transformation rules of the third layer together with their application conditions are introduced. The rules cover parallel, exclusive and inclusive gateways with user choice. The rules for exclusive and inclusive gateways are very similar and only slightly different from those of parallel gateways. Sequences and iterations are addressed within the other layers. Layering offers a kind of ordering, since all rules of one layer are applied as long as possible before the next layer is considered. A set of rules R is dened to be layered, if for each rule r R , there is a rule layer rl (r ) with 0 rl (r ) k0 , where k0 + 1 is the number of layers (compare [16, p. 250]). Note that layer 0 is called the rst layer, layer 1 the second layer and so on. The application of rules is restricted by application conditions (AC), which can either be positive or negative. A negative application condition (NAC) of the form NAC(x ) with graph morphism x : L X is satised by a graph morphism m : L G if there does not exist an injective graph morphism p : X G with p x = m . This means that if there is an occurrence of the left-hand side L in G , then the NAC is satised if X is not also part of that match in G . A positive application condition (PAC) is the counterpart to a NAC and satised if such an injective graph morphism exists. ACs are further allowed to contain L only partially (s : L Sub L and x : L Sub X ). In the following rule descriptions, the NACs and PACs do not include the MeasuredValues element (cf. for this paragraph [16, p. 64, 67ff, 309]). 5.3.1 ParallelWithPhiDualRule This rule replaces every occurrence of a parallel gateway addressing one task and one Phi-path with an obligatory task as shown in Fig. 13. The NAC forbids that the splitting gateway references further nodes and thereby avoids dangling edges. If further nodes exist, then the rule ParallelRule may be used. The intersection K of the left- and right-hand sides ( K = LHS RHS) consists for the given rule of the two Nodes and the element MeasuredValues. In general, it can be said that all elements with a preceding number on the RHS are dened 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 element MeasuredValues shows that the transformation leads to a reduction of two gateways and three sequence ows. Since a task on the only non-empty path will have to be performed under all circumstances once the splitting gateway res, the semantics does not change if a standard task is replaced by an obligatory task. Furthermore, the empty path has no additional meaning and can be removed. 5.3.2 ParallelRule The rule ParallelRule can be applied several times to classify an arbitrary number of tasks being referenced by a parallel gateway as obligatory as shown in Fig. 14. The PAC species that at least one further node is referenced. This application condition assures that the rst gateway addresses not only one further Phi-path (ParallelWithPhiDualRule should be used) and that it is not a merging gateway with a subsequent task followed by a splitting gateway. According to the MeasuredValues element, this rule does not reduce the number of gateways and sequence ows. Every task in between two parallel gateways must be performed once the splitting gateway res. Consequently, the semantics do not change if a task between two parallel gateways is replaced by (i.e., classied as) an obligatory task. 5.3.3 ParallelRuleFinish After all tasks have been classied as obligatory, the rule ParallelRuleFinish removes a possible Phi-path. This rule is applied if at least two tasks are classied as obligatory and no further BPMN task exists as dened by the NAC. The
123
5.3.4 ExclusiveWithPhiDualRule The rule ExclusiveWithPhiDualRule takes an exclusive gateway with a task and a Phi-path and transforms it to a permissible task (see Fig. 16). The NAC forbids further alternative nodes and thereby avoids dangling edges. The rule ExclusiveWithPhiRule may be used in case of further tasks. The transformation leads to a reduction of two gateways and three sequence ows. In order to check that the semantics are preserved by this rule, as explained before, we have to transform the new permissible task into a conditionally obligatory task with precondition UserChoice before we can compare the diagrams before and after the transformation. The precondition UserChoice is reected in the boolean function choiceCondition(task) in our ASM model. Let sf7 and sf9 be the sequence ows marked in Fig. 16 with 7: SF and 9: SF, respectively, and let task3 be the task marked with 3: Task and pTask the resulting conditionally obligatory task. We distinguish two cases. Case 1: In the standard model (LHS of the transformation rule), selectOutgoingSequenceFlows(split Gateway) yields sf7 at runtime (i.e., sf7 was chosen by the user, i.e., firingCondition(sf7) = true). Then task3 received a token, thus it is performed (as choiceCondition(flow Node) is true for all nondeontic 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, selectOutgoingSequenceFlows(splitGateway) yields sf9. In this case task3 is not performed, and the merging gateway receives a token via sf9.
(a) LHS
(b) RHS
(c) PAC: FurtherNode

Fig. 14 ParallelRule
(a) LHS
(b) RHS
(c) NAC: NoFurtherTask

Fig. 15 ParallelRuleFinish
(a) LHS
transformation leads to a reduction of one sequence ow (Fig. 15). A Phi-path within a parallel split does not extend the functionality and is executed in parallel with all other paths. Therefore, this construct is dispensable and it would be best practice to not use it at all. However, since this construct is not forbidden by the BPMN standard, a transformation rule is necessary.
(b) RHS
(c) NAC: NoFurtherNode

Fig. 16 ExclusiveWithPhiDualRule
123
After the graph transformation, choiceCondition (pTask) will be false, therefore pTask will not be performed (like task3), yet will pass on a token towards the merging gateway. Thus, the behaviour of the subdiagram is again the same.
pTask performs whenever task2 performs and that token ow is unaffected. 5.3.6 ExclusiveWithPhiRuleFinish The rule ExclusiveWithPhiRuleFinish is applied after the rule ExclusiveWithPhiRule and removes the Phi-path as shown in Fig. 18. The left-hand side of the rule requires two permissible tasks as well as a Phi-path, and the NAC forbids further not transformed tasks. The transformation leads to a reduction of one sequence ow. Again, in order to compare the semantics before and after the graph transformation, we treat pTask3 and pTask4 as conditionally obligatory tasks with precondition UserChoice. We distinguish two cases: Case 1: Some P(Task) is chosen. This can be done before and 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 are performed, but a token is passed on directly to the merging gateway. In the diagram after the graph transformation, the user may choose any of the remaining pathse.g., the path to pTask3and then they can choose not to perform pTask3. Then no task is performed, but still a token is passed on to the merging gateway. Thus, it is possible to achieve the same behaviour. More formally, the same behaviour is achieved if
5.3.5 ExclusiveWithPhiRule The rule ExclusiveWithPhiRule transforms a task of an exclusive gateway with a Phi-path into a permissible task (see Fig. 17). The rule can be applied several times to classify an arbitrary number of tasks. The PAC species that a further node exists; otherwise the rule ExclusiveWithPhiDualRule should be used. This rule does not reduce the number of gateways and sequence ows. Here the conditions associated with the outgoing sequence ows of the splitting gateway are retained. We name sequence ows and tasks as with the previous rule. pTask could now be treated as an ordinary obligatory task (with choiceCondition(pTask) = true in all cases), as it will only get a token when its incoming sequence ow sf gets a token, based on the value of firingCondition(sf). However, in order to be consistent with our treatment of the previous rule, we prefer to assume that choiceCondition(pTask) = firingCondition(sf) = firingCondition(sf5) (even if it constitutes a redundancy). In any case, it is easy to see that
(a) LHS
(a) LHS
(b) RHS
(b) RHS
(c) PAC: FurtherNodea

Fig. 17 ExclusiveWithPhiRule

Fig. 18 ExclusiveWithPhiRuleFinish
123
(a) LHS
(a) LHS
(b) RHS
(b) RHS
(c) NAC: NoMixedStartGateway (c) NAC: NoFurtherNode

Fig. 20 InclusiveWithPhiDualRule
(d) NAC: NoMixedEndGateway
(e) NAC: NoPhiPath
(f) PAC: FurtherNode

Fig. 19 ExclusiveWithoutPhiRule
gateway is a splitting gateway. The transformation does not reduce the number of gateways and sequence ows as shown by the MeasuredValues element. When we considered alternative tasks, and subsequently conditionally obligatory tasks with precondition NOT (AlternativeTask(s)), which can be thought to represent the former, we have seen that they actually behave like unconditional obligatory tasks under the given conditions, and thus just like standard BPMN tasks. Thus, the semantics is unaffected by this transformation step. 5.3.8 InclusiveWithPhiDualRule
(firingCondition(sf) = true) -> ((firingCondition(sf6) = true) (choiceCondition(pTask3) = or ((firingCondition(sf8) = true) (choiceCondition(pTask4) =
and false)) and false))
(where primes refer to elements after graph transformation; additional P(Task)s could be added by disjunction accordingly). The relevant settings of firingCondition and choiceCondition have to be performed by the transformation rule. 5.3.7 ExclusiveWithoutPhiRule The rule ExclusiveWithoutPhiRule classies the task of an exclusive gateway without a Phi-path as an alternative task (see Fig. 19). This rule can be applied several times to transform an arbitrary number of tasks. Three NACs dene that neither the rst nor the second gateway has multiple incoming and outgoing sequence ows and that no Phi-path exists. A further PAC species that at least one other node exists in parallel to the task in question, which ensures that the rst
This rule transforms an inclusive gateway with one task and a Phi-path into a permissible task as shown in Fig. 20. The NAC forbids further nodes and thereby avoids dangling edges. In addition, the element MeasuredValues highlights that the transformation leads to a reduction of two gateways and three sequence ows. For comparing the semantics before and after the transformation, we consider three cases according to possible user choices: Case 1: At the splitting inclusive gateway, they can choose the path with the task, but not the Phi-path. This option is fully retained after graph transformation by choosing to perform the resulting P(Task), i.e., by setting choiceCondition(pTask) = firingCondition(sf7). Case 2: Users can choose the Phi-path, but not the path with the task. Also this option is fully retained after graph transformation by choosing not to perform P(Task), i.e., choiceCondition(pTask) = false. Case 3: Users can choose both paths. However, this has the same effect as choosing only the path with the task: the task will be performed, and the merging gateway will be able
123
to re afterwards without delay, as the additional token on the Phi-path will already be there when the task has been completed. So this case is actually also covered by Case 1. So the behaviour remains the same in each possible case before and after the graph transformation.
5.3.10 InclusiveWithPhiRuleFinish The rule InclusiveWithPhiRuleFinish is applied after the rule InclusiveWithPhiRule and removes the Phi-path as shown in Fig. 22. The rule requires at least two permissible tasks addressed by inclusive gateways as well as a Phi-path. The NAC forbids further not transformed tasks. The transformation leads to a reduction of one sequence ow. As with InclusiveWithPhiDualRule, we can distinguish three cases, depending on possible user choices before the graph transformation: Case 1: At the splitting gateway, users choose at least one path with a task, but not the Phi-path (which is eliminated by the rule). This choice is not affected by the elimination of the Phi-path. Case 2: Users choose the Phi-path, but no other path. After graph transformation, users can choose any of the remaining paths and then choose not to perform the P(Task) there, to the same effect. Case 3: Users choose the Phi-path plus at least one other path. In this case, the Phi-path is redundant, as already explained for InclusiveWithPhiDualRule. So again, the behaviour of the subdiagram is not changed in any possible case. 5.3.11 InclusiveWithoutPhiRule This rule classies a task of an inclusive gateway without a Phi-path as a permissible task that is obligatory under the
5.3.9 InclusiveWithPhiRule The rule InclusiveWithPhiRule converts a task of an inclusive gateway with a Phi-path into a permissible task (see Fig. 21). The rule can be applied several times to classify an arbitrary number of tasks. The PAC species that a further node exists, since otherwise the rule InclusiveWithPhiDualRule should be used to remove the gateways. This rule does not reduce the number of gateways and sequence ows. As the inclusive gateways as well as all paths are retained by this rule, control ow is unaffected. In order for each P(Task) pTask which is created by the rule to perform whenever the corresponding standard BPMN task would have performed, we just have to make sure in the course of graph transformation that choiceCondition(pTask) = firingCondition (sf6). Again, the information that the task is permissible is actually redundant, but useful for the user.
(a) LHS (a) LHS
(b) RHS
(b) RHS
(c) PAC:FurtherNode
Fig. 21 InclusiveWithPhiRule

Fig. 22 InclusiveWithPhiRuleFinish
123
(a) LHS
(b) RHS
(c) NAC: NoMixedStartGateway
(d) NAC: NoMixedEndGateway
(e) NAC: NoPhiPath
Case 1: Before the graph transformation, the users would have chosen only one path. Then the task on this path will become an obligatory task, as the precondition NOT(AlternativeTask(s)) is true. We have already shown above that an obligatory task behaves just like a standard BPMN task. Case 2: The users want to choose more than one path. Then each task on a chosen path becomes a permissible task, as the precondition for becoming an obligatory task is false. As shown before, a permissible task pTask can be thought of as a conditionally obligatory task with the precondition UserChoice. By setting choiceCondition(pTask) = firingCondition(sf) (sf being the outgoing sequence ow of the splitting gateway which leads to pTask ) in the course of the transformation, pTask again becomes an obligatory task (if sf is a chosen path and thus firingCondition(sf) = true), and so it also behaves like a standard BPMN task. So also this rule does not change the behaviour of the subdiagram in question.
5.3.12 Example
(f) PAC: FurtherNode
Fig. 23 InclusiveWithoutPhiRule
precondition that no alternative task will be executed (see Fig. 23). In fact, the precondition should address all tasks individually, e.g.,: P(A) O(A|B C). However, since the tasks in DeonticBpmnGTS are currently not named, the precondition NOT(AlternativeTask(s)) is used instead. This rule can be applied several times to transform an arbitrary number of tasks. Three NACs dene that neither the rst nor the second gateway has multiple incoming and outgoing sequence ows and that no Phi-path exists. A further PAC species that at least one other node exists. The transformation does not reduce the number of gateways and sequence ows. As the inclusive gateways are retained by this rule, also the behaviour is fully retained thereby. As we will see, the changes made by this rule are only of optical relevance for the user. We can distinguish two cases:
After dening the rules, a typed graph can be created for a specic BPMN model and is then transformed to Deontic BPMN. This is demonstrated by an example whose BPMN model is shown in Fig. 24. The gateways are displayed in their image view. According to the MeasuredValues element, the BPMN model consists of eight gateways and twenty-nine sequence ows. The graph transformation in AGG can be executed non-deterministically (NT), by rule layers (LT), rule priorities (PT) or rule sequences (ST). Every transformation in DeonticBpmnGTS is executed based on the rule layers. After starting the transformation, every rule of the rst layer may be executed followed by the rules of the second layer. Afterwards the third layer is taken into account and the following rules are applied: ParallelRule (2x), ExclusiveWithPhiDualRule (1x), ExclusiveWithoutPhiRule (2x), InclusiveWithPhiRule (4x) and InclusiveWithPhiRuleFinish (1x). Finally, the rules of the fourth layer are executed. The order 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 application conditions. The resulting Deontic BPMN model is shown in Fig. 25. The transformation leads to a reduction of two gateways and ve sequence ows. In addition, the obligatory, alternative and permissible tasks can be distinguished on rst sight based on their prex and background colour.
CPA is supported by the tool AGG, which identies all conicting rule applications by computing the minimal critical graphs to which rules can be applied in a conicting way (compare [16, p. 314]). CPA distinguishes two types of critical pairs (compare [2, p. 54]): Conicts in case of parallel dependent rule applications and Dependencies in case of sequential dependent rule applications. For proving local conuence of DeonticBpmnGTS, only parallel dependent rule applications must be considered. AGG computed 45 conicts which are shown in Table 1. The layers are taken into account and CPs are only calculated for rules of the same layer. If the rules are dened on different layers, then the cell in the table is left empty. Otherwise the number of critical pairs is displayed. The CPA computed 13 duplicate critical pairs. Furthermore, the 3 critical pairs identied for the rule combinations WithPhiRule/WithPhiDualRule are invalid, since the corresponding rst rule denes a PAC FurtherNode, which is not considered by the AGG tool. The remaining 29 critical pairs have been studied in detail. As can be seen in Table 1, the number and alignment of the conicts identied for the three different gateways in the third layer are similar. Especially the conicts for exclusive and inclusive gateways are almost the same and only slightly different from those of parallel gateways, which do not distinguish transformation rules with and without Phipaths. In addition, the graphs of all CPs identied within the third layer are isomorphic. Thus, strict AC-conuence can be concluded based on the isomorphism as shown for the critical pair ParallelWithPhiDualRule/ParallelWithPhiDualRule. In the following, graph G denotes the original graph, graphs H1 and H2 show the resulting graphs after an application of the two parallel dependent rules, and graph X presents the nal graph that is achieved through extended transformations to prove conuence. 5.4.1 ParallelWithPhiDualRule/ ParallelWithPhiDualRule One critical pair has been identied by AGG for the parallel application of the rule ParallelWithPhiDualRule as shown in
5.4 Strict AC-conuence This section starts with the foundations and main denitions of strict AC-conuence. Afterwards the critical pair analysis (CPA) of DeonticBpmnGTS is presented, followed by the proof that DeonticBpmnGTS is locally conuent. Proving conuence requires in a rst step the identication of all critical pairs. A critical pair is dened as a pair of direct graph transformations that are parallel dependent and minimal. Two direct graph transformations are parallel dependent if they are not parallel independent as dened in Sect. 5.1. In addition, a pair of graph transformations is minimal if each item in K has a preimage in the left-hand side L of one of the two graph transformations (cf. for this paragraph [16, p. 47f, 60]). If no critical pairs are identied, then the GTS is already locally conuent. Otherwise strict AC-conuence must be proven for each critical pair. A critical pair P1 K P2 is conuent if a graph K together with graph transformations P1 K and P2 K exists. Furthermore, the conuence is called strict if the largest common subgraph N of K , P1 and P2 is preserved by P1 K and P2 K (cf. for this paragraph [16, p. 60f]). In addition, the application conditions must be considered. This means that if every NAC is satised by the two given graph transformations, then it must not be possible to violate a NAC in the further transformations P1 K and P2 K (strict NAC-conuence). Otherwise, a graph transformation to K might exist but cannot be applied due to a NAC. Strict AC-conuence is an extension of strict NAC-conuence and requires that all ACs, both NACs and PACs, are satised during further graph transformations. According to Ehrig et al. [16, p. 314], critical pairs for rules with NACs (but not for PACs) are already implemented in AGG.
123
Deontic BPMN: a powerful extension of BPMN with a trusted model transformation Table 1 CPA: parallel dependent rule applications 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 1. SeveralPhiReductionRule 2. IterationRepeatUntilRule 3. SequenceRuleBase 4. SequenceRuleExtended 5. SequenceRuleFinish 6. ParallelWithPhiDualRule 7. ParallelRule 8. ParallelRuleFinish 9. ExclusiveWithPhiDualRule 10. ExclusiveWithPhiRule 11. ExclusiveWithPhiRuleFinish 12. ExclusiveWithoutPhiRule 13. InclusiveWithPhiDualRule 14. InclusiveWithPhiRule 15. InclusiveWithPhiRuleFinish 16. InclusiveWithoutPhiRule 17. SequenceBpmnRulePragmatic 18. SequenceDeonticRulePragmatic 2 0 0 0 2 1 1 0 0 3 0 0 2 1 4 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 7 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 7 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 7 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1 5 6 7 8 9 10 11 12 13 14 15 16 17 18
isomorphic graphs is also strict, since the largest subgraph N (marked by a dashed line) is equal to the resulting graphs ( N = H1 = H2 = X ). Thus, the CP is strictly AC-conuent.
Fig. 26 CP:ParallelWithPhiDualRule/ParallelWithPhiDualRule
Fig. 26. Both rule applications replace the gateways and the task with a deontically classied task prohibiting a further application of the corresponding other rule. Since the resulting graphs ( H1 , H2 ) are isomorphic, no further transformation is necessary to prove conuence and no application conditions may be violated (see Fig. 27). Furthermore, every parallel application of rules resulting in
Fig. 27 Strict AC-conuence of CP shown in Fig. 26
123
However, non-isomorphic CPs emerged in the other layers and strict AC-conuence had to be proven as shown for the critical pair SequenceRuleBase/SequenceRuleExtended. The proof for the other non-isomorphic critical pairs is likewise. 5.4.2 SequenceRuleBase/SequenceRuleExtended The graph transformation rules SequenceRuleBase (see Fig. 28) and SequenceRuleExtended (see Fig. 29) are parallel dependent as shown by the CP in Fig. 30. SequenceRuleBase transforms 2:Task resulting in graph H1 , whereas SequenceRuleExtended deontically classies 1:Task leading to graph H2 . The resulting graphs H1 and H2 are different and strict AC-conuence must be proven. After the application of SequenceRuleBase leading to graph H1 , the respective other rule SequenceRuleExtended can be applied resulting in graph X as shown in Fig. 31. However, an extended transformation of graph H2 is more complex, since SequenceRuleBase cannot be applied anymore. Instead, the rule SequenceRuleExtended is used for the transformation H2 X . Thus, the transformation is conuent. The transformation is also ACconuent due to the fact that neither SequenceRuleBase nor SequenceRuleExtended species any application conditions. Moreover, the largest subgraph N of G , H1 and H2 consists of the rst task and the node and is also preserved by graph X . Local Conuence: Since it can be proven that all CPs are strictly AC-conuent, it can be concluded that DeonticBpmnGTS is locally conuent.
Fig. 30 CP: SequenceRuleBase/SequenceRuleExtended
5.5 Termination In order to show conuence and consequently global determinism of a GTS, it is necessary to prove termination. After an introduction to the foundations of termination and a description of the inheritance problem, this section proves termination 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 innite sequence of graph transformations (cf. [16, p. 59f]). In order to prove termination of DeonticBpmnGTS, the theorem for termination of layered typed graph grammars with layer conditions is required. The layers are divided into deletion and nondeletion layers. Every deletion layer deletes at least one element, whereas nondeletion layers do not delete anything, but provide NACs to prohibit an innite 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 , G 0 ) with injective matches terminates, provided that it is layered in the following sense: 1. P is layered, i.e., for each p P there is a production layer pl ( p ) with 0 pl ( p ) k0 ( pl ( p ), k0 N), where k0 + 1 is the number of layers of GG, and each typed graph production p P has a set NAC p of negative application conditions NAC(n : L N ) [...]; the latter is abbreviated as n NAC p . 2. The type set TYPE of GG is given by all graph nodes and edges of the type graph TG, i.e., T Y P E = ET G VTG 3. GG is nite 4. For each type t TYPE there is a creation layer cl (t ) N and a deletion layer dl (t ) N, and each production layer k is either a deletion layer or a nondeletion layer, satisfying the following layer conditions for all p Pk : [see Table 2] A layered graph grammar denes, for each rule r , a rule layer rl (r ) = k and for each type t , a creation layer cl (t ) and a deletion layer dl (t ) (compare [2, p. 79]). The creation and deletion layers are calculated as follows:
(a) LHS
Fig. 28 Rule: SequenceRuleBase
(b) RHS
(a) LHS
(b) RHS
Fig. 29 Rule: SequenceRuleExtended
123
Fig. 31 Strict AC-conuence of CP shown in Fig. 30
Table 2 Termination: layer conditions (source: [16, p. 64], slightly modied) Deletion layer conditions 1. p deletes at least one item 2. 0 cl (t ) dl (t ) k0 + 1 for all t TYPE 3. p deletes an item of type t dl (t ) pl ( p ) 4. p creates an item of type t cl (t ) > pl ( p ) Nondeletion layer conditions 1. p is nondeleting, i.e., K = L such that p is given by r : L R injective 2. p has n N AC p with n : L N , and there is an injective n : N R with n n = r 3. x L with t ype(x ) = t cl (t ) pl ( p ) 4. p creates an item of type t cl (t ) > pl ( p )
Denition 5 Layer assignments (source: [16, p. 253]): cl (t ) = if t T0 then 0 else max { pl ( p )| pcr eatest } + 1, dl (t ) = if tisdeletedbysomep then min { pl ( p )| pdeletest }elsek0 + 1. The termination of GTSs is in general undecidable, but termination can be concluded if suitable termination criteria as dened in the termination theorem are met (cf. [16, p. 318]). The tool AGG provides a termination analysis for layered graph transformation systems. The rule layers for the termination proof can either be set by the user or generated by AGG. All creation and deletion layers are then calculated by AGG so that the layer conditions are fullled if possible (cf. for this paragraph [16, p. 318]). However, the termination analysis is restricted to GTSs without abstract nodes and inheritance relationships in the type graph. According to Varr et al. [42], the termination criteria can be used for GTSs with node type inheritance if the inheritance graph is attened. Since AGG does not support a attening of the type graph, Natschlger and Schewe suggested a attening algorithm in [30]. The attening algorithm considers abstract nodes, inheritance relationships, multiple inheritance, attributes and application conditions. Based on the attening algorithm, a concrete prototype was developed and used to atten the type graph of DeonticBpmnGTS, resulting in 822 rules and 10.170 ACs. For example, the attening of
the rule ParallelWithPhiDualRule leads to 169 concrete rules in which the two abstract nodes Node are replaced in any combination. In the attened type graph of DeonticBpmnGTS, all abstract nodes and inheritance relationships were removed and attributes were copied. After attening DeonticBpmnGTS, the termination analysis (TA) is executed manually and by the tool AGG. In a rst step, the rule layers are calculated as shown in Table 3. The layers are based on the ordering described in Sect. 5.2 and rened to full the termination criteria. The rules SequenceBpmnRulePragmatic and SequenceDeonticRulePragmatic span two layers (34), since the attened rules dened within layer 3 delete a node of type O(Task|Precondition) whereas the attened rules in layer 4 delete a node of the subtype P(Task) and O(Task|Precondi tion). The third column of Table 3 species the reduction type, since each rule in a deletion layer must decrease the number of graph items in general or of one special type. Afterwards the creation and deletion layers for all node types and for the edge label are calculated as presented in Table 4. The adapted second deletion layer condition (0 cl (l ) dl (l ) k0 + 1) is fullled by all node types and the edge label as can be seen in the table. The remaining deletion layer conditions (1, 34) are proven for each rule. As an example, we show the termination proof for the rule ParallelWithPhiDualRule:
123
Table 3 Termination analysis of DeonticBpmnGTS: rule layers
Rule SeveralPhiReductionRule IterationRepeatUntilRule SequenceRuleBase SequenceRuleExtended SequenceRuleFinish ParallelWithPhiDualRule ParallelRule ParallelRuleFinish ExclusiveWithPhiDualRule ExclusiveWithPhiRule ExclusiveWithPhiRuleFinish ExclusiveWithoutPhiRule InclusiveWithPhiDualRule InclusiveWithPhiRule InclusiveWithPhiRuleFinish InclusiveWithoutPhiRule SequenceBpmnRulePragmatic SequenceDeonticRulePragmatic
Layer 0 0 0 0 1 2 2 2 2 2 2 2 2 2 2 2 3 4 3 4
Reduction General Reduction Reduction of Tasks Reduction of Tasks Reduction of Tasks Reduction of Tasks General Reduction Reduction of Tasks General Reduction General Reduction Reduction of Tasks General Reduction Reduction of Tasks General Reduction Reduction of Tasks General Reduction Reduction of Tasks Reduction of O(Task|Precondition) and P(Task) and O(Task|Precondition) Reduction of O(Task|Precondition) and P(Task) and O(Task|Precondition)
1. The rule deletes one node of type Task, two nodes of type ParallelGateway and three edges of type SF. 3. dl (T ask ) = 0 pl ( ParallelW ith Phi Dual Rule) = 2 dl ( ParallelGateway ) = 2
pl ( ParallelW ith Phi Dual Rule) = 2 dl ( S F ) = 0 pl ( ParallelW ith Phi Dual Rule) = 2 4. cl ( O (T ask )) = 5 > pl ( ParallelW ith Phi Dual Rule) = 2 Since all deletion layer conditions, and consequently the termination criteria, are fullled, it is proven that DeonticBpmnGTS is terminating. 5.6 Discussion After proving that DeonticBpmnGTS is locally conuent and terminating, further results and conclusions are presented in this section. Although the transformation from BPMN to Deontic BPMN is unique, the opposite direction may be ambiguous. Nevertheless, it can be concluded that DeonticBpmnGTS is globally deterministic. Moreover, every transformation leads to a semantically equivalent target graph. Thus, the second hypothesis in Sect. 5.2 can be conrmed. In addition, the rst hypothesis is proved as shown by the MeasuredValues element. 5.6.1 Unidirectional uniqueness The transformation from BPMN to Deontic BPMN is locally conuent and terminating, thus the result is unique. However,
Table 4 Termination analysis of DeonticBpmnGTS: node types and edge label Type ParallelGateway ExclusiveGateway InclusiveGateway O(Task) O(Task|Precondition) X(Task) X(Task|Precondition) P(Task) P(Task|Precondition) P(Task) and O(Task|Precondition) Task StartEvent EndEvent MeasuredValues SF cl(t) 0 0 0 5 1 3 0 3 0 3 0 0 0 0 0 dl(t) 2 2 2 5 3 5 5 5 5 4 0 5 5 5 0
123
transforming in the other direction from Deontic BPMN to BPMN might be ambiguous, since the two rules ExclusiveWithPhiDualRule (Fig. 16) and InclusiveWithPhiDualRule (Fig. 20) transform to the same RHS. Thus, whenever a permissible task is part of the normal ow, the transformation to BPMN can result in either surrounding exclusive or inclusive gateways. 5.6.2 Global determinism DeonticBpmnGTS is locally nondeterministic since several rules might be applicable to a given graph, and for a given rule, several matches might be possible. Nevertheless, DeonticBpmnGTS is globally deterministic, since the proven local conuence and termination imply conuence, which in turn allows to conclude that DeonticBpmnGTS is globally deterministic. 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 graph transformation is unique (cf. for this paragraph [16, p. 5962]). 5.6.3 Validation of hypotheses The rst hypothesis states that the transformation from BPMN to Deontic BPMN leads to equally many or fewer gateways and sequence ows. This hypothesis can be validated for all transformations of DeonticBpmnGTS. Every transformation rule in DeonticBpmnGTS comprises a MeasuredValues element, which counts the number of gateways and sequence ows. Since every rule leads to equally many or fewer gateways and sequence ows, it can be concluded that the whole transformation also results in equally many or fewer gateways and sequence ows. The second hypothesis states that the transformation from BPMN to Deontic BPMN is locally conuent and terminating, resulting in a globally deterministic transformation. This hypothesis can also be validated for the transformations of DeonticBpmnGTS. The local conuence of DeonticBpmnGTS has been proven in Sect. 5.4, followed by the termination proof in Sect. 5.5. Based on these proofs, global determinism can be concluded. 5.6.4 Semantic equivalence The semantic equivalence of every transformation rule is proven in Sect. 5.3. Although the combination of deontic logic and BPMN changes the display format, the meaning and behaviour of the ow remain the same. Furthermore, the cyclomatic complexity according to McCabe [26], which measures the complexity of a models decision structure, is unaffected, since even if a task is
permissible, the user must decide whether to execute the task or not. It should further be noted that in the resulting Deontic BPMN diagrams, all the inclusive and exclusive gateways could be replaced by parallel gateways, so that we would end up with a single gateway type. Thereby, the decision semantics would not be redundant any more, as decisions at the exits of gateways would be dropped, and also the order of outgoing sequence ows of gateways would not be relevant any more. However, in the case of conditional gateways, the resulting deontic expressions would be more complex, since it must also be specied when a task is forbidden. The resulting 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 correctness properties of a trusted model transformation are termination, uniqueness (conuence), and behaviour preservation. All three properties have been proven for DeonticBpmnGTS, so that this transformation can be called a trusted model transformation.
5.6.6 Performance aspects In each transformation step, either one standard (nondeontic) task is replaced by a deontic task, or a pair of gateways is removed, or one sequence ow (Phi-path) is removed, or a combination of these actions is performed (see e.g., ExclusiveWithPhiDualRule). A Phi-path can only be removed in between two gateways. Therefore, for each step of the graph transformation, non-deontic tasks and pairs of gateways must be checked for the applicability of a rule. Consequently, each step has linear complexity with respect to 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 Phipaths, or a combination of those; no step increases the number of non-deontic tasks, or the number of splitting gateways, or the number of Phi-paths. Therefore the number of steps of a complete transformation is, in the worst case, linear with respect to the number of tasks, splitting gateways, and Phi-paths. In summary, simplied, a complete graph transformation has an order of complexity of O((t , g , )2 ), where t is the number of tasks, g is the number of gateways, and is the number of Phi-paths.
123
6 Conclusion In this paper, we presented an extension of BPMN with deontic logic, called Deontic BPMN, and studied the semantics of BPMN and Deontic BPMN based on abstract state machines (ASMs). We dened the graph transformation system DeonticBpmnGTS and identied all parallel dependent rule applications within the critical pair analysis. Afterwards we showed, for every critical pair, that it is strictly AC-conuent, so the overall transformation is locally conuent. In order to prove that DeonticBpmnGTS is terminating, we had to atten the type graph and the transformation rules. We then showed that every rule fulls the deletion layer conditions. Since the graph transformation is locally conuent and terminating, the GTS is conuent, and every BPMN diagram is transformed to a unique Deontic BPMN diagram. So although DeonticBpmnGTS is locally nondeterministic, the whole transformation is globally deterministic. Moreover, we used ASMs to prove that the left- and right-hand sides of every transformation rule are semantically equivalent. Thus, we proved that DeonticBpmnGTS is a trusted model transformation. Further goals are (I) to extend the graph transformation from BPMN to Deontic BPMN beyond the afore mentioned limitations, (II) to increase the support for actor modelling in BPMN based on deontic logic and (III) to support other business process modelling languages by extending the Workow Patterns (see [1]) with deontic logic.
Acknowledgments The project Vertical Model Integration is supported within the program Regionale Wettbewerbsfhigkeit O 2007 2013 by the European Fund for Regional Development as well as the State of Upper Austria.
References
1. van der Aalst, W., ter Hofstede, A., Kiepuszewski, B., Barros, A.: Workow patterns. Distrib. Parallel Database 14, 551 (2003) 2. AGG The AGG 1.5.0 Development EnvironmentThe User Manual. http://user.cs.tu-berlin.de/~gragra/agg, (2006). Accessed March 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.: Deontic logics for modeling behavioural variability. In: Benavides, D., Metzger, A., Eisenecker, U.W. (eds.) VaMoS09, Universitt Duisburg-Essen, 29, pp. 7176. ICB Research, Report (2009) 5. Asirelli, P., ter Beek, M.H., Gnesi, S., Fantechi, A.: A deontic logical framework for modelling product families. In: Benavides, D., Batory, D.S., Grnbacher, P. (eds.) 4th International Workshop on Variability Modelling of Software-intensive Systems (VaMoS10), Universitt Duisburg-Essen, ICB-Research. Report 37, 3744 (2010) 6. Brger, E., Srensen, O.: BPMN core modeling concepts: Inheritance-based execution semantics. In: Embley, D., Thalheim, B. (eds.) Handbook of Conceptual Modeling: Theory, Practice and Research Challenges. Springer, Heidelberg (2011)
7. Brger, E., Strk, R.: Abstract State MachinesA Method for HighLevel System Design and Analysis. Springer Verlag, New York (2003) 8. Brger, E., Thalheim, B.: A method for veriable and validatable business process modeling. Adv. Softw. Eng. LNCS 5316, 59115 (2008) 9. Broersen, J., Van der Torre, L.: Ten problems of deontic logic and normative reasoning in computer science. European Summer School of Logic, Language and Information (ESSLLI), Germany (2010) 10. Broy, M.: Informatik-Eine grundlegende Einfhrung, vol 2Systemstrukturen und Theoretische Informatik, 2nd edn. Springer Verlag, New York (1998) 11. Dijkman, R., Dumas, M., Ouyang, C.: Formal semantics and automated analysis of BPMN process models. Queensland University of Technology, Faculty of Science and Technology, Tech. rep., Brisbane (2007) 12. Eclipse: BPMN Modeler. www.eclipse.org/bpmn (2011). Accessed August 2011 13. Ehrig, H, Pfender, M, Schneider, H.J.: Graph-grammars: an algebraic approach. In: Proceedings of FOCS 1973, IEEE, pp 167180 (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.) Graph Grammars and Their Application to Computer Science, Lecture Notes in Computer Science, vol 532. Springer Verlag, New York, pp. 269291 (1991) 15. Ehrig, H., Habel, A., Kreowski, H.J., Parisi-Presicce, F.: Parallelism and concurrency in high-level replacement systems. Math. Struct. Comput. Sci. 1, 361404 (1991) 16. Ehrig, H., Ehrig, K., Prange, U., Taentzer, G.: Fundamentals 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 Computer Science, vol 4749. Springer, Berlin, pp. 169180 (2007) 18. Goedertier, S., Vanthienen, J.: Designing compliant business processes with obligations and permissions. In: Eder, J., Dustdar, S., (eds.) Business Process Management Workshops, Lecture Notes in Computer Science, vol 4103, Springer, New York, pp. 514 (2006) 19. Goedertier, S., Vanthienen, J.: Declarative process modeling with business vocabulary and business rules. In: Meersman, R., Tari, Z., Herrero, P. (eds.) On the Move to Meaningful Internet Systems 2007: OTM 2007 Workshops, Lecture Notes in Computer Science, vol 4805, Springer, Berlin, pp. 603612 (2007) 20. Governatori, G., Milosevic, Z.: A formal analysis of a business contract language. Intern. J. Co-op. Inform. Syst. (IJCIS) 15(4), 659685 (2006) 21. Gurevich, Y.: Sequential abstract state machines capture sequential algorithms. ACM Trans. Comput. Logic 1(1), 77111 (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 Dedicated to Stig Kanger on His Fiftieth Birthday, Reidel Publishing Co, Boston, pp. 114 (1974) 24. Lwe, M.: Extended algebraic graph transformation. PhD thesis, TU Berlin (1990) 25. Lwe, M., Beyer, M.: AGGan implementation of algebraic graph rewriting. 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
Deontic BPMN: a powerful extension of BPMN with a trusted model transformation 27. Mogos, A.H., Urzica, A.: TN4PM: A textual notation for process modelling. In: Papadopoulos, G., Badica, C. (eds.) Intelligent Distributed Computing III, Studies in Computational Intelligence, vol 237, pp. 263268. Springer, Berlin (2009) 28. Moody, D.L.: The physics of notations: Towards a scientic basis for constructing visual notations in software engineering. IEEE Trans. Softw. Eng. 35(5), 756778 (2009) 29. Natschlger, C.: Deontic BPMN. In: Hameurlain, A., Liddle, S., Schewe, K.D., Zhou, X. (eds.) Database and Expert Systems Applications, Lecture Notes in Computer Science, vol 6861. Springer, Berlin, pp 264278 (2011) 30. Natschlger, C., Schewe, K.D.: A attening approach for attributed type 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 160173 (2012) 31. Natschlger, C., Geist, V., Kossak, F., Freudenthaler. B.: Optional activities in process ows. In: Rinderle-Ma, S., Weske, M. (eds.) EMISA 2012: Der Mensch im Zentrum der Modellierung, Gesellschaft fr Informatik, Bonn, Lecture Notes in Informatics, vol P-206, pp 6780 (2012) 32. Natschlger-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 the 3rd Asia-Pacic Conference on Conceptual Modelling, Australian Computer Society, Inc., Darlinghurst, Australia, vol 53, pp. 7584 (2006) 36. Raoult, J.C.: On graph rewritings. Theoret. Comput. Sci. 32, 124 (1984) 37. qvist, L.: Deontic Logic, pp. 147264. Kluwer Academic, Dordrecht (2002) 38. Sadiq, S., Governatori, G., Namiri, K.: Modeling control objectives for business process compliance. In: Alonso, G., Dadam, P., Rosemann, M. (eds.) Business Process Management, Lecture Notes in Computer Science, vol 4714, Springer, Berlin, pp. 149164 (2007) 39. Taentzer, G.: AGG: A tool environment for algebraic graph transformation. In: Applications of Graph Transformations with Industrial Relevance (AGTIVE), Lecture Notes in Computer Science, Springer, Berlin, pp. 481488 (2000) 40. Taentzer, G.: AGG: A graph transformation environment for modeling and validation of software. In: Pfaltz, J., Nagl, M., Bhlen, B. (eds.) Applications of Graph Transformations with Industrial Relevance (AGTIVE), Lecture Notes in Computer Science, vol 3062, Springer, Berlin, pp. 446453 (2004) 41. Urzica, A., Tanase, C.: Mapping BPMN to AUML: Towards an automatic process. In: 17th International Conference of Control Systems and Computer Science, MASTS 2009 Workshop, Germany, pp. 539547 (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. 260274 (2006) 43. Weigand, H., Verharen, E., Dignum, F.: Interoperable transactions in business modelsa structured approach. In: Constantopoulos, P., Mylopoulos, J., Vassiliou, Y. (eds.) Advanced Information Systems Engineering, Lecture Notes in Computer Science, vol 1080, Springer, Berlin, pp. 193209 (1996) 44. Wieringa, R., Meyer, J.J.: Applications of deontic logic in computer science: A concise overview. In: Deontic Logic in Computer Science: Normative System Specication, Wiley, New York, pp. 1740 (1993) 45. Wong, P., Gibbons, J.: A process semantics for BPMN. In: Liu, S., Maibaum, T., Araki, K. (eds.) Formal Methods and Software Engineering, Lecture Notes in Computer Science, vol 5256, Springer, Berlin, pp. 355374 (2008)
Author Biographies
Christine Natschlger is an industrial researcher at SCCH, working primarily in process ontologies and deontic constraint modelling in process-oriented systems. She holds an M.Sc. and an M.A. in Computer Science from the University of Applied Sciences of Upper Austria, and recently nished her Ph.D. at the Johannes-Kepler-University Linz. She is involved in the EFRE-funded project Vertical Model Integration at SCCH, dealing with deontic rules in process-oriented systems. Felix Kossak is an industrial researcher at SCCH, working primarily in the eld of rigorous methods and process models. He holds a degree in Software Engineering from the University for Applied Sciences of Upper Austria. He is involved in the EFREfunded project Vertical Model Integration at SCCH, with his main interest on rigorous specication and process modelling.
Klaus-Dieter Schewe (born 1958) is the scientic director of the Software Competence Center Hagenberg (SCCH), a non-prot research institution funded mainly by the Austrian COMET programme. He is at the same time honorary professor at Johannes-Kepler University Linz (JKU) and director of the Christian-Doppler laboratory for client-centric cloud computing (CDCC). Before joining SCCH he held the position of full professor for Information Systems at Massey University, New Zealand from 2000 to 2008, and he was the director of the Information Science Research Centre (ISRC) in New Zealand from 2002 to 2010. At Massey University he received twice an award as Distinguished Researcher. He holds a PhD in Pure Mathematics from the University of Bonn (1985) and a DSc in Theoretical Computer Science from Brandenburg University of Technology Cottbus (1995).
123

Deontic BPMN

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Deontic BPMN

Enviado por

Direitos autorais:

Formatos disponíveis

Softw Syst Model DOI 10.

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

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

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

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

(b) Deontic BPMN

Fig. 4 Exclusive gateway with Phi

(b) Deontic BPMN

Fig. 5 Exclusive gateway without Phi

(b) Deontic BPMN

(b) Deontic BPMN

(b) Deontic BPMN

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

Fig. 10 Order execution process: deontic BPMN diagram

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

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

where derived chosenSequenceFlows(gateway) = { sequenceFlow in outgoingSequenceFlows( gateway) | firingCondition( sequenceFlow) = true }

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

Fig. 11 Conuence and local conuence (source: [16, p. 59])

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

Fig. 12 Type graph of DeonticBpmnGTS

(c) NAC: NoFurtherNode

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

(c) PAC: FurtherNode

(c) NAC: NoFurtherTask

(c) NAC: NoFurtherNode

(c) PAC: FurtherNodea

(c) NAC: NoFurtherTask

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

(c) NAC: NoMixedStartGateway (c) NAC: NoFurtherNode

(d) NAC: NoMixedEndGateway

(e) NAC: NoPhiPath

(f) PAC: FurtherNode

(firingCondition(sf) = true) -> ((firingCondition(sf6) = true) (choiceCondition(pTask3) = or ((firingCondition(sf8) = true) (choiceCondition(pTask4) =

and false)) and false))

(a) LHS (a) LHS

(c) NAC: NoFurtherTask

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

(c) NAC: NoMixedStartGateway

(d) NAC: NoMixedEndGateway

(e) NAC: NoPhiPath

Fig. 24 Example: BPMN Model

Fig. 25 Example: Deontic BPMN model

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

Fig. 30 CP: SequenceRuleBase/SequenceRuleExtended

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

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

Table 3 Termination analysis of DeonticBpmnGTS: rule layers

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

Você também pode gostar