Issue 6171: 7.10.1 Operation (uml2-superstructure-ftf) Source: SSA (Mr. Arthur Culbertson, nobody) Nature: Uncategorized Issue Severity: Summary: Semantics The following is stated: "An operation may be redefined in a specialization of the featured classifier. This redefinition may specialize the types of formal parameters or return results, add new preconditions or postconditions, and new raised exceptions, or otherwise refine the specification of the operation." This statement is not correct if the 'isSubstitutable' attribute of the Generalization is true. To achieve substitutability the parameter types must either be invariant or contra-variant (generalized) rather than specialized. Clearly this statement reflects the type safety restrictions of programming languages, but overriding in actual programming languages does not guarantee substitutability. Similarly, the preconditions of the redefined operation in the specialized class can only be weakened (i.e., removed) not strengthened (i.e., added). Notation BNF should be used for specifying the syntax of an operation string. Resolution: see above Revised Text: Actions taken: September 3, 2003: received issue March 8, 2005: closed issue Discussion: The point is well taken that in jobs like specifying a C++ program, the parameter types and preconditions must not change at random as one goes down a hierarchy of userdefined types, so some language is in order to acknowlege the issue. An insertion of two sentences is proposed. The UML spec does not provide instruction on how to specify a well-designed hierarchy for any particular programming language, nor take sides in discussions regarding covariance and contravariance and design-by-contract, but notes this as a semantic variation point. The Notation -- BNF part of this issue is a duplicate. insert new text in at the end of Section 7.10.1 Operation after: Inserted Text: When operations are redefined in a specialization, rules regarding invariance, covariance, or contravariance of types and preconditions determine whether the specialized classifier is substitutable for its more general parent. Such rules constitute semantic variation points with respect to redefinition of operations. End of Annotations:===== From: "Culbertson, Arthur" To: "'issues@omg.org'" , "'uml2-superstructure-ftf@omg.org'" Subject: UML 2.0 Superstructure Issues (Part I -Structure) Date: Wed, 3 Sep 2003 10:43:47 -0400 X-Mailer: Internet Mail Service (5.5.2654.52) Dear Sirs: The following are some potential issues that I have found while reviewing Part I - Structure portion of the UML 2.0 Superstructure Specification (document pct/03-08-02) dated August 2003. As some of these issues could impact performance on the UML certification exams, I would appreciate feedback as soon as possible. 4) 7.10.1 Operation Semantics The following is stated: "An operation may be redefined in a specialization of the featured classifier. This redefinition may specialize the types of formal parameters or return results, add new preconditions or postconditions, and new raised exceptions, or otherwise refine the specification of the operation." This statement is not correct if the 'isSubstitutable' attribute of the Generalization is true. To achieve substitutability the parameter types must either be invariant or contra-variant (generalized) rather than specialized. Clearly this statement reflects the type safety restrictions of programming languages, but overriding in actual programming languages does not guarantee substitutability. Similarly, the preconditions of the redefined operation in the specialized class can only be weakened (i.e., removed) not strengthened (i.e., added). Notation BNF should be used for specifying the syntax of an operation string. From: "Thomas Weigert" To: "Branislav Selic" , , Subject: RE: Ballot 24 draft Date: Thu, 19 Aug 2004 23:35:54 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Comments: 6171: Delete last sentence of replacement text. It is not at all clear whether the mentioned rules are in scope of UML or not. Certainly we have declared those to be a semantic variation point in other places. I would suggest to move the text into the semantic variation point section and replace the last sentence by "Such rules constitute semantic variation points." 6988: Please make sure you use the new terminology introduced by Jim R. 7392: This would be resolved by the resolution to the Nick's event issue I sent in tonight. I would suggest to combine those. 7417: Just FYI. The text that the submitter complains about was a note that I had written to myself using the Frame conditional text feature. Somehow it ended up in the spec but was later removed, as it should have been. The resolution is correct. 7431: This resolution should be deleted. The issue references an outdated version of the spec. If the adopted resolution to issue 7122 were considered, much of the tension is gone: Constraint [2], as it is in place due to issue 7122, states that "The connectable elements attached to the ends of a connector must be compatible." Constraint [1], for a subtype of connector, states that the connectable elements must have the same or compatible interfaces. So the only conflict is that the phrasing in Components has not been updated to move the compatibility relation to the connectable elements and it still speaks of compatible interfaces. I think the bigger issue is that the constraint [1] mentions a connector between interfaces, which is nonsense. So what we should do is bring the constraint [1] in line with constraint [2] terminology, as compatibility between interfaces is not any more defined. 7434: There are two presentation options discussed under collaboration occurrence. The option quoted "point at the owning classifier" is not relevant to the problem; it refers to the situation where a collaboration represents an operation. But actually, the text of the presentation option has become so confusing due to the repeated changes to the keywords that it makes little sense. A clearer wording is required. In addition, it should be made clear which direction the arrow points. I would defer this issue, as the proposed solution does not really address the problem. 7438: The choice of word "connector" in this resolution is not good, as "Connector" is the name of a model element. 7575: Make sure that the bookmark references are correct in the final version. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 7:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 draft Attached, please find the draft of ballot 24. There are 66 resolutions in this one -- good work! Reminder: voting on this ballot will commence on Friday at 6 pm EDT. If you have any complaints or suggestions, please submit them by tomorrow noon EDT. Regards, Bran Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 02:22:18 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 24 draft Thread-Index: AcSGUaOOvWEvXmwvTEeA2cPkA+ZL9gAHR9rg Priority: Urgent From: "Pete Rivett" To: "Branislav Selic" , , X-Virus-Scanned: by amavisd-new at sentraliant.com 3391: I don't really like the idea of 2 separate sequences (one for body one for language) which must be kept in sync. It seems to me each (body+language) pair should be a structure/tuple: was this considered? I don't think the resolution should be pulled just on my objection but do think that at the very minimum the language property should be unique; and there should be a constraint that the size of the 2 sequences must be equal. 3398: the discussion (and hence the disposition) do not address the issue raised which is that the XMI spec specifies a number of tags that may be attached to metamodel elements in order to tailor the XMI Schema or Documents. While most of these have sensible defaults, there are others that do not. Prime examples are the XML namespace URI (e.g. http://schema.omg.org/spec/UML/2.0) and the namespace prefix (e.g. UML). Such values should certainly be included in the XMI for the metamodel and also in the specification document (a good place would be Appendix F). 5977: two problems are raised by the resolution: a) isUnique=true is the default for MultiplicityElement so we have a problem in that AFAIK (looking at resolution to 7575 in this set of issues) there is no notation to specify non-default multiplicity: the of {unique} is pointless since that's the default anyway! b) whether or not {nonunique} has an explicit notation the point raised by the issue still stands at the metamodel level: there should be a constraint to say that if one end of an association has isUnique=false then the other end must also have isUnique=false. 5979: also requires an Infra change 6171: In the last sentence, rather than saying 'Such rules are beyond the scope of UML' could they not be made a semantic variation point? A precedent is in 7.8.3 where there is a SVP related to compatibility of redefinitions. (I don't feel strongly about this) 6409, 6430, 6452: The discussion gives the reason for deferral as the OCL 2.0 spec not having been adopted; in fact it was adopted at the same time as Super. The declared intention of the submission teams on adoption was for the FTFs to perform a reconciliation between the largely stable adopted specs: OCL in particular has had virtually no changes. In any case the differences in OCL 2.0 are not great and it is not the case AFAIK that 'the vast majority of constraints are likely have to be rewritten'. If we've run out of time let's say that rather than raise unwarranted concerns (e.g. to AB) that major reconciliation work is still required with OCL. 6616: (minor typo) the discussion states: "and provides yet another way to introduce inconsistencies into a model, declaring a node a root when it in fact has children." In fact the inconsistency would be if the node had parent(s) 6630: I'm not very happy with the resolution since it continues to ignore the point I've been trying to make about the distinction between navigability and ownership (you can have navigability without an owned property): and I did not see any objection to my proposal of using the new dot notation to show non-ownership. It would be nice to have a response to that though I will not continue to object on this point. However I do strongly object to removing the name of association end supplierDependency on the basis that " by naming the supplierDependency end, the metamodel would invite constraints to be written involving it, etc". (this from an email between those word-smithing the issue) My objections are: a) the issue did not cite any problem with this being named b) I think it's acknowledged that some tools at least would like to do 'where used' navigations - and recent discussions on MDA have stressed the need for traceability: removing the association end name is actively hostile to such tools c) the only people who will be writing constraints on this association end would be ourselves or a successor RTF d) taking this rule as a precedent would involve deleting large numbers of other association end names from the metamodel. e) the resolution does not even make explicit that this name is being removed 7400: Misses the point of the issue: I wrote an email to explain the issue and the change needed (which is to have AssociationClass::ownedEnd subsetting AssociationClass::ownedAttribute). Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 7:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 draft Attached, please find the draft of ballot 24. There are 66 resolutions in this one -- good work! Reminder: voting on this ballot will commence on Friday at 6 pm EDT. If you have any complaints or suggestions, please submit them by tomorrow noon EDT. Regards, Bran Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 04:45:42 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 24 draft Thread-Index: AcSGb0j65U0m9FPKRZSucF9awkngmAAOmWYA From: "Karl Frank" To: "Thomas Weigert" , "Branislav Selic" , , X-OriginalArrivalTime: 20 Aug 2004 11:45:44.0959 (UTC) FILETIME=[3A57F8F0:01C486AB] wrt the issue I wrote up: 6171. Agreed. The reason the text is where it is in semantics, is that the original text that raised the issue was in semantics. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Friday, August 20, 2004 12:36 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Ballot 24 draft Comments: 6171: Delete last sentence of replacement text. It is not at all clear whether the mentioned rules are in scope of UML or not. Certainly we have declared those to be a semantic variation point in other places. I would suggest to move the text into the semantic variation point section and replace the last sentence by "Such rules constitute semantic variation points." 6988: Please make sure you use the new terminology introduced by Jim R. 7392: This would be resolved by the resolution to the Nick's event issue I sent in tonight. I would suggest to combine those. 7417: Just FYI. The text that the submitter complains about was a note that I had written to myself using the Frame conditional text feature. Somehow it ended up in the spec but was later removed, as it should have been. The resolution is correct. 7431: This resolution should be deleted. The issue references an outdated version of the spec. If the adopted resolution to issue 7122 were considered, much of the tension is gone: Constraint [2], as it is in place due to issue 7122, states that "The connectable elements attached to the ends of a connector must be compatible." Constraint [1], for a subtype of connector, states that the connectable elements must have the same or compatible interfaces. So the only conflict is that the phrasing in Components has not been updated to move the compatibility relation to the connectable elements and it still speaks of compatible interfaces. I think the bigger issue is that the constraint [1] mentions a connector between interfaces, which is nonsense. So what we should do is bring the constraint [1] in line with constraint [2] terminology, as compatibility between interfaces is not any more defined. 7434: There are two presentation options discussed under collaboration occurrence. The option quoted "point at the owning classifier" is not relevant to the problem; it refers to the situation where a collaboration represents an operation. But actually, the text of the presentation option has become so confusing due to the repeated changes to the keywords that it makes little sense. A clearer wording is required. In addition, it should be made clear which direction the arrow points. I would defer this issue, as the proposed solution does not really address the problem. 7438: The choice of word "connector" in this resolution is not good, as "Connector" is the name of a model element. 7575: Make sure that the bookmark references are correct in the final version. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 7:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 draft Attached, please find the draft of ballot 24. There are 66 resolutions in this one -- good work! Reminder: voting on this ballot will commence on Friday at 6 pm EDT. If you have any complaints or suggestions, please submit them by tomorrow noon EDT. Regards, Bran Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 04:54:15 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 24 draft Thread-Index: AcSGUaOOvWEvXmwvTEeA2cPkA+ZL9gAHR9rgAA6L76A= From: "Karl Frank" To: "Pete Rivett" , "Branislav Selic" , , X-OriginalArrivalTime: 20 Aug 2004 11:54:17.0929 (UTC) FILETIME=[6C18FB90:01C486AC] wrt the ones I wrote up: 1. 6616 Right. More dyslexia than typo, the reversal of parent and child in 6616, will change. 2. 6171. Thomas made the same point. Agreed. 3. 6630: I agree with you on this, but removed the navigability supported by association ownership from my proposal because Conrad objected to it, and because I felt the new dot navigability notation would then constitute a quite different sort of change than the original issue was asking for. Then I thought, well if a product supports a where-used query which the spec does not require, this does not constitute non-compliance, it is a case of going beyond what is required. As you can see, I am in favor especially of providing for the dot notation (in my opinion a square dot would be better becauase of the ball end of IDEF/1 notation) but see it as a distinct issue. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 20, 2004 2:22 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Ballot 24 draft Importance: High 3391: I don't really like the idea of 2 separate sequences (one for body one for language) which must be kept in sync. It seems to me each (body+language) pair should be a structure/tuple: was this considered? I don't think the resolution should be pulled just on my objection but do think that at the very minimum the language property should be unique; and there should be a constraint that the size of the 2 sequences must be equal. 3398: the discussion (and hence the disposition) do not address the issue raised which is that the XMI spec specifies a number of tags that may be attached to metamodel elements in order to tailor the XMI Schema or Documents. While most of these have sensible defaults, there are others that do not. Prime examples are the XML namespace URI (e.g. http://schema.omg.org/spec/UML/2.0) and the namespace prefix (e.g. UML). Such values should certainly be included in the XMI for the metamodel and also in the specification document (a good place would be Appendix F). 5977: two problems are raised by the resolution: a) isUnique=true is the default for MultiplicityElement so we have a problem in that AFAIK (looking at resolution to 7575 in this set of issues) there is no notation to specify non-default multiplicity: the of {unique} is pointless since that's the default anyway! b) whether or not {nonunique} has an explicit notation the point raised by the issue still stands at the metamodel level: there should be a constraint to say that if one end of an association has isUnique=false then the other end must also have isUnique=false. 5979: also requires an Infra change 6171: In the last sentence, rather than saying 'Such rules are beyond the scope of UML' could they not be made a semantic variation point? A precedent is in 7.8.3 where there is a SVP related to compatibility of redefinitions. (I don't feel strongly about this) 6409, 6430, 6452: The discussion gives the reason for deferral as the OCL 2.0 spec not having been adopted; in fact it was adopted at the same time as Super. The declared intention of the submission teams on adoption was for the FTFs to perform a reconciliation between the largely stable adopted specs: OCL in particular has had virtually no changes. In any case the differences in OCL 2.0 are not great and it is not the case AFAIK that 'the vast majority of constraints are likely have to be rewritten'. If we've run out of time let's say that rather than raise unwarranted concerns (e.g. to AB) that major reconciliation work is still required with OCL. 6616: (minor typo) the discussion states: "and provides yet another way to introduce inconsistencies into a model, declaring a node a root when it in fact has children." In fact the inconsistency would be if the node had parent(s) 6630: I'm not very happy with the resolution since it continues to ignore the point I've been trying to make about the distinction between navigability and ownership (you can have navigability without an owned property): and I did not see any objection to my proposal of using the new dot notation to show non-ownership. It would be nice to have a response to that though I will not continue to object on this point. However I do strongly object to removing the name of association end supplierDependency on the basis that " by naming the supplierDependency end, the metamodel would invite constraints to be written involving it, etc". (this from an email between those word-smithing the issue) My objections are: a) the issue did not cite any problem with this being named b) I think it's acknowledged that some tools at least would like to do 'where used' navigations - and recent discussions on MDA have stressed the need for traceability: removing the association end name is actively hostile to such tools c) the only people who will be writing constraints on this association end would be ourselves or a successor RTF d) taking this rule as a precedent would involve deleting large numbers of other association end names from the metamodel. e) the resolution does not even make explicit that this name is being removed 7400: Misses the point of the issue: I wrote an email to explain the issue and the change needed (which is to have AssociationClass::ownedEnd subsetting AssociationClass::ownedAttribute). Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 7:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 draft Attached, please find the draft of ballot 24. There are 66 resolutions in this one -- good work! Reminder: voting on this ballot will commence on Friday at 6 pm EDT. If you have any complaints or suggestions, please submit them by tomorrow noon EDT. Regards, Bran Reply-To: From: "Conrad Bock" To: , Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 13:04:54 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Comments on ballot 24 below. Conrad - 4932 (Starting state machine) Typo: replace "filter" with "filer". - 5979 (The description of DataType is plainly wrong in the specification) Typo: "considered the be the same". I assume the Figure 41 example will be included in the final document, even though it isn't in the resolution? The removal of presentation options and style guidelines is a separate issue isn't it? - 6171 (Operation) The new text should refer to Generalization::isSubstitutable, rather than say issues of substitutability are out of scope. - 6616 (UML Superstructure FTF : isRoot property disappeared) The resolution says that isRoot can be derived from whether a classifier has supertypes. This is incorrect, because isRoot is a record for modeler intent that no supertypes will be defined for the classifier. It is analogous to isLeaf, which declares there will be no subtypes, so compilers can optimize message passing into function invocation. I don't mind that isRoot was removed, but the issue should not say it is derivable. - 6902 (Identify sections specifying run-time semantics) Thanks for the update on this. Combined with Jim R's much improved description of events in common behavior, this will be OK for process modelers. (Since the separation of inter- and intra-object is not reflected much in actions and behaviors, it still seems a little confusing, but we don't have time for another update). Typo: "TThese". - 6975 (missing illustrations of graphical paths for create and destroy message) The issues asks for examples, not new notation. That seems reasonable, so this one can be deferred. - 7219 (Operations and derived attributes) One of the roles of FTF/RTF's is to answer questions, even if there is no change. If there is not time to answer these, they can be deferred. - 7438 (Section: 12.3.3) The resolution is incorrect (this should have been assigned to Activities). Here is the resolution: "Connectors are purely notational and have no name. The name displayed is the name of the edge. This is stated by the first sentence under Figure 207. However, there may be an issue that edges are not contained by ownedMember, to be restricted by the Activity namespace, but this requires more discussion to resolve."