Subversion and EA

[SwissSteve]

I have started to document an existing system using EA and Subversion for VC.

The current applcation consists of a number of independent components with quite well defined Interfaces.   What I want to do is document this application using EA as a first step.

the difficulty I have is that there are multiple developers who will work on these components in parallel.   To facilitate this I tried to contain the whole app design in one EA project.

Then each component is modeled within its own package.  So that each developer can check out his own component model individually and this seems to work ok with some issues on shared elements e.g. actors as has already been discussed on this forum.

However I am getting some pressure to seperate the common EA project and give each component its own EA project.

My gut feelins is this is incorrect but I would like to take the advice of the forum before I start to fight my corner based on instinct.

TIA

[«Midnight»]

My gut feeling is that your gut feeling is sound.

At the very least, you will not be able to reference an element in another project. That alone should cause you grief down the way.

Of course you could always design each component in its own project, and import them into a 'master' project where they are 'used' in the design of the overall system. You'd have to be very careful about GUIDs throughout the process.

Look into "Controlled Package" in EA help index (without the quotes of course). This is a very old piece of functionality, and rarely used now that VC support has come along. See below. Still, it might be worth reading through.

David

[SwissSteve]

Thanks for confirming my suspicions.

I am interested in your statement that Controlled Packages are an old concept and ot so much used since VC is available.    It is not clear to me why this would be?

Also where in EA are the GUID's an issue?   Are you referring to the unique ID used when adding the package to VC?

Your help is appreciated.

[Eve]

What David said about controlled packages isn't strictly accurate.

The version control support of EA is a special case of controlled packages where EA enforces a a locking state based on version control and communicates directly with the version control provider.  It also supports (and is the recommended mode of operation) saving a package to stubs only.

If you're using the most recent version of EA I would recommend looking at Export Version Controlled Model Branch
and Import Version Controlled Model Branch. As these provide the advantage of easily importing a model using controlled packages, but using version control.

[thomas.kilian]

That looks like it's a new feature I've overlooked o far. Resembles the controlled packages from RR. Will try that right away...

[«Midnight»]

Sorry folks,

My phrasing left a lot to be desired, and certainly obscured my point. What I meant - and this is partly based on my impressions back in the EA 4.x days - was that as VC support by EA has grown more powerful, controlled packages have sort of fallen into the shadow. As far as I can see, controlled packages do everything they ever did, and do all these things quite well.

David

[SwissSteve]

I appreciate all who have responded to date but to be honest it is still not clear to me the best way to acheive my goals.   Reading the User Guide "Model Sharing and Team Deployment" section has really muddied the water for me.

What I am actually trying to do I guess is probably not any different that what others are already doing.

Basically I will be using EA and have the possibility to use Subversion.
Currently all users are using EA as a drawing tool and each developer holds their own model for teir own components.

What I am looking for is the best way to organise a model of the software in EA.  I imagined a single project which all developers whould use.   So at the top level I would have the high level use cases, system diagrams, deploymnet diagrams etc.

The you should be able to drill down into each component which is where the difficulty is arising in that currently each componet has it own EA project.

So should I continue withthis approach and somehow import these projects into the top level project?

Should I create packages for each component which would allow each developer to check out their own component?

One issue that springs to mind is the reuse of use case components within the component EA projects?   Will both of the above approacjes allow the developers to share common elements?

How do others structure their projects to give their developers the maximum flexibility?

Whisch is the prefered Team Development approach commonly used or recommended for EA, Replication, XMI Import / Export, Version Control, Package Control or User Security.

Sorry if the mail i sa little large in scope but I have to make a recommendation and currently I am a little confused by the options.

TIA

[thomas.kilian]

The answer is unfortunately not that easy - as always it depends. We have the problem that we can't really work on the central repository due to access regulations (external consultants need to connect via WAN/VPN which makes working with the DB a real PITA). Checking out modules is also not a real alternative (partially due to the named restrictions). So we're fighting through a slow connection with no real fun. Concurrent access from several groups is the next problem. We currently try the EA security. It's possible to lock single packages to single groups. That seems to be a nice approach. It is, however, possible to create arbitrary connectors in spite of any lock. This is good (can connect to any foreign element) and bad (can fiddle around in foreign elements). Hmpf. An there are of course packages where everybody should be allowed to work - but only in certain parts mixed very nicely To how I see it, VC can not help much here. We control all root packages and perform batch exports over night which are then checked in automatically (at least we plan to do so). VC is then just some kind of backup with limited roll back. Luckily we do not REAL VC with different branches - can't image what pain that would cause...