UML24 — Problem with ExtensionEnd::lower

In the UML 2.4 metamodel, there is a definition of ExtensionEnd::/lower in the superstructure that marks the property as derived, and at the same time gives it a default of 0. The spec text and diagrams do not show it as derived, so the metamodel and diagrams are inconsistent. The same is true in 2.3.

This seems to be a significant issue with regard to profile interchange, so I’d like to fix it in 2.4. Juergen, could we have an issue number please?

Profiles::ExtensionEnd::/lower redefines MultiplicityElement::/lower.

MultiplicityElement::/lower is marked as derived. It does not have a default value. Instead, there is a derivation constraint:

lower = lowerBound(); and operation

lowerBound() = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif

In the metamodel, ExtensionEnd::/lower is marked as derived, redefining MultiplicityElement::/lower, and with default value = 0. What is this supposed to mean? If it redefines MultiplicityElement::/lower, presumably it should redefine the way that it is derived. But it does not. So there is no well-defined derivation.

If we regarded the derivation in MultiplicityElement to be somehow “inherited” across the redefinition, we would then have a clash between the 1 defined in Multiplicity::lowerBound(), and the 0 defined as the default value for ExtensionEnd::lower.

I think to fix this what we ought to do is the following. Instead of giving ExtensionEnd::/lower a default value, we should provide the following constraints and operations in ExtensionEnd:

lower = lowerBound(); and

lowerBound() = if lowerValue->isEmpty() then 0 else lowerValue.integerValue() endif

This seems to be consistent with current profile interchange practice. I see the following in MIWG testcase3, which is consistent with my proposal.

<packagedElement xmi:type="uml:Extension" xmi:id="_9YgZUFzvEd6YpLSSRX9zkg" name="Property_Stereotype3" memberEnd="_9YgZUVzvEd6YpLSSRX9zkg _9YgZU1zvEd6YpLSSRX9zkg">

<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_9YgZUVzvEd6YpLSSRX9zkg" name="extension_Stereotype3" type="_FbscYFzfEd6YpLSSRX9zkg" aggregation="composite" owningAssociation="_9YgZUFzvEd6YpLSSRX9zkg" association="_9YgZUFzvEd6YpLSSRX9zkg">

<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_9YgZUlzvEd6YpLSSRX9zkg" value="1"/>

</ownedEnd>

</packagedElement>

After analysis, it becomes clear that the diagnosis above is flawed. When Profiles are merged in at L2 and above, Kernel is merged in too. When they are all merged in, the complete definition of ExtensionEnd::/lower [0..1] is acquired from the following sources:

• the fact that it is derived is from AuxiliaryConstructs::Profiles
• the constraint that determines how it is derived from lowerBound() is inherited from Kernel::MultiplicityElement
• the redefined operation lowerBound() is merged from InfrastructureLibrary::Profiles::ExtensionEnd: the operation is specified there even though lower is not derived in that place. This operation redefines Core::Constructs::MultiplicityElement::lowerBound(), so after merging will redefine Kernel::MultiplicityElement::lowerBound().
  However, the [0..1] multiplicity of lower() – the operation which gives the derivation for ExtensionEnd::/lower in the metamodel – conflicts with the [1] multiplicity of the corresponding redefined lower() operation in MultiplicityElement – it represents a “widening” of the multiplicity in a redefinition. This turns out to be a bug in the metamodel. In the spec, MultiplicityElement::lower(), MultiplicityElement::lowerBound() MultiplicityElement::upper(), MultiplicityElement::upperBound(), ValueSpecification::integerValue() are all defined with result types of Set(Integer), but have been implemented in the metamodel as Integer[1]. So the material defects are that lower is not correctly defined in the text or diagrams of clause 18, and the operations around MultiplicityElement and ValueSpecification should have their multiplicities corrected.