Unexpected behavior for structure changes when doing model merge

[ThoWi]

We are using Sparx EA v14.
When trying ”Merge model XMI into current model” we run into some unexpected behavior which in some cases leads to loss of data.
The scenario is as follow:
1.   We have a databased-stored repository, lets call it “Master”, which have a main package containing a package structure with classes, class attributes, use cases and nested activities.
2.   We then made a project transfer from “Master” to an eapx-file, lets call it “Branch_A.eapx” and created a baseline of the main package in Branch_A.eapx.
3.   Within the main package in the Branch_A.eapx repository we then did some structural changes, by moving some elements to new destinations within the same main package. The new destinations are both existing packages/elements and new packages/elements.
4.   Finally, we export the main package together with a merge-file based on the initial baseline and using ”Merge model XMI into current model” in the “Master”-repository to merge the changes from Branch_A.eapx into “Master”.

The result after merge is that elements that have been moved to already existing packages or elements are not moved and in some cases lost after merge. However, elements that have been moved to packages/elements created in the “Branch_A.eapx”-repository remains in those destinations after merge.

We have also observed that when moving an element from a parent element to another location within the main package and then deleting the old parent element from the model, the moved element is lost after merge.
This rises the questions:
•   Have we used XMI-export and merge in an incorrect way?
•   Is this kind of structure changes known limitations in Sparx  EA? If so are there a public list of all kind of limitations available?
•   Is there a suitable workaround for handling structure changes in combination with XMI-merge?

/Thomas

[Geert Bellekens]

Thomas,

I'm afraid the only answer is, that merging models is simply not feasible with the current features in EA.

You might be able to with specialized tools such as LemonTree from LieberLieber but my personal experience is that it is generally not worth the effort.

So unless you have some very good reasons to want merging (such as: direct code generation from the model) I would strongly advice against merging models.

Geert

[ThoWi]

Geert,

Thanks for very quick reply, even if your answer was not what I hoped for.  If it had worked, it would have been a nice way to enable branch/merge scenarios.
I have looked at presentations of Lemontree, but as I understand, it does not (yet?) support database repositories, which is needed in our case of performance and scalablility reasons.

Thanks,
Thomas

[qwerty]

Yes, it works only on EAP files. Anyhow, you should say good bye to the idea of handling UML models as code. They are not. I think that this misconception had been infiltrated in the past and now you can't get rid of that poison. A model is always reflecting a current state (from a recent past) to understand how to proceed in the future. Code is much more flexible. You have Lego parts that can be made to work in various conditions. You never would take parts of any model to implant it in your model. And working on multiple branches will just spread grief (see DeMarco's Peopleware).

q.