Precise Detection of Conflicting Change Operations using ... - CiteSeerX

Precise Detection of Conflicting Change Operations using Process Model Terms Christian Gerth1,2 , Jochen M. K¨uster2 , Markus Luckey1 , and Gregor Engels1 1

Department of Computer Science, University of Paderborn, Germany {gerth,luckey,engels}@upb.de 2 IBM Research - Zurich, S¨aumerstr. 4 8803 R¨uschlikon, Switzerland {cge,jku}@zurich.ibm.com

Abstract. Version management of process models requires that changes can be resolved by applying change operations. Conflict detection is an important part of version management and the minimization of the number of detected conflicts also reduces the overhead when resolving changes. As not every syntactic conflict leads to a conflict when taking into account model semantics, a computation of conflicts solely on the syntax leads to an unnecessary high number of conflicts. In this paper, we introduce the notion of syntactic and semantic conflicts for change operations of process models. We provide a method how to efficiently compute conflicts, using a term formalization of process models. Using this approach, we can significantly reduce the number of overall conflicts and thereby reduce the amount of work for the user when resolving conflicts.

1

Introduction

Although model-based development (MBD) is accepted as a well-established development approach, there are still some shortcomings that let developers decide against MBD and for more traditional development paradigms. These shortcomings comprise a lack of fully integrated and fully featured development environments for MBD, for instance a comprehensive model version management. In this paper, we consider version management of business process models exemplarily for modeling languages that have non-trivial semantics. In our recent work [13, 6], we have investigated different problems in version management of business process models, including the detection of conflicts between change operations, which is a crucial technique for the consolidation of different model versions. The detection of conflicts can be performed syntactically by analyzing the structure of the models and/or by comparing change operations, e.g., using a conflict matrix [17]. However, conflict detection that is solely based on syntactical features potentially results in false-positive conflicts, that is two changes are detected as being conflicting, although both changes are semantically equivalent or overlap to a large degree. In this paper, we introduce a notion of syntactic and semantic conflicts between change operations and show how conflicts can be computed taking into account the C. Gerth is funded by the International Graduate School of Dynamic Intelligent Systems at the University of Paderborn

semantics of the modeling language. Our approach can also provide a hint on limitations of generic approaches to conflict detection, which do not consider semantics of specific modeling languages. By reducing the overhead for a user in merging different versions of a process model, we take a further step towards a versioning system for process models with the convenience and usability known from versioning systems for textual documents. The remainder is structured as follows: In Section 2 we introduce a typical merge scenario in distributed business process modeling. We show the shortcomings of existing approaches to conflict detection. In Section 3, we consider the basic foundations for our approach to conflict detection. In Section 4, we define syntactic and semantic conflicts of change operations. We present a novel method to compute precise conflicts in Section 5 and show that the amount of work for a user when resolving differences can be significantly reduced. In Section 6 we discuss related work, and we conclude and give an outlook on future work.

2

Motivation

In this section, we first provide a scenario for version management of business process models in distributed environments and we show why conflict detection needs to take semantics into account. Figure 1 shows three process models in the Business Process Modeling Notation (BPMN) [21], representing a typical multi-user scenario. The process models describe the necessary steps to open a banking account for a customer in a bank. The source model V in the middle of Figure 1 was created first and afterwards V was individually refined by different users into the versions V1 and V2 .

Fig. 1. Different Versions of a Business Process Model

2

An overview of our scenario is given in Figure 2. Distributed process modeling is a classical 3-way merge scenario known from versioning systems for textual documents. At some point in time, a consolidated version VC is needed that integrates the changes applied to the different versions V1 and V2 . For that purpose, we have to consider Fig. 2. Scenario Overview the changes between the source process model V and the two versions V1 and V2 . VC is then created by applying a subset of the changes that were applied to achieve V1 and V2 . We assume that these changes are given in terms of change operations and are stored in change logs ∆(V, V1 ) and ∆(V, V2 ). The change logs are either created during the modeling of the version V1 and V2 or they are computed afterwards1 . Change operations include InsertAction, DeleteAction, and MoveAction operations to modify actions in process models. Analogously, the change operations InsertFragment, DeleteFragment, and MoveFragment are used to deal with entire fragments in process models [14]. Figure 3 shows the change logs with change operations representing the differences between the process models V and V1 as well as V and V2 in our example presented in Figure 1. The first parameter of a change operation specifies the modified model element. The other parameters determine the position (i.e., the actual predecessor and successor) to which an element is inserted or moved to. In the remainder we refer to these parameters as position parameters. Whenever changes are applied individually on different versions of a process model, some changes might be conflicting. Informally, two change operations op1 ∈ ∆(V, V1 ) and op2 ∈ ∆(V, V2 ) are conflicting if the application of op1 on the consolidated version VC turns operation op2 inapplicable. Conflicts between change operations have to be detected before a consolidated version can be created. Existing approaches to conflict detection use e.g. conflict sets [2] or conflict matrices [17, 12], which specify conditions under which two change operations are conflicting. For that purpose, change operations are analyzed by comparing the model elements which are modified by the operations and their position parameters to identify conflicting pairs of operations. Applying such an approach on our example (Figure 1) results in the conflicts between change operations indicated by arrows in Figure 3. The curled brackets are added for readability reasons and indicate that every operation within the bracket is in conflict. Overall 18 conflicts are detected, among them several conflicts between equivalent change operations. Two operations are equivalent if their applications have identical effects on the process model. For instance, the operations that inserted the actions ”Set Credit Limit to 0” are inserted in process model V1 as well as in V2 at the same position. Thus, their effects on the process model are equivalent and shall not give rise to a conflict. We refer to conflicts between equivalent operations as false-positive conflicts in the remainder. Approaches to conflict detection based on syntactic features result potentially in false-positive conflicts because they cannot identify equivalent change operations in every case. For instance, a syntactic comparison of the change operations i and y that 1

In our recent work [14] we have shown how change operations can be computed in the absence of a change log.

3

Fig. 3. Change Logs ∆(V, V1 ) and ∆(V, V2 ) of our Example in Figure 1 with Conflicts

insert the actions ”Set Credit Limit to 0” results in a conflict, since the position parameters of the operations differ and it seems that the actions are inserted at different positions in V1 and V2 . The identification of equivalent operations is even more difficult in cases where elements are modified in structures that are syntactically different but semantically equivalent, which is often the case. To give an example, a syntactic conflict detection between change operations in the highlighted structures fP1−V1 and fP1−V2 in Figure 1 results in several false-positive conflicts (see operations d-h and q-t in Figure 3). For these operations that modify elements in this structures in V1 and V2 , it is not straight-forward to decide whether they are equivalent. A syntactic comparison of the change operations or the structures results in false-positive conflicts. However, considering the behavior of the structures in terms of their execution traces reveals that the structures are equivalent to a large degree and should not give rise to conflicts between all change operations within the structures. To prevent false-positive conflicts, the semantics of process models must be taken into account. In this paper, we address this problem and propose a method for precise conflict detection. Next, we introduce basic foundations.

3

Foundations

In this section, we consider the basic foundations of our approach. We start with an introduction of process structure trees. Then, we briefly describe process model terms. 3.1

Process Structure Tree

For the following discussions, we assume a business process model M to be expressed using the basic workflow graphs described in [25, 26] and define the semantics of pro4

cess models similar to the semantics of Petri nets [19] in terms of token flows. In our recent work [6], we have shown how concrete BPMN models can be abstracted to such process models and described the behavior of particular process model nodes in detail. To enable a comparison of individual parts of process models, they are decomposed into single-entry-singleexit fragments [26] (e.g., fA , fB , ... in process model V in Figure 1). Such a fragment is a non-empty subgraph in the process model with a single entry and a single exit edge. A fragment can either be an alternative fragment consisting of an Exclusive Decision and an Exclusive Merge node, a concurrent fragment consisting of a Parallel Fork and a Parallel Join node or further types of fragments including unstructured or complex fragments, Fig. 4. Process Structure which allow us to express all combinations of gateways. Tree of Process Model V For more details about fragment types the reader is referred to [26]. Based on the decomposition into fragments we are able to compare individual pairs of fragments instead of relying on the complete process model. In addition, the PST specifies semantic information of the underlying process model e.g., the type of a fragment (parallel, alternative, complex, ...). Figure 4 shows the process structure tree (PST) [26] of the source process model V (Figure 1). The PST represents the fragments hierarchy. The fragments fA , fC , and fD are sequential fragments, and fB is an alternative fragment. 3.2

Process Models Terms

Process model terms (PMT) [7] are a formalization of the process structure tree and are used to identify equivalences between different fragments, while taking their semantics into account. In contrast to process structure trees, PMTs specify the execution order of elements located in fragments and can be compared efficiently. We use PMTs later to identify semantical conflicts within syntactical different fragments. Figure 5 summarizes the translation of PST elements to their corresponding term representation. ControlNodes are not added to process model terms, since they are already represented by their surrounding fragments. The transformation of process models into terms is straight-forward by traversing its PST using the infix approach. We define O to be the partial order set over the set of sequences representing branches within a fragment. A PMT consists of a term and a partial order relation O, which specifies the execution order of branches within fragments. PST Element InitialNode, FinalNode, Action n Sequence s Parallel Fragment p Alternative Fragment a Alternative Loop Fragment l Complex Fragment c

Term n s(...) p(...) a(...) l(...) c(...)

Fig. 5. Transformation of PST into Term 5

Fig. 6. Process Model Term t f P1−V2

The highlighted fragment fP1−V2 in process model V2 of our example (Figure 1) results in the PMT tP1−V2 shown in Figure 6. The sequences s2 and s3 are executed before sequence s4 , resulting in the partial order OP1−V2 = {s2 < s4 , s3 < s4 }. Since s1 is executed in parallel to the other sequences, it is not in added to the partial order O. In addition, we do not explicitly specify the execution order of elements within sequences, since it is given implicitly. The partial order within a fragment can be obtained easily by traversing all branches of each fragment using the depth first approach. Process model terms can be syntactically compared efficiently. However, to compare the semantic equivalence of syntactically different models, their corresponding terms have to be transformed into a normal form to be considered equivalent, since syntactically different models result in different terms regardless of their semantic meaning. For that purpose, we have developed a term rewriting system [7] that transforms syntactically different process models with the same semantics into a unique normal form. The term rewriting system consists of 16 rules for the transformation of sequences, alternative, and parallel fragments of process models. The fragments can be structured or unstructured. For more details about the term rewriting system the reader is referred to [7].

4

Syntactic and Semantic Conflicts of Change Operations

In this section, we introduce a notion of conflicts between change operations. For the following discussion, we assume that changes between a source process model V and independently modified versions V1 and V2 are given in terms of compound change operations in the change logs ∆(V, V1 ) and ∆(V, V2 ). Matchings between the versions and the source process model are given in terms of correspondences Corr(V, V1 ) and Corr(V, V2 ) that relate elements with the same functionality in the models. The set Corr(V1 , V2 ) contains correspondences between elements with the same functionality that were newly inserted into the versions V1 and V2 . Corr(V1 , V2 ) can be obtained by matching elements with same or similar name, e.g., by measuring the Levenshtein distance [16] between element names or using an ontology-based matching. Conflicts between change operations can be classified into syntactical or semantical conflicts. Informally, two changes are syntactically in conflict if the application of one change turns the other one inapplicable. Formally, we define syntactical conflicts of change operations by expressing them as model transformations [13], where an opop eration op is applied on a model V leading to a model V 0 (V =⇒ V 0 ). Definition 1 (Syntactically Conflicting Change Operations) Let two change operaop1 op2 tions op1 ∈ ∆(V, V1 ) and op2 ∈ ∆(V, V2 ) be given such that V =⇒ V 0 and V =⇒ V 00 . We call op1 and op2 syntactically conflicting if op2 is not applicable on V 0 or op1 is not applicable on V 00 . In our example the change operations a) and m) (Figure 3) are syntactically conflicting. Both operations insert different elements at the same position in the process models. For the consolidation, only one of the operations can be applied on the source process model V. 6

In the case of semantic conflicts, we first have to define when two process models are considered to be behavioral equivalent. For the following discussion we use trace equivalence [24] as equivalence relation that has been defined for process models in [10, 22]. We consider two process models V1 and V2 to be trace equivalent (V1 ≡trace V2 ) if their sets of traces are equal. Informally, two change operations modifying corresponding elements are semantically in conflict if the corresponding elements are executed at different positions, resulting in different execution traces. We define semantically conflicting operations as follows: Definition 2 (Semantically Conflicting Change Operations) Let two change operations op1 ∈ ∆(V, V1 ) and op2 ∈ ∆(V, V2 ) be given that modify the elements (action or fragments) x1 and x2 . Further, let x1 correspond to x2 , i.e. (x1 , x2 ) ∈ Corr(V1 , V2 ). op1 op2 Then we call op1 and op2 semantically conflicting if V =⇒ V 0 , V =⇒ V 00 , and not V 0 ≡trace V 00 . An example for Definition 2 is represented by the operations b) and u) that insert the actions ”Open Account” in different positions in the process models V1 and V2 in Figure 1. Syntactical conflicts can be computed using existing theory, e.g., by using conflict matrices, with the described shortcomings (Section 2). A naive solution to identify semantically conflicting change operations would be to directly apply Definition 2. That would require that all changes need to be applied individually on V (with respect to dependencies between the changes) and their traces need to be computed to verify their trace equivalence. This approach suffers from several drawbacks: First of all, the application of the individual operations represents a significant overhead, since it requires in the worst case the application of all subsets of change operations, which is not always possible. Second, for the evaluation of trace equivalence all possible execution traces need to be computed that may result in exponential complexity. An approach to compute syntactical and semantical conflicts that overcomes these shortcomings is introduced in the following.

5

Computation of Conflicting Change Operations

In this section, we present a novel method to compute conflicts between given change operations. It avoids false-positive conflicts by taking into account semantic equivalence of business process models. In the following, we classify change operations into independent and dependent operations, since the approaches of conflict detection differ for both categories. In [13], we have shown how dependencies of change operations can be computed efficiently. For example, a change operation is dependent if it inserts or moves an element into a fragment, that was newly inserted itself. Based on this classification, our approach consists of two main steps (Figure 7 and 11): In the first step, we compute conflicts between independent change operations (Section 5.1) and in the second step we determine conflicts between dependent operations (Section 5.2). In the following we explain the individual steps in detail. 7

5.1

Conflict Detection of Independent Change Operations

In the first step, we compute conflicts between independent change operations by comparing the change operations syntactically using conflict matrices. However, in contrast to existing approaches we compare the operations in a specific order and use dynamic computation of Fig. 7. Conflict Detection of Independent Operaposition parameters to determine the tions position of modified model elements uniquely. Thereby, equivalent independent operations are identified. First, position parameters for all independent change operations are specified using only corresponding model elements that are not modified by a change operation in the process models V1 and V2 (Step 1). We refer to these elements as fixpoints in the remainder. For instance, the actions ”Record Customer Data” in the models V1 and V2 constitute fixpoints, since they correspond to each other and are not modified. An algorithm to compute position parameters using fixpoints is presented in [13]. In Step 1a, we iterate over the independent change operations whose position parameters were specified using fixpoints in the change logs and syntactically compare pairs of change operations op1 ∈ ∆(V, V1 ) and op2 ∈ ∆(V, V2 ) that modify corresponding model elements using a conflict matrix. Figure 8 shows an excerpt of our conflict matrix for change operations that specifies condition in which change operations are conflicting. In the case, that operations are not in conflict, the underlying corresponding model elements will be at the same position after the execution of the operations, resulting to equal traces. The corresponding model elements modified by op1 and op2 are added to the set of fixpoints. Before the next comparison of change operations, position parameters of the remaining change operations are recomputed to consider the increased set of fixpoints. In the case, that the operations are in conflict according to the conflict matrix, op1 and op2 are marked as conflict, since their application results in corresponding model elements at different positions.

Fig. 8. Excerpt of our Conflict Matrix for the Comparison of Change Operations specified with Fixpoints

Figure 9 provides an example using the operations i,j,k and v,w,x from our example. In (a), the position parameters of the change operations are initially specified using fixpoints. We start the comparison with the operations i and x. Since they are not conflicting, their underlying model elements ”Set Credit Limit to 0” are added to the set of fixpoints and the position parameters are recomputed, reflecting the new fixpoint. 8

Next in (b), the operations j and w are compared, with the result that ”Remove Credit Card” is added to the set of fixpoints entailing again a re-computation of the position parameter of the remaining operations. Finally in (c), the remaining operations k and v are compared and the actions ”Set Interest Rate to 0” are added to the set of fixpoints.

Fig. 9. Conflict Computation between Change Operations modifying corresponding Model Elements

Note, that compared to our previous approach from [13] by specifying position parameters of the operations i,j,k and v,w,x in terms of fixpoints and a dynamic computation of change operation parameters, no false-positive conflicts are detected between the equivalent operations. After Step 1a, all conflicts between independent change operations modifying corresponding model elements have been computed. In Step 1b, we compare the remaining independent change operations that modify non-corresponding model elements. According to the conflict matrix, a syntactic conflict between these operations is detected if non-corresponding elements are located at the same position after the application of the operations. An example for such a conflict is the conflict between the operations a and m in Figure 10, which insert the action ”Check Customer Data” and the fragment F A1−V1 at the same position. Figure 10 shows the conflicts between the change operations in ∆(V, V1 ) and ∆(V, V2 ) that have been computed after Step 1. Conflicts of the highlighted operations have been computed in this step and are indicated by dotted arrows. In the following, we compute conflicts of the remaining dependent operations (d-h and q-t) within the fragments fP1−V1 and fP1−V2 . Since these change operations contain dependencies to each other, the conflict detection approach differs from the one described above. 5.2

Conflict Detection of Dependent Change Operations

Conflicts between dependent change operations cannot be computed based on a comparison of change operations and their position parameters, due to the following reasons: First, position paramFig. 11. Conflict Detection of Dependent Operaeters within fragments are difficult tions to compare because syntactically 9

Fig. 10. Computed Conflicts after Step 1

different fragments may have the same behavior in terms of their execution traces. Further, beside the actual position of an element within a fragment, also the execution order and logic of the fragment must be considered. To give an example, in the top of Figure 12 the highlighted fragments of our example (Figure 1) are shown. These fragments are syntactically different although they are semantically equivalent to a large degree comparing their behavior in terms of execution traces. Existing approaches to conflict detection that compare change operations based on a conflict matrix would mark all the dependent operations contained in modified fragments as conflicting regardless whether they are equivalent or not, resulting in falsepositive conflicts. In the case of the fragments fP1−V1 and fP1−V2 , most of the conflicts constitute false-positive conflicts. To avoid these false-positive conflicts, we check whether the corresponding elements within the two fragments lead to equivalent traces. For that purpose, in Step 2a, we iterate over corresponding fragments that are modified by a change operation. For each pair of these fragments we then leverage process model terms to identify conflicts of dependent change operations contained in the fragments. Process model terms enable us to compare two fragments for semantic equivalence (see Section 3.2) by detecting differences in the terms. In the following, we first define differences of process model terms, which we then use to identify conflicting change operations.

Definition 3 (Term Difference) Let f1 ∈ V1 and f2 ∈ V2 be two corresponding fragments together with a mapping Corr(V1 , V2 ) of V1 and V2 . Let further the normalized process model terms tCorr− f 1 , tCorr− f 2 of the fragments be given that are reduced to their corresponding elements (e1 , e2 ) ∈ Corr(V1 , V2 ). We define a term difference as a difference of the two terms tCorr− f 1 , tCorr− f 2 or a difference of their partial orders. 10

Given a term difference, we now define the operations that yield the term difference as term-conflicting operations. Figure 12 shows the fragments fP1−V1 and fP1−V2 of our example. We first reduce the fragments to their corresponding model elements (by removing the actions ”Sign Contract” and ”Ask for Credit Limit”) and transform them into their process model terms. These terms are normalized using our term rewriting system introduced in [7]. The normal forms of the terms together with their graphical representation are shown in the bottom of Figure 12. Finally, we compare the normalized terms under consideration of commutativity in order to identify term differences. Since the terms are not equal, a term difference is obtained: The sequence s(Calc) in the normal form NF(tP1−V1 ) cannot be mapped to a sequence in NF(tP1−V2 ). In other words, in our example, the actions ”Calculate Interest Rate” and ”Select Credit Card Operation” are executed in parallel in fP1−V1 , however they are executed sequentially in fP1−V2 . Thus, the operations g and r that insert the actions ”Calculate Interest Rate” are term-conflicting.

Fig. 12. Term-Conflicting Operations

The following theorem shows the equivalence of term differences in process model terms and differences in the execution traces of process models. Theorem 1 (Equivalence of term difference and trace difference). Let f1 ∈ V1 and f2 ∈ V2 be two corresponding fragments together with a mapping Corr(V1 , V2 ) of V1 and V2 be given that are reduced to the corresponding elements (e1 , e2 ) ∈ Corr(V1 , V2 ). 11

Let further the normalized process model terms tCorr− f 1 , tCorr− f 2 be given. Each difference between the terms tCorr− f 1 , tCorr− f 2 induces a trace difference in the execution traces of f1 and f2 and each difference in the traces of f1 and f2 lead to a term difference. Proof Sketch: To prove Theorem 1 we have to show that each term difference induces a trace difference and no term difference induces no trace difference.

Case 1 (term difference → trace difference): We assume that the terms tCorr− f 1 , tCorr− f 2 contain at least one difference. A difference can have two reasons. Either the term representations itself differ, or there is a difference in the partial order of the branches of the fragments. A difference in the former case occurs if corresponding elements are in different orders what obviously results in different traces. In the latter case, there is no difference in the term representation, since all contained sequences can be matched. However, the partial orders of the terms are different. That means, at least one branch is executed in a different order resulting in different execution traces.

Case 2 (no term difference → no trace difference): We assume that in the terms tCorr− f 1 , tCorr− f 2 no term difference exists. That means, the corresponding elements in the terms itself are in identical orders. In addition, since the partial orders of the terms are identical, the sequences within the terms are executed in the same order. Thus, an execution of the fragments results in equal traces.

We have shown, that for each pair of term-conflicting change operations modifying corresponding model elements there exists a term difference in the process model terms, which is equivalent to a trace difference (Theorem 1). Hence, the term-conflicting operations constitute semantically conflicting change operations according to Definition 2. This shows that we have found a way to efficiently compute semantically conflicting operations. In Step 2a, we have computed conflicts between change operations modifying corresponding model elements within fragments. What remains, is the computation of conflicts between dependent operations that modify non-corresponding elements that were ignored in the previous step. Similar to Step 1b, this can be done, using corresponding elements, whose change operations are not conflicting as fixpoints. Therefore, we compute position parameters of dependent change operations within the fragment in terms of fixpoint (e.g., operation e) InsertAction(”Sign Contract”, ”Print Credit...”, ”JoinP1−V1 ”)). Then the operations are compared using the conflict matrix to identify conflicts. In some cases, position parameters of dependent change operations cannot be specified using fixpoints only. These operations are marked as conflicting. Figure 13 shows the conflicts that are computed using our method. Our work shows that conflict detection can be performed on a semantic level using a term formalization of process models and their hierarchical structure. Thereby, we have significantly reduced the overall number of conflicts (from 18 to 6 in the example) between change operations and in particular the number of false-positive conflicts. Based on process model terms, equivalent operations contained in complex fragments cannot be identified using only our approach. Instead, for those fragments, we leverage trace equivalence. This still is way faster than a pure trace equivalence approach, since traces only need to be computed for fragments, which are significantly 12

Fig. 13. Computed Conflicts after Step 2

smaller compared to the whole process model. For more details about the term rewriting system the reader is referred to [7].

6

Related Work

One area of related work is concerned with model composition and model versioning. Alanen and Porres [1] describe an algorithm how to compute elementary change operations. Kolovos et al. [11] describe the Epsilon merging language which can be used to specify how models should be merged. Kelter et al. [9] present a generic model differencing algorithm. In the IBM Rational Software Architect [15] or using the EMF Compare technology [5], dependencies and conflicts between versions are computed based on elementary changes. These approaches to model versioning deal with the problem of model merging but they do not study the concept of semantic conflicts in order to reduce the number of syntactic conflicts. In [20], Nejati et al. combine different matching strategies (static & behavioral) in their approach to statechart matching and merging. This may also lead to less falsepositive conflicts, however, conflict detection is not considered in their work. In the graph transformation community, dependencies of transformation rules have been studied in the literature: Mens et al. [18] analyze refactorings for dependencies using critical pair analysis. They first express refactorings as graph transformations and then detect dependencies using the AGG tool [23]. Our earlier work [12] formalizes change operations using graph transformations and then proposes dependency and conflict matrices for them. All these approaches follow a syntactic approach to conflict detection, based on transformation rules and conflict matrices. Brosch et al. [3] have recently identified the problem that the quality of conflict detection and resolution in model versioning systems is not sufficient. They introduce an approach for identifying refactorings in modeling tools and propose to integrate these refactorings into the conflict detection of versioning systems. In [2], Altmanninger et 13

al. make semantic aspects of modeling languages explicit using semantic views. Based on the views semantic conflicts can be reported. These works can be considered complementary to our work which aims at making the conflict detection more precise by taking into account the execution semantics of models. Cicchetti et al. [4] propose a metamodel for the specification and detection of syntactical and semantical conflicts. In contrast to their work, we introduce a particular approach for efficiently computing semantic conflicts. Rinderle et al. [22] have studied disjoint and overlapping process model changes in the context of the problem of migrating process instances but have not considered dependencies and conflicts between change sequences and different forms of conflict resolution.

7

Conclusion and Outlook

In this paper, we have considered the detection of conflicting change operations in version management of business process models as an example for life-cycle support of models in model-based development. We have identified shortcomings of existing approaches that rely on a purely syntactic comparison and potentially result in falsepositive conflicts. To overcome these shortcomings, we have introduced a notion of syntactic and semantic conflicts. For the detection of conflicts, we have presented a dedicated method for version management of business process models using normalized process model terms. Our initial results have shown that taking the semantics of process modeling languages into account, helps to compute precise conflicts and avoids false-positive conflicts. The validation of our approach by integrating the semantic conflict detection between change operations into our existing tool support for model merging, is subject to future work. Acknowledgements: The authors wish to thank Jana Koehler for valuable feedback on an earlier version of this paper.

References 1. M. Alanen and I. Porres. Difference and Union of Models. In P. Stevens, J. Whittle, and G. Booch, editors, UML 2003, volume 2863 of LNCS, pages 2–17. Springer, 2003. 2. K. Altmanninger. Models in Conflict - Towards a Semantically Enhanced Version Control System for Models. In Holger Giese, editor, MoDELS Workshops, volume 5002 of LNCS, pages 293–304. Springer, 2007. 3. P. Brosch, P. Langer, M. Seidl, and M. Wimmer. Towards End-User Adaptable Model Versioning: The By-Example Operation Recorder. In ICSE Workshop on CVSM, pages 55–60. IEEE, 2009. 4. A. Cicchetti, D. Di Ruscio, and A. Pierantonio. Managing Model Conflicts in Distributed Development. In K. Czarnecki, I. Ober, J.-M. Bruel, A. Uhl, and M. V¨olter, editors, MODELS, volume 5301 of LNCS, pages 311–325. Springer, 2008. 5. Eclipse Foundation. EMF Compare. http://www.eclipse.org/modeling/emft/?project=compare. 6. C. Gerth, J. M. K¨uster, and G. Engels. Language-Independent Change Management of Process Models. In A. Sch¨urr and B. Selic, editors, MODELS’09, volume 5795 of LNCS, pages 152–166. Springer, 2009.

14

7. C. Gerth, M. Luckey, J. M. K¨uster, and G. Engels. Detection of Semantically Equivalent Fragments for Business Process Model Change Management. In SCC’10, pages 57–64. IEEE Computer Society, 2010. 8. International Business Machines Corp. (IBM). IBM WebSphere Business Modeler. http://www.ibm.com/software/integration/wbimodeler/. 9. U. Kelter, J. Wehren, and J. Niere. A Generic Difference Algorithm for UML Models. In P. Liggesmeyer, K. Pohl, and M. Goedicke, editors, Software Engineering 2005, volume 64 of LNI, pages 105–116. GI, 2005. 10. B. Kiepuszewski. Expressiveness and Suitability of Languages for Control Flow Modelling in Workflows. PhD thesis, Queensland University of Technology, Brisbane, 2002. 11. D. S. Kolovos, R. Paige, and F. Polack. Merging Models with the Epsilon Merging Language (EML). In O. Nierstrasz, J. Whittle, D. Harel, and G. Reggio, editors, MoDELS 2006, volume 4199 of LNCS, pages 215–229. Springer, 2006. 12. J. M. K¨uster, C. Gerth, and G. Engels. Dependent and Conflicting Change Operations of Process Models. In R. F. Paige and A. Hartman, editors, ECMDA’09, volume 5562 of LNCS, pages 158–173. Springer-Verlag, 2009. 13. J. M. K¨uster, C. Gerth, and G. Engels. Dynamic Computation of Change Operations in Version Management of Business Process Models. In T. K¨uhne and B. Selic, editors, ECMFA’10, volume 6138 of LNCS (to appear). Springer, 2010. 14. J. M. K¨uster, C. Gerth, A. F¨orster, and G. Engels. Detecting and Resolving Process Model Differences in the Absence of a Change Log. In M. Dumas and M. Reichert, editors, BPM’08, volume 5240 of LNCS, pages 244–260. Springer-Verlag, 2008. 15. K. Letkeman. Comparing and merging UML models in IBM Rational Software Architect : Part 3. A deeper understanding of model merging. IBM Developerworks, 2005. 16. V. I. Levenshtein. Binary Codes Capable of Correcting Deletions, Insertions and Reversals. Soviet Physics Doklady, 10:707, 1966. 17. T. Mens. A State-of-the-Art Survey on Software Merging. IEEE Trans. Software Eng., 28(5):449–462, 2002. 18. T. Mens, G. Taentzer, and O. Runge. Analysing refactoring dependencies using graph transformation. Software and System Modeling, 6(3):269–285, 2007. 19. T. Murata. Petri Nets: Properties, Analysis and Applications. Proceedings of the IEEE, 77(4):541–580, 1989. 20. S. Nejati, M. Sabetzadeh, M. Chechik, S. M. Easterbrook, and P. Zave. Matching and Merging of Statecharts Specifications. In ICSE 2007, pages 54–64. IEEE Computer Society, 2007. 21. Object Management Group (OMG). Business Process Modeling Notation (BPMN). http://www.omg.org/spec/BPMN/1.2. 22. S. Rinderle, M. Reichert, and P. Dadam. Disjoint and Overlapping Process Changes: Challenges, Solutions, Applications. In R. Meersman and Z. Tari, editors, CoopIS’04, volume 3290 of LNCS, pages 101–120. Springer, 2004. 23. G. Taentzer. AGG: A Graph Transformation Environment for Modeling and Validation of Software. In AGTIVE, volume 3062 of LNCS, pages 446–453, 2003. 24. R.J. v. Glabbeek. The Linear Time-Branching Time Spectrum I - The Semantics of Concrete, Sequential Processes. In Handbook of Process Algebra, Chapter 1, pages 3–99. Elsevier. 25. W. M. P. van der Aalst, A. Hirnschall, and H. M. W. Verbeek. An Alternative Way to Analyze ¨ Workflow Graphs. In A. Banks Pidduck, J. Mylopoulos, C. C. Woo, and M. Tamer Ozsu, editors, CAiSE, volume 2348 of LNCS, pages 535–552. Springer, 2002. 26. J. Vanhatalo, H. V¨olzer, and F. Leymann. Faster and More Focused Control-Flow Analysis for Business Process Models Through SESE Decomposition. In ICSOC 2007, volume 4749 of LNCS, pages 43–55. Springer, 2007.

15