How to represent bi-directional associations in UML?

After reading the question “In UML class diagram can composition be bidirectional?“, I’m wondering how concrete examples of bi-directional shared/composite aggregation will look on a UML diagram. Specifically, I’m interested how arrow-heads and multiplicity are used to distinguish between the following cases:

1) Uni-directional shared aggregation (aggregation)

class Foo {
    // Can contain 0+ elements
    ArrayList<Bar> bars = new ArrayList<>();
    
    void addBar(Bar bar) {
        bars.add(bar);
    }
}

class Bar {...}

2) Bi-directional shared aggregation (aggregation)

class Foo {
    // Can contain 0+ elements
    ArrayList<Bar> bars = new ArrayList<>();
    
    void addBar(Bar bar) {
        bars.add(bar);
        bar.setFoo(this);
    }
}

class Bar {
    Foo foo;
    
    void setFoo(Foo foo) {
        this.foo = foo;
    }
}

3) Uni-directional composite aggregation (composition)

class Foo {
    // Can contain 0+ elements
    ArrayList<Bar> bars = new ArrayList<>();

    void addBar() {
        bars.add(new Bar());
    }
}

class Bar {...}

4) Bi-directional composite aggregation (composition)

class Foo {
    // Can contain 0+ elements
    ArrayList<Bar> bars = new ArrayList<>();

    void addBar() {
        bars.add(new Bar(this));
    }
}

class Bar {
    Bar foo;
    
    Bar(Foo foo) {
        this.foo = foo;
    }
}

Case 1 and 2 should be straightforward. I’m not sure how to represent the bi-directional associations, and how to distinguish them from the uni-directional ones, as both will have multiplicities on both sides. The diagram must include multiplicities.

Answer

Arrowheads are used to distinguish uni-directional from bi-directional associations.

• An uni-directional association has one arrowhead.
• A bi-directional association has two arrowheads, one on each side.

Normally, an association without arrowheads has an unspecified navigability. But it is allowed to have the convention that such assocations are always bi-directional.

To explicitly indicate that an association is not navigable in a certain direction, you may display a cross at the non-navigable end, but this is not used very often in practice.

Multiplicities and the aggregation type are not relevant for the navigability.

For example, your last case can be modeled as follows:

For more examples, see UML 2.5 specification, section 11.5.5.