MergeAdvisor
Last Updated on Friday, 01 June 2012 14:54 Written by Administrator
A Recommender System for Model Versioning
Despite steady advancements in managing the evolution of software models, merging conflicting models remains a challenging undertaking. The modeler in charge of merging has to navigate through several artifacts to collect information necessary to effectually reproduce changes and conflicts. Recently, conflict aware merge strategies have been proposed, which integrate those solitary artifacts and provide a unified, tentatively merged model. Even if this model turned out to be helpful for analyzing the evolution, resolution support moves hardly beyond the choices "take my change", "take their change", or "abandon all changes and provide a new manual solution". As the same types of conflicts are likely to reoccur, mechanisms providing more sophisticated resolution support would be appreciated.
Thus, we present MergeAdvisor, a recommender system for conflict resolution. MergeAdvisor is a generic framework for conflict resolution acting on top of a tentatively merged model, called Conflict Diagram. Conflicts in conflict diagrams are annotated with stereotypes of the versioning profile. MergeAdvisor matches those stereotypes and suggests matching conflict resolution patterns, which are stored in an extensible pattern repository. The user in charge of merging may select a suggested conflict resolution pattern and resolve the conflict.
Conflict Resolution Example
Consider the following example depicted in the figure below. Two modelers, Harry and Sally, check out a model Vo from a central versioning repository. Both add an equally named class to the model and check in their revisions Vr1 and Vr2, respectively. The second commit may be prevented by the repository, as conflict is detected. Each class shall have a unique name within the model. As Harry and Sally both added a class named X, and the conflicting version Vc would therefore contain two classes X, an Add-Add conflict is reported.
MergeAdvisor may match the conflict's context consisting of the conflicting classes and their respective conflict annotation. Based on this information, the following conflict resolution patterns are conceivable.
M1: The conflict may be resolved by neglecting the change of version Vr2 and applying only the change of version Vr1.
M2: On the contrary, the conflict may be resolved by neglecting the change of version Vr1 and applying only the change of version Vr2.
M3: The features of both classes may be merged to one class X.
M4: Both classes remain their structure, but get renamed to fulfill the unique name constraint.
M5: Both classes are renamed and common features are pulled to a superclass called X.
