links removed when "checking out"

[webrod]

Hi all,

I have a main issue.
Let me explain.
I use subversion.
Let say I have 2 packages:
+ Actors=> with all the actors
+ Use Cases=> with all the use cases

Let say that I control these packages separately.
So I have 2 XML files in subversion (Actors.xml and Use Cases.xml).

1- Developper A does a check out of "Actors", he adds an actor, and do a check in
2- Developper A does a check out of "Use Cases", creates a new use case diagram, and adds 3 use cases linked to the actor. Now he does a check in.

later
1- Developper B does a "Get" of the 3 packages, so he can see actors and use cases.

later
1- Developper A does a check out of "Actors", he adds again an actor, and does a check in
2- Developper A does a check out of "Use Cases", update the previous use case diagram by adding a link to one of the 3 use cases to the new actor. Now he does a check in.

later again, the problem comes
1- Developper B wants to update a use case, He does a check out of "Use case" only. He does not see the actor added previously by developper A. He updates the use case and do a check in!!!
The link has been definetely removed!! Even if developper A or B do a check out of  "Use case", they will not see the link between the actor and the use case.

This is really a problem.
The only workaround we have found is to say to all our developpers to do a "Get All latest" just after ther "check out"!!
But some of them could forget.

Could you please let me know how to solve the problem?
Is there a way to enforce a "get all latest"?

The thing is that we do need to control the package separately as we want to allow developpers to works on several packages on the same time (which is not possible if they need to check out the whole packages).
This was a trivial example, in our real world we can't prevent links between packages. And that's why we use EA.

thanks for your help.

[thomaskilian]

That looks definitely serious (wow! I'm about to face that situation soon ). Please send a bug report to Sparx using the bug report page and keep us informed. Thanks

P.S. simply refer to this thread in your bug report.

[thomaskilian]

I was curious and played aroud a bit. Then all of a sudden I was wondering how this XMI stuff could ever work. Whenever you have ANY connector between two different packages and you save them in two distinct XMI ---

[glb]where the hell does the connector go[/glb]

Is it in both XMI? Or in only one? And then, in witch???

Very, very confused now!

[Paolo F Cantoni]

I think we figured out it's in both...

HTH,
Paolo

[thomaskilian]

Well, my impression was that it's in the source's element package... I might be wrong, though. However, any way seems to make way for very strange effects!

[gpc]

Looks to me like a similar issue I had with objects used in sequence diagrams. Sparx said that I should use instances rather than simple links in the diagrams and then those instances will be kept with the package containing the diagrams - works fine. HTH.

[thomaskilian]

But for good reasons I want to use the links and not objects. Anyway the links do not exist inside diagrams but between elements - independent of any diagram. So when I save changes with a link to elements being located in 2 different controlled packages then I have to save both packages (assume I just rename the link). Now still I do nat have a good feeling with that. In what state is the model when re-loading it at another location? Especially as the re-load is not atomic, what is the state after loading one of the two packages. I'm feeling pretty unsafe...

[Frank Horn]

Hello,

I did a little experiment and found that there is a flaw indeed.

My model contains 2 packages with 1 class each, and an association drawn in the diagram in Package2 from Class2 to Class1 (which resides in Package1).

Now if I export each package to an XMI file (default options, i.e. XMI 1.3., enable full round trip, save diagrams a.s.o.), EA saves the association in both files, and puts the object which the orphan association end points to into an "EAStub" tag in the "XMI.extensions" branch. If I reimport both packages into another eap file, the association is duly being restored.

The flaw however is this:

If I reimport Package1 and then Package2, the result is excactly like my original model. If I do it vice versa, Class1 is missing in the Package2 diagram.

This means that when you have a complex model with various links across packages, the "source" (or the first association end, which is, of course, arbitrary in case of associations between classes, depending only on the direction in which you drag it on the diagram) being sometimes in one package and sometimes in another one, there is no way to restore the full project. The logical model will not suffer, but the diagrams will not be completely restored.

For the time being this means: A package which contains diagrams for objects from different subpackages must be exported and imported (or put under version control) as a whole unless you want to redraw those diagrams over and over again.

Frank

[thomaskilian]

I did almost the same experiment and my conclusion was also that I have to have a fully export. Even worse: I have two root packages with cross-references. And it is not possible to save them in one XMI. That means: no version control possible. Except I export to EAP and version control that binary - not really an option  

P.S. Sent a bug report to Sparx.

[gpc]

Hi Frank.
I did a similar experiment and found that the order didn't really matter and that sometimes it worked, sometimes it just didn't. However, if you pull the packages in again (this was before I was using version control), the links get re-established.
My fear was / is that a link would wonder off into oblivion and no-one would notice until some time later.

[Paolo F Cantoni]

You have to import everything twice!

That is the current, official, Sparxian work around!

When we are recreating our models from scratch, which we do regularly, we use batch import and do everything twice in order to ensure the links don't get blown away...

HTH,
Paolo

[Frank Horn]

Paolo,

how can I import a package twice? There's no option for synchronizing or overwriting existing packages, and "Strip GUID's" would only import a duplicate package.

Frank

[thomaskilian]

Paolo,

how can I import a package twice? There's no option for synchronizing or overwriting existing packages, and "Strip GUID's" would only import a duplicate package.

Frank

Strip GUIDs should be an absolute No-No. It's only a two-pass import. First make the items known then in the repeated import the links are established.

I also was thinking of doing the import twice. I ceased elaboration after I found this strange behavior but I will try once again. But I'll give it a 2nd try.

Edit: Just tried that and it worked. However, I think that Sparx should fix this and issue a message like "Import dependent package blabla". The very least is a statement in the white paper/help!

[Frank Horn]

I don't understand this one bit. We have shared packages in a  Subversion repository (where in fact they are stored as XMI 1.3. files), and when I want to edit one or more of them, I create a new eap file with root models and views to my liking and import the packages I need via "Package Control - Get Package". No batch import is possible there (the "Batch Import" check box in the "Package Control Options" dialog is always disabled, and the "Batch XMI Import" dialog never shows me any packages to select), and I have no idea how to restore diagrams with links between objects from different shared packages.

[gpc]

The suggestion is, to workaround the 'bug', to use the get package and pull in all of the packages you need and then (I haven't tried this!) use the get package again on all packages and the links should be restored.