Messages

1

General Board / Spell checking linked documents?

« on: September 17, 2008, 03:50:30 pm »

How can I spell-check the contents of linked documents (documents created using EA)?

I tried the normal "spell check current package" but it did strangely enough not seem to catch errors in the contents of the document...

As I see it documents should be the premiere place were spell check is really needed!

/magnus

2

General Board / Version control philosophy

« on: April 23, 2008, 09:49:16 pm »

We are just starting to use EA and is having a little bit of a problem to figure out how to best set up version control.
We have a number of people that need to perform modeling (within the same model!) at the same time.
Right now we have created a shared project were each model as well as the packages below each model are all separate configuration management items (each of them are exported/inported from the CM-system when you check-in / check-out).

This works fine until you like to create "common repository packages" for actors or commonly used classes etc. Since relationships seem to be stored together with the object from were the "arrow orginates" we all the time have to check out the actor package when we add an actor to a new interaction diagram (since we need to add a new arrow from the actor to another element of some kind) and this is problematic since only ONE person can have it checked out at a time  

How are other users handling this kind of problems?

One could in theory decide to not version manage this kind of frequently shared repositories but as soon as not the whole model is version controled I think one largly looses the point with using version control at all.. Also EA with only a data base as storage for the work seem risky in a multiuser environment - anybody can by misstake for instance remove important work and restoring an old backup version of the database is rarly an alternative since all work after the restore date/time would be lost...

The prefered solution (as I see it) would be if multiple users could check-out the same package and EA contained an auto-merge function that could handle any conflicting edits.
One could also consider to be able to do version control on a finer granularity than packages (single object or diagram?) and allow a mode were each change automatically check-in & check-out from the CM-system this way keeping the lock time short)...

All sugestions about how to handle the problem today (as well as thought about future improvements for the EA team) are appreciated!

We are right now using version 6.5 but are in the process to migrate to 7.1 and we use Perforce as CM system.

3

General Board / Re: How to structure huge EA project?

« on: April 28, 2008, 09:47:47 pm »

You are right about actors and that they should normally not be referenced MANY TIMES from each diagram.

What I mean is that every time you start working on a new diagram the first thing you usually do is to draw arrows from one or more actors to another element (usually the first element) and in order to add that one arrow from the actor you need to check it out (or rather the package were the actor is located). If you then forget to immediatly check-in that package the next person creating a diagram using the same actor (or if multiple actors are located in the same package - any of them) is stuck since the package is already checked out...

This is sadly not only a problem with actors but also with many other heavilly re-used elements. Ie as soon as you want to implement a "shared repository" of common elemants (actors, classes etc)...

If everybody has the disipline to keep the shared packages checked-out as short time as ever possible I supose it is doable (at least until the number of developers using EA at the same time are becoming really large) but it is quite tedious with all "klicks" (dialog boxes and confiormations etc) every time you are checking things in/out and because of this it is tempting to "cut a corner" and keep em checked out if you know you soon will be creating another diagram etc...

I wanted to make sure that this is indeed the best that can be done with the tool the way it works today and from what you say (and other threads I have read ) it seems like that is the case.

I do not evebn know if some "merge" for versuion managed models is planned for the future so this is probably the solution we are stuck with for quite some time...

4

General Board / Re: How to structure huge EA project?

« 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...

5

General Board / Re: How to structure huge EA project?

« 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...

6

General Board / Re: How to structure huge EA project?

« 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?

7

General Board / Re: How to structure huge EA project?

« 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...

8

General Board / Re: Restrict read access to repository packages

« on: April 24, 2008, 09:23:09 pm »

If you use a private repository model you should be able to solve this using your version management system, ie Perforce or whatever restrict read access to the XML-files representing the specific package that some users should not be allowed to access...
If you use a shared repository model you will however need support for this in EA since as it is today the first time a user with read access to the "secret package" imports it to the model it will be visible to everybody  

9

Bugs and Issues / Links not updated

« on: September 17, 2008, 04:00:32 pm »

I have used the possibility to drag a class or other item into the text of a linked document. This is very handy since it allows navigation to the item by clicking on it.

I had also EXPECTED that if the item was renamed the name in the document would change accordingly - this would have been VERY handy since it reduces the work to keep linked documents updated when names of classes etc change.

Sadly enough it does not work that way - if the class is renamed the reference in the document retain its old (now obsolete) name  

I hope this can be fixed in a later release since it is VERY anoying  [smiley=angry.gif]

/Magnus