Author Topic: How to structure huge EA project? (Read 15227 times)

cosmo · « **on:** April 18, 2008, 02:49:47 am »

All,
   I'm trying to get a handle on a very large VS200x project with EA:
-topmost VS200x solution has 30+ projects, totaling 7000+ files
  -one project has majority of object model
  -one project has majority of WinForm classes
-over 10 developers
-using SVN
-trying to bring in UML to get better handle on this monster (blame previous architects, not me!)

   We have effective source file version control practices between VS200x and SVN/Tortoise. But in moving to UML, trying to understand how to structure a manageable EA project that shadows this existing codebase right now. Once we have enough stuff documented, I'll flip the development process upside down (UML first, code second--instead of re-engineer UML from existing code)

Questions:
1) How can I create an EA project that so many developers can effectively do concurrent diagramming? For example, all devs will be working to document their respective object model classes/behavior. I can't afford to have only one dev checking out the EA object model project, while the rest wait their turn. How can I get some parallel attack on this problem?

2) If I split into multiple .EAP files like the help files suggest, while I have cross-file visibility? For example, if ClassX in the Foo1 process is in Foo1.EAP and Class X is also in the Bar2 process in Bar2.EAP (a separate file), will my developers be able to know that ClassX is used in both processes? Right now it looks like I have to keep opening up each .EAP file to see if ClassX is used. Which also means I have to document its use in multiple places, and the documentation will degrade over time. Can I make a master file that pulls all of the little .EAP files together, so that developers branch or check out just a little piece but effectively see each others collective changes (without bumping into each other)?

   Surely someone on this group can point me in the correct direction. I would appreciate any advice that can be given.

Thanx,
Cosmo

brannstrom · « **Reply #1 on:** April 21, 2008, 08:13:35 pm »

You can add configure version controll on packages, not just to the entire project. This way a dev can check out just the packages he needs to work in.

/N

Oliver F. · « **Reply #2 on:** April 21, 2008, 09:49:42 pm »

Quote

-trying to bring in UML to get better handle on this monster (blame previous architects, not me!)

Hehe, never heard something similar, no, that never happens, this is an absolutely rare case, yadda yadda....

Just kidding, such is life. You are not alone here. A whole lot of projects have started before UML became known practice and even today I see a lot of projects be started without a modelling base.
Usually they start small ("Hey, why do that sort of overhead for a small project") and suddenly they evolve and become large, undocumented projects.

Quote

Once we have enough stuff documented, I'll flip the development process upside down (UML first, code second--instead of re-engineer UML from existing code)

Welcome to the club- just to say that our projects are even larger and the problems remain the same.

Quote

Questions:

Well, you can have several project files of course- however I do not see the reason for doing this. One of the bigger drawbacks is that cross documentation will become a PITA if referenced parts are spread across the files.
My proposal: A system wide database repository covering all aspects of the system filled by versioned packages from version control.

The database repository is fast enough to give you quick access on all aspects of the system and allows a system wide view for modelling and documenting while version control helps restricting checkout access to parts of the model for developers.

EA supports you structuring your project with wizards, so you have a basic setup of domain/class model and GUI model (eg. Forms), however you will have to find your own way to structure the hole thing.

So hopefully that helps you further.

Regards,

Oliver

Martin Terreni · « **Reply #3 on:** April 21, 2008, 10:10:16 pm »

If you are really brave and adventurous (or you have no other option but to torture your self) you can use locking for the 1st phase. Just using for the "reverse engineering" phase, so you can lock single elements, and then move to SVN.

I have the same scenario, so for the group doing reverse engineering/current state documentation I use locking (and god I suffer...) but for the group working on the new version I work with VSS.

cosmo · « **Reply #4 on:** April 23, 2008, 07:01:19 am »

Hey guys,
   Thanx for the tips. I continue to bang my head on this.

   Our object model is arranged in one flat directory/namespace structure. If I put the objectmodel package under version control (to prevent accidental changes to it) everything comes to a screeching halt.
   For example, I can drag class A from the locked objectmodel package and drop it onto a new sequence diagram in another package that is not under version control. I can repeat the same process with a different class B from the same locked objectmodel. But, when I try to map a call from class A to class B, I immediately receive a locked package warning from EA. It appears that my attempt to map the call is updating the objectmodel--which is read-only (not checked out).
   This actually makes sense, but I don't have any solution to my problem yet. I am researching EA security but I'm not sure what that will get me unless I do strict locking.

Any ideas?

Thanx,
Cosmo

Eve · « **Reply #5 on:** April 23, 2008, 08:44:04 am »

Strict locking sounds like what you need.

It will prevent accidental changes, and can be applied to elements as well as packages.

magnus-e · « **Reply #6 on:** April 24, 2008, 02:42:41 pm »

How to avoid strict locking from stoping up your projrct? As soon as you need to draw an arrow from say an actor you need to check check out (lock) the package were the actor is located and until you check that package back in nobody else can do anything with that package

Going to the extreme and put commonly used actors and classes each in there own packages colud help a little bit but would still cause problems when many people need to model with the same actor/class...

Eve · « **Reply #7 on:** April 24, 2008, 03:59:03 pm »

Quote

How to avoid strict locking from stoping up your projrct? As soon as you need to draw an arrow from say an actor you need to check check out (lock) the package were the actor is located and until you check that package back in nobody else can do anything with that package
Going to the extreme and put commonly used actors and classes each in there own packages colud help a little bit but would still cause problems when many people need to model with the same actor/class...

Yes, that is the cost of version control. Strict locking allows the lock at the element level so won't cause this problem. See http://www.sparxsystems.com.au/EAUserGuide/index.html?securitypolicy.htm

magnus-e · « **Reply #8 on:** April 24, 2008, 04:07:29 pm »

I am a little confused - how does the security / locking seting relate to the use of a version control system that also involve locking? They seem to be somewhat overlapping?

If version control is used one can (as far as I have seen) only use packages as "configuration items" (not individual diagrams or objects etc) and then a user working on anything in one package will block all other users from modifying anything in the same package.

Enabling strict locking will not improve on this situation and mostly seem like a mechanism to use when NOT using version control or?

Martin Terreni · « **Reply #9 on:** April 26, 2008, 04:29:13 am »

IMHO you are right, no need for both.

magnus-e · « **Reply #10 on:** April 28, 2008, 02:43:23 pm »

Strickt locking do however only solve half of the problem of orderly development (prevents concurrent edits to objects), it does not help if somebody by misstake (or perhaps due to some bug in the tool) deletes or in the wrong way alters some part of the model!
In that situation it is of little use to have backups of the database either since reverting to a backup will cause all work since that point to be lost...

So version control seem to me to be the only safe option but then you are sadly enough limited to use package as the finest granularity of locking and this (at least for us) causes major problems with users locking things that others need to do there work...

I am still looking for a solution to this problem with EA...

Eve · « **Reply #11 on:** April 28, 2008, 04:04:07 pm »

Rather than using version control as a backup, have a look at baselines. This will only help if you actually save them, but they also allow selectively rolling back changes within a package.

From memory you do need to have an edit lock on the entire package to do a merge, but I would hope that's a relatively less frequent action that you would be able to work around.

Geert Bellekens · « **Reply #12 on:** April 28, 2008, 04:30:50 pm »

- Use a real database to store your model, not seperate .eap files. That should save a whole lot of administration/support and it is probably faster.
- Use version control.

And then the hard part:
- Structure you model (divide in packages) in such a way that you don't have too many conflicts with developers wanting to update the same package at the same time. This kind of forces you into some common best-practices that you probably already have in place without the limitation of the package-based version control. In fact, if a certain package is too often needed by several people at the same time, it is an indication that something is wrong.
This structuring would imply obvious things like : "keep the number of your global elements to a strict minimum". In projects I've done we would tend to keep only things like Actors global. Actors were only used to be displayed on use-case diagrams (triggering usecases). Normally linking actors to usecases should be something you only do once in a while, so that should not be a real problem.
Next think to keep in mind: "Keep you dependencies straight". I believe that is one of the main "best-practices" to keep in mind. If you have a model that has a strict "one-way" non-circular dependency policy you rarely run into trouble. The moment you notice that you have to check-out a package that is lower in the hierarchy then your package (e.g. your package has a depency to the other package) then you know something is wrong.
Last thing: keep the granularity of your packages as small as possible depending on the number of people working in parallel on elements in the same package. Ideally there should only be a need for one person to work on a single package at a time.

Hmm... That is quite a lot, but keep in mind, this excercise will eventually lead to a better architecture, and less of a stovepipe system. (ref. AntiPatterns)

Good luck!

magnus-e · « **Reply #13 on:** April 28, 2008, 08:39:20 pm »

One of the worst parts for us so far are the actors!

We have a fairly small number of actors and even if we would put every single one in a separate package everybody would still have to check out / in one of those packages every time they start a new diagram (in order to draw an arrow from the actor to your other diagram elements you must check out the actor) or else other users would not be able to create other diagrams with that actor...

In general I belive a much better soluition would be if EA were able to merge changes performed by two users. I do of course realize that this is no easy task to solve automatically in the case were other (possibly conflicting) changes have been done by another user to the same entity. In this case some GUI were the users doing the last check-in must help to decide what should be the result would be required...

Geert Bellekens · « **Reply #14 on:** April 28, 2008, 09:11:06 pm »

I agree with you on the solution part, but I'm afraid that won't get developed any time soon.
In the mean time, maybe you could tweak the way to model things a bit so this doesn't really pose a problem.
I don't really see how you could rely so heavely on the actors that they become a problem. Maybe you are using these on a sub-optimal way that could be improved.
If you really have a locking issue with actors, that means that you have a heap of connections from those few actors to a lot of other elements. I have a hard time seeing the added value of tracking one actor to say a few thousand operations directly.

In my vision an actor has relations with usecases, and nothing much else. Usecases don't tend to get created all that much so we never had an issue with that.

Could you possibly explain how you run into trouble with the actors?

Sparx Systems Forum

News: