xmi import behaviour

[Heather Wallace]

We have a need to provide a stable architecture baseline to another project team (Project Team B), who will then trace their own project artefacts (Model A) to our artifacts (Model B).  After this, we need to provide that project team with any updates that occur, without disturbing the traces that are in place.

I had thought we would use a simple mechanism of exporting Model A as xmi for import as Model A into the Project Team B EA project, alongside Model B.  Project Team B would then establish traces between Model A and Model B.  When changes occurred in Model A, the whole of Model A would be reimported into the Model A package in the Project Team B EA project.

When I trialled this, I found the re-import perfectly represented the changes that had occurred in the source EA project (additions, updates and deletions of elements and relationships), but destroyed any links between Model A and Model B artefacts.

I was expecting this to be successful because of the way the DOORS integration works, whereby we have established many traces with requirements as source or target that survive successive re-imports of the requirements.

Any suggestions?

[qwerty]

You made an [highlight]import[/highlight], not a [highlight]merge[/highlight]. You might use a baseline comparison, but I personally would not recommend that. Instead try to find a way that separates both packages for the two groups and the requirements in a central package. Now when you add traces from the individual packages [highlight]to[/highlight] the requirements you will be save.

q.

[Heather Wallace]

Cheers,
I can see way you suggested avoiding baseline compare and merge.  This is a relatively small model on a local eap and it looks as though it may be hours before I know if it had the desired effect.

The packages were already completely separate, but the relationships were mainly from elements in the Model A package that was reimported to elements the Model B package.  When the merge is complete I'll run another import trial with the relationships reversed.

Is that what you were suggesting i.e. to stick with the import approach?  Or is there another way to achieve a merge?

Heather

[qwerty]

That's what I would suggest. Merging in any way is quite tricky. I've seen many projects stumbling over that without getting it. In your case it should be doable since connectors belong to the From element.

q.

[Heather Wallace]

Wow - it took circa 20 hours to run the merge and it still deleted the relationships from the A model to the B model.

I tried making a relationship in the reverse direction from B to A and this survived a re-import of A, so we have a workaround at least.  It also works if the direction of the relationship is set as Destination -> Source, so we can have the arrows pointing in the right direction.

Based on these results I'm even more surprised that we have been able (in a different model) to maintain relationships in both direction to requirements imported and frequently refreshed from DOORS.

[qwerty]

I guess the DOORS import is a bit more tricky. It has some code which is optimized for synching which is different from the normal xml import.

q.

[Uffe]

The DOORS synch comparison is not really relevant: DOORS is not a modelling tool and the synch function isn't based on XMI.

I've done some basic tests and I get the same behaviour: connectors whose target/supplier ends are in the XMI:ed package are preserved, while those whose source/client ends are in that package are lost.

I think this is pretty reasonable, given that most connectors are asymmetric. What doesn't make sense to me is the direction of your connectors.

Typically you'd use relationships like generalization, realization and dependency for these purposes and I don't see why you'd want to draw them from the reference architecture to the derived project-specific models.