Issue 7400: AssociationClass (uml2-rtf) Source: (, ) Nature: Clarification Severity: Significant Summary: The text says that a non-navigable end of an association class is an attribute of that association class. "When a property is owned by a class it represents an attribute." [7.11.4] "AssociationClass is both an Association and a Class." [7.16.1] "When a property is owned by an association it represents a non-navigable end of the association." [7.11.2] This is good, is as expected, and is consistent with both the object and the relational theories of modelling. It is said that the drawings tell a different story. If so, they should be corrected. There is no practical advantage to requiring that the non-navigable ends of an association class are not attributes of that class. On the contrary, such a requirement is unexpected and will be confusing. Resolution: Discussion The issue is obsolete. The text in 11.5.3 clearly states that the ownedEnds of an AssociationClass are not attributes. Disposition: Closed - No Change Revised Text: Actions taken: May 31, 2004: received issue February 20, 2015: closed issue Discussion: Disposition: Deferred to UML 2.4 RTF End of Annotations:===== m: webmaster@omg.org Date: 31 May 2004 00:14:54 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Joaquin Miller Company: X-Change Technologies mailFrom: no@but.thanks Notification: Yes Specification: UML 2 Section: 7 FormalNumber: ptc/-3-08-02 Version: 2.0 RevisionDate: 9/-/3 Page: Nature: Clarification Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Opera 7.22 [en] Description The text says that a non-navigable end of an association class is an attribute of that association class. "When a property is owned by a class it represents an attribute." [7.11.4] "AssociationClass is both an Association and a Class." [7.16.1] "When a property is owned by an association it represents a non-navigable end of the association." [7.11.2] This is good, is as expected, and is consistent with both the object and the relational theories of modelling. It is said that the drawings tell a different story. If so, they should be corrected. There is no practical advantage to requiring that the non-navigable ends of an association class are not attributes of that class. On the contrary, such a requirement is unexpected and will be confusing. Reply-To: From: "Conrad Bock" To: Subject: RE: issue 7400 -- UML 2.0 Superstructure FTF issue Date: Wed, 2 Jun 2004 15:10:42 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Joaquin, > The text says that a non-navigable end of an association class > is an attribute of that association class. "When a property is > owned by a class it represents an attribute." [7.11.4] > "AssociationClass is both an Association and a Class." [7.16.1] > "When a property is owned by an association it represents a > non-navigable end of the association." [7.11.2] This is good, is > as expected, and is consistent with both the object and the > relational theories of modelling. It is said that the drawings > tell a different story. If so, they should be corrected. There > is no practical advantage to requiring that the non-navigable > ends of an association class are not attributes of that class. > On the contrary, such a requirement is unexpected and will be confusing. The end properties of an association can't be ownedAttributes of the association, because these properties represent navigation, or lack thereof, from one end object to the other, not from the link to the end objects. You've seen the attached paper, there are six navigations involved. I don't think they all should be compressed into the end properties. Conrad Subject: RE: Super FTF telecon on Wed. Aug. 18 Date: Tue, 17 Aug 2004 16:43:42 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Super FTF telecon on Wed. Aug. 18 Thread-Index: AcSEqTAaQMluTGe6QmefADO1NI9UZAAB1OVQ From: "Karl Frank" To: "Branislav Selic" Cc: , X-OriginalArrivalTime: 17 Aug 2004 23:43:43.0973 (UTC) FILETIME=[08329950:01C484B4] 1. 6212 It may be yet another defect if having a query named "isCoConsistentWith" is incompatible with queries of another name defined in another place "isConsistentWith()" . The prepended "co" is supposed to suggest "covariance" as opposed to "contra" in contravariance. Questions: -- argumentative in intent but meant in a collaborative way, my intent is to get a good spec out of this, not win arguments -- a) How can the "same" query be defined in more than one place?. You say "the query is defined in numerous places in the spec". The same query or queries of the same name? If the name is "isConsistentWith", how is that query inconsistent with one named "isCoConsistentWith" ? b) Isn't it a problem to have the word "consistent" used in a way contrary to its accepted meaning OUTSIDE the spec? For Operations, the definition as it stands in the spec is most certainly not what the words "is consistent with " mean. These words have a longer history by orders of magnitude than the few decades computers have been around. c) For us who are used to naming conventions, and have stomached using the word redefinition to include renaming, why is a made up word like "coconsistent" such a problem? 2. 6404 Given that a resolution to 6404 is in ballot 23, we should surely pull it from Ballot 24. You just sent me a list in which you listed 6405 as one of my remaining 10 issues and I screwed up by pulling 6404. Sorry.. 3. 6437. I always forget about Infra, since I am not on the Infra FTF. Will research the infra implications. 4. 6616 I specifically called Guus' attention to this already in the email you received, don't understand why you should suggest what I have already told you I did. Guus' views on the matter will get good attention, I am sure. But if he wants "isRoot" back (the issue does NOT say it is needed, nor does it give any argument for why it's loss is regrettable) he should explain why, because it is easier to leave it out. It is not in the FAS as approved, and no-one (including Guus) has so far given any complaint. 5. 7400. Yes, the terminology should be "Closed, no change". I had to create my own format for these, reliving the hell you have been thru often enough, because the styles and wording on the issues website do not match our report styles and wording, and I got this wrong. Will change it for the ballot. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 6:26 PM To: Karl Frank Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Super FTF telecon on Wed. Aug. 18 Karl, some feedback on your propsoed resolutions: 6212: I have two objections to your resolution: (1) I do not feel that renaming "isConsistentWith()" to "isCoConsistentWith()" improves anything as the concept of "co-consistency" is not a common and well-understood term in the computing science community and (2), that query is defined in numerous places in the spec and would have to be redefined everywhere. I would much prefer your second potential solution. 6404: I have already provided a resolution to this issue in ballot 23. (Also, I think that your resolution is incorrect.) 6437: shouldn't this also have an Infrastructure fix in it? 6630: We had this discussion already and I strongly object to your resolution. Specifically, I believe that a client of a dependency should be able to navigate to its dependencies (it is the client). The ramifications of your change are significant since Dependency is the parent class of Realization, Usage, and InterfaceRealization, which are extensively used in many models. Your resolution will impact many implementations adversely. 6616: I seem to recall that Guus felt rather strongly about this one. I suggest that you consult him about it directly. 7400: shouldn't this be a "closed, no change" rather than a "resolved"? Cheers, Bran "Karl Frank" 08/17/2004 03:53 PM To Branislav Selic/Ottawa/IBM@IBMCA, , cc Subject RE: Super FTF telecon on Wed. Aug. 18 Eight proposals are attached. One, 6630, met with counterarguments in an earlier circulation. I am still convinced my proposal is in the best interest of UML modeling, so I am sending it out again with a little more argument to back it up. The obvious easy resolution is self-evident, just x-out the navigability from Supplier, but before I fall back to that easy answer, I want to try out my preferred solution first. Guus, one of your issues is in this batch, so you should look for it. 6616, humorously but accurately named "isRoot disappeared". Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 3:20 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Super FTF telecon on Wed. Aug. 18 DATE: Wed. Aug. 18 TIME: 11 am EDT (usual time) DURATION: 35 minutes NUMBER: 866 842-3549 (toll free North America) 1+613 787-5018 (International) PASSCODE: 8455752# Please plan to attend this one, it is very important. Thanks...Bran[attachment "ForBallot24.doc" deleted by Branislav Selic/Ottawa/IBM] To: "Karl Frank" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Super FTF telecon on Wed. Aug. 18 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 17 Aug 2004 20:32:01 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/17/2004 20:32:02, Serialize complete at 08/17/2004 20:32:02 Karl, A few additional comments embedded below: > 1. 6212 It may be yet another defect if having a query named > "isCoConsistentWith" is incompatible with queries of another name > defined in another place "isConsistentWith()" . > The prepended "co" > is supposed to suggest "covariance" as opposed to "contra" in > contravariance. > Questions: -- argumentative in intent but meant in a collaborative > way, my intent is to get a good spec out of this, not win arguments -- > a) How can the "same" query be defined in more than one place?. You > say "the query is defined in numerous places in the spec". The same > query or queries of the same name? If the name is > "isConsistentWith", how is that query inconsistent with one named > "isCoConsistentWith" ? This was by intent. Since "consistency" has different meanings in different contexts and is also a semantic variation point, there is a default version (the one that you renamed) that was intended to be overridden by other more specific versions. So, a change in one place would require the thing to be changed in all the places. > b) Isn't it a problem to have the word "consistent" used in a way > contrary to its accepted meaning OUTSIDE the spec? For Operations, > the definition as it stands in the spec is most certainly not what > the words "is consistent with " mean. These words have a longer > history by orders of magnitude than the few decades computers have > been around. > c) For us who are used to naming conventions, and have stomached > using the word redefinition to include renaming, why is a made up > word like "coconsistent" such a problem? Perhaps you are used to it, but I am not and I honestly don't believe that most people would get any additional information out of it. In fact, I suspect that it will actually raise more questions. That is, while most people have an intuitive understanding of "consitent", I doubt if they have an intuition about what "co-consistent" could mean. > 2. 6404 Given that a resolution to 6404 is in ballot 23, we should > surely pull it from Ballot 24. You just sent me a list in which you > listed 6405 as one of my remaining 10 issues and I screwed up by > pulling 6404. Sorry.. No problem. > 3. 6437. I always forget about Infra, since I am not on the Infra > FTF. Will research the infra implications. OK > 4. 6616 I specifically called Guus' attention to this already in > the email you received, don't understand why you should suggest what > I have already told you I did. Guus' views on the matter will get > good attention, I am sure. But if he wants "isRoot" back (the issue > does NOT say it is needed, nor does it give any argument for why > it's loss is regrettable) he should explain why, because it is > easier to leave it out. It is not in the FAS as approved, and no- > one (including Guus) has so far given any complaint. Sorry. I now recall that you did draw Guus' attention to it. So, this is good. I agree with your proposed resolution, but wanted to make sure that it went into the ballot without being contested. > 5. 7400. Yes, the terminology should be "Closed, no change". I had > to create my own format for these, reliving the hell you have been > thru often enough, because the styles and wording on the issues > website do not match our report styles and wording, and I got this > wrong. Will change it for the ballot. No problem. You should be able to get the correct styles if you use the posted Draft FTF report. (And, you are right: I had to manually change the formatting of each and every paragraph of the 890 issues that are in that report.) Regards...Bran Subject: RE: Super FTF telecon on Wed. Aug. 18 Date: Tue, 17 Aug 2004 20:33:11 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Super FTF telecon on Wed. Aug. 18 Thread-Index: AcSEj3arftLItj3ySduRIgtMeO5IrQAA0g4wAAlGhJA= From: "Pete Rivett" To: "Karl Frank" , "Branislav Selic" , , X-Virus-Scanned: by amavisd-new at sentraliant.com With regard to 7400, though I did not raise the issue I do recall the elongated discussion at the time... I think the problem is in Figure 66: though AssociationClass inherits from both Class and Association, this diagram (and the text beneath) does not make clear what happens in terms of redefinition of the inherited properties. Specifically, for an instance of AssociationClass what is the relationship between Association::ownedEnd and Class::ownedAttribute? Such explicitness would avoid the sort of prolonged email discussion we had on the question of whether the ownedEnds when considered as an Association are also ownedEnds when considered as a Class (i.e. do they appear as 'attributes')? (BTW my answer is 'yes' but it needs to be made clear e.g. by saying that ownedEnd redefines ownedEnd and subsets ownedAttribute) Hence I disagree with the proposed resolution which is to do nothing. 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: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Tuesday, August 17, 2004 8:54 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Super FTF telecon on Wed. Aug. 18 Eight proposals are attached. One, 6630, met with counterarguments in an earlier circulation. I am still convinced my proposal is in the best interest of UML modeling, so I am sending it out again with a little more argument to back it up. The obvious easy resolution is self-evident, just x-out the navigability from Supplier, but before I fall back to that easy answer, I want to try out my preferred solution first. Guus, one of your issues is in this batch, so you should look for it. 6616, humorously but accurately named "isRoot disappeared". Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 3:20 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Super FTF telecon on Wed. Aug. 18 DATE: Wed. Aug. 18 TIME: 11 am EDT (usual time) DURATION: 35 minutes NUMBER: 866 842-3549 (toll free North America) 1+613 787-5018 (International) PASSCODE: 8455752# Please plan to attend this one, it is very important. 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