UML best practice: Attribute or Association

[Geert Bellekens]

Another one in the series of UML best practices: how to decide whether to use an attribute or an association:

http://geertbellekens.wordpress.com/2011/08/10/uml-best-practice-attribute-or-association/

Any and all comments/input/insults are welcome

Geert

[RoyC]

Geert, you're a block-head.

(Well, you DID say....)

Nah - you're a very respectable gentleman, guv'nor.

[Geert Bellekens]

 

[Frank Horn]

Using associations for classes and attributes for primitive types seems the natural choice indeed.

An additional argument for this would be that you'll hardly ever need backward navigability from primitive types, but you will often need it with classes; the same applies for the aggregation type. So using attributes of class type is often a bad idea because you may later decide that the relation should be navigable in both directions, or a composite, and will have to switch to an association to properly model this.

I admit, though, that out of lazyness I usually use associations with enumerations as well, just because it's more comfortable to draw it and give it a source role name then to pick the type from a list or tree.

One drawback with associations in EA is that they cannot be ordered. There are up and down arrow buttons for the attributes, but nothing like that for associations, let alone for the union of attributes and associations navigable from a class. If ordering all of them is important for code generation, you have to roll your own. Only for XSD generation EA offers an ordering tagged value on attributes and roles because no one could create a descent xsd:sequence without it.

When you're modelling plain stupid data classes this may not be an issue, but what if you want to generate code for serialization and deserialization? Associated objects may refer to other associated objects which need to have been deserialized further up the line.