structure for vc access?

[gpc]

Hi,
I have managed to get EA working with our version control system and am now ready to define how the project should be structured and stored. The problem is I have a common package containing classes, utilities, etc. and another with requirements, and then I would like to create a number of others to hold the numerous use-case diagrams, etc.
I expect to have a number of engineers working on each of the new use-case packages (i.e. one each) - nice. Except.... If I try to export / store the use-case package, I lose all of the links because they reference elements in the other package(s).
The only way I can see this working is if each use-case package contains the 'common' package. the problem is then what happens when I wish to create a view containing a number of these use-case packages, all containing the same 'common' package (i.e. duplicating GUIDs)?
Any help / guidance would be greatly appreciated.
Thanks.

[gpc]

Hmmm. After reading that links are not exported and confirming that with the xml files under vc, I have since run through the steps again and it all appears fine?
Obviously, if the packages are brought in to the model in the wrong order, then links will be removed, but if the common package is loaded first the links appear to be ok now.
Very confused  

[«Midnight»]

That's because when you bring in the core package first there is something to link to. If you do it the other way EA doesn't find a target, so does not create the link at all.

Of course this could always be done with links in both directions, with the XMI for each package containing full link information. This would involve creating XMI differently, and does not appear to be the Sparx model.

I keep thinking there is an option to include referenced elements when you export a package to XMI. But I've not looked - I could easily be thinking of something else, or talking through my hat.

David

[gpc]

OK. did some further testing...
I pulled in my packages in a number of different orders and for all occurences, the links were lost in the diagrams.
I then did a diff against disk and links were marked as deleted.
I then checked out the diagram package and undid the checkout and the links miraculously reappeared.
looks like a bug?    

[«Midnight»]

Yes it does.

My first guess is that EA is not tracing the links to external elements (those owned by other packages) where the external package is not also checked out.

Please report this as a bug to Sparx. Please also search my recent posts for a best practice the forum community uses to keep everyone up to date when filing a bug report or feature request.

David

[gpc]

Bug raised. I'll post back here if I hear anything. Thanks.

[gpc]

Response:
When drawing a Sequence diagram in EA, two important points to remember are :

1. The lifelines cannot be elements - they need to objects. Even though EA allows to drop the elements as lifelines on a sequence diagram, it is not strictly UML.
2. Also, EA expects the lifelines to be in the same package as that of the diagram.

These conditions ensure that the Sequence Diagrams round-trip without any changes. Now, if for some reason, the elements and the diagram needs to be in different package then the round-trip may not be successful. A work-around this issue is to drag-and-drop the classes into the Sequence
Diagram as objects and then drawing the messages between them.  Select the option "as Instance of Element(Object)" in the "Paste Element" dialog when the class is dragged and dropped on to the Sequence Diagram.

[«Midnight»]

Sigh...

Sequence diagrams in EA have always - as long as I've been using the product - been sort of an 'orphan.' It seems that the EA sequence diagram has a different internal 'engine' than other diagram types. At the very least, some general rules don't seem to apply to these diagrams, and they have behavior and constraints that are unique within EA.

Whether this is a throwback to their earliest development days or something else I cannot say.

David