Composite-Level Conflict Detection in UML Model Versioning

At present, model-driven engineering plays an essential role in software development. Model versioning systems perform the task of conflict detection when merging parallel-developed model versions. However, conflict detection is typically conducted at the primitive operation level in operation-based systems. This situation implies that the overall intention of model developers may be disregarded, which results in unsatisfactory performance. In this study, we present an approach to conflict detection at the composite level in model versioning systems for Unified Modeling Language. This approach has two main stages. During the preprocessing stage, redundant operations are removed from the originally recorded operation lists to increase efficiency. During the conflict detection stage, a fragmentation procedure is conducted with only potentially conflicted operations allocated into the same fragment. Then, a pattern-matching strategy is applied to help indicate conflicts.


Introduction
Software engineering has entered an era where artifacts such as codes and documents require systematic management.In such circumstances, model-driven engineering (MDE) exerts considerable influence throughout the entire life cycle of software development.In MDE, models are regarded as firstclass artifacts because they can be directly involved in code generation and serve as abstraction.As software evolves, the scale and complexity of models grow with the system, which calls for the efficient management of models.
Among these models, Unified Modeling Language (UML) models are widely employed in the industry.They are represented by several kinds of diagrams in different scenarios, including class diagrams in object-oriented software development.To ensure static model properties such as correctness and consistency, the model-checking approach [1] has been proposed to verify UML models.By adopting model modulation [2], the application range of model checking can be widened and its user-friendliness can be enhanced, particularly for individuals who have minimal experience [3].
Apart from their static properties, managing the evolvement of models is also crucial.Thus, model-specified version control systems (VCSs) are employed.VCSs that support concurrent development typically operate under an optimistic mechanism [4], which allows each developer to work on a local copy of model instances.To support collaborative editing, concurrent modified changes made by different developers have to be merged into a single stable version.During merging, conflicts among changes from paralleledited versions may occur and have to be detected and resolved, which is a crucial task of VCSs.
The merging stage requires parallel-modified changes to be entered as inputs, which can be retrieved using either state-or operation-based approaches [5].An operation-based approach obtains changes directly from recorded change logs; hence, the operations of arbitrary granularity can be determined as long as the editor supports it.Recorded operations are classified into primitive operations (e.g., create, delete, and update) and composite operations, which consist of primitive operations.The latter may be domain-specific such as refactorings [6].Complex examples include Gangof-Four design patterns [7] of UML class diagrams.These operations can provide better usability and understandability than primitive operation sequences.Furthermore, conflict detection conducted at the composite operation level may be more accurate because an integrated operation reflects the overall intention of a developer, which is an essential criterion in declaring conflicts.
However, current operation-based versioning systems either provide limited support for detecting conflicts with composite operations during model merging [8] or conflict detection is not conducted at the composite operation level [9]; that is, composite operation is not regarded as a whole.In this study, we propose a tentative approach to detecting conflicts associated with composite operations.This approach includes a preprocessing stage that removes redundant operations [10] from recorded operations and a detection stage that identifies conflicts.
The remainder of the paper is organized as follows.In Section 2, we introduce some notions and properties employed in the study and provide a motivating example to illustrate our approach.The preprocessing and conflictdetection stages are introduced in Sections 3 and 4, respectively.Section 5 evaluates the proposed approach.Section 6 introduces related works.Finally, the conclusion drawn from the study is presented in Section 7.

Preliminary
In this section, several concepts, including models and operations, applied in the proposed approach are introduced.The models referred to in this study are UML models.Definition 1.An instance of model  is naturally defined by the model elements  that it contains, the available operations  that can be conducted on it, and the constraints  that it complies with; that is,  = ⟨, , ⟩.
Available model elements and constraints are frequently defined by a , which is typically represented as a UML class diagram.A metamodel regulates the kinds of element that will be shown in the model, the relationships between elements, and the numerical and other rules applied in the model.An example metamodel is provided in Figure 1.The example is a highly simplified version of a metamodel for class diagrams (refer to [11] for the complete version).In this metamodel, class is the central element, which may aggregate several attributes or methods.A class may inherit one superclass and may generalize several subclasses.Each instance of class, attribute, and method has a name.Definition 2. An operation  is specified by its target elements , preconditions , and postconditions   ; that is,  = ⟨, ,   ⟩.Preconditions are requirements that an operation has to observe before execution, whereas postconditions are outcome characteristics.
If we denote  ⊃   when a set of elements  satisfies the preconditions of an operation , then () ⊃    will automatically hold.In this case,   and    are substituted for the precondition and postcondition of operation , respectively, and () is substituted for the elements generated by executing  on .This relation is expressed as follows: for  ∈ ,  ⊃   ⇒  () ⊃    .After an operation is defined, several crucial relations among operations are then defined as follows.Additional properties of operations are discussed in [12].
Two operations are compatible with each other if they are not in conflict, which is denoted as  ‖ .
However, this definition of conflict is reconsidered in our approach, particularly regarding composite operations.We may consider some operation pairs compatible if they complete similar tasks, which is introduced in Section 4. q 1 : PullUpMethod(C1, login()) q 2 : AddClass(C5) q 3 : UpdateSuper(C5, C1) q 4 : UpdateSuper(C2, C5) q 5 : UpdateSuper(C3, C5) q 6 : PullupField(C5, username) q 7 : AddClass(C4) that creates, deletes, or updates a simple element that does not contain other elements or have relationships with them.The internal representation of operations is sometimes difficult to understand for model developers [13], which is one of the reasons why composite operations should be composed of primitive ones.A composite operation can be expressed as follows:

Relation 4 (dependency
can be arbitrary to whichever operation is available, regardless of whether primitive or composite.Thus, composite operations can be organized in a hierarchical manner, in which primitive operations compose low-level composite operations and low-level composite operations can further compose high-level operations such as refactorings.
An example that illustrates model changes is presented in Figure 2. A class diagram that is initially at version  0 is edited in parallel by two developers.Thus, two derived versions,  1 and  2 , are available after respective changes have been made by the two developers.One of the developers can commit changes directly without performing an additional process, whereas the other can commit changes only after model merging.Two sequences of recorded operations from both developers are analyzed to detect conflicts.To simplify, classes with the same label, such as  4 , from the two versions are regarded as corresponding elements with the same meaning.
The signatures of some composite operations shown in our example are briefly explained as follows and defined by

Composite operation
Sequence of suboperations the suboperation sequences in Table 1.A detailed explanation of these operations is provided in [6].
(i) PullUpField(class , attribute ): all subclasses of class  initially have the same attribute .Attribute  will be removed from all subclasses and created in .(ii) PushDownField(class , attribute ): class  initially has attribute .Attribute  will be removed from  and created in all of its subclasses.Our example has two operation lists.In version  1 , the operations are recorded as  1 to  6 .First, the common attribute  from  2 and  3 is extracted to their superclass  1 .Then  is pushed downward.Afterwards the method  is moved from  2 to  1 and the same method is removed from  3 .Finally a new class  4 is added and the superclass of  4 is set to  1 .
In version  2 , the operations are recorded as  1 to  8 .First, the common method () is extracted from  2 and  3 to their superclass  1 .Then, a new class  5 is created, with its superclass set to  1 .Subsequently, the superclasses of  2 and  3 are set to the same class  5 and their common attribute username is pulled upward to  5 .Finally, a new class  4 is created and its superclass is set to  1 .
These two lists of operations both contain several composite operations, some of which are refactorings defined for class diagrams, such as pulling up a common attribute from subclasses to their shared superclass.If the operations from both sides are compared in pairs to detect conflicts, 48 pairs of operations should be checked, and complexity can be extremely high if numerous operations are included in the lists.To detect conflicts between the two lists of operations efficiently, two issues have to be resolved:

Preprocessing Operations
Before conflict detection, the original recorded operation lists have to be minimized; that is, redundant operations whose effects are masked by succeeding operations should be removed.Both primitive and composite operations are considered in this process.

Removing Redundant Primitive
Operations.Basic rules for omitting redundant primitive operations are provided in [14].Primitive operations such as creating or deleting an element and updating an attribute feature can be compacted by following self-confident generic rules.In this case,  and V represent a stand-alone element and one of its property values, respectively.An empty operation that always does nothing to the model is denoted by : The preceding rules are utilized to remove redundant primitive operations in Algorithm 1. Two primitive operations that operate on the same element are compacted if no other operation that operates on the same element comes between them.Hence, the compacted operation will participate in further compaction.
In the motivating example, operations  5 / 6 match the second rule; that is, they create an element and subsequently update its property value.Therefore, these two operations can be compacted to a single operation ( 5 [ :=  1 ]).Operation pairs  2 / 3 and  7 / 8 can be similarly compacted.

Removing Redundant Composite Operations.
Composite operations are typically defined in domain-specific environments; hence, rules for omitting redundant composite operations cannot be defined in a generic manner.In this case, we apply the concept of inverse operations to accomplish the task.An operation is regarded as an inverse operation of another if executing both operations on an applicable model results in no change.The inverse operation of an operation  is denoted as  − .The following equation can be derived: The inverse operation of a composite operation  can be expressed as follows: Thus, a composite operation can be reversed by initially reversing the sequence of suboperations and then reversing each suboperation.For example, the two composite operations  and ℎ defined in Table 1 are mutually reversed if they operate on exactly the same set of elements, which can be proven by the preceding equation.With the specified reversal rules, the mutually reversed composite operations in an operation list can be safely removed if no other operation that modifies any common element comes between them.
In our example, operations  1 and  2 , which operate on the same set of elements, are mutually reversed composite operations based on the preceding analysis; hence, they can be removed from the operation list.

Conflict Detection
Conflict detection is performed to check for conflicts between two operation serializations.Two issues should be addressed in conflict detection.First, operation pairs from two lists should be filtered to detect conflicts because time will be wasted if all pairs are considered [12].Second, conflict rules, which determine whether two operations are in conflict, should be defined formally.

Fragmentation by Elements.
Operation pairs to be checked should be minimized to efficiently detect conflicts between two versions.The concept of fragmentation is adopted in this study to divide operations into several partitions.Only operations from the same fragment are compared to detect conflicts.We conduct fragmentation according to the operated elements.The fragmentation procedure is simple if the definition of operations is fine-grained.One fragment corresponds to an operated element and contains all operations that modify this element.In this case, only the simplest elements are considered, such as the attributes in a class diagram.Each fragment contains a set of operations and each operation may be contained by several elements.No conflict exists if two operations do not in any common fragment, which can be expressed as follows.() denotes element set related operation .Consider for ,  ∈ ,  ‖  ⇐  () ∩  () = ⌀.
The fragmentation procedure is illustrated in Figure 3.The table on the left lists the operations after preprocessing, whereas the table on the right shows the fragments.The first column of the fragment table lists the involved elements.Each row represents a fragment associated with one element.Three kinds of element from each class are considered: attribute ; method (); and relationship , which refers to the superclass.During fragmentation, the two operation lists are traversed to check the elements involved in each operation.Then, each operation is placed in the rows of their related elements.After fragmentation, operations from the two lists are separately classified according to elements, which are shown in the table as Left Operations and Right Operations.In the succeeding procedure, only operation pairs (each pair contains one operation from the left and right columns) in the same row are compared to detect conflicts.

Conflicts between Primitive Operations. Conflicts between two primitive operations can only occur when both
operations operate on the same element in a fine-grained model versioning system.In this case, detection can be implemented by establishing a map from the changed elements to the operations that cause the changes.A conflict can only occur if an element maps operations from both operation lists, which can be expressed as follows.In this case,   indicates the element operated by primitive operation .Concrete conflict rules for primitive operations can be found in the following [15]: for ,  ∈ PO,  ∦   ⇒   =   . (8)

Conflicts Associated with Composite
Operations.Multiple elements are frequently involved in composite operations; hence, a sophisticated approach is required to accomplish precise detection.Conflicts between a primitive operation and a composite operation occur if the primitive operation changes the same element in a different manner from that of a suboperation in the composite operation, which can be expressed as follows: However, this is not a necessary condition; that is, other cases that result in conflicts also occur.For example, suppose a  operation  that requires that all subclasses have one same attribute  and a delete operation  that removes  of one subclass.Operation  does not conflict with any suboperation of  because  also removes  from that subclass; however, conflict still occurs because the precondition of  is violated (i.e., the attribute  of one subclass is missing).To detect conflicts associated with composite operations, a pattern-matching strategy is employed.
Definition 4 (equivalence pattern).Operation , which matches the equivalence pattern of composite operation , has the same effect as  on a model instance.A composite operation may have several equivalence patterns, with each pattern containing a set of operations and their internal dependencies (c.f.Relation 4).Thus, an equivalence pattern defined by its contained suboperations  and internal dependency relations  between suboperations can be expressed as ⟨, ⟩.We denote   () as an equivalence pattern of operation , and   ()  ⊃   () if   () contains all the rules ( and ) specified by   ().
Equivalence patterns can be derived from the suboperation sequences in Table 1.First, the suboperation set  can be directly generalized from the definition.Then, according to the dependency rule in Section 2, dependency relations  can be obtained by checking the preconditions and postconditions of these suboperations.Some example equivalence patterns, which help navigate the logic structure of composite operations, are represented in Table 2.
Definition 5 (compatibility pattern).Operation , which matches the compatibility pattern of a composite operation , does not conflict with .A composite operation may also have several compatibility patterns.A compatibility pattern can be defined in a similar manner as equivalence pattern, that is, by suboperations and their relations.Definition 6 (minimal compatibility pattern).A compatibility pattern with a minimal set of suboperations is called a minimal compatibility pattern.Given that several compatibility patterns may exist, attempting to match each of them is a complicated task.Thus, defining a pattern that specifies the minimum set of rules, which can represent several similar patterns, is useful.The minimal compatibility pattern reflects the intention of this composite operation because it is a common set of several compatibility patterns.We denote   () as the minimal compatibility pattern of operation .

𝑚
⊃ is also applicable to compatibility patterns.For example,   ()  ⊃   () indicates that operation  matches all the rules specified by pattern   ().
In this algorithm, the input is the fragmentation result, such as the right table in Figure 3, and the output  contains conflict operation pairs.Apart from ,  records pairs that are possibly in conflict, whereas  records those that are not in conflict.Pairs to be checked are retrieved from the left and right operations (represented by  and ℎ) in each row of the fragment table (lines (4)-( 5)).In lines ( 8)-( 9), operation pairs that conform to Rule 1 are placed under .Meanwhile, operation pairs that conform to Rule 2 can be checked directly (lines (10)-( 12)).Checking Rule 3 relies on the results of the other two rules, and, thus, operation pairs that potentially conform to Rule 3 are temporarily added to  (lines ( 13)-( 14)) and are retested later (lines (23)-( 27)) after checking all operation pairs from both sets.
In our example, operation pairs  1 /   2 / 1 conforms to Rule 3 because  1 / 1 has been checked with   ( 1 ), which is matched by   ( 1 ).Therefore, no conflict exists in these three pairs of operations.

Evaluation
In this section, we evaluate our proposed approach on several sets of input data.To illustrate the effect, we compare our approach with an existing operation-based model versioning system and provide an analysis of the results.

Test Cases.
Test cases are from a subproject of a modeling system called Concept Modeling Tool (ConMoT).ConMoT aims to provide a modeling platform for developers from different companies.Several UML models are supported, such as class diagrams and entity relationship diagrams.We compare our approach with EMFStore [9], an operation-based model versioning system that implements functions, which include model repository, operation recording, and conflict detection and resolution.We transplant our models and algorithms into EMFStore.The models in ConMoT are specified by EMF Ecore [16], which is the same technology as EMFStore, and thus they can be integrated into EMFStore.We transform several composite operations such as PullUpField into formats composed by EMFStorespecified operations, whereas primitive operations are the same as those in EMFStore.Some methods are employed to ensure that the conflict detection mechanism of EMFStore will work well on our models.For example, most of the elements are created beforehand in case newly created elements will not correspond in the two compared operation lists considering that EMFStore recognizes corresponding elements through a unique ID.
Four sets of input data are provided in Table 4.Each test case contains two operation lists of parallel-edited models.The PO-Left and CO-Left columns show the operation numbers of primitive and composite operations in one operation list, respectively, while the PO-Right and CO-Right columns show operation numbers in the compared operation list.On average, approximately 50 elements are involved in Case 1 and Case 2, while approximately 110 are involved in Case 3 and Case 4. Most operations contained in Case 1 and Case 3 are primitive operations, with a small portion of composite operations.In Case 2 and Case 4, a higher proportion of the operations are composite.

Results and Discussions.
We measure our approach through precision and recall, which are two indicators derived from the information retrieval scenario.In this study, precision is equivalent to the ratio of correctly detected

Rule 1 .
Two composite operations are not in conflict if an equivalence pattern of either operation satisfies the rules of the minimal compatibility pattern of the other operation, which implies that either operation complete the main task of the other operation.Consider for ,  ∈ CO,  ‖  ⇐   ()  ⊃   () ∧   ()  ⊃   () .

( 10 )
Rule 2. Operation  is not in conflict with composite operation  if the equivalence pattern of  satisfies the minimal compatibility pattern of  and is satisfied by the equivalence pattern of .An operation is not in conflict with a composite operation if it accomplishes the essential part of the composite operation.Consider for  ∈ ,  ∈ CO,  ‖  ⇐   ()  ⊃   () ∧   ()  ⊃   () .

( 11 ) 3 .
Rule Operation  is not conflict with composite operation  if an equivalence pattern of  is satisfied by an equivalence pattern of  and the minimal compatibility pattern of  is satisfied by another operation .Once the minimal compatibility pattern of  has been satisfied by , other operations that construct part of  do not conflict with .Consider for  ∈ ,  ∈ CO,  ∈ ,  ‖  ⇐   ()  ⊃   () ∧   ()  ⊃   () .
Relation 1 (equivalence).Two operations  and  are V if they operate on the same set of elements  and share exactly the same preconditions  and postconditions   .Relation 2 (composite).Two operations  and  can be composed if () ⊃   holds; that is, the preconditions of operation  are satisfied after applying  to an element set .The composed operation is denoted as  ∘ , which indicates that  should be applied before .
and  are independent if neither  ≺  nor  ≺  holds.

Table 1 :
Definition of composite operations by suboperations.
Removing redundant operations: for a state-based VCS, a minimized change set can be calculated by model comparison.Meanwhile, in an operationbased VCS, redundant recorded operations are inevitable if all operations are recorded after execution.(ii) Detecting conflicts effectively: in theory, each operation in one list should be compared with each operation in the other list to obtain a precise result.
However, some comparisons are unnecessary because the compared operation may not influence one another.Therefore, analyzing only necessary pairs of operations is essential to improve efficiency.

Table 3 :
Excerpt of minimal compatibility pattern table.
1 ,  2 / 1 , and  3 / 6 are compared. 3 and  6 are exactly the same operation, which indicates that Rule 1 is satisfied.Operation pair  1 / 1 complies with Rule 2 when referring to the equivalence pattern table and the minimal compatibility pattern table.Operation pair

Table 4 :
Test cases under different scenarios.