Issue 6502: Multiplicity seems to be broken - UML2 Infra & Super (uml2-rtf) Source: Daimler AG (Mr. Mario Jeckle, mario(at)jeckle.de) Nature: Uncategorized Issue Severity: 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? Resolution: Revised Text: Actions taken: November 7, 2003: received issue February 18, 2005: moved from infrastructure August 23, 2006: closed issue Discussion: UML 2 Revision Task Force Disposition: Closed, no change OMG Issue No: 6502 Document ptc/06-01-01 Page 641 Or am I just misreading the spec? Discussion: The response to these items is embedded below each: • (P1) (9) and (10) are never used This claim is simply incorrect: both of these designators can be used in specifying a multiplicity • (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]) Technically, this is true, but the possibility is prevented by an OCL constraint. The BNF is used merely to define the valid notational forms and does not deal with semantic constraints, which are covered elsewhere. The case where a lower bound would require an UnlimitedNatural does not seem to be required and may confuse some readers and would likely cause a disruption in numerous implementations. • (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) This was fixed in the FTF. • (P4) (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. Once again (see the response to (P2)), the submitter is mistakenly assuming that the BNF is used to define the semantic constraints, whereas it merely specifies the notation. • (P5) 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. Again, there is a constraint that deals with that case. • (P6) What is the role of the value_specification mentioned at (8) and (9) isn't it redundant there? Value specifications allow the use of various symbolic references. Disposition: Closed, no change End of Annotations:===== -Return: cris.kobryn@telelogic.com Date: Sat, 08 Nov 2003 07:23:09 -0000 From: "Cris Kobryn" To: juergen@omg.org, issues@omg.org, cris.kobryn@telelogic.com Subject: Fwd: Multiplicity seems to be broken - UML2 Infra & Super User-Agent: eGroups-EW/0.82 X-Mailer: Yahoo Groups Message Poster X-Originating-IP: 68.71.8.84 --- In u2p-issues@yahoogroups.com, Mario Jeckle wrote: There seems to be a flaw at the specification of Multiplicities. 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? Mario -- Prof. Mario Jeckle University of Applied Sciences Furtwangen Dept. Business Applications of Computer Science W3C Representative of DaimlerChrysler Research and Technology OMG Representative of DaimlerChrysler URL: http://www.jeckle.de MailTo:mario@j... MailTo:jeckle@f... My public key: http://www.jeckle.de/marioJeckle.pub [mail really from me _always_ has this signature and is signed digitally -- mail without it is forged spam] Reply-To: Joaquin Miller X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 08 Apr 2005 11:15:55 -0700 To: UML-RTF From: Joaquin Miller Subject: Ballot 1 draft Please review the proposed ballot 1 resolutions. I sent out a batch yesterday and others will, presumably, send some out later today and tomorrow. If you have any problems with any of the resolutions, this is the time to raise them, not when the ballot has been issued and the vote started. Issue 6275 This would have been clearer had there been an explicit {redefines raisedException} constraint on Operations::raisedException, so let's add that. Or, let's make explicit the reasonable policy that we have limited resources, so we will fix actual errors but not work to improve usability. Issue 6616 The isLeaf feature seems unnecessary, since it is easy to determine if something is a leaf classifier simply by checking whether it is included in the .generalization. meta-attribute of any classifier. In contrast, the .isRoot. property, on the other hand is necessary since it defines a constraint that defines that a classifier must not have any further generalizations. Or is it our intention that UML 2 does not have the capability to specify that the authors of a model intend that users are not to generalize from certain classifiers? Or, perhaps, is it explicit or implicit or assumed in the UML 2 specification that users can't or won't generalize existing classifiers, but that they can and will specialize existing classifiers? Issue 8075 Our audience includes readers of paper documents. If this happens only in a few places, let's correct this usability problem. If it is our policy to cater only to readers using Acrobat or Acrobat Reader, well... Maybe it is too late to change that policy. Issue 8082 Does the proposed resolution describe a best practice? Wouldn't the spec shine even more brightly if it stuck to a single style, even in examples? This is a pedagogical question, and very much worth our time to consider. Issues 8081, 8085, and 6502 I don't want to make work, but do have a question: Is there a positive reason to use integer instead of unlimited natural in the specification of lower bound, and then backpedal with a constraint? (I bet there is a positive reason not to use unlimited natural, and a good one; but then let's mention that reason in the resolution. If we had more resources, i'd urge adding natural to our armamentarium. ) Cordially, Joaquin www.joaquin.net --- End forwarded message ---