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)?
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.
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 ?
Your analysis is correct. UML 2 doesn't give shared aggregation any semantics.
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.
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.