Java Roundtrip Engineering

Development

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

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.
The second difference is the association with AssociationEnd. To this I have no invention, I only want the Attribute deassociated with Classifier.
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 engineering.
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 generator.
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 Association.
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.
To 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 today.

But I don't decide the UML specification. I have to implement a solution for this in JavaRE. The strategy I will try is this.
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.
When reverse 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 Associations.
I am also thinking about generating only Associations and removing any Attributes from the model. This could be controlled with a command line parameter.