EMF Compare/API MetamodelRequiresLink
THIS PAGE IS OUTDATED AND IS NOT SCHEDULED TO BE UPDATED
A reference 0..n has been added in the "diff" meta-model to manage dependencies between difference elements (DiffElement). This reference is named "requires". There is an opposite one which is named "requiredBy".
This reference may be used from different levels.
- The "requires" link is automatically filled in the generic EMF Compare core, deducing these dependencies from the dependencies between the model objects referenced by the difference elements.
It is considered that object 'A' depends on object 'B' if 'A' owns a reference to 'B' at least. The aim is to keep the integrity of the dependencies between model objects, after any partial merge process. So, if 'A' has to be copied during a merge action, its references to 'B' have to be copied too and, consequently, if 'B' does not exist in the target model, it has to be copied. In this case, the difference on 'A' will own a dependency to the difference on 'B', through the 'requires' link and the related A's merger will interpret this dependence to respect this "technical" rule.
Only two kinds of difference are concerned by the filling of this link:
- The model element changes: It is the previous example. 'A' does not exist in one side of the comparison.
- The reference changes: 'A' exists in the both sides but it is one of its references which changed (for example: from 'C' to 'B'). If 'A' is copied, 'B' must be copied too. The differences referenced by the "requires" link will always be model element changes of course (the presence of the related model objects condition the references integrity).
The default merger takes into account these dependencies when it is requested to copy the model object references.
Below, a scheme to clarify these two cases:
- The "requires" link may be used to store the encapsulated differences from a difference extension. References to other difference extensions may be added, through this link, from a difference extension, to manage dependency specific business cases.
So, a default extension merger exists to merge difference extensions. These ones are just pointers to others encapsulated differences or extensions. This merger delegates the merge to the related mergers. In all the cases, the encapsulated differences are merged. The required extensions are merged in relation to a "business" rule. Below, an example to manage the merge of a profile of a UML model. The "business" rule is: If a profile application is deleted from a model, then all of the related stereotype applications must be deleted too. In an other hand, the application of a profile can be executed alone.