Types from the external model MUST NOT be used for composition relationships - Why?

[pahjbo]

In section 4.4.10 there is the statement in the model import section "Types from the external model MUST NOT be used for
composition relationships" - The rationale behind this restriction is not explained and does not seem to be necessary.

[glemson]

Motivation for this was/is that a parent-child composition relation should be unique, in the sense that a child object type should know its parent object type when it is defined. It is defined in the context of the parent if it has one.
Allowing a type from one model to be contained in (i.e. be a child in a composition relation with) a type from a model that imports its model would break this.
What this says is that, wrt object types, a model can/should be thought of as defining the root elements ("entities") in composition relationship trees with their contents.

[pdowler]

The definition/explanation here is pretty good: https://www.uml-diagrams.org/composition.html

I think @glemson is mainly describing bullets 1-2. I normally think of composition in terms of instance lifecycle, which is essentially bullets 3-4.

To me this means that only some classes in a model are re-usable in a composition relationship in another model. In that sense, the "quoted" statement may be too strong and/or inadequate...

I definitely think that a class in model A that is the child of a composition in A cannot be re-used by itself in another model, so there is some "less re-usable"-ness there.

From basic concepts, a class from model A that is not a child in a composition could (in principle) be used in a composition by model B... I don't know what that means for model C (that also imports A) and also wants to do that. Maybe the intent of the statement is that allowing cross-model composition is going to be a mess so just never do that.

If model A has a class X and model B imports it, can it extend X and then use that in a composition? The stated rule would be satisfied... is that rule just requiring a (potentially no-op/featureless) subclass to enable composition? Is that a good thing or a bad thing?

[pahjbo]

The definition/explanation here is pretty good: https://www.uml-diagrams.org/composition.html

I think @glemson is mainly describing bullets 1-2. I normally think of composition in terms of instance lifecycle, which is essentially bullets 3-4.

There is of course the existing "Unique Composition" schematron rule that does warn about that situation - there is no similar rule that validates the VO-DML against the composition target coming from another model (which is surprising given the "MUST" NOT nature).

Having said this I do not really agree that either being absolutely banned, but I think that they should only come with warnings that you need to be careful with exact lifecycles of individual instances of the classes in the composites - Using the example from the UML you could have a model where a University could have a Department as well as a Hospital - as @pdowler says you could do potentially no-op subclasses of Department to obey the rule, but I do not think that there is much value in actually forcing that.

What this says is that, wrt object types, a model can/should be thought of as defining the root elements ("entities") in composition relationship trees with their contents

.I think that conceptually this is correct, but again for a particular set of instances of the imported model if the instances are created in a context where the only the imported model is considered - as soon as the model is imported into another model then the model context for those entities not already explicitly the targets of some composition relationship become "contained" within
the importing model's global context - if we do not allow that then it makes factoring models into reusable chunks very difficult.