10

Can composition be bidirectional in a way that both classes are aware of each other?

And if not, what is the default direction of composition?

antifriz
  • 873
  • 2
  • 13
  • 20
  • See also [Stack Overflow: Understanding Diagrams](http://stackoverflow.com/questions/24430581/understanding-diagrams) and [uml-diagrams.org: UML Association → Navigability](http://www.uml-diagrams.org/association.html#navigability) – xmojmr Nov 05 '14 at 05:13
  • 1
    The question is very simple, but I haven't seen it here yet. +1. – Gangnus Nov 05 '14 at 13:56

4 Answers4

6

You should distinguish navigability and aggregation. Arrow and diamond.

Arrow A->B means only that B is reachable from A in some simple way. If A contains a composition of B, it means that

the composite object has responsibility for the existence and storage of the composed objects (parts).

(citation from OMG Unified Modeling Language TM (OMG UML) - p.109)

So, can composition have bi-directional navigability?

Yes. It is quite normal.

If, for example, you have decided to destroy B in some of its functions, you MUST reach A and destroy it from there. So, composition has bi-directional navigability often enough. Notice, that bi-directional navigability, according to both current and coming UML standards, is shown as line without arrows on both sides. Both-sided arrow is deprecated. THAT is the reason you won't see it often.

Can the composition itself be bi-directional? Can we see black diamonds on both sides of an association?

No, of course this sort of association cannot be mutual, for it is impossible for B to be created in A only and, simultaneously, for A to be created in B only.

What is interesting, the shared aggregation (empty diamond) cannot be mutual, too, but here the limitation is not inherent, it is simply forbidden by UML standard.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
Gangnus
  • 24,044
  • 16
  • 90
  • 149
  • _"Both-sided arrow is deprecated"_ source? Because OMG UML 2.5 (June 2015) p.203 still says: _"The top pair AB shows a binary Association with two navigable ends"_ the line of that figure has an arrow at both ends. – Martin Schneider May 05 '17 at 15:23
  • It is not forbidden, merely out of mode. Look at their own diagrams - no both-end arrows there. Take it as a shortcut in use. And use both-end arrows if you like them. – Gangnus May 08 '17 at 20:12
  • What is congregation? Is this an alias for composition? – Jan Nov 22 '20 at 20:46
  • @Jan No, the composition is a subset of the aggregation. (in UML) – Gangnus Nov 23 '20 at 01:24
  • I am not native English, why do you introduce the word congregation? Do you mean composition? What’s the meaning? – Jan Nov 23 '20 at 07:30
  • @Jan I am not introducing it, it is the standard term of UML. I am talking about it, because bidirectional connection for it has sense, but is forbidden, whereas, for its subset, composition, it is both senseless and forbidden.... BTW, I am not from an English-speaking country, too, – Gangnus Nov 23 '20 at 13:45
  • ok so congregation is another word for aggregation! But congregation is NOT a term defined in UML. – Jan Nov 24 '20 at 06:36
  • I recently had a short discussion about 2-sided aggregation and it came up that it' a runtime constraint, not a static one. So there can be black diamonds on both sides, but during runtime only one of them may be acitve. Currently I don't have the time to look into the UML details. – qwerty_so Oct 02 '21 at 09:41
  • @qwerty_so. Sorry, no. Black diamond means that elements of one class exist ONLY as members of some group that is a single property of another class. You are inventing an alternative UML. Good luck! – Gangnus Oct 02 '21 at 17:32
  • No, I don't. I also was convinced of what you said. But the UML specs talks of objects in conjunction with composite aggregation. I'll try to come up with an answer. – qwerty_so Oct 02 '21 at 17:59
  • Please have a look at my answer. I might have gotten it wrong, but you need to convince me :-) – qwerty_so Oct 02 '21 at 18:17
  • P.S. Just noticed that 'congregation' in your text. Freud? – qwerty_so Oct 02 '21 at 18:18
  • @qwerty_so I don't know. But thank you very much for the editing. – Gangnus Oct 05 '21 at 20:47
  • No problem with that :-) Well, your picture lets me think we are at similar age (me being 62 now). And sometimes my fingers produce completely different things than my brain was commanding. Maybe you had just listened to some speech of the Pope ;-) – qwerty_so Oct 05 '21 at 21:40
  • @qwerty_so Rather of Nevzorov (a witty Russian atheist). But I really feel myself an idiot - I have been warned about this error, but I didn't see it... – Gangnus Oct 11 '21 at 00:07
  • LOL, yes. I saw that too (but only later when reading the old comments). But sometimes you read ox and understand cow. Happens to me all the time... – qwerty_so Oct 11 '21 at 09:28
5

Yes, Composition does not add constraints with regards to the navigability of the association. More info on the difference between Accociation, Composition and Aggregations can be found here: UML Composition vs Aggregation vs Association

Geert Bellekens
  • 12,788
  • 2
  • 23
  • 50
1

From https://www.lucidchart.com/pages/uml/class-diagram:

Bidirectional associations are the default associations between two classes and are represented by a straight line between two classes. Both classes are aware of each other and of their relationship with each other. In the example above, the Car class and RoadTrip class are interrelated. At one end of the line the Car takes on the association of "assignedCar" with the multiplicity value of 0..1 which means that when the instance of RoadTrip exists, it can either have one instance of Car associated with it or no Cars associated with it. In this case, a separate Caravan class with a multiplicity value of 0..* is needed to demonstrate that a RoadTrip could have multiple instances of Cars associated with it. Since one Car instance could have multiple "getRoadTrip" associations-- in other words, one car could go on multiple road trips--the multiplicity value is set to 0..*

Mark Cidade
  • 98,437
  • 31
  • 224
  • 236
1

In the past I had the same opinion as Gangnus with

So, can composition have bi-directional navigability?

But following some recent discussion I had a more detailed look into the UML specs. And simply, that statement is not true (only partially). Let's look into the UML 2.5 specs. On p. 110 it is stated

Sometimes a Property is used to model circumstances in which one instance is used to group together a set of instances; this is called aggregation. To represent such circumstances, a Property has an aggregation property, of type AggregationKind; the instance representing the whole group is classified by the owner of the Property, and the instances representing the grouped individuals are classified by the type of the Property. AggregationKind is an enumeration with the following literal values:

[omitting shared aggregation]

composite: Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).

Composite aggregation is a strong form of aggregation that requires a part object be included in at most one composite object at a time. If a composite object is deleted, all of its part instances that are objects are deleted with it.

Note my emphasis on the object/instance in the above text. So UML just talks of responsibility. If A composes B it will be responsible to delete B when it is destroyed itself. Vice versa B would be responsible for A's destruction. So, if you have references in both directions (i.e. diamonds on both sides) then you will be reponsible to delete the object on the other side. This of course works only if just one of both holds a reference to the other. If both would have a reference, it would not be possible to have a directed responsibility (because it's circular).

I still think that having composite aggregation on both sides is not really a good idea. But according to the specification it is possible.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86