Here is the design and development information presented. If you
want to comment anything on this page, or contribute any ideas,
please do this in the JavaRE
Open Forum at SourceForge.
Associations and Attributes
Associations and Attributes
I think Classifier Attributes in UML are flawed. Additionally, they
create problems in reverse engineering.
Since the very first day when I started with object oriented
modeling, I have not felt at ease when working with associations
and attributes. They have overlapping semantics that always makes
me wonder which to choose in every case I encounter. When thinking
more about this problem, I have come to the controversial
conclusion that Attributes do not belong in Classifiers. An
Attribute is just a special case of an Association, and therefore
an unneccessary element in UML. I will try to explain below how I
have reached this conclusion.
When consulting the UML specification, one finds that Classifiers
can be associated with StructuralFeatures. The only
StructuralFeature available is Attribute. The two things with
Attributes that have no correspondence in Association or
AssociationEnd is that it can have an initial value and be a
qualifier to an AssociationEnd.
The initial value is an
implementation detail that also does not belong in UML. But what
about frozen Attributes? Well, AssociationEnds can also be frozen,
but they have no initial value. The initialization of frozen
AssociationEnds is deferred to the "creation of the source object"
where it belongs - as an implementation detail.
difference is the association with AssociationEnd. To this I have
no invention, I only want the Attribute deassociated with
All Attributes can be replaced with Associations,
and noone can tell the difference. This can even be automated.
Lets take a look on code generation and reverse
Automatic code generation for an association is
not really possible, since an Association can be implemented in a
variety of ways. The code generator will have to dictate the
implementation policy for different associations, and if the
programmer is not satisfied with this, he can not use the code
generator or have to rewrite it. A possible soultion is to add
stereotypes to the AssociationEnd to give directions to the code
Anyway, the result in most cases will be that both
Associations and Attributes are generated as classifier attributes
in the implementation language. This is most unfortunate for the
reverse engineering of the code. What strategy should be used to
determine what is what?
One strategy would be to match
attributes in the code with Attributes and Associations in the
model to see if it already exists as either one. If it does not
exist, the programmer has to be asked what the intention of the
attribute is, Attribute or Association. But why ask when an
Attribute can be substituted with an Association? Just generate
The second strategy would be to generate
Associations of all the attributes in the code. This would be
simpler and not less expressive.
The conclusion is that model
attributes do not add any value to code generation, but makes it
harder to reverse engineer the code.
My conclusion is that the association between Classifier and
StructuralFeature in UML should be removed. It is redundant.
improve the readability of class diagrams when everything is
associations, I propose that associations should be possible to
represent as text in the compartment where attributes are written
But I don't decide the UML specification. I have to implement a
solution for this in JavaRE. The strategy I will try is
Generating code for Attributes is trivial. Associations
will have to be considered more careful. Only named, navigable
AssociationEnds without a stereotype will be generated as code
attributes. If the programmer does not want code generated, a
stereotype will have to be added to the AssociationEnd. All other
Associations will be left unprocessed.
engineering, JavaRE will check if the code attribute exists in the
model as an Attribute. If this is the case, the Attribute will be
kept as such. All other code attributes will be engineered as
I am also thinking about generating only
Associations and removing any Attributes from the model. This
could be controlled with a command line parameter.