bi-directional and uni-directional associations UML

Question

While I think I understand aggregation and composition, I am having difficulties understanding bi-directional and uni-directional association. I've read that with bi-directional association, both classes know about each other and with uni-directional association only one of the classes is aware of the relationship. However this explanation seems too abstract for me and I would like to know what this in particular means for my code and for the program I am writing. It would be very nice if you could, along with explanation, provide a simple example of how these two translate to code (I prefer c++, but it can be anything including pseudocode)

Solution 1

Bi-directional associations are navigable from both ends. For instance, given the following classes (for simplicity, suppose that the association is 0..1 in both ends)

class Parent {
  Child* children;
}

class Child {
  Parent* parent;
}

you can go from a Parent to its child, and vice-versa: the parent knows about its child, the child knows about its parent, and (if this.parent!=null) this.parent.child==this (othewise it would not be the same association).

Parent <---------> Child

However, if there were no pointer to Parent in Child:

class Child { }

it would be an uni-directional association: you can go from parent to child, but you cannot go back from children to parent.

Parent ----------> Child

Solution 2

Unfortunately, the UML specification does not define any concept of "bidirectional association", but only mentions "bidirectional navigability" where "navigability" (indicated with an arrow in a class diagram) does not have a well-defined computational meaning as it can be provided, e.g., by reference properties or by queries. The most efficient form of "navigability", provided by reference properties, is modeled with the UML concept of association end ownership (indicated with a dot in a class diagram).

Bidirectional associations can be precisely defined as a pair of mutually inverse reference properties. This definition implies two conditions:

1. for this referencing a child, this.parent.child == this, as explained in the somewhat incomplete answer of Javier, but in addition also

2. for this referencing a parent, this.child.parent == this.

You can read more about this, and find many class diagrams describing examples of bidirectional associations in the tutorials Managing Bidirectional Associations in Java EE and Managing Bidirectional Associations in JavaScript.

Comments

[Mihai8]

You have some examples in sourcemaking.com/refactoring/… and etutorials.org/Programming/UML/….

[jcxz]

Thanks for the clarification of the difference between bi-directional and uni-directional association, but now I have a second question. So far I thought that having a member pointer/reference to the associated class would be an implementation of aggregation, but your code sample uses pointers too. Does it mean that aggregation and association are implemented the same way in code?

[Javier]

Yes, aggregation is more like a conceptual element of the model. I remember we discussed about it in stackoverflow.com/questions/15285996/…

[jcxz]

Ok, thanks very much, now it all starts to make much more sense to me. So to summarize my findings: association, aggregation and composition are rather semantic concepts which can basically be implemented in very similar ways. Additionaly (for all those that happen to come across this thread in future) I found this so post: stackoverflow.com/questions/4298177/association-vs-aggregati‌​on, that clarifies the semantic differences between the three.

[James Bond]

Now I know what, but I'm wonder the Why, it looks like there's no reason to uni-directional if you can bi-directional.