UML23 — lowerBound/upperBound constraints and derivations wrong

Issue on UML 2.2 Superstructure, Section 7.3.32:

1. There are 2 constraints numbered [1]

2. The 2nd of these is: lowerBound()->notEmpty() implies lowerBound() >= 0.

However the way lowerBound() is defined (operation [4]) means it can never be empty: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif

It makes more sense to have the constraint condition apply to the stored lowerValue. i.e. lowerValue()->notEmpty() implies lowerBound() >= 0

3. Likewise constraint [2] should be: upperValue()->notEmpty() implies upperBound() >= lowerBound()

4. Note that this omits the test currently in constraint for lowerValue notEmpty since lowerBound will then default to 1 – and it’s necessary to have the constraint check that upperValue is not less.

5. /upper and /lower are defined as [0..1]. However since they are defined in terms of upper/lowerValue – which always has a value - then they will never be empty so should be declared as [1].

1. This is no longer relevant in UML 2.5.
2. Actually, lowerBound can be empty, because lowerValue.integerValue() will be empty if lowerValue does
not have an integer value. Redefining lowerBound() to check if lowerValue.integerValue() is null, rather
than just lowerValue, would ensure that lowerBound always was non-empty. With this change, simply
lowerBound() >=0 would be sufficient for the constraint. (But see also the resolution to Issue 17583.)
3. Similarly changing the definition of upperBound() to check upperValue.unlimitedValue() would mean
that upperBound() >= lowerBound() would be sufficient as the constraint.
4. Actually, including the constraint upperValue->notEmpty() is not correct. Because if the upperValue is
empty, then upperBound() defaults to 1, which still needs to be greater than or equal to lowerBound().
5. Actually, upper and lower are defined in terms of upperBound() and lowerBound(), not upperValue
and lowerValue. Modified as described above, those operations will always return a value. So, the return
parameters for upperBound() and lowerBound() should have multiplicity 1..1, as well as the attributes upper
and lower.
This also resolves Issue 17808.