A categorization for conflicts in model versioning

Abstract

To coordinate different versions of a software model, edited by modelers in parallel, various model versions need to be merged to one consolidated version. Therefore, adequate tool support in terms of version control systems (VCSs) is considered essential. Diverse approaches evolved for merging model versions including different conflict detection methods. Indeed, only a limited consensus about possible categories for conflicts exists. A common terminology and a categorization of possible types of conflict are missing.In this article we propose a categorization for conflicts in model versioning along with an assessment of levels of severity: a base for future discussions and comparison of approaches to conflict detection on models.Eine Kategorisierung von Konflikten in der Modellversionierung.Zur Koordination der verteilten Bearbeitung von Software-Modellen mü ssen die entstandenen Modellversionen wieder zusammengefü hrt werden. Daher wird eine zufriedenstellende Toolunterstü tzung in Form von Versionierungssystemen (VCSs) als wesentlich erachtet. Es haben sich unterschiedliche Ansä tze fü r das Zusammenfü hren von Modellen einschließlich Konflikterkennungsmethoden entwickelt. Dabei herrscht nur eine eingeschrä nkte Einigkeit ü ber eine mö gliche Kategorisierung von Konflikten. Eine gemeinsame Terminologie und Kategorisierung fehlen.In diesem Artikel wird eine Kategorisierung von Konflikten in der Modellversionierung zusammen mit einer Bewertung der Niveaus der Schwere von Konflikten vorgeschlagen: eine Basis fü r zukü nftige Diskussionen und fü r den Vergleich von Konflikterkennungsansä tzen fü r Modelle.Schlü sselwö rter: Versionierungssystem; Konflikterkennung; Model-Management; modellgetriebene Softwareentwicklung

Automatic resolution of model merging conflicts using quality-based reinforcement learning

“…Apart from the given conflict reasons, different types of model merging conflicts can be categorized into syntactic and semantic conflicts, which respectively are defined by considering the syntax and the semantics of models [17]. Although there exist various categorizations of conflicts, in this paper, we follow the categorization proposed by Altmanninger and Pierantonio [18].…”

“…Syntactic conflicts do not necessarily produce language syntax violations. For instance, contradicting modifications for an element (e. g., renaming a class with two different names) or updating the same model element by adding different properties constitutes a syntactic conflict [18]. This type of conflict may be detected by checking the structure of models and comparing the similarity of elements.…”

“…The parallel control flow in UML state machine is a semantic conflict that can be revealed by considering the semantics of the used modeling concepts. Moreover, the inheritance cycle is a semantic conflict in which the language constraint "there must not be any inheritance cycle in UML class diagrams" is violated [18]. Semantic conflicts are divided into three categories: Static semantics, behavioral semantics, and semantic equivalence [4].…”

“…Where the combination of modification leads Check to inherit Debit (indicated by Sally), and Debit inherits Check (indicated by Harry). As mentioned in Section 2.2, C1 is a semantic conflict [18] since it can be detected only by considering the validation rules of the UML class diagram. Available actions for C1 are as follows: A1 : Reverse the order of changes application by applying Harry's change at first.…”

“…The next conflict is C2, a syntactic conflict where modelers add two different multiplicity values for the end property of class Customer in the association belongs_to. C2 occurs due to the concurrent application of contradicting changes to edit the same property with different values that would report a syntactic conflict for the association [18]. The available actions for C2 are as follows:…”