UML 2.3 RTF Avatar
  1. OMG Issue

UML23 — lowerBound/upperBound constraints and derivations wrong

  • Key: UML23-72
  • Legacy Issue Number: 13992
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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].

  • Reported: UML 2.2 — Mon, 15 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT