Inconsistency Resolution in Merging Versions of Architectural Models

Abstract

Abstract-State-of-the-art optimistic model versioning systems, which are critical to enable efficient team-based development of architectural models, are able to detect and help resolve basic conflicts arising during the merging of model versions. However, it is often overlooked that model merging may also cause severe syntactical and semantic inconsistencies. In this paper, we propose an approach to guide the resolution of inconsistencies detected in a merged architectural model. Our approach automatically finds and presents to the software architects all solutions for resolving all inconsistencies arisen during the merging of model versions. For inconsistencies that preexist in the model, our approach is able to suggest exactly which model elements should be changed to resolve them. Our approach is built upon a repair generation which can quickly derive resolutions for an inconsistency by examining its static and dynamic structure and forming concrete repair actions from changes in the versions to be merged. An empirical validation on a range of industrial models has demonstrated that our approach is scalable to both large models and large differences between model versions.

Automated Model Merge by Design Space Exploration

“…We incorporate two kinds of operations in the exploration based model merge: generic merge operations [30] and (domain-specic) composite operations [14,23] (such as refactorings, or repair rules). Each operation is captured by (graph) transformation rules [16], which consist of a precondition described as a graph pattern (using the EMF-IncQuery language [10] in our case) and an action part which captures model manipulations.…”

“…Based on the model comparison technique, the approaches may be classied into state-based and operation-based. [1,2,13,14,25,30] and DSE Merge are state-based as they execute a comparison process between model states. However, [23] [1,2,13,25,30] are semi-automated as they use a two-phase process: (i) they apply the non-conicting operations and then (ii) let the user prioritize and select the operation to apply in case of two conicting changes.…”

“…This always results in a single solution due to the manual resolution by the user. In comparison, [14,23] and DSE Merge resolve the conicts automatically in dierent ways and oer several solutions.…”

“…[23] applies the input operations which are composite refactorings in their case. [14] uses basic generic operators for conicts but generates composite operations as repair plans from the description of inconsistency constraints. Our DSE Merge approach allows to combine both generic and domain-specic composite operators in the form of change-driven transformation rules.…”

“…[23] uses two xed goals which are the base of the conict resolution. [14] provides support for incrementally detecting violations of inconsistency constraints. [13] is connected to an additional model checker component [11] which allows to check OCL constraints as goals.…”