Attributes as Associations and vice versa

[tinue]

Fundamentally, any (directed) relationship between two classes can be shown on a diagram as an Association or as an Attribute of the source class.
For example, in a particular "Service Interface" (datatype) class diagram I want to explicitly display my Enumerations, so that I see their literals.
On this diagram, I need to display the relationship between the Datatype and the Enumeration in the form of an Association.
On another diagram, I might not be interested in such details, so I merely show the attribute of the class and can see the particular (Enumeration) type.

Therefore, I would like to decide on the level of a diagram whether I show an Association or a Relationship.

As far as I can see, I have to decide in the model itself whether there is an Attribute or a Relationship, so I can't do what I like to do.

Am I overlooking something, or is this simply not doable?

Thanks! Martin

[Paolo F Cantoni]

Nope Martin, "it cayn't be durn"...

EA sees the Association and Attribute as two separate things rather than "doppelgangers".  There is some interaction between the two - but not enough to allow their correct handling.

On my list of things to do for Add-Ins is a manager for such things...

Submit a formal feature request using the links below...

Paolo

[tinue]

Submit a formal feature request using the links below...

Done, thanks for the hint!

Regards, Martin

[Geert Bellekens]

Martin,

At most places I worked we effectively made a choice between attributes and associations.
The (internal) rule was then that UML datatypes are being used at type of attributes and regular classes are not allowed as type of attributes, but can only be linked by associations.
Similarly associations from classes to datatypes are not allowed.

So in this context I would model an attribute and use the enumeration as type of the attribute. (since enumeration is a datatype).
If we need to show this on a diagram we use a dependency from the class to the enumeration (you can even link the dependency to the attribute using "Link to Element Feature" if you want)

Geert

[tinue]

Hello Geert

We have the same rule for service modeling: Only primitive types as attributes. Your hint of using a dependency on the diagram is helpful, thanks!

There is another quirk in our environment, though. The system holding the service definitions and the datatypes does not "speak" UML yet, and knows only attributes.

We are now developing an UML import/export feature, and now the problem hits: While exporting, we can decide on attribute vs. association based on the type, so no problem there.
What is lost though is the field order: When I re-import, there will be either attributes first, followed by associations, or vice-versa.

If I could mix them in the model, I could keep the field ordering intact.

Again, thanks and best regards,

Martin