You're thinking from a diagram-centric perspective not a model-centric perspective. Create explicit relationships so anyone else creating diagrams from the model has access to "the truth". They can choose to hide any relationships they do not want to show.
Well - I'm not.
The reason I was leaning towards 1 (ie creating explicit relationships) is to ensure that the model is complete and correct - and this seems to be the right way to go, supported by pretty much everyone who has responded.
I guess where I've been confused is with the nesting behaviour that is quite core to Sparx, at least from a project browser perspective, but doesn't seem to be explicitly captured in the model. I figured it must be there for a reason and wondered what I was missing and how I should be using it.
I think the answer is alluded to by Uffe's post - it is important if you need package behaviour. So for modelling detailed behaviour and code generation, I could see it would be useful. But not for what I am trying to achieve,
Thanks all :-)
As qwerty says, I'll have a detailed comment...
Yes, you should use explicit relationships to indicate the meronymy (relationship of the whole to part), but you MUST differentiate between the Composition relationship and the Nesting relationship. Formally, the Nesting relationship is about access/addressing (think of file in folder system) to access the file (using the normal browser analogy) you have to traverse the folders to get to the file - thus items in Sparx EA are nested in folders (see Copy Node path to Clipboard function, also Show namespace function for diagrams). Similarly, Ports have to nested in classes (you can't conceptually have a port without its parent class). Now there is a containment relationship (a meronymy - specifically composition) between the parent (folder/item) and the child (item/folder) but that is a consequence of the Nesting, NOT the other way around!
If you merely have a pure composition relationship between the whole and the part (such as between Car and Wheels) then that is expressed as composition only. There is NO requirement that they be visually "nested" in a browser nor visually embedded on a diagram. (Notice the careful separation of the two concepts). Indeed, when considering classifier models, the same meronym (part) could be composed into multiple holonyms (wholes) - Wheels in Cars and Wheels in Aircraft. Which one should you "nest" under (since you can only nest in one!)?
Only at the instance model level can you (as a part) only be composed into one whole.
Consequently, as part of our automated processing, we unnest things that should not be nested - even (and especially) if Sparx EA incorrectly nests them. Part of the problem is that Sparx EA only PARTIALLY supports Nesting and Visual embedding (and in my view, some of it is just WRONG) and, as a consequence, users find EA's behaviour confusing.
Once we had conceptually separated Nesting and Composition relationships and Visual Nesting and Visual Embedding (as 4 separate, but related concepts), we found the semantics of our models improved greatly.
HTH,
Paolo
