BUG: Relationship between package elements and XMI

[Essnet]

Hi folks,

There's a critical issue since build version 804 (I’m not sure if previous builds maybe affected too).

Our environment is based in version control (SCC) and individuals EAP files.

The bug: Packages in check-in (locked) have been changed due the load (get latest or check-out) of other packages that, in some moment, have relationship between elements.

This bug is not critical. It's catastrophic!
See steps to reproduction below.

1 - Create a new model EAP.

2 - Select Use Case model.

3 - Create package 'A' in use case model view.

4 - Create package 'B' in use case model view.

5 - In package A, create a use case diagram.

6 - Create one use case in this diagram with the name 'Use Case1A'.

7 - Repeat the steps 5 and 6 to package B using the name 'Use Case1B' to the use case.

8 - Drag and drop a simple link of 'Use Case1A' to diagram in package B.

9 - Create a extends link from 'Use Case1B' to 'Use Case1A'.

10 - Export packages A and B to XMI files A1.xmi and B1.xmi respectively.

11 - In diagram from package B, delete from model the link between use cases and the simple link of 'Use Case1A'. Only the 'Use Case1B' will continue in diagram. Save changes. (In this step, we expect that no changes was applied in the package A)

12 - Export packages A and B to XMI files A2.xmi and B2.xmi respectively.

13 - Import package A from A1.xml file overwriting the actual package A.

14 - Deliberately, package B was changed with the last import. Now, imagine these steps considering the use of version control feature. This is a hell.

15 - To finish, take a look in the xml files exported with a diff tool. In any moment the package A was changed intentionally.

I hope that Sparx fix this issue quickly.

Regards,
Edvan

[darren.sampson]

Hi Edvan,

Did you report this as a bug to Sparx on either the registered/unregistered bug report web pages?  This is a user forum - some Sparx staff do read the forum, but nothing beats a formal report.   It's worth referencing this thread in your report.

This problem is an issue for us too, and is not restricted to any particular version of EA.

The only way to store a connector that spans two different XMI (or controlled packages/version controlled packages etc) and be compliant to the XMI spec is to put the connector in both XMI files. This is problematic in itself, and needs to be carefully managed by the UML tool (EA).  Personally, I don't think EA does a great job of this.

I've already posted comments about the need to indicate in the EA GUI when a controlled package is modified since it was last saved (potentially by modifying a connector in a diagram in another package) here.

On further reflection, I think the XMI import also needs a few more features to manage this problem better, and in particular the problem you mention.

In your case, I would expect that the current behaviour is that the connector is re-instated as the connector is saved in A1.xml.

The only way to "fix" this is for the EA import to be more explicit about what it does when it discovers a connector that is different to the one that exists (or does not exist) in the model. I think the options should be:

Connectors to "other packages" (for want of a better term)
() Add connectors if they don't exist
() Use imported connector if newer
() Use imported connector if older
() Ask each time

In this way, the modeller gets to choose the behaviour on import, and doesn't have to accept EA's arbitrary interpretation.  The last option is obviously not useful for batch import.

Just my 2 cents worth!

Darren