Depending on how the contributor models have been modified a compare/merge session may show different kinds of changes. Below we go through all the different types of changes you may encounter when comparing or merging two models.
An Add change means that a new element has been added to the left contributor model. The change description is on the form
Add <element> to <location>
where <element> describes the new element and <location> describes where in the model it has been added.
For example, the change shown above means that an attribute (a.k.a Property) "flag" has been added to the capsule "TopCap".
A Delete change means that an element has been deleted from the left contributor model. The change description is on the form
Delete <element> from <location>
where <element> describes the deleted element and <location> describes from where in the model it has been deleted.
For example, the change shown above means that an operation "someOp" was previously contained in the capsule "Capsule1", but has now been deleted from the model.
A Modify change means that an element has been modified, so that one of its properties has changed in the left contributor model compared to what it is in the right contributor model. The change description is on the form
Modify <property> of <element> from <value before> to <value after>
where <element> describes the modified element, <property> specifies which property of the element that was changed and <value before> and <value after> describes the value of the property before and after the change.
For example, the change shown above means that the type of the attribute "a" was changed from "double" to "char".
A Move change means that an element has been moved within a model. There are two ways in which an element can be moved. Either it is moved within the same owner element, or it is moved to a different owner element.
In the first case the element is reordered within its container collection, so that it still has the same owner element after the move. In this case the change description is on the form
Reorder <element> within <owner>
where <element> describes the moved element and <owner> is the owner element within which the element has been moved.
In the second case the element is moved so that it has a different owner element afterwards. In this case the change description is on the form
Move <element> from <old owner> to <new owner>
where <element> describes the moved element, <old owner> is the owner element before the move, and <new owner> is the owner element after the move.
Let's look at two examples:
This change means that the property (i.e. attribute) "a" was reordered within the capsule "HelloWorld". That is, after the move the capsule still contains attribute "a" but at a different position in its list of attributes.
This change means that the attribute "branched" was moved from the capsule "HelloWorld" to the class "Class1".
This change means that an element was absorbed from a fragment file (.efx), to instead be stored in a model file (.emx). The change description is on the form
Absorb <element> from <fragment file>
where <element> describes the element that was absorbed from the fragment file and <fragment file> is the affected fragment file that no longer stores the element afterwards.
For example, the change above means that the class "FragmentClass" was previously stored in the fragment file "FragmentClass.efx" but was absorbed into the model file instead. Below the fragment absorb change you can see that this change in fact is implemented by first deleting the class, so that it gets removed from the fragment file, followed by adding it again into the model file that now will store it instead.
Note that the model does not change because of a fragment absorb change. The class is deleted from the same location in the model at which it later is added again. The only difference is in how the model is stored in files.
This change means that an element was separated out into a model fragment file (.efx). The change description is on the form
Separate <element> into <fragment file>
where <element> describes the element that was separated out to a fragment and <fragment file> is the fragment file that stores the element afterwards.
For example, the change above means that the class "Class1" is now stored in the fragment file "ModelFragment_1.efx". Below the fragment separation change you can see that this change in fact is implemented by first deleting the class, so that it gets removed from its previous file, followed by adding it again into the fragment file.
Note that the model does not change because of a fragment separation change. The class is deleted from the same location in the model at which it later is added again. The only difference is in how the model is stored in files.
A change of this type means that a view (i.e. a symbol or a line) on a diagram has been repositioned or resized. The change description has the following form for a symbol position change:
Drag [View] <element> on diagram <diagram>
and the following form for a symbol size change:
Change Size of [View] <element> on diagram <diagram>
where <element> is the element whose view was repositioned or resized and <diagram> is the diagram where the view is located.
For example, the change above means that a state symbol showing the state "CompositeState" was moved on a state machine diagram. The details of how it was moved can be seen in Modify changes for the X and Y coordinates that are nested below this change.
When the layout of a line has changed, the change description has the following form:
Modify layout of [View] <element>
where <element> is the element whose line was rerouted.
For example, the change above means that a line for transition ”t1” has been rerouted. The detailed changes that are nested below it give some hints on how the line was rerouted, but usually it’s easier to see this visually in the Diagram tab.
This type of change is used for changes that are not caused by any modification you have made to the model yourself, but that the Compare/Merge tool itself has induced when loading the contributor models. You may see such changes if you compare or merge models that have been created in older versions of Model RealTime. They will only appear the first time you compare or merge them. Once the models have been saved in the new Model RealTime version these changes will no longer appear in future compare/merge sessions.
One example of this kind of change is when additional information has been added in model files in order for Compare/Merge to be able to present changes in a better way. For example, in order to be able to show the name of the event that is referenced by a transition trigger that has been modified, it is necessary that the event name is available in the model file where the transition trigger is stored. This is because Compare/Merge may only get that single model file to operate on, and will then not be able to find out the name of the event unless it is present in that model file. Because of this recent versions of Model RealTime now stores the event name as an additional piece of information for transition triggers. However, the first time you compare or merge against a file that was created in an old version of Model RealTime where this information was not present in the file, you will get a Compare/Merge Induced Reference Modification. There is a filter available in the Delta Tree Configuration button menu that you can use for hiding these kinds of changes.
This type of change is used for elements that get indirectly deleted from the model when another element gets deleted, even if they are not contained within it. For example, when you delete an element which has stereotypes applied, the stereotype instances will be deleted too. However, since the stereotype instances are stored separately from the element to which they are applied, these deletions are not a structural consequence of the element deletion, but more of a logical consequence (i.e., it usually does not make sense to keep such stereotype applications once the element has been deleted).
Here is an example:
The "Header Preface" code snippet for a class is stored by means of a stereotype. When the class is deleted, so is the code snippet.
There is a filter available in the Delta Tree Configuration button menu that you can use for hiding these kinds of changes.