UML class diagram: to add fields used to implement relationships or not?

I a开发者_Python百科m trying to figure out if it is correct to put in the fields of the particular class a reference to an object/collection that this class is related with.

Let's say I have a class University that aggregates many instances of Student class. When I put on my diagram both classes, I add the relationship of aggregation between them.

And now the question: Can I add in University a field like 'students : Student[]'? Do I have to? Or maybe I must not?

Thanks in advance, Piotr

Attributes own association properties in UML 2. This is new and it is not always easy to understand the concept. I didn't understand why we need an attribute till I have seen the following demo. The golden rule is that attributes should be created in order to save association information in the model. I have found an interesting teaching session on association and aggregation in UML 2.

It is a 2m30s flash demo http://www.download-omondo.com/AggregationAndComposition.swf

The above association creation is for expert level, I mean modeler who wants clean design and clean model as well as perfect metamodel. If you don't care then just create an association at model level and it would do the job but the code generation will not be done. It means that mappings for database will needed to be created at code level later by developers. To understand the difference between both kinds of associations see this other flash demo at: http://www.download-omondo.com/association.swf

It depends on what you are doing with your model, but generally, you shouldn't have to use an attribute for this, you can use an association instead. Associations are able to contain more information that attributes, such as whether they are composite or shared, which ends are navigable, multiplicity on each end, named endpoints, etc.

One benefit of associations is that one association can actually represent a property on each class it is connected to, while an attribute only represents a property on the class it belongs to.

So, in your case, University has Students, so you'd draw an association from University to Student, naming each endpoint and setting the multiplicity correctly.

Now when you go to generate code from your model, just be sure to take into account associations as well as attributes. This way you won't need to add the properties both as attributes and associations, just as associations. I have a few diagrams I've tested this approach with, generating sql and php code from the xmi via an xsl transform, and it works quite well... if you'd like more details I can dig it up.

There are 3 types of relations : association, aggregation and composition. composition is a specialization of aggregation, aggregation is a specialization of association.

Using one or the other depends on the phase of your analysis. You could just use association in first draft and then refine it later to aggregation or composition, the difference with aggregation is that a student had no meaning out of one University Universe. If there are several universities instances, it would be aggregation rather.

If you use relations, there's no need to and you shouldn't add students[] because it is redundant. And if you do that you lose the semantics of the 3 types of relations.