Reverse Engineer Association

[MB]

I started evaluating EA today and have been trying to get forward/reverse engineer of associations to work.

From the model, I can generate code for two classes and a uni-directional association between them (using Java).

If I modify the source (add a method) and reverse, the association remains but I get an "attribute" for the association as well.

Hopefully I'm doing something wrong.

Suggestions/tips?

[Eve]

No, you're not doing anything wrong (except that ideally you should always be updating the model and generating ) that's just the way EA works.

[MB]

Are there any plans to address this?  It is pretty common to perform "round trip" engineering.  MagicDraw handles this very well.

I suppose the work around is to delete all "association" attributes created by the reverse process, right?

[Eve]

EA is round trip engineering it.  Including both is just the format that EA always reverses.

Deleting one or other representation is a valid workaround if you don't like what EA does.

[SF_lt]

if I'm correct, if there is a named association (with a role), then attribute (which is represented by association) should be deleted. Redundancy isn't welcome in this case

[Eve]

if I'm correct, if there is a named association (with a role), then attribute (which is represented by association) should be deleted. Redundancy isn't welcome in this case

Possibly, but it's not that simple.  I believe that a lot of people want to see the attribute you're proposing to delete.

I think a better approach IMO (but I'm not saying it's easy) would be to to create both, and have any changes automatically synchronised between to the two.  Then automatically hide the attribute if the association is displayed.

[Paolo F Cantoni]

Possibly, but it's not that simple.  I believe that a lot of people want to see the attribute you're proposing to delete.

I think a better approach IMO (but I'm not saying it's easy) would be to to create both, and have any changes automatically synchronized between to the two.  Then automatically hide the attribute if the association is displayed.

Simon,

The best approach is to allow the user to decide what is to be shown.

In UML a named AssociationEnd IS an Attribute so we have (as I have often commented) two renderings of the same thing.  So you are right in saying the changes need to be synchronized.  It's not a question of redundancy - but of rendering.

The Attribute need to be designated as associative and the Association designated as attributive.  This is to link the two.  The use can then decide which/how many renderings to view.

There should be a repository default, a package default, a diagram default, a class default and attribute default.

Paolo

[Eve]

I thought I'd get a bite.    And you do have a valid point.

You'll notice that I did not say anything about the "best" approach.  I don't think I am qualified to make such an absolute statement.  I doubt that you are either, and even if you were it would take longer than the 14 minutes between our posts to come up with it.

For example.

There should be a repository default, a package default, a diagram default, a class default and attribute default.

This is certainly not the "best" approach for someone who wants to tool to behave simply.  Further, I believe that there is no intuitive order of precedence for all of these options.  I think particuarly of diagram and class which is ambiguous ordering unless you add diagram object (instance of a class on a particular diagram) thus making it Class, Diagram, Diagram Object.  But that creates an ambiguity between attribute and diagram object.

Then how do they interact with the existing options to hide attributes?

I think you can't make a design decision like this without some compromises.

My $.02.

[Paolo F Cantoni]

Simon,

It took less than 14 minutes to write it, >3 months to think about it...  

I don't think I've changed my position since I enunciated the named-end vs attribute nexus.

As to the "best" approach.  Unless the user can ask for a non-sense, it is always best to give the user maximum flexibility within reasonable defaults.  That is, the least constraints on the user the better.

If you look carefully, you'll see that if the defaults cascade (I did rush the reply and should have made that clear - if it wasn't implicit already), then one can have both simplicity and flexibility to the degree desired (by each individual user).

If I want the simple life, set the repository default and forget the rest.  If my needs are more variable, then I can set each as aspect accordingly.

Admittedly, it's a little harder to program, but it can be a common pattern and thus be relatively easy to add in all the right places.

Paolo

[Tobbe]

Is there any work in progress regarding this?

I find it very annoying that duplicates of my attributes are created when reverse engineering.

[Tobbe]

...and error prone!

[sargasso]

 

I thought I'd get a bite...

bruce

[armin]

Hi

It's a pity the discussion stopped without providing any solution how to handle this problem. I have a long time experience in OO modelling and books as well as tools I used / read handle Associations and Attribute as a different representation of the same thing. So it should be possible to choose. I was doing some tests with the EA Roundtrip behaviour. I created 3 classes (C1,C2,C3) and one directed assoc between C1 and C2. I generated code. I reverse engineered the code. Now there was the assoc and an attribute with type C2 in C1. Now I changed the type of this attribute form C2 to C3. The assoc to C2 was still there. After I did another roundtrip there were two assocs. One beetwen C1 and C2 the other beetwen C1 and C3 and also two corresponding attributes in C1. I think this as a strange inconsistent behaviour. When generating code EA maps assoc to attribute. From generator point of view it is the same thing. When reverse engineering EA thinks of it as two different things....
Are there any activities to handle this problem in future?

Regards Armin