Handling of nested controlled packages

[Christian Herger]

Hi there

Let's assume I have created a fairly complex project with packages which contain packages which contain packages.
All of these packages as well as the child packages are controlled and even put in version control.

If now any of my team member wants to work with some of these packages he creates his own EAP-file and starts to import the packages he needs into, let's say, the root package 'Logical View'.
Now the issues:

• If the package I want to import to already consists of one ore more packages, I'm not able to import

As a workaround I create another empty package, import my desired package and move it by drag&drop. Quite annoying... :-/

• I can see child packages of my imported packages but... they are not loaded!  

I first have to check them out from version control (and probably can  not if some of my co-worker locked it for himself).
There probably some function like 'Load package' I'm overlooking?

• In a diagram of a certain package is an element from another package.

Now, If the package containing this element is not imported or loaded, this element is just removed from the diagram.
Would be nice if there remains some sort of a 'blind link' as a placeholder.

• Changes made by my co-workers are not reflected in my model until... again!!... I check out the relating package! Reload package?  :-?

I really don't want to check out a package unless I need to work with it but I sure want be able to see changes applied by my co-workers.
[/list]

For your information:
We work with SourceForge and use SVN for version control.
Normally, our SVN client is TortoiseSVN.
However, for EA i needed to istall SVN itself on my WS to get version control work with it.

Thanks for taking note  

[Frank Horn]

I can see child packages of my imported packages but... they are not loaded!

Make sure your EA project has the "This model is private" option checked in version control configuration. Then you have a "Get all latest" context menu on controlled packages which will recursively update (from version contro repository) and load all child packages without checking them out.

If the package I want to import to already consists of one ore more packages, I'm not able to import

Why not? What happens?

[RoyC]

• Changes made by my co-workers are not reflected in my model until... again!!... I check out the relating package! Reload package?  :-?

I really don't want to check out a package unless I need to work with it but I sure want be able to see changes applied by my co-workers.
[/list]
Try any of these options (currently scattered throughout the Help, but I've just gathered them into one topic called 'Refresh View of Shared Project'):

• Right-click on the package name in the Project Browser and select the Contents | Reload Current Package context menu option

• Right-click on the opened diagram tab in the diagram view, and select the Reload <diagram name> context menu option

• Select the File | Reload Current Project menu option

• Close the project and reopen it.

[Eve]

I think the commands that you're looking for are 'Get Latest' and 'Get All Latest'.

The packages that are present, but not filled are saved as stubs.  A 'Get All Latest' will import them all.

The model does store that 'something' is missing from the diagram when something isn't available.  It isn't visible on the diagram though.

Hope that helps.

[Christian Herger]

[smiley=dankk2.gif] Frank

I missunderstood the meaning of model privacy. Thought, because we are a team working with the same model it needs to be shared and forgot that we share through version control.

Now I can use the 'Get (All) Latest' commands.

And for the import I just found the 'Get Package...' command! Before I always used the 'Import package from...' command. And this command is disabled if already one or more packages are present. Why? I don't understand...

So most of my issues are solved except one:

The model does store that 'something' is missing from the diagram when something isn't available.  It isn't visible on the diagram though.

This is not very nice!
Why? Because if I check out a package with diagrams containing missing elements; do my work and then check it in... the diagrams are changed (missing elements removed) even though I never changed them intentionally. I mean, it even delets links in elements!!!

In my opinion, this must be solved somehow! Why not keep the EAID and show the missing element(s) named 'missing element' or something like that.
Of course, it would be very nice if even the name was visible but then you probably have to store it redundant...

Thanks 8-)

[Frank Horn]

if I check out a package with diagrams containing missing elements; do my work and then check it in... the diagrams are changed (missing elements removed) even though I never changed them intentionally.

In my opinion, this must be solved somehow!

I couldn't agree more. We are trying to avoid this problem by allowing only one-way dependencies between controlled packages, i.e. we define e.g that package A depends on package B and an element in B must never depend on any element from A. But this is a bitter restriction (and a recursive one at that) and hard to enforce in a team which does not entirely consist of mathematicians and computer scientists.

[Eve]

It does store the ID and enough information to reconstruct the diagram.  At the moment this information isn't exported to XMI.  There was some discussion internally about a warning if information about missing diagram elements was present nd the option of exporting it.

As far as I can tell this has not been implemented yet.

[Frank Horn]

It does store the ID and enough information to reconstruct the diagram.  At the moment this information isn't exported to XMI.

It is exported to XMI. If you create a packages P1 with a class C1 and  a package P2 with a class C2 and a diagram in P2 with both classes and a dependency from C2 to C1, and then export both packages to xmi (or put them under version control), you can restore it all.

The problem is that when you open a new model and import first P2 and then P1, C1 will be missing in your diagram. But when you import vice versa, everything will be there.

But when you have dependencies both ways, there is no way to get all your diagram contents back.

By the way, I sent a bug report titled "Cross package links not restored in diagrams" about this, with sample project and all, on Nov. 14 or 15, 2007 and never got an answer except for the autoreply.

[Christian Herger]

I think what Simon means is that the links to objects are correctly imported form XMI but then not exported anymore if not resolved.

By the way, Frank, I think you can get your diagrams back with dependencies in whatever direction by just using 'Get All Latest' after you imported all packages...  

Still, my concern is project handling. We develop HW which consists of HW, FW and SW.
Now, the different teams don't care about other teams design that much and won't see the whole cake but only their stuff. Nevertheless, the parts are linked by requirement management.
The situation now is that all project members need to care for the whole cake to avoid information deletion by chance. :-/
Even the Requirement Manager needs to have my class design...

[Frank Horn]

Just tried it out again and couldn't reproduce the problem, so they must indeed have fixed something in version 7.1.

Still if you want to edit a package you need all packages it depends on. So if the requirements model has dependencies on the class model, your requirement manager needs the class model as well. But if you can keep the dependencies one way, the requirements manager can work with the requirements model alone, and you can check out both and add links in your class model.

[Christian Herger]

Uhhh, I think solving this problem won't be easy

I opened the eap-file with access and cruised the db a little...
Now, all elements have a unique 'ea-guid' but this ID is not used as the object key in the tables. Instead, EA uses an autonumber field for table keys!
And unfortunately all object linking is done with this table keys.

So, I was wrong before: diagram subjectsd are imported via ea-guid and if the element can not be found in the corresponding tables... it is just dropped. Frightening!!!

[Eve]

Don't worry about the various IDs.  If you had a look you'd see that they are transient through an XMI import.  During XMI operations the only thing that matters is the guids.

Frank, the change to remember the diagram information for elements not in the model was a recent change.  (7.1 I think)  The problem I mentioned was that the diagram information set aside for future linking is never re-exported.  This does result in a potential loss of information, and someone is looking into it.

[Frank Horn]

the change to remember the diagram information for elements not in the model was a recent change.

... and an important one. Now the need for one-way dependencies of controlled packages is gone, though they may still make sense sometimes (as Christian put it, the requirements manager does not need the class design).

the diagram information set aside for future linking is never re-exported

Meaning if I checkout a package with unresolved stubs and change it, the diagram information for the stubs will be lost? Good to know that someone's looking into it.

What about Christian's suggestion? I think it would be a great improvement to show missing elements in diagrams as dummy shapes, so that at least one would see that packages are missing.

[Christian Herger]

During XMI operations the only thing that matters is the guids.

Simon, I know that the guids matter for XMI but I think it is a problem that the guids are not used for linking objects in the database!
For instance, connectors between objects from different packages are not loaded into the 't_connector'-table if one package is missing! Why? Simply because either the Start- or End_Object_ID is missing! If you'd use the guids of the Start and End-Objects there, the entries could just be made without the necessity that the corresponding object is existent in the 't_object'-table. For the guid is a guid the relationships can be easily resolved as soon as the missing objects are present.
Same applies to the m-m-relationships solving tables like 't_diagramobjects'.

Like this, it would not be necessary to store information in the xml-file from a diagram which actually belongs to another package. This is namely how Frank's problem is solved since version 7.1.
However, this only works for first time import. If I delete a package an reimport it again, the diagrams are not restored. To restore them, I have to load the other package again.
Ok, delete means delete... But what choice do I have if I don't want to see a package in my project? Is there maybe a function like 'Unload' or 'Remove Package' function in the case  
 

This does result in a potential loss of information, and someone is looking into it.

Glad to read this

[Jüri]

I would say, that without resolving the previously mentioned problem, version control and teamwork is not supported properly. It is not very wise do automatically DELETE information what users have created!

I don’t understand, why tool deletes connections (information from the model) between elements and changes diagrams without user signal? User must be the one, who deletes something, not the tool. And it doesn’t matter, do you warn user before delete or not. Also such approach what rational many years ago had, that you have to load all separate packages (it said what UNITs are needed) because you most probably end up with almost full model.

We are trying to have enterprise level view as well and with current EA logic, where it deletes relations between elements, it is impossible! And it doesn’t matter, do you use diagrams or not, relations are lost between elements (diagram for me is just one view to the model. Model may have more relationships between elements than presented on diagrams).

Yes, you may say, that use one huge enterprise level DB repository but then you will have other problems such as:
1.      performance
2.      not possible to work offline with some packages
3.      no possibility to define Business UNIT based settings for repositories (sucs as clients, project authors etc)
4.      mess of RTF templates and searches (because those are available for all then) because all units and teams
5.      most important-> no possibility to share part of models with outsource partners or clients (they should not be able to see full enterprise).
6.      etc

I don’t know, to where I have to sign in order to speed up problem solving.
I searched the forum and there is no promise, that sparx will deal with this serious problem.

But currently seams to me, that because of this serious problem my company starts to search some other tool, what has proper teamwork support and does not delete information automatically (too many cases already with this).