UML22 — Invalid mandatory compositions and associations

I initially thought this just affected chapter 11 and compositions, but the more I looked the wider the impact: this seems quite a systemic problem.

There are several significant metamodel errors that would prevent population of models in repositories that enforce association semantics. These affect both the diagrams and the metamodel (though I have not checked every association in the metamodel XMI).
The common problem is metaclasses being shown with multiple mandatory composite owners (i.e. a multiplicity of 1 as opposed to 0..1) next to the black diamond. In some cases this is implicit (the default multiplicity being 1..1, in others explicitly '1'). Since any instance can have at most one composite owner, to have more than one such owner mandatory makes for an 'impossible' (to be valid) metamodel.

There are non-composition cases where it also does not make sense to have associations mandatory. Often the mandatory nature is implicit (there is not explicit multiplicity shown on the diagrams).

Here is the list of diagrams and the problematic classes:
Figure 7.7 Element (not every Element will be constrained)
Figure 7.8 StructuralFeature (not every StructuralFeature will have a Slot defined for it in some instance model) and Classifier (again not every Classifier will have at least one InstanceSpecification)
Figure 7.9 NamedElement, Classifier (for redefinedElement, general), RedefinableElement (for redefinedElement, redefinitionContext)
Figure 7.10 Type
Figure 7.12 Type (via endType), Class(via superClass), and Property (via opposite, redefinedProperty, subsettedProperty)

Figure 8.2 Classifier (not every Classifier will realize a Component) and Interface (not every Interface will be both provided and required by at least one Component)

Figure 10.2 Artifact (inverse of nestedArtifact is mandatory - not every Artifact will be nested in another)
Figure 10.3 Node (ditto for nestedNode)

Figure 11.3 InputPin and OutputPin
Figure 11.4 InputPin and OutputPin
Figure 11.5 InputPin
Figure 11.8 InputPin
Figure 11.13 InputPin
Figure 11.17 InputPin and OutputPin.

Figure 11.2 does not have mandatory composition but requires each InputPin (and OutputPin) to be the inputValue of an OpaqueAction which seems quite wrong.

Figure 12.10 ValueSpecification
Figure 12.11 ValueSpecification
Figure 12.13 Constraint
Figure 12.14 ValueSpecification
Figure 12.19 ValueSpecification

Figure 13.12 ValueSpecification
Figure 13.13 ValueSpecification and Observation (the latter is not a composition error but it seems wrong)

Figure 14.3 Constraint
Figure 14.5 NamedElement (again not composition but not every NamedElement should be the signature of a Message)
Figure 14.7 ValueSpecification

Figure 15.2 Trigger (there is only one mandatory composition but it makes the optional composition useless since the latter could never be set)

Figure 17.16 ParameterableElement (not a composition but each ParameterableElement will not be the default of a TemplateParameter)

Proposed Resolution: mark all the above association ends as 0..1 and update the metamodel accordingly

No Data Available