Issue 5951: UML 2.0 Superstructure: Operation vs. Attribute notation (uml2-superstructure-ftf) Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com) Nature: Severity: Summary: For reference, my copy here is ad/03-04-01. I wonder about an inconsistency between the notations for attributes (section 1.8, page 41, in "Classifier (from Kernel, Dependencies, PowerTypes)") and operations (section 1.10, page 55, in "Operation (from Kernel)"). For attributes, the notation is (slightly simplified) visibility name : type [multiplicity] {property-string} and for operations, it is visibility name (parameter-list) : property-string So in the case of attributes, a colon separates the name from the type, and the property-string is in curly braces, whereas for operations, the colon separates the name and signature from the property-string, which is not in braces. I think this discrepancy is counter-intuitive, I would expect the same atoms to be used in both blaces. I realize that the syntax for operations changed from UML 1.5 because of promoting the "return value" to a parameter. My suggestion is to change the notation for operations to visibility name (parameter-list) {property-string} i.e. to remove the colon, and to add braces around the property- string. This would be more consistent with both the attribute notation and the old UML 1.x notation. Resolution: see above - resolved Revised Text: Actions taken: June 13, 2003: received issue March 8, 2005: closed issue Discussion: The issuer was using an outdated version of the spec. In fact, in the final adopted spec, the notation for operations is exactly as specified above. However, there are a number of issues raised against eliminating the “: <return-type>” capability, which is both familiar and much used, and is also referred to by many books and supported in many tools. In fact, there are examples in the spec itself (e.g., pg. 79). Therefore, in conjunction with the fix to issue 7135, the following notation is proposed for operation: [<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’ [‘:’ [<return-type>] ‘{‘ <oper-property> [‘,’ <oper-property>]* ‘}’] where <return-type> is the type of the return result parameter if the operation has one defined. Further details of where this text is to be inserted are provided in the resolution to issue 7135. End of Annotations:===== Subject: UML 2.0 Superstructure: Operation vs. Attribute notation Date: Fri, 13 Jun 2003 16:04:52 -0400 Thread-Topic: UML 2.0 Superstructure: Operation vs. Attribute notation Thread-Index: AcMx5w0TSHgZNlcrTGyjDFdTV3K4Pw== From: "Pilhofer, Frank" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h5DK4w51019836 Hi, this is an issue for whatever FTF is tasked to finalize the UML 2.0 Superstructure document. For reference, my copy here is ad/03-04-01. I wonder about an inconsistency between the notations for attributes (section 1.8, page 41, in "Classifier (from Kernel, Dependencies, PowerTypes)") and operations (section 1.10, page 55, in "Operation (from Kernel)"). For attributes, the notation is (slightly simplified) visibility name : type [multiplicity] {property-string} and for operations, it is visibility name (parameter-list) : property-string So in the case of attributes, a colon separates the name from the type, and the property-string is in curly braces, whereas for operations, the colon separates the name and signature from the property-string, which is not in braces. I think this discrepancy is counter-intuitive, I would expect the same atoms to be used in both blaces. I realize that the syntax for operations changed from UML 1.5 because of promoting the "return value" to a parameter. My suggestion is to change the notation for operations to visibility name (parameter-list) {property-string} i.e. to remove the colon, and to add braces around the property- string. This would be more consistent with both the attribute notation and the old UML 1.x notation. Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 29 Feb 2004 21:31:54 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: ,cl, Issue 5951 Operation and Attribute notation Before recommending a resolution of this issue, we ask for comments. We find three different ways to specify notation and two variations. The three ways: 1. a sort of Bakus-Naur form as in: multiplicity ::= [ .{. .}. ] see 7.4.1 2. a second way as in: [visibility] [/] name [: type] [multiplicity] [= default] [{ property-string }] see 7.8.1 The characters that are a part of the notation (virgule, colon, equals and braces) are simply shown. 3. a third way, combining features of both as in: visibility name .<. template-parameter-list .>. .<<.binding-expression-list .>>..( . parameter-list .). .:. property-string see 17.5.12 The characters that are a part of the notation (angle bracket, parens, colon) are enclosed in single quotes. (The inverted comma and apostrophe are not consistently used as opening and closing single quotes.) Both the second and the third ways are sometimes used at the same place as in: [visibility] [/] name [: type] [multiplicity] [= default] [{ property-string }] {{ [ name ] .:. classname } | name } [ .[. multiplicity .]. ] see 17.5.7 The two variations: a. Sometimes a single bracket does double duty as in: direction name : type-expression [multiplicity] = default-value [{ property-string }] see 7.10.1 Here, the brackets around multiplicity indicate both that multiplicity is optional, and that the multiplicity is to be shown inside brackets. see 7.10.1 b. Sometimes the brackets are not used when an item is optional as in: visibility name ( parameter-list ) : property-string see 7.10.1 ...................................................... Would it be best to adopt a single notation to specify text strings used in the notation? If not, please comment, explaining why. If you like the idea, silence will result in a proposal for a single notation for the specification of notation text. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 From: "Thomas Weigert" To: "Joaquin Miller" , "UML Superstructure FTF" Subject: RE: ,cl, Issue 5951 Operation and Attribute notation Date: Mon, 1 Mar 2004 07:24:25 -0600 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Joaquin, your note below is a little confusing to read, but I think what you are asking for is: "Should there be a single meta-grammar used to specify production rules of textual grammars for all the situations where text strings are used as notation in UML?" If that is the question, the answer is clearly "YES". We should define a single meta-grammar in the beginning of the text, and then use this grammar in all situations where we define text strings as part of the UML syntax. The detail of the meta-grammar are not very important, as long as the symbols of the meta-grammar are easily distinguished from the terminal symbols of the grammars defined. You might want to use, for example, the meta-grammar defined for ITU documents in Z.100, or make up any one you like... Unfortunately, there is no universal one you could just reference. All the best, Th. -----Original Message----- From: Joaquin Miller [mailto:joaquin.no.spam@acm.org] Sent: Sunday, February 29, 2004 11:32 PM To: UML Superstructure FTF Subject: ,cl, Issue 5951 Operation and Attribute notation Before recommending a resolution of this issue, we ask for comments. We find three different ways to specify notation and two variations. The three ways: 1. a sort of Bakus-Naur form as in: multiplicity ::= [ { }] see 7.4.1 2. a second way as in: [visibility] [/] name [: type] [multiplicity] [= default] [{ property-string }] see 7.8.1 The characters that are a part of the notation (virgule, colon, equals and braces) are simply shown. 3. a third way, combining features of both as in: visibility name < template-parameter-list ><> parameter-list ):property-string see 17.5.12 The characters that are a part of the notation (angle bracket, parens, colon) are enclosed in single quotes. (The inverted comma and apostrophe are not consistently used as opening and closing single quotes.) Both the second and the third ways are sometimes used at the same place as in: [visibility] [/] name [: type] [multiplicity] [= default] [{ property-string }] {{ [ name ] :classname } | name } [ [ multiplicity ]] see 17.5.7 The two variations: a. Sometimes a single bracket does double duty as in: direction name : type-expression [multiplicity] = default-value [{ property-string }] see 7.10.1 Here, the brackets around multiplicity indicate both that multiplicity is optional, and that the multiplicity is to be shown inside brackets. see 7.10.1 b. Sometimes the brackets are not used when an item is optional as in: visibility name ( parameter-list ) : property-string see 7.10.1 ...................................................... Would it be best to adopt a single notation to specify text strings used in the notation? If not, please comment, explaining why. If you like the idea, silence will result in a proposal for a single notation for the specification of notation text. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 To: Joaquin Miller Cc: UML Superstructure FTF Subject: Re: ,cl, Issue 5951 Operation and Attribute notation X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 1 Mar 2004 08:26:26 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/01/2004 08:26:29, Serialize complete at 03/01/2004 08:26:29 Excellent point, Joaquin -- this inconsistency is clearly confusing and unacceptable. I suggest that we use the BNF (BTW, it's 'Backus' not 'Bakus') shown in the first example, with angular brackets for non-terminals, and either square brackets followed by an optional * for the case of 0..* or braces followed by an optional * for representing the case of 1..*. However, please raise a new issue to deal with this specific problem. It would not be appropriate to sneak this under the guise of a fix to issue 5951 which is quite specific to the problem of the concrete syntax for attributes and operations in classifiers. Cheers, Bran Joaquin Miller 03/01/2004 12:31 AM Please respond to Joaquin Miller To UML Superstructure FTF cc Subject ,cl, Issue 5951 Operation and Attribute notation Before recommending a resolution of this issue, we ask for comments. We find three different ways to specify notation and two variations. The three ways: 1. a sort of Bakus-Naur form as in: multiplicity ::= [ â..{â.. â..}â.. ] see 7.4.1 2. a second way as in: [visibility] [/] name [: type] [multiplicity] [= default] [{ property-string }] see 7.8.1 The characters that are a part of the notation (virgule, colon, equals and braces) are simply shown. 3. a third way, combining features of both as in: visibility name â..<â.. template-parameter-list â..>â.. â..<<â..binding-expression-list â..>>â..â..( â.. parameter-list â..)â.. â..:â.. property-string see 17.5.12 The characters that are a part of the notation (angle bracket, parens, colon) are enclosed in single quotes. (The inverted comma and apostrophe are not consistently used as opening and closing single quotes.) Both the second and the third ways are sometimes used at the same place as in: [visibility] [/] name [: type] [multiplicity] [= default] [{ property-string }] {{ [ name ] â..:â.. classname } | name } [ â..[â.. multiplicity â..]â.. ] see 17.5.7 The two variations: a. Sometimes a single bracket does double duty as in: direction name : type-expression [multiplicity] = default-value [{ property-string }] see 7.10.1 Here, the brackets around multiplicity indicate both that multiplicity is optional, and that the multiplicity is to be shown inside brackets. see 7.10.1 b. Sometimes the brackets are not used when an item is optional as in: visibility name ( parameter-list ) : property-string see 7.10.1 ...................................................... Would it be best to adopt a single notation to specify text strings used in the notation? If not, please comment, explaining why. If you like the idea, silence will result in a proposal for a single notation for the specification of notation text. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Mar 2004 13:01:06 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: ,cl, Issue 5951 Operation and Attribute notation [My machine just returned after four days in the shop.] Thanks. I hope someone else will volunteer. If not, i will have a look at using a language from Z.100. Do you have in mind the sort of BNF in clause 5.4, or one of the other languages in that clause? Thomas wrote: your note below is a little confusing to read, but I think what you are asking for is: "Should there be a single meta-grammar used to specify production rules of textual grammars for all the situations where text strings are used as notation in UML?" If that is the question, the answer is clearly "YES". We should define a single meta-grammar in the beginning of the text, and then use this grammar in all situations where we define text strings as part of the UML syntax. The detail of the meta-grammar are not very important, as long as the symbols of the meta-grammar are easily distinguished from the terminal symbols of the grammars defined. You might want to use, for example, the meta-grammar defined for ITU documents in Z.100, or make up any one you like... Unfortunately, there is no universal one you could just reference. Right. That's why i wrote: 1. a sort of Bakus-Naur form By the way: Would it be best to adopt a single notation to specify text strings used in the notation? You restated this exactly. (I like my formulation, but it has an entirely different use from yours, which is much more effective when we get down to actually doing the work.) PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Mar 2004 13:02:54 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: Re: ,cl, Issue 5951 Operation and Attribute notation [My machine just returned after four days in the shop.] Bran wrote: ... please raise a new issue to deal with this specific problem. It would not be appropriate to sneak this under the guise of a fix to issue 5951 which is quite specific to the problem of the concrete syntax for attributes and operations in classifiers. Right. I'm hoping someone will volunteer the post the issue, and that the issue posting will contain a suggested resolution. Until that does not happen, i'll focus on our working group's issues. If no issue with proposed resolution is posted by midweek, i'll post one, and probably propose we use the syntax of Z.100 clause 5.4.2, as suggested by Thomas. Frank