The model element merge feature is very useful when two model elements are realised to represent one and the same thing, but each has its own set of associations and diagram representations. However, I have found that the merge is at the model element level and does not take account of duplicate associations and merge (or at least offer to merge) them. It simply adds all of the associations to the resultant model element. Moreover, when each model element (e.g. of type class) has generalisations to (or specialisations from) a common model element the merge fails with an error message that there are duplicate generalisations (or specialisations). The workaround is to remove the duplicate generalisation(s) from one of the candidate model elements, but in doing so the diagrammatic representation of these generalisations is also removed. This creates a manual task of finding all the impacted diagrams and then fixing them afterwards. A similar problem is created by the merging of all of the associations from both model elements onto the resultant model element. This creates model ambiguity and confusion, and requires a manual intervention to remove the duplicate associations and fix all of the affect diagrams.
Thus, please consider the model element merge feature to account for duplicate associations (inc. generalisations) and merge them, whilst persevering there graphical representations. There is a clearly some question about what should constitute a duplicate association, for which either a sensible level of detail in specification of each association can be considered, or an interactive merge assistant devised to walk the user through the choices.
... View more