I take a very rigorous approach to nomenclature. I reserve the term “nesting” for physical nesting, in which the identity of an item depends on its holonym. I use the term “Visual Embedding” to describe the ability to move an item into or out of (just as important) another item on a diagram.
I know, and was aware I could get in
trouble by using a less rigorous approach to nomenclature. But I will blame the forum poor search engine for not allowing me to quickly find one of the posts where we discussed this is the past. Perfectly happy with "nesting" meaning physical nesting, and using "visual embedding" to describe the ability to move an item in or out of another item on a diagram. Having said this, Sparx EA, at times, doesn't do "visual embedding" very graciously.
Also "nesting" is really a form (de-)composition but, AFIK, there is no relationship for it in any modelling language I am familiar with. It this not the same to represent "car" as a group of interrelated elements - e.g., engine, wheels, chassis, body, and so on - or a one element with (physically) nested elements.
As Guillaume and I have shown, no redesign of the browser is required; all that is required is to redesign the concept in our brains. It is easy enough to implement.
Just to clarify my point, I know you and Guillaume have proven you can do this with an MDG. Actually I have done it myself. My point is two fold:
1 - From previous interactions with Sparx Systems through the support desk, and with Eve and other people in this forum, I got the impression that changing the way the Grouping element works is considered a very significant change not very high up in their plans.
2 - From a usability point of view, the package browser, which is essentially a physically nested structure (almost an extended folder structure), often makes collaborative work on a single repository difficult and leads to unwanted data duplication. The collaboration problem would be easier to solve if a view, a Sparx EA view, could be constructed showing how elements are/or could be visual embedded. If the browser could be hidden for certain users, this view could be the main entry point for any work done by some of the users we typically collaborate with. After all, some relationships are a natural visual embedment: specialisation, aggregation, and composition.
Recent Posts
I agree with your point about the searching capability. Why is searching SO hard (as a functionality)? It’s not just here that one can criticise the searching as being less than optimal. Anyway, another gentle correction (to myself, not the least), Nesting doesn’t actually apply to physical nesting; it applies to referential or access nesting - as I have indicated in the past, nesting defines the namespace of the meronym - in other words, you have to access the higher level items to get to the lower level item (x.y.z). The physical nesting in the browser is just a manifestation of that concept.