Abstract
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.
1. 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 first-class 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 parallel-edited 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 Gang-of-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 conflict-detection 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.
2. 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:
After an operation is defined, several crucial relations among operations are then defined as follows. Additional properties of operations are discussed in [12].
Relation 1 (equivalence). Two operations and are 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 .
Relation 3 (conflict). Traditionally, an operation pair and are in conflict if either of them makes the other inapplicable or if their execution sequences lead to different results. We denote this relation as . Consider
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.
Relation 4 (dependency). The dependency rule is expressed as follows, which conveys that dependency can be affirmed if the preconditions of one operation depend on the postconditions of the other. We denote if the execution of depends on . Consider and are independent if neither nor holds.
Definition 3. Operations are classified into two sets according to whether an operation can be composed by simpler operations: primitive operations and composite operations ; that is, . The former often refers to an activity 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:
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 is edited in parallel by two developers. Thus, two derived versions, and , 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 , 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 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 , the operations are recorded as to . First, the common attribute from and is extracted to their superclass . Then is pushed downward. Afterwards the method is moved from to and the same method is removed from . Finally a new class is added and the superclass of is set to .
In version , the operations are recorded as to . First, the common method is extracted from and to their superclass . Then, a new class is created, with its superclass set to . Subsequently, the superclasses of and are set to the same class and their common attribute username is pulled upward to . Finally, a new class is created and its superclass is set to .
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:(i)Removing redundant operations: for a state-based VCS, a minimized change set can be calculated by model comparison. Meanwhile, in an operation-based 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.
3. 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.
3.1. 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 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 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 . Operation pairs and can be similarly compacted.
3.2. 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 and , 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.
4. 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.
4.1. 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
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.
4.2. Conflict Detection with Compatibility Pattern
4.2.1. 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]:
4.2.2. 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 . The symbol is also applicable to compatibility patterns. For example, indicates that operation matches all the rules specified by pattern .
The table of minimal compatibility patterns for our example is labeled as Table 3. Compared with equivalence patterns, compatibility patterns have fewer specified rules. For example, the suboperation of operation is absent from the minimal compatibility pattern and the suboperation that can represent the intention is reserved.
After operation patterns are specified, several rules are established to detect conflicts in the presence of composite operations.
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
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
Rule 3. 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
The algorithm that detects conflicts by following the aforementioned rules is illustrated in Algorithm 2. and are used to check if and , respectively. Some detailed codes are dismissed for understandability. For example, a code that guarantees each operation pair is checked only once.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 , , and are compared. and are exactly the same operation, which indicates that Rule 1 is satisfied. Operation pair complies with Rule 2 when referring to the equivalence pattern table and the minimal compatibility pattern table. Operation pair conforms to Rule 3 because has been checked with , which is matched by . Therefore, no conflict exists in these three pairs of operations.
5. 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.
5.1. 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 EMFStore-specified 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.
5.2. 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 conflicts to all detected conflicts. Meanwhile, recall is equivalent to the ratio of correctly detected conflicts to all actual conflicts. Given that the actual number of conflicts cannot be obtained through a perfect approach, it is estimated through the sum of correctly detected conflicts of both approaches.
The test results are shown in Table 5. In Case 1 and Case 3, in which the ratio of primitive operations is high, both approaches perform well (high ratios of approximately 90%). However, ConMoT achieves higher precision and recall than EMFStore when composite operations are more, as shown in Case 2 and Case 4 (approximately 85% versus 70%). The number of elements does not influence the results considerably, as demonstrated by comparing Case 1 with Case 3 (or Case 2 with case D).
The differences are attributed to EMFStore detecting conflict that concerned composite operations by comparing their contained primitive operations, whereas ConMoT compares them as integrated operations. EMFStore may misjudge mutually compatible composite operations as conflicts, which decreases its precision rate. Moreover, EMFStore may fail to detect conflicts when one operation destroy the preconditions of the other operations, which results in a low recall rate.
In conclusion, our proposed conflict detection approach, which regards composite operations as a whole, can perform well in operation-based versioning systems, particularly under circumstances where composite operations such as refactorings are frequently executed.
6. Related Works
In this section, we discuss related works in model versioning, particularly conflict detection techniques.
A rapid improvement in model versioning has been witnessed in recent years. Although many state-based model versioning systems have been developed [17, 18], operation-based systems have demonstrated their advantages. For example, model modifications can be immediately retrieved from change logs. CoObRA [8] is an operation-based system developed for UML models. In this system, composite operations are regarded as a set of primitive operations, and conflict detection is performed at the primitive operation level. EMFStore [9] is another operation-based modeling system that supports storage and versioning of EMF-based models. EMFStore records both primitive and composite operations and provides hooks for customized composite operations. Although this system can fully detect conflicts among primitive operations, conflicts among composite operations are detected according to whether their contained primitive operations are in conflict. The aforementioned systems do not conduct conflict detection at the composite operation level, which is the objective of our approach.
Some approaches can detect conflicts that concern composite operations. Gerth et al. [19] exploited formalized terms for business process models (BPMs), which can detect both syntactic and semantic conflicts. Given that this approach employs the structural characteristics of BPMs, for example, a maximum of one link exists between two nodes, it cannot be applied in other models used in MDE. Brosch et al. [20] detected conflicts in composite operations by matching the preconditions and postconditions of operations in a state-based environment, as well as providing precise recommendations for conflict resolution. Mens et al. [21] detected UML refactoring conflicts through graph transformation and by specifying critical pairs. Rules were specified where conflicts might occur and corresponding resolutions were provided. However, specifying all conditions where conflicts can occur between two operations may be a complex process. By contrast, our approach specifies patterns for each composite operation.
7. Conclusion
In this study, we introduce an approach for detecting conflicts among change lists in an operation-based environment. We focus on detecting conflicts at the composite operation level, which can improve the accuracy of conflict detection by considering the intention of operations. Operations are initially preprocessed to remove redundant operations and improve performance. Then, operations are classified into fragments according to their operated elements, and conflicts are located through pattern matching.
We compare our approach with an existing model versioning system, and the results show that our approach is effective. However, considerable work still has to be performed in the future, including detecting conflicts on model inconsistency and resolving conflicts according to the detection results.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.