COllaborative working

[iain]

All,

I am well through an evaluation of EA, which as a single user system has proved as feature rich if not better than some of its competitors.

I would like to roll it out to our development team but concerns have been raised over its collborative capabilities we have tried using replicas (3 people) simulataneous developing use case etc in the same model - unfortunately we manage to corrupt the model and lose data in different scenarios.

Can we please have a definitive example of how to develop models in a collaborative manner as the features provided by EA currently are causing us problems.

If anyone (especially Sparx) has any ideas on to utilise the tool productively in a collaborative environment I would definitely like to hear.

Possible areas are  model / object locking, better synchronisation, ability to link models / classes in separate projects

[TerryC]

Hi

I'm evaluating EA for use by a team over a WAN. We currently put all of our code into a CVS repository and it would be nice if we could do this with EA. Unfortunately the fact that EA stores its data in a binary file means that CVS can't store differences and so every CVS update would mean sending a potentially large file across the network and completely replacing the current CVS entry - which is impractical over a WAN.

I've noticed that EA can save its diagrams as tagged values in XMI files - so I could save the XMI files in the CVS instead, but there doesn't seem to be a way to save ALL the EA model in the XMI file e.g. the issues list gets lost.

An ideal solution for me would be to have a way of exporting/importing a complete project as XML. That way it would work with any source code control system.

Cheers

[CJ]

Iain and TerryC,

Neither of you mention whether or not you're using controlled packages and, if you are, how you are using the feature.

Could you follow up with a little info on that?

Best regards.

[TerryC]

Hi Jason

I've just tried out the controlled packages feature and it makes import/export easier. Here's some info I've found:

1. You can use a relative path name for the package's XML file i.e. type something like .\packagename.xml in the 'XML filename' field in the Package Control/configure menu. Relative paths are better as they don't force you to checkout your CVS module to the same directory.

2. It would be nice if you could put $id: $ in the version ID field so that CVS could do the version tracking. Unfortunately when I tried this I got problems loading the package - the CVS had put the correct value into the XML but EA fell over because the string was too long - it's also caused the project to lose all of its package control information - this stuff should be transactional (if the Access DBMS can handle that).

3. Another problem is that loading and then saving a package - without making any changes - results in lots of changes to the XML file (mostly dates and GUIDs). Ideally there would be no changes and so the XML files would appear unmodified to the CVS.

If this could be done then ideally there would be an 'auto load/save' checkbox on the package-control/configure menu that would make EA automatically import/export that package's XML file when a project was loaded/saved.

Cheers

[sparks]

Hello,

Below is a short description of the different methods of multi-users access in EA.


"1. Simplest of all is place the project file *.eap on a shared network drive ... then one or more users simply open the file on the shared drive. This is OK for small workgroups .. say up to 10-15 users concurrently working in EA.

2. Use the Replication features to expand the number of users and geographic distribution ... users have their own copy of the project which they periodically synch with a Design Master project at a central location.   By the sounds of your note this is the method you are using at the moment.  This functionality is part of MS Jet, so unfortunately we are not able to change the way it works.

3. Use the XMI import/export capability to create and manage controlled folders. Assign a folder to a user or local workgroup, then export the folder as XMI for import into a larger repository. Likewise, esport from the larger repository to XMI for import into smaller projects.

Check out the help file for some more information on these techniques.  Each has its benefits and shortcomings, and you may decide to use a mix of all three to get the job done - or simply settle for a single technique."

Another point worth mentioning is the fact that the next release of EA (version 3.50) will introduce the Corporate Edition which will include support for model information to be stored in MySQL or SQLServer database instead of MS Jet and the ability to lock elements based on a security level.  Storing the project file in one of these database should reduce the chance of the data being corrupted.  

Hope this answers your questions.

Paul Mathers