It may be more complicated than that. The elements within an exported package may have all kinds of relationships with elements not contained therein.
In case of classifiers, realizations, dependencies and generalizations the desired behaviour seems obvious: preserve the target GUIDs and resolve them when importing for duplication, or, if they cannot be resolved, keep them as stubs and resolve them when the package containing the targets is being imported.
But what about associations? Isn't the concept of source and target for an association UML 1 legacy stuff anyway?
Well Frank, I don't believe so... I believe the concept of
Directedness is essential to good modelling. (see:
Directedness and Navigability of Edges) I concede that
on the paper you can't tell, but, in my view that's a rendering problem - which can be partly alleviated by the little direction indicator ([ch9658]) (which incidentally took me about 15 mins to find and wouldn't have if I hadn't remembered finally that it was associated with a label on the edge - so no label, no indicator... EAUI! Roy -
Help needs tidying up here. The menus says direction indicator, but help won't find it!) But back to the topic. In our modelling, we use directedness extensively to encode information about the nature of the relationship between the two vertices.
In XMI 2.1. the notion of association source and target is contained only in the extensions section. In the model section there are two ends for an association and that's it. Who is source and who is target is completely arbitrary.
EA however marks the element from which the connector has been dragged as source and the one to which it has been dragged as target, and puts the association itself into the package containing the "source" element.
I stand to be corrected, but I believe it it doesn't attach the edge to
any package, only to the two vertices at either end. When exporting to XMI, EA (correctly) puts the association in
both packages.
So what should happen with associations contained in the package reimported for duplication when their target is outside? I guess we would want them to be duplicated as well, to point from the duplicated source to the old (common) target.
Here, again, I think it gets back to the three use cases I mentioned. In the case of the
Copy use case you probably do want them duplicated, in the case of the
New use case you probably don't. But I guess this could be an additional option (perhaps defaulted as mentioned).
The trap here is that you don't see in your diagrams who is source and who is target. You may have inadvertently reversed the direction, or dragged it the other way in the first place, without any difference showing in diagrams. And without any difference in the uml:Model section of an XMI 2.1 export, come to that. And it will simply be missing then after duplication because it will never have been within the exported package.
As I mentioned, there IS a rendering issue here. My personal view is that in addition to the formal UML direction indicator, EA should have an option on the diagram as a whole to add a (discreet) indicator on the edge itself to show the direction.
And there are many more things, like RefGuid tagged values, method overrides and such. It will take some time to think it through, and we might end up needing a tree view dialog showing all stubs and check boxes to control which kinds of relations or which individual relations are to be handled in which way.
Agreed it's more complicated; but we can move toward a final solution by stepwise improvement. I think at least allowing for three (fairly) standard use cases is a start. Especially if allied with more comprehensive information about what happened during the read in.
My AU$0.05
Paolo
