Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: 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
-
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
-
-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....
:D
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.
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.
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
-
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.
-
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
-
Strict locking sounds like what you need.
It will prevent accidental changes, and can be applied to elements as well as packages.
-
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...
-
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
-
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?
-
IMHO you are right, no need for both.
-
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...
-
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.
-
- 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!
-
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...
-
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?
-
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...
-
EA has the ability to compare and merge (http://www.sparxsystems.com.au/EAUserGuide/baselinesanddifferences.htm) 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 ;)
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Good point. Need to remember that for my next UML implementation.