Generation of Code for Associations
From the above it is clear that implementing associations is not a trivial matter. Don't you find it amazing how much code you need to implement such a simple diagram, or how much of the code needs to be changed when you decide to change a '1' in the diagram into a '1..*'? This certainly shows the power of modeling.
Yet there are only a limited number of different configurations for an association. In this article we have shown you how to implement four: the one-to-one, the one-to-many, the many-to-many, and the one-way-navigable configuration. Other configurations come from combining these with an association class. (The implementation of these classes will be the subject of our next article.) Furthermore, every association with the same configuration can be implemented in the same manner. That is why we advocate the generation of code, particularly for implementing associations.
When you have to implement associations manually, you have to do the same thing over and over again, which is not very interesting. Besides, when you do this manually (and get bored), you easily make mistakes. And when the modeler decides that the multiplicities should be changed, you can start all over again. This is the reason that implementing associations is a good example of the power of the Model Driven Architecture (MDA). MDA tools that generate code from a UML model also generate the implementation of the associations. Examples of such tools are Octopus and the Eclipse Modeling Framework.
|Author's Note: The Eclipse Modeling Framework is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce amongst other things a set of Java classes for the model.
In this article we have explained the output of Octopus. However, different implementations are possible, as long as they adhere to the ABACUS rules. For instance, EMF uses a completely different approach than Octopus. Behind the scenes there is a complete notification framework that does the job of notifying the partner object of the creation of a link. We feel that this framework is unnecessarily complicated, and we have shown that a simpler implementation also runs correctly. We adhere to the principle that the code you generate should be (almost) the same as the code you would have written by hand. At least, the generated code should be readable and easy to understand.
Note that the traditional UML modeling tools also claim that they generate code, but they do not generate a correct implementation of associations. Tools such as Together, Poseidon, or Rational Rose simply generate a pair of pointers and leave the rest up to you. If you want to do us a favor, then please, take up your duty as consumers of these tools and demand from the suppliers that they generate correct implementations of associations. It can be done and it will decrease your efforts to implement a UML model.
To conclude this article we leave you some mind teaser that can help you to become fluent in the use of associations in a model. Simply play around with them and try to understand what a particular model means for the instances of the given classes.
- Figure out how to model a marriage using one class: Person, without using the classes Man and Woman. Also try to model a homosexual marriage.
- Another interesting situation is where there are two associations between the same two classes. Try to model a situation where a person may work for a bank, thus having a employee-employer relationship, while at the same time that person is a client to the bank. What if the person works for several banks?
Finally, we would like to stress the fact that introducing a Man and a Woman class to represent people is not always a good idea. We used them in this article to explain the UML association, but in real life things are usually more complicated, which creates demand for a different classification.