Round-trip engineering problem

[Martin]

Hi:
I have a round-trip engineering problem with MDG link I desperately need to resolve. I have a team working on a small application, and we're evaluating MDG link. As the designer, I need to be able to expand the content of classes (add methods and attributes, as well as specifications) while developers are working on portions that are already designed.  The problem we're running into is the following:
- the model and code are in synch;
- I do a merge;
- I add attributes, methods, and specs;
- a programmer deletes an attribute or method;
- I do a merge;
My added stuff is present in the code, but the attribute or method that the programmer deleted is back in the code as well - the deletion on the code side is not applied to the model.

I realize that I may be misinterpreting what MDG can do, but the manual is pretty slim. Solving this is critical to getting this organization to adopt EA/MDG, so any help would be appreciated.

Martin

[Eve]

Hi Martin,

I think that EA is doing the best thing it can possibly do here, there is nothing to distinguish between things that you have added and things the programmers have deleted.

You could try updating your model with the changes in the code before you change a class and generate your changes back out again.  (There are options to delete model attributes/methods not in code when reverse engineering)

ie.  Your update routine would be.
Reverse engineer the class.
Update the class.
Generate it.

Having said that, I think that a "Hey Martin, I've deleted attribute Foo from class Bah" when someone deletes something from code could be easier.  (Or even better buy licences for all your programmers so they can update the model for you.)  

Simon

[Martin]

Hi:
Thanks for the reply.

I think that a "Hey Martin, I've deleted attribute Foo from class Bah" when someone deletes something from code could be easier.

This is about the only option we had thought of, short of going to a product that does full synch. The only thing is that
a) EA does everything else so well, and
b) I'm not sure that the problems for team development might not be just as significant with synchronization, since I can't access a class while someone else is working on it - that's really the crux of the problem, because we have about 8 significant business classes, and lots of scenarios they participate in - i.e. lots of design, few objects to code.

The real answer might be in something I just became aware of this morning - we use Visual SourceSafe here, and apparently the next version is going to allow multiple checkouts of an object. This means that the designer could reverse engineer a local copy, elaborate it, and check it back in - VSS will offer a merge screen that will enable the designer to resolve the differences. A bit of work, true, but probably has more chance of hapenning than the programmers updating the model  

Thanks again,

Martin

[thomaskilian]

Hi Martin,
I'm using this for other purposes than you, but with the same goal. My repository contains a master database and each designer is working with a replica. Now and then one decides to publish changes and updates the local master copy from the versioning system. EA is then told to synchronize which in turn brings own changes to the master and also gets updates to the replica. Next the replica is checked into the versioning system with a revision comment. This procedure works well for a small amount of concurrent designers. I have no idea how many people could work in that way in parallel.