How to structure huge EA project?

[magnus-e]

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

[peter.zrnko]

EA has the ability to compare and merge contents of two packages (current and a baseline or exported xmi file). But it's not integrated with version control at this time. But maybe it will be in the future  

[Frank Horn]

In my experience connectors are not created in the package containing the source element, but in the package containing the diagram on which you draw the connector. So for a connector between two elements from different controlled packages only one needs to be checked out, i.e the one containing the diagram.

So if you have a use case in a package which is checked out, and an actor in a locked package, you should be able to put a diagram into the use case package, drag the use case and the actor onto it, and draw a connector between the two without checking out the actor package.

If in some situation this does not work, it's a severe bug and worth reporting.

There ARE bugs with where things are created, of course, only I've never come across this one. But I just reported another one:

http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1209477600

Some UML tools offer an option of showing connectors in the project browser so you can see what's happening, but unfortunately EA doesn't. Only chance to see in which package a connector has been created is to look at the database or at an XMI export file.

[Geert Bellekens]

I do not agree. If a relation is created between two elements it should be located in the package containing the source element.
In the example, the relation between an actor and a usecase actually changes the actor. Therefore I want EA to block me if I haven't checked out the actors package.
If it currently works differently in EA I would consider that a bug.

[Frank Horn]

If a relation is created between two elements it should be located in the package containing the source element

I'm not so sure about this; e.g. for an association it's completely arbitrary who is source and who is target. No difference in XMI 2.1 either: just two connection ends. Marking one as source and one as target is nothing but a convention in EA.

the relation between an actor and a usecase actually changes the actor

I think that can be viewed both ways. I would have thought just vice versa. Anyway, if it's really necessary to checkout the package containing the predefined actors everytime a use case is added, then EA's concept of controlled packages is next to useless in cosmo's scenario.

Well, I just tried it out. Seems like EA actually puts the connector into the parent package of the element from which you drag it (call it source if you wish). It's no problem, however, to draw it the other way around (from the use case to the actor residing in a locked package). Looks the same anyway.

With sequence diagrams this is no help, of course. But you can create  (in a sequence diagram within a checked out package) instances of a class from a locked package, and create messages between them without any problems.

[thomas.kilian]

If a relation is created between two elements it should be located in the package containing the source element

Actually it's on both. So importing XMI with assocs to another (not yet imported) XMI causes EA to flag errors. Therefore if I import XMI I do it always twice: load all packages then reload. Paolo stated somewhere that this is also a Sparx recommendation.

[Frank Horn]

Actually it's on both

No it ain't. A connector belongs to one and only one package. At least this is the structure in XMI 2.1.

But when you export a package to XMI and it contains a connector with an end from another package, EA saves a "stub" element so as not to orphan the connector's end. When you then import to another model, the stub cannot be resolved and the connector will be nowhere to be seen. It's still there, though, pointing to a stub.

If you had imported the other package before, the stub would have been resolved. If you import it afterwards, EA will not care to resolve stubs in packages which have been there before, so you have to repeat the process.

[Geert Bellekens]

Frank,

You indeed have a point when it comes to associations.

With sequence diagrams this is no help, of course. But you can create  (in a sequence diagram within a checked out package) instances of a class from a locked package, and create messages between them without any problems.

For sequence diagrams this would be behavior to be expected since you are not changing anything to the (locked) classes. You are changing an instance of the class, which usually is created in the same package as the sequence diagram.

[Frank Horn]

You are changing an instance of the class

Exactly. That's why I pointed this out. Maybe Cosmo can live with this. Could even use instances of actors, which isn't so far fetched perhaps. If these actor are just representing roles like "customer", "analyst" and what not, all these elements related to actors could perhaps be seen as related to instances,  i.e to "one customer" and so on.

I don't know Cosmo's model or the philosophy behind it.  I was just imagining I had a package "Actors" which would only be checked out when we wanted to introduce some completely new type of actor. And a package "XY Application" which I have currently checked out to define use cases and things. Then I could create an instance of "customer" called "XY customer" and relate it to the uses cases.

[Geert Bellekens]

Good point. Need to remember that for my next UML implementation.