Associations, Attributes and C++

[lorenzo]

From this discussion I understand that in UML 2.0, an association IS an attribute, and I also discovered that reverse engineering a class with an attribute will create both the association and attribute in the model (see this topic).

However this attribute vs. association stuff is still confusing to me:
When both the attribute and association are in the model, if I modify only the attribute (like change its name), and forward engineer, then I got two attributes in the code (one coming from the model-attribute, one from the model-association). This makes consistency in the model really hard to maintain.

Could somebody give me some light on this (typically I would prefer if reverse engineer would not create a class attribute and just keep the association)?

Thanks,

Lorenzo

[Paolo F Cantoni]

Hi Lorenzo,

First of all ONLY (role) named AssociationEnds are Attributes in UML.   You have to actually provide a role name (instead of any imputed role based upon the relation name)

Secondly NO product handles this properly (AFAIK).  EA is no worse (or better) than most of the others...

I strongly suspect that an significant internal architectural change in EA would be required before it would support it.

However, it WOULD be nice wouldn't it?

Sparxians, any plans?

HTH,
Paolo

[sargasso]

I'm slowly getting to the point where I would prefer that EA didn't RE anything from associations and would not generate anything from associations.

Current theories of mine:
Associations are no more than specialised aggregations.
Aggregations are meaningless at the code level.

IOW both constructs have modelling semantics only and not unique realisation semantics.  This is similar to the dreaded "assembly" link on component diagrams which IMO are only a modelling semantic to illustrate one of many possible realisations, not the "demanded" realisation.

bruce (as usual getting my 14c worth in)

[Paolo F Cantoni]

I'm slowly getting to the point where I would prefer that EA didn't RE anything from associations and would not generate anything from associations.

bruce,
as we've previously agreed regarding modelling semantics versus code semantics, I'm essentially saying the same thing.  The correspondence between a model Association and a model Attribute should be maintained by the model.  Forward and reverse engineering (of code) should be via Attributes only.

Current theories of mine:
Associations are no more than specialised aggregations.

UML explicitly says Aggregations are specializations of Associations.

Aggregations are meaningless at the code level.

Aggregations (actually Meronymies) are collections and can be expressed in code quite satisfactorily.  If the generator is rich enough (which they aren't)

IOW both constructs have modelling semantics only and not unique realisation semantics.  This is similar to the dreaded "assembly" link on component diagrams which IMO are only a modelling semantic to illustrate one of many possible realisations, not the "demanded" realisation.

bruce (as usual getting my 14c worth in)