Does UML shared aggregation imply absence of cycles?

Question

In short

Shared aggregation seems to express nothing more than a simple association. It is apparently a "modeling placebo" with no objective reason to use it (except in specific contexts where modelers have agreed between them on specific additional semantic).

Several sources claim however that shared aggregation would imply absence of cycles in the aggregation graph of instances. This would make aggregation a powerful tool in the domain of graph modeling.

But I couldn't find any evidence of those claims in the specifications. Did I miss some indirect evidence (e.g. interplay of several constraints)?

More details

The quote

In their book The Unified Modeling Language Reference Manual, 2nd Edition, Booch, Jacobson and Rumbaugh claim about (shared) aggregation:

The distinction between aggregation and association is often a matter of taste rather than a difference in semantics. Keep in mind that aggregation is association. Aggregation conveys the thought that the aggregate is inherently the sum of its parts. In fact, the only real semantics that it adds to association is the constraint that chains of aggregate links may not form cycles, which is often important to know, however. (...) In spite of the few semantics attached to aggregation, everybody thinks it is necessary (for different reasons). Think of it as a modeling placebo.

Other rather well informed sources(e.g. uml-diagrams.org and several academic papers) keep the directed acyclic graph for granted as well.

Verification against the UML specifications

The books is from 2004, based on UML 2.0. But most of this claim is still verified in the UML 2.5.1 specification. Shared aggregation is defined therein in very vague terms and without any objective advantage over a simple association (p.112):

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; (...)
...
shared : Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.

Another clause about aggregation prevents some special cycling situations (p.200):

An end Property of an Association may only be marked as a shared or composite aggregation if the Association is binary and the other end is not marked as a shared or composite aggregation.

I have however not found any evidence that "chains of aggregate links may not form cycles" in the general case. I also did not find other properties such as transitivity and anti-symetry which could allow to infer the absence of cycles.

Is the claim by the UML inventors now obsolete? Or did I miss something in the current specs that would allow to derive this statement ?

user_9430250 · Answer

Your analysis is correct. UML 2 doesn't give shared aggregation any semantics.

However

The UML 1 said:

Both kinds of aggregations define a transitive, antisymmetric relationship (i.e., the instances form a directed, non-cyclic graph).

I don't know, why this was not taken over to UML 2. I can only speculate that it was a case of throwing the baby out with the bath water. Some people wanted to make it absolutely clear, that the specification leaves the semantics of shared aggregation open for domain specific interpretation. And they forgot that it in fact was meant to have some, however weak, semantics.

My take on that

Our situation is this: A whole lot of books and websites on the subject, the UML 1 specification and common sense agree, that a whole-part relationship, whether shared or composite, is acyclic. UML 2 is silent on the subject.

Therefore, I for my part will interpret shared aggregation as acyclic. Of course, I would document this interpretation in a modeling guideline. However, I don't expect that it will confuse a lot of readers of my diagrams, even if they didn't read my guideline, since it corresponds to what they would expect anyway.

As a final note: Don't use aggregation unless you really need to. In my experience it causes a lot of unnecessary discussions.

user_3379653 · Answer

I think my favorite page 110 of UML 2.5 is quite clear about this:

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:

none Indicates that the Property has no aggregation semantics.

shared Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.

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.

Emphasis by me. Shared aggregation is out of the run in any case since its semantic is undefined by definition. So the implication is only for composite aggregation.

What is the standard?

UML has quite some history. And there are lots of citations out there. Only the fewest get updates along with UML evolving. Although Booch et al. invented UML, they are no longer defining the standard. That's done by OMG and they publish the ISO standard (for which you can pay extra money if you like). Quite some terms go round which have ancient origins and are outdated the one or other way. Still, they are being used - and in the now wrong context.

Is the standard perfect?

Definitely not. It's evolving and still has quite some flaws or misconceptions. In my opinion the introduction of shared aggregation in UML 2.0 was not a so good idea. To define something that has no definition per definition seems odd. And looking at the confusion about this concept proves me right.


none	Indicates that the Property has no aggregation semantics.
shared	Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
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).