Issue 6262: UML 2 Super / Templates / TemplateParameter not named (uml2-rtf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: TemplateParameters do not appear to be namable. They inherit from Element and not NamedElement. In UML 1.5 they inherited from ModelElement (i.e. were namable). They need to be named to be referred to in the implementation of the template. Resolution: Revised Text: Actions taken: September 23, 2003: received issue August 23, 2006: closed issue Discussion: TemplateParameters do not appear to be namable. They inherit from Element and not NamedElement. In UML 1.5 they inherited from ModelElement (i.e. were namable). They need to be named to be referred to in the implementation of the temp late. Discussion: The real problem is not the one stated above. This is because there is a mistaken assumption here that the metamodel element called TemplateParameter models the actual parameter. Instead, it is merely a “pointer” to the parameter. A more precise name might be to call it ParameterReference or ParameterSelector. But, such a change would require a very careful examination of the very, very many references to the term “template parameter” to distinguish whether it refers to the actual parameter or to the reference to the parameter. This is a significant change that, arguably, is out of scope of this FTF, since it is not something that is broken or inconsistent in the spec. The metamodel element called TemplateParameter is merely a “pointer” to some named element owned by the templateable element (e.g., an attribute) that has been designated as a template parameter. Therefore, there is no need for TemplateParamter to be a named element, since it is never referenced. Disposition: Closed, no change End of Annotations:===== ubject: UML 2 Super / Templates / TemplateParameter not named X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 23 Sep 2003 05:59:12 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/23/2003 05:59:14, Serialize complete at 09/23/2003 05:59:14 TemplateParameters do not appear to be namable. They inherit from Element and not NamedElement. In UML 1.5 they inherited from ModelElement (i.e. were namable). They need to be named to be referred to in the implementation of the template. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 OMG Issue No: 6262 Title: UML 2 Super / Templates / TemplateParameter not named Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: TemplateParameters do not appear to be namable. They inherit from Element and not NamedElement. In UML 1.5 they inherited from ModelElement (i.e. were namable). They need to be named to be referred to in the implementation of the template. Discussion: The real problem is not the one stated above. This is because there is a mistaken assumption here that the metamodel element called TemplateParameter models the actual parameter. Instead, it is merely a .pointer. to the parameter. A more precise name might be to call it ParameterReference or ParameterSelector. But, such a change would require a very careful examination of the very, very many references to the term .template parameter. to distinguish whether it refers to the actual parameter or to the reference to the parameter. This is a significant change that, arguably, is out of scope of this FTF, since it is not something that is broken or inconsistent in the spec. Disposition: Deferred Subject: RE: Yet more proposed resolutions Date: Tue, 17 Feb 2004 03:54:59 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Yet more proposed resolutions Thread-Index: AcP05puIbsCeyDsyQ6i/J1NAdx1AegASg+SA From: "Pete Rivett" To: "Branislav Selic" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i1H8gSrh005281 For 6262 we could at least make some minor additions to the text to mitigate the confusion caused by the poor choice of name. In general I'm disappointed that we don't do more clarification but tend to 'close no change': rather than addressing the cause of the confusion that caused at least one person to go the trouble of raising an issue about it. For 6970 the resolution seems to ignore the 1st point made in the issue: "A subsystem is a component stereotype, so it doesn't make sense to mention it here." Moreover, I don't see why UML 2 should be constrained by backward compatibility with UML 1.x in the manner suggested: there are surely very many areas where UML 2 allows things not allowed in UML 1.x. NB the sentence does not read correctly "The intent of the constraint was to specifically only allow the associations to elements listed in the constraint are allowed " Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, 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: Monday, February 16, 2004 5:37 PM To: uml2-superstructure-ftf@omg.org Subject: Yet more proposed resolutions I've updated my ballot 8 resolution proposals with resolutions to issues 6962, 6963, 6964, 6966, 6968, 6969, 6970 (all of these are trivial issues to use case related problems). Bran To: "Pete Rivett" Cc: uml2-superstructure-ftf@omg.org Subject: RE: Yet more proposed resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 17 Feb 2004 08:03:16 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/17/2004 08:03:20, Serialize complete at 02/17/2004 08:03:20 Thanks for doing the review, Pete. I really wish more of the FTF members would do the due diligence that you do. (I feel that the FTF members who are not contributing resolutions should at least review them -- otherwise, what is the point of being on the FTF?) Regarding issue 6262: note that the proposed resolution is to "defer" the issue, not to close it off with no change. The problem is that the name (TemplateParameter) is misleading, because it really is just a pointer to the actual parameter. This is actually clarified in the current text that describes the concept (which is what you were asking for). But, unless someone reads that part of the text, they will continue to be confused. The only real solution is to change the name, but this requires a significant amount of work. The term "template parameter" appears close to 50 times in the text, sometimes referring to the actual parameter and sometimes to the pointer to the parameter. Given the time pressure we are under and our resource limitations, I felt that this particular issue was not worth the effort of visiting each of those 50 references and changing it appropriately. So, I left the issue to be addressed at some future time. As for issue 6970: I think that the person raising the issue did not quite understand that the intent was to explicitly restrict use cases to ONLY to the ones listed in the constraint AND NO OTHERS. Hence, his proposed resolution was inappropriate. Whether use cases should be restricted to just those or not, is a separate issue and one that has been debated (very heatedly I assure you) for over 3 years. Actually, I lost that debate. But, given that this was decision made by the U2P based on input from people who are deemed the experts on use cases (Ivar included), I did not feel it appropriate for me to change that decision now. In this case, there is nothing broken or inconsistent about this particular point that warrants such a change. Those who feel strongly about this should raise a separate issue and it can be discussed on its own merits. (BTW, thanks for spotting the bit of bad English in the resolution text -- I will fix that.) Please tell me if you find these explanations adequate. If not, I will pull the issues from the ballot so that we can discuss them further. Thanks, Bran "Pete Rivett" 02/17/2004 03:54 AM To: Branislav Selic/Ottawa/IBM@IBMCA, cc: Subject: RE: Yet more proposed resolutions For 6262 we could at least make some minor additions to the text to mitigate the confusion caused by the poor choice of name. In general I'm disappointed that we don't do more clarification but tend to 'close no change': rather than addressing the cause of the confusion that caused at least one person to go the trouble of raising an issue about it. For 6970 the resolution seems to ignore the 1st point made in the issue: "A subsystem is a component stereotype, so it doesn't make sense to mention it here." Moreover, I don't see why UML 2 should be constrained by backward compatibility with UML 1.x in the manner suggested: there are surely very many areas where UML 2 allows things not allowed in UML 1.x. NB the sentence does not read correctly "The intent of the constraint was to specifically only allow the associations to elements listed in the constraint are allowed " Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, 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: Monday, February 16, 2004 5:37 PM To: uml2-superstructure-ftf@omg.org Subject: Yet more proposed resolutions I've updated my ballot 8 resolution proposals with resolutions to issues 6962, 6963, 6964, 6966, 6968, 6969, 6970 (all of these are trivial issues to use case related problems). Bran e-mail: bselic@ca.ibm.com