Issue 6215: UML 2 Super/pg.64/Classifier redefinition notation (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: pg. 64: Classifier/Notation: Attribute with same name as one that would have been inherited is interpreted as a redefinition. Very dangerous. .It would be better to make it explicit with a <redefines> statement Resolution: see above Revised Text: Actions taken: September 7, 2003: received issue March 8, 2005: closed issue Discussion: Agreed. Replace the text on page 64 and also in the Infrastructure. There is another problem here also, the point is not specific to attributes alone, but to any redefinable element that is redefined in the context of a generalization hierarchy. Therefore generalize the verbiage beyond "attribute" to redefinable element The relevant text on page 64 of Superstructure and 121 of Infrastructure is: New Text: in both Super and Infra All redefinitions shall be made explicit with the use of a {redefines <x> } property string. Redefinition prevents inheritance of a redefined element into the redefinition context, thereby making the name of the redefined element available for reuse, either for the redefining element, or for some other. End of Annotations:===== To: issues@omg.org Subject: UML 2 Super/pg.64/Classifier redefinition notation X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Branislav Selic Date: Sun, 7 Sep 2003 09:47:41 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/07/2003 09:48:11, Serialize complete at 09/07/2003 09:48:11 pg. 64: Classifier/Notation: Attribute with same name as one that would have been inherited is interpreted as a redefinition. Very dangerous. .It would be better to make it explicit with a statement Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 Subject: RE: ,cl, Issue 6215 redefining then reusing a name Date: Thu, 29 Jul 2004 12:00:10 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cl, Issue 6215 redefining then reusing a name Thread-Index: AcR1nK3i9Zf5UJqXSXqmSFw52MBIagAAP2Kw From: "Karl Frank" To: "Joaquin Miller" , "MOF UML Infrastructure FTF" , "UML Superstructure FTF" X-OriginalArrivalTime: 29 Jul 2004 19:00:19.0946 (UTC) FILETIME=[4B28BCA0:01C4759E] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i6TJBjlj032143 In my writeup of the proposed resolution I too thought about this, and considered putting in a remark to discourage reusing a name that had been freed by redefinition, saying that such a practice was likely to cause confusion. However, I did not consider outlawing that bad practice, because: 1. I expect it may cause upgrade compatibility problems to outlaw what was formerly permitted (am I right, I think it has been permitted) 2. I expect that further down in an inheritance hierarchy, reusing a library for example in which something is already redefined and renamed, someone may want to use the name again, and not even be aware that it was formerly used and then hidden by an upstream redefinition. None of these considerations seem to me to be conclusive. - karl -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, 29 July, 2004 2:49 PM To: MOF UML Infrastructure FTF; UML Superstructure FTF Subject: ,cl, Issue 6215 redefining then reusing a name I wonder about something. If we see: a {redefines a} we're OK. If we see: b {redefines a} (e.g. S-11.3.38) we may wonder why the name needed to be changed, but what is going on is clear, and we have only b, and no a, so we can be reasonable comfortable. We may even (e.g. S-13.3.10) feel the name change is a good idea, or, anyway (e.g. I-11.3.2), while hardly necessary, at least OK, and even in rare cases, (e.g. I-11.7.2) unavoidable. But if we were to see: b {redefines a} a and now for something entirely different we have to ask a couple of questions: What is the connection between a in the general case and a in this case. What is the practical advantage of doing this. Or, forgetting those questions, here is a different one: Do we expect that anyone would actually do that? And another: Do we feel folks could somehow make do without doing that? If the answer the the last question is yes, or even probably, let's disallow this particular cute trick. Cordially, Joaquin To: Joaquin Miller Cc: MOF UML Infrastructure FTF , UML Superstructure FTF Subject: Re: ,cl, Issue 6215 redefining then reusing a name X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 29 Jul 2004 17:18:40 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/29/2004 17:18:41, Serialize complete at 07/29/2004 17:18:41 Joaquin, Redefinition was introduced by the U2P as a practical matter and is certainly at odds with some pretty reasonable theories of generalization. However, there were practical reasons why it is required (one of them is that the Liskov Substitutability Principle is not refined enough to deal with some of the complex semantics of some UML formalisms). Note that the spec actually attempts to give some guidelines when it says that the redefinition has to be compatible with what is being redefined, but, it then cops out by not specifying precisely what "being compatible" means. I happen to think that this is the right approach since the issue is to subtle to address in a simple way and is domain specific. I believe that the issue you are raising here is whether unconstrained redefinition should be supported in UML? However, I feel that answering that question is out of scope of the FTF. The OMG membership adopted the submission with redefinition defined as it was and did not consider this as one of the key issues that the FTF had to tackle. It may be a good idea to raise the issue in general, but I don't think it is appropriate to force the issue through this peripheral and relatively minor point. Regards, Bran Joaquin Miller 07/29/2004 02:48 PM Please respond to Joaquin Miller To MOF UML Infrastructure FTF , UML Superstructure FTF cc Subject ,cl, Issue 6215 redefining then reusing a name I wonder about something. If we see: a {redefines a} we're OK. If we see: b {redefines a} (e.g. S-11.3.38) we may wonder why the name needed to be changed, but what is going on is clear, and we have only b, and no a, so we can be reasonable comfortable. We may even (e.g. S-13.3.10) feel the name change is a good idea, or, anyway (e.g. I-11.3.2), while hardly necessary, at least OK, and even in rare cases, (e.g. I-11.7.2) unavoidable. But if we were to see: b {redefines a} a and now for something entirely different we have to ask a couple of questions: What is the connection between a in the general case and a in this case. What is the practical advantage of doing this. Or, forgetting those questions, here is a different one: Do we expect that anyone would actually do that? And another: Do we feel folks could somehow make do without doing that? If the answer the the last question is yes, or even probably, let's disallow this particular cute trick. Cordially, Joaquin Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 Jul 2004 16:20:50 -0700 To: MOF UML Infrastructure FTF , UML Superstructure FTF From: Joaquin Miller Subject: RE: ,cl, Issue 6215 redefining then reusing a name Just to discuss this particular point: 1. I expect it may cause upgrade compatibility problems to outlaw what was formerly permitted (am I right, I think it has been permitted) The only mention i find in formal-03-03-01 is: "For a classifier, no attribute, operation, or signal with the same signature may be declared in more than one of the segments (in other words, they may not be redefined)." [1.5-2.5.4.4] (Segment is a concept defined during the explanation of inheritance.) I don't find any mechanism for doing it, except on element import. [1.5-2.15.2.2] In this case, the new name is an alias, which means the element still has the original name. There is mention of redefining role names [1.5-3.66.2], and of the effect of redefinition on the meaning of OCL statements [1.5-6.5.9], but i find no mechanism for doing either of those. Perhaps i am missing something. The case we are interested is a redefinition that changes the name of an element, while permitting that same name to be used in the same namespace for a new item of the same kind. Cordially, Joaquin Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 Jul 2004 17:38:04 -0700 To: MOF UML Infrastructure FTF , UML Superstructure FTF From: Joaquin Miller Subject: Re: ,cl, Issue 6215 redefining then reusing a name Bran: I'm not thinking of this as being about "whether unconstrained redefinition should be supported in UML." But i suppose that is a way to put it. Nor am i objecting to redefinition as introduced by U2P and use in specifying UML 2. There is no case in the metamodels where a is redefined and renamed 'b', and then an entirely new item is added, and named 'a'. So we know we don't need that in the metamodel. I don't want to squeeze things in where they don't belong, but i would like to know if anyone can tell me: Do we expect that anyone would actually do that? Do we feel folks could somehow get by without doing that? At 02:18 PM 7/29/2004, Branislav Selic wrote: Joaquin, Redefinition was introduced by the U2P as a practical matter and is certainly at odds with some pretty reasonable theories of generalization. However, there were practical reasons why it is required (one of them is that the Liskov Substitutability Principle is not refined enough to deal with some of the complex semantics of some UML formalisms). Note that the spec actually attempts to give some guidelines when it says that the redefinition has to be compatible with what is being redefined, but, it then cops out by not specifying precisely what "being compatible" means. I happen to think that this is the right approach since the issue is to subtle to address in a simple way and is domain specific. I believe that the issue you are raising here is whether unconstrained redefinition should be supported in UML? However, I feel that answering that question is out of scope of the FTF. The OMG membership adopted the submission with redefinition defined as it was and did not consider this as one of the key issues that the FTF had to tackle. It may be a good idea to raise the issue in general, but I don't think it is appropriate to force the issue through this peripheral and relatively minor point. Regards, Bran I wonder about something. If we see: a {redefines a} we're OK. If we see: b {redefines a} (e.g. S-11.3.38) we may wonder why the name needed to be changed, but what is going on is clear, and we have only b, and no a, so we can be reasonable comfortable. We may even (e.g. S-13.3.10) feel the name change is a good idea, or, anyway (e.g. I-11.3.2), while hardly necessary, at least OK, and even in rare cases, (e.g. I-11.7.2) unavoidable. But if we were to see: b {redefines a} a and now for something entirely different we have to ask a couple of questions: What is the connection between a in the general case and a in this case. What is the practical advantage of doing this. Or, forgetting those questions, here is a different one: Do we expect that anyone would actually do that? And another: Do we feel folks could somehow make do without doing that? If the answer the the last question is yes, or even probably, let's disallow this particular cute trick. Cordially, Subject: yet another issue for 21 Date: Thu, 29 Jul 2004 08:49:13 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: yet another issue for 21 Thread-Index: AcR1DUbFbakWIQDWRQOgOl27+z3U0gAdfJIA From: "Karl Frank" To: "Branislav Selic" , "Pete Rivett" Cc: , X-OriginalArrivalTime: 29 Jul 2004 15:49:24.0241 (UTC) FILETIME=[9F06E010:01C47583] Here is another shared issue with a proposed resolution. - Karl 6215.doc MOF/Infra - OMG Issue No: 6215 Title: UML 2 Super/pg.64/Classifier redefinition notation Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: pg. 64: Classifier/Notation: Attribute with same name as one that would have been inherited is interpreted as a redefinition. Very dangerous. .It would be better to make it explicit with a statement Discussion: Agreed. Replace the text on page 64 and also in the Infrastructure. There is another problem here also, the point is not specific to attributes alone, but to any redefinable element that is redefined in the context of a generalization hierarchy. Therefore generalize the verbage beyond "attribute" to redefinable element The relevant text on page 64 of Superstructure and 121 of Infrastructure is: New Text: in both Super and Infra All redefinitions shall be made explicit with the use of a {redefines } property string. Redefinition prevents inheritance of a redefined element into the redefinition context, thereby making the name of the redefined element available for reuse, either for the redefining element, or for some other. Disposition: Resolved To: "Karl Frank" Cc: mu2i-ftf@omg.org, "Pete Rivett" , uml2-superstructure-ftf@omg.org Subject: Re: yet another issue for 21 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 29 Jul 2004 12:30:19 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/29/2004 12:30:19, Serialize complete at 07/29/2004 12:30:19 Good one, Karl. It's short and simple enough that, even though it is somewhat late in the week, I will put this on ballot 21 unless someone has objections. Bran "Karl Frank" 07/29/2004 11:49 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Pete Rivett" cc , Subject yet another issue for 21 Here is another shared issue with a proposed resolution. - Karl[attachment "6215.doc" deleted by Branislav Selic/Ottawa/IBM] To: "Karl Frank" Cc: "Branislav Selic" , mu2i-ftf@omg.org, "Pete Rivett" , uml2-superstructure-ftf@omg.org Subject: Re: yet another issue for 21 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Kenneth Hussey Date: Thu, 29 Jul 2004 14:01:45 -0400 X-MIMETrack: Serialize by Router on D25ML06/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 07/29/2004 14:01:49, Serialize complete at 07/29/2004 14:01:49 Karl, I think this resolution is great idea, but I fear that there are cases in the current specification where properties have been "implicitly" redefined in this way (without the use of a "redefines" constraint). We should probably clean these up in response to this (or another) issue.... Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Karl Frank" 07/29/2004 11:49 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Pete Rivett" cc , Subject yet another issue for 21 Here is another shared issue with a proposed resolution. - Karl[attachment "6215.doc" deleted by Kenneth Hussey/Ottawa/IBM] Subject: RE: yet another issue for 21 Date: Thu, 29 Jul 2004 11:37:09 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: yet another issue for 21 Thread-Index: AcR1lghEGe5nlN/dQW+G3phrw/KeHQABMeiA From: "Karl Frank" To: "Kenneth Hussey" Cc: "Branislav Selic" , , "Pete Rivett" , X-OriginalArrivalTime: 29 Jul 2004 18:37:18.0496 (UTC) FILETIME=[13C03200:01C4759B] That is another interesting case of reflexivity in this enterprise. We could always put in a disclaimer saying WE DON'T EAT OUR OWN KIBBLE. Seriously, it will surely lead to more problems, but I think we need to deal with them as they are identified, not delay this issue because others are likely. - Karl -------------------------------------------------------------------------------- From: Kenneth Hussey [mailto:khussey@ca.ibm.com] Sent: Thursday, 29 July, 2004 2:02 PM To: Karl Frank Cc: Branislav Selic; mu2i-ftf@omg.org; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: Re: yet another issue for 21 Karl, I think this resolution is great idea, but I fear that there are cases in the current specification where properties have been "implicitly" redefined in this way (without the use of a "redefines" constraint). We should probably clean these up in response to this (or another) issue.... Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Karl Frank" 07/29/2004 11:49 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Pete Rivett" cc , Subject yet another issue for 21 Here is another shared issue with a proposed resolution. - Karl[attachment "6215.doc" deleted by Kenneth Hussey/Ottawa/IBM] To: Joaquin Miller Cc: MOF UML Infrastructure FTF , UML Superstructure FTF Subject: Re: ,cl, Issue 6215 redefining then reusing a name X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Thu, 5 Aug 2004 09:04:04 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/05/2004 07:04:03, Serialize complete at 08/05/2004 07:04:03 Joaquin, I think your third example, redefining an inherited attribute, and creating a new attribute with the same name as the formerly inherited attribute is possible, but not good modeling practice. Redefinitions can be easily abused. Renames redefinitions in fact break normal inheritance rules and should be avoided. An option to renames is to create a derived attribute in the subclass that has the desired name and is implemented in terms of the inherited property. Then inheritance is preserved, and the subclass can still have a more appropriate name. Another is to use the facade pattern to create another interface on the class that has the desired attribute names. This is more flexible and avoids unnecessary inheritance coupling. Joaquin Miller 07/29/2004 02:48 PM Please respond to Joaquin Miller To MOF UML Infrastructure FTF , UML Superstructure FTF cc Subject ,cl, Issue 6215 redefining then reusing a name I wonder about something. If we see: a {redefines a} we're OK. If we see: b {redefines a} (e.g. S-11.3.38) we may wonder why the name needed to be changed, but what is going on is clear, and we have only b, and no a, so we can be reasonable comfortable. We may even (e.g. S-13.3.10) feel the name change is a good idea, or, anyway (e.g. I-11.3.2), while hardly necessary, at least OK, and even in rare cases, (e.g. I-11.7.2) unavoidable. But if we were to see: b {redefines a} a and now for something entirely different we have to ask a couple of questions: What is the connection between a in the general case and a in this case. What is the practical advantage of doing this. Or, forgetting those questions, here is a different one: Do we expect that anyone would actually do that? And another: Do we feel folks could somehow make do without doing that? If the answer the the last question is yes, or even probably, let's disallow this particular cute trick. Cordially, Joaquin To: Jim Amsden Cc: Joaquin Miller , MOF UML Infrastructure FTF , UML Superstructure FTF Subject: Re: ,cl, Issue 6215 redefining then reusing a name X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 5 Aug 2004 09:12:32 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/05/2004 09:12:33, Serialize complete at 08/05/2004 09:12:33 Yes, this is the approach that should have been used. There are far too many redefinitions in the spec without good reason. From what I see, most of it is because people did not understand when to use one versus the other. In my view, there should not be a single case of redefinition in the spec -- none of the ones I have seen are justified. In fact, there should probably be an issue to remove all of them. This is not an argument against redefinition, which I know is necessary in certain situations. But, it is an argument against using it in the spec, since the spec does not run into these situations. Bran Jim Amsden 08/05/2004 09:04 AM To Joaquin Miller cc MOF UML Infrastructure FTF , UML Superstructure FTF Subject Re: ,cl, Issue 6215 redefining then reusing a name Joaquin, I think your third example, redefining an inherited attribute, and creating a new attribute with the same name as the formerly inherited attribute is possible, but not good modeling practice. Redefinitions can be easily abused. Renames redefinitions in fact break normal inheritance rules and should be avoided. An option to renames is to create a derived attribute in the subclass that has the desired name and is implemented in terms of the inherited property. Then inheritance is preserved, and the subclass can still have a more appropriate name. Another is to use the facade pattern to create another interface on the class that has the desired attribute names. This is more flexible and avoids unnecessary inheritance coupling. Joaquin Miller 07/29/2004 02:48 PM Please respond to Joaquin Miller To MOF UML Infrastructure FTF , UML Superstructure FTF cc Subject ,cl, Issue 6215 redefining then reusing a name I wonder about something. If we see: a {redefines a} we're OK. If we see: b {redefines a} (e.g. S-11.3.38) we may wonder why the name needed to be changed, but what is going on is clear, and we have only b, and no a, so we can be reasonable comfortable. We may even (e.g. S-13.3.10) feel the name change is a good idea, or, anyway (e.g. I-11.3.2), while hardly necessary, at least OK, and even in rare cases, (e.g. I-11.7.2) unavoidable. But if we were to see: b {redefines a} a and now for something entirely different we have to ask a couple of questions: What is the connection between a in the general case and a in this case. What is the practical advantage of doing this. Or, forgetting those questions, here is a different one: Do we expect that anyone would actually do that? And another: Do we feel folks could somehow make do without doing that? If the answer the the last question is yes, or even probably, let's disallow this particular cute trick. Cordially, Joaquin e-mail: bselic@ca.ibm.com