What does this class diagram mean? The class diagram of reflexive association uses solid lines and arrows, but here is replaced by a hollow diamond. Does it have anything to do with recursion? What will this class diagram generate? It would be best if you can give an example. In addition, this recursive relationship should be one-to-many, how to build a table if you store a database.
Im UML, this class means that Every Unit is aggregated into some other Unit.
The UML standard doesn’t cover code generation, so interpretation of this as code depends on which tool you choose. Every proprietary code-generation tool should either stop with an error or provide an additional constructor that creates a new Unit that references itself. Otherwise, what Unit does the caller pass to the constructor for the very first Unit?
Other ways to fix the problem include taking an open-world interpretation of this UML model (where not all true information is present, as is the case for OWL), or loosening the multiplicity to 0..1.
This class diagram means that an instance of Unit can be associated with several other instances of Unit:
The hollow aggregation diamond is just a "modeling placebo": it does not change the meaning of the diagram, but just suggests that the association represents some kind of grouping.
A reflexive association means that it associates a class with itself. There is no direct relation with recursion, as this SO answer explains.
Nevertheless, recursive algorithms are good candidates to explore such associations (e.g. find all the instances of Unit that are indirectly related to a specific instance). In a database environment the term "recursive association" is sometimes used instead of "reflexive" because of the recursive joins that are used to implement them.
Note that the 1 should probably a 0..1 because 1 means exactly 1 and this would imply having endless cycles when navigating up.
Since it's a one-to-many association, you could visualize it as a forest of trees: each Unit instance can be the start of some branches and several trees may share common branches (nonesense: there's at max one parent).
Let's add some roles to better speak about the ends of the aggregation:
Code generation will depends on the tool and target languages. But the model with the aggregation and the model with the simple association will most probably generate exactly the same code, something like:
class Unit { // Java
private String id;
private Unit[] child; // java objects are sharable by default
private Unit parent; // unless we make it non navigable in that direction
...
}
In an RDBMS, the table would look very similar. The relational model allows to do a bidirectional link with only one column:
ID (PK) | Parent (FK, nullable)
----------------------------------
w |
u |
u1 | u
u2 | u
u3 | u
u21 | u2
u31 | u3
u32 | u3
v |
v2 | v
A self-join or a recursive CTE would allow to query the data making use of the reflexive association.
P. 110 of UML 2.5 states for this kind of relation:
shared - Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
So in short: it means what you define it should mean.
A note on history
In UML 1.5 there was only aggregation. Then in 2.0 they introduced the shared aggregation. On p. 80 of UML 2.0
Indicates that the property has a shared aggregation.
and further down
Precise semantics of shared aggregation varies by application area and modeler.
Obviously this latter sentence has not made it to the common people and you find all kinds of interpretation about what it shall mean.
Luckily now in UML 2.5 these two sentences were brought into one paragraph. Namely on my famous p. 110.