[SNIP]
The difference in terminology here is Paolo using a different term from the commonly understood in an attempt to be unambiguous.
The difference in terminology and the implications of how Sparx Systems has chosen to implement it need to be fully understood.
In UML nesting is a relationship between 2 elements without physically nesting them - i.e., without making the element on the target end of the relationship a child of of the element in the source end of the relationship, without representing them hierarchically. The nesting relationships could be visually represented as relationships or as a map of visually embedded elements. The same could apply to other relationships such as generalization/specialization, aggregation/composition. This is, of course, not the way Sparx Systems has chosen to implement nesting.
Instead Sparx Systems has done something very Sparxian. When you attempt to nest anything in Sparx it creates a physical relationship between the elements, it creates a physical hierarchy - i.e., it makes one element the physical parent of the other - and does not create a relationship between the nested elements. The UML nesting relationship is a bit of afterthought, the same way that visually nesting generalizations/specialisations or aggregations/compositions.
Ideally, I Sparx should create out of the box nesting relationships between packages, generalization/specialization relationships between visually nested classes (or any passive structure element) and aggregations/compositions between components, all of it without physically nesting them, and allow displaying them as hierarchy (physical nesting) or as visual nesting.
I agree with Arnoud we are between a rock and hard place.
