UML 2.2 RTF Avatar
  1. OMG Issue

UML22 — Multiplicity seems to be broken - UML2 Infra & Super

  • Key: UML22-507
  • Legacy Issue Number: 6502
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    The current Infastructure document defines it at page 54 as (line
    numbers have been added by me):
    (1) multiplicity ::= multiplicity_range
    (2) multiplicity_range ::= [lower '..'] upper
    (3) lower ::= integer
    (4) upper ::= unlimited_natural | '*'

    But at page 56 (also page 20 of the Superstructure document which
    copies
    the definition) it says:

    (5) multiplicity ::= multiplicty_range [

    {order_designator}

    ]
    (6) multiplicity_range ::= [lower '..'] upper
    (7) lower ::= integer | value_specification
    (8) upper ::= unlimited_natural | '*' | value_specification
    (9) order_designator ::= ordered | unordered
    (10) uniqueness_designator ::= unique | nonunique

    There are several problems arising from this definition:

    (P1) (9) and (10) are never used
    (P2) Defining the lower bound as "integer" (according to page 142 of
    the
    Infrastructure document) allows it to specify multiplicities with
    lower bounds below 0 (e.g. [-5..7], [-42..0])
    (P3) (4) and (8) include the asterisk symbol to denote an
    infinite
    upper bound. Though, this is redundant since the symbol is already
    there
    as part of the lexical representation of unlimited_natural (according
    to
    page 144 of the Infrastructure document)
    (P3) (4) and (8) define the upper bound using the datatype
    "unlimited_natural" which comprimises all integer numbers starting
    from
    zero. Thus multiplicities like [0..0] would be legal.
    (P4) It should be mentioned that the lower part is lower or equal to
    the
    value given for the upper part (where '*' is geater than any other
    element of the set named integer). Otherwise multiplicities like
    [8..2]
    would be considered legal.
    (P5) What is the role of the value_specification mentioned at (8) and
    (9) isn't it redundant there?

    Or am I just misreading the spec?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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