Issue 3682: Notation for inherited associations (uml2-superstructure-ftf) Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com) Nature: Uncategorized Issue Severity: Summary: The CWM submitters needed to display inherited associations on some class diagrams to enhance understandability. These were not intended to be derived associations; that is, there was no intention to specify additional computational machinery when showing these inherited associations. Unfortunately, the MOF and UML have no succint way to display inherited associations. The CWM submitters placed the "/" derived prefix on the association end names in the class diagrams. At the same time, in order to prevent the generation of additional computational machinery, they omitted the inherited association from the normative XMI rendition of the metamodel. This was probably a reasonable choice under the circumstances. However, it means that the class diagrams and the XMI representation of the metamodel conflict with one another. It is very common to need to show inherited associations on a class diagram. We ran into this when we specified the CORBA metamodel for the CORBA Component Model submission. We used derived associations in the class diagrams as well. However, we retained the derived associations in the XMI rendition of the metamodel. In order to prevent additional computational machinery from being generated, we stereotyped the associations as <<implicit>>. This stereotype is defined in the UML specification but not in the MOF specification and says that an association is only conceptual and not manifest. We then made sure that the generator producing the IDL and XML DTDs was sensitive to the <<implicit>> stereotype. This had the advantage of maintaining consistency between the class diagrams and the XMI rendition of the metamodel. Of course this is also a non-standard approach--since <<implicit>> is not defined in the MOF, we can't expect MOF generators to understand it. The lack of a standard means for representing inherited associations in class diagrams is thus resulting in a proliferation of non-standard approaches in adopted OMG metamodels. This could become unmanageable as the number of metamodels grows. A standard means should be specified. Resolution: Revised Text: Actions taken: July 3, 2000: received issue August 30, 2000: transferred to UML RTF March 9, 2005: closed issue Discussion: In UML 2.0 it is possible to draw a standard generalization arrow between two associations. Additional adornments can be included to specify the kind of specialization that has taken place (see pg. 83 of the FAS). End of Annotations:===== X-Authentication-Warning: gendev.com: Host ppp-209-232-193-73.dialup.chic01.pacbell.net [209.232.193.73] claimed to be dfrankel Reply-To: From: "David S. Frankel" To: "OMG--MOF RTF" Cc: , "David Last" , , "Doug Tolbert" , "John Poole" , "Don Baisley" Subject: Notation for inherited associations Date: Mon, 3 Jul 2000 10:43:38 -0700 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <39609F17.9D048340@uk.oracle.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: =`""!,g?e9$&f!!a,Ce9 The CWM submitters needed to display inherited associations on some class diagrams to enhance understandability. These were not intended to be derived associations; that is, there was no intention to specify additional computational machinery when showing these inherited associations. Unfortunately, the MOF and UML have no succint way to display inherited associations. The CWM submitters placed the "/" derived prefix on the association end names in the class diagrams. At the same time, in order to prevent the generation of additional computational machinery, they omitted the inherited association from the normative XMI rendition of the metamodel. This was probably a reasonable choice under the circumstances. However, it means that the class diagrams and the XMI representation of the metamodel conflict with one another. It is very common to need to show inherited associations on a class diagram. We ran into this when we specified the CORBA metamodel for the CORBA Component Model submission. We used derived associations in the class diagrams as well. However, we retained the derived associations in the XMI rendition of the metamodel. In order to prevent additional computational machinery from being generated, we stereotyped the associations as <>. This stereotype is defined in the UML specification but not in the MOF specification and says that an association is only conceptual and not manifest. We then made sure that the generator producing the IDL and XML DTDs was sensitive to the <> stereotype. This had the advantage of maintaining consistency between the class diagrams and the XMI rendition of the metamodel. Of course this is also a non-standard approach--since <> is not defined in the MOF, we can't expect MOF generators to understand it. The lack of a standard means for representing inherited associations in class diagrams is thus resulting in a proliferation of non-standard approaches in adopted OMG metamodels. This could become unmanageable as the number of metamodels grows. A standard means should be specified. --David Frankel ================================ David S. Frankel Chief Scientist Genesis Development Corporation An Iona Technologies' Company 741 Santiago Court Chico, CA 95973-8781 USA +1 530 893-1100 voice +1 530 893-1153 fax dfrankel@gendev.com http://www.gendev.com ================================ > -----Original Message----- > From: David Last [mailto:dlast@uk.oracle.com] > Sent: Monday, July 03, 2000 7:12 AM > To: DFrankel@gendev.com > Cc: dtchang@us.ibm.com; Doug Tolbert; John Poole; Don Baisley > Subject: Your Feedback on CWM Submission > > > Dave, > > First of all, thank you for all your feedback on the final submission. > > As Dan said, we went through your comments at the Oslo meeting. > In the attached document I have added notes on our discussion of > each of the > points you raised. > Please do not hesitate to get back to me if you are still > concerned on any of > these points. > > The final point was not in the version of your paper that we > discussed, so I > have recorded this as a new issue B46, to be discussed at the > next meeting. > > Regards, > David > > dtchang@us.ibm.com. wrote: > > > Dave, > > > > The CWM FTF has gone over thoroughly your comments during the > Oslo meeting > > on 6/13. In fact, I personally went over your comments with David Last > > again the next day, 6/14, to make sure we did not miss anything. > > > > David has taken the lead for the CWM FTF on tracking your > comments. He has > > done a very admirable job, not only keeping your document but > also taking > > down notes during the AB meeting. I am copying David on this > note so that > > if you think anything is still missing you can discuss it with David. > > Please note that the CWM FTF only records and resolves issues of direct > > relevance to CWM. We do not record nor resolve issues related > to UML, MOF, > > XMI, etc. > > > > After talking to David (if needed), if you still think you have > issues, of > > direct relevance to CWM, not recorded and should be recorded, > please attend > > the September CWM FTF so that you can discuss them face to face with the > > CWM FTF. > > > > Regards, Dan > > > > e-business Data Standards and Technology > > IBM Silicon Valley Laboratory > > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > > Internet: dtchang@us.ibm.com > > VM: IBMUSM50(DTCHANG) > > Phone: (408)-463-2319 > > > > ---------------------- Forwarded by Dan Chang/Santa Teresa/IBM on > > 06/30/2000 02:30 PM --------------------------- > > > > "David S. Frankel" on 06/30/2000 01:16:42 PM > > > > Please respond to > > > > To: Dan Chang/Santa Teresa/IBM@IBMUS > > cc: > > Subject: More RE: CWM FTF issues lists > > > > Dan-- > > > > These issues lists don't appear to cover all of the issues that > I submitted > > to you at the time that the final submission came up for AB > review. I see > > four issues generally attributed to the "Architecture Board" > but only one > > of > > them is one of my issues. If I am missing something, please explain. > > > > For your convenience I have attached the original document that > conveyed my > > issues. > > > > Thanks. > > > > --Dave > > > > ================================ > > David S. Frankel > > Chief Scientist > > Genesis Development Corporation > > An Iona Technologies' Company > > 741 Santiago Court > > Chico, CA 95973-8781 USA > > > > +1 530 893-1100 voice > > +1 530 893-1153 fax > > dfrankel@gendev.com > > http://www.gendev.com > > ================================ > > > > > -----Original Message----- > > > From: dtchang@us.ibm.com [mailto:dtchang@us.ibm.com] > > > Sent: Friday, June 30, 2000 12:04 PM > > > To: Doug Tolbert; john_poole@hyperion.com; dlast@uk.oracle.com; > > > hans-peter.hoidn@ubs.com; plongden@gendev.com; > > > Lynn.Hedegard@SanDiegoCA.NCR.com; chris@dimension-edi.com; > > > SmithDaveC@JDCORP.deere.com; Barbara.Walters@sas.com; > > > robinnt@us.ibm.com; lin@de.ibm.com; Don Baisley; > > > Sridhar.Iyengar2@unisys.com; david_zhang@hyperion.com; > > > dmellor@us.oracle.com; mhornick@us.oracle.com; Gordon Callan; > > > jeffrey.peckham@ubs.com; DFrankel@gendev.com; > > > anders.tornqvist@comfact.com; Craig.Rubendall@sas.com > > > Subject: CWM FTF issues lists > > > > > > > > > > > > > > > Team, > > > > > > Attached are the lists (A & B) of CWM FTF issues. We resolved most of > > them > > > in Oslo and we will start working on actions to close the > resolved ones > > > when Don fixes the CWM Metamodel in Rose, scheduled for 7/21. > > > Please let me > > > know if you have comments. > > > > > > (See attached file: CWMAIssues.pdf)(See attached file: CWMBIssues.pdf) > > > > > > Regards, Dan > > > > > > e-business Data Standards and Technology > > > IBM Silicon Valley Laboratory > > > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > > > Internet: dtchang@us.ibm.com > > > VM: IBMUSM50(DTCHANG) > > > Phone: (408)-463-2319 > > > > > > > (See attached file: CWMfeedback.rtf) > > > > > ------------------------------------------------------------------------ > > Name: CWMfeedback.rtf > > Type: Winword File (application/rtf) > > CWMfeedback.rtf Encoding: base64 > > Description: Rich Text Format > > Download Status: Not downloaded with message > X-Mailer: exmh version 2.1.0 09/18/1999 To: dfrankel@gendev.com cc: "OMG--MOF RTF" , uml-rtf@omg.org, "David Last" , dtchang@us.ibm.com, "Doug Tolbert" , "John Poole" , "Don Baisley" , crawley@dstc.edu.au Subject: Re: Notation for inherited associations In-Reply-To: Message from "David S. Frankel" of "Mon, 03 Jul 2000 10:43:38 MST." Mime-Version: 1.0 Date: Tue, 04 Jul 2000 11:10:04 +1000 From: Stephen Crawley Content-Type: text/plain; charset=us-ascii X-UIDL: kcV!!4[Zd9*Zid97^(e9 Dave, The MOF spec does no specify a "human usable notation" for MOF meta-models. The MOF 1.0 final submitters made a deliberate decision to not standardise any notation, diagrammatic or textual. The "MOF meta-model as UML diagram" notation that CMW is using is loosely defined in the UML spec. If there are flaws in this notation, then they should be taken up with the UML RTF in the first instance. I don't think it would be inappropriate to include the "MOF in UML" notation as part of the MOF spec ... if other people think this would be a good idea. However, if this happens, I'd also like to see a textual notation incorporated as well. The obvious one is the MODL language, which has been used in the MOF spec from day 1. At this stage, I think that CMW's problem is an issue for the UML RTF; i.e. how to represent an inherited Association in a regular UML diagram. Or maybe this an implementation issue for UML tool vendors. [Isn't the decision to display an inherited Association "just" a diagram presentation issue? In the same category as the layout of Classes on the page or the amount of detail shown for any given Class?] -- Steve > The CWM submitters needed to display inherited associations on some class > diagrams to enhance understandability. These were not intended to be > derived associations; that is, there was no intention to specify additional > computational machinery when showing these inherited associations. > Unfortunately, the MOF and UML have no succint way to display inherited > associations. The CWM submitters placed the "/" derived prefix on the > association end names in the class diagrams. At the same time, in order to > prevent the generation of additional computational machinery, they omitted > the inherited association from the normative XMI rendition of the metamodel. > This was probably a reasonable choice under the circumstances. However, it > means that the class diagrams and the XMI representation of the metamodel > conflict with one another. > > It is very common to need to show inherited associations on a class diagram. > We ran into this when we specified the CORBA metamodel for the CORBA > Component Model submission. We used derived associations in the class > diagrams as well. However, we retained the derived associations in the XMI > rendition of the metamodel. In order to prevent additional computational > machinery from being generated, we stereotyped the associations as > <>. This stereotype is defined in the UML specification but not > in the MOF specification and says that an association is only conceptual and > not manifest. We then made sure that the generator producing the IDL and > XML DTDs was sensitive to the <> stereotype. This had the > advantage of maintaining consistency between the class diagrams and the XMI > rendition of the metamodel. Of course this is also a non-standard > approach--since <> is not defined in the MOF, we can't expect MOF > generators to understand it. > > The lack of a standard means for representing inherited associations in > class diagrams is thus resulting in a proliferation of non-standard > approaches in adopted OMG metamodels. This could become unmanageable as the > number of metamodels grows. A standard means should be specified. > > --David Frankel > > ================================ > David S. Frankel > Chief Scientist > Genesis Development Corporation > An Iona Technologies' Company > 741 Santiago Court > Chico, CA 95973-8781 USA > > +1 530 893-1100 voice > +1 530 893-1153 fax > dfrankel@gendev.com > http://www.gendev.com > ================================ > > > -----Original Message----- > > From: David Last [mailto:dlast@uk.oracle.com] > > Sent: Monday, July 03, 2000 7:12 AM > > To: DFrankel@gendev.com > > Cc: dtchang@us.ibm.com; Doug Tolbert; John Poole; Don Baisley > > Subject: Your Feedback on CWM Submission > > > > > > Dave, > > > > First of all, thank you for all your feedback on the final submission. > > > > As Dan said, we went through your comments at the Oslo meeting. > > In the attached document I have added notes on our discussion of > > each of the > > points you raised. > > Please do not hesitate to get back to me if you are still > > concerned on any of > > these points. > > > > The final point was not in the version of your paper that we > > discussed, so I > > have recorded this as a new issue B46, to be discussed at the > > next meeting. > > > > Regards, > > David > > > > dtchang@us.ibm.com. wrote: > > > > > Dave, > > > > > > The CWM FTF has gone over thoroughly your comments during the > > Oslo meeting > > > on 6/13. In fact, I personally went over your comments with David Last > > > again the next day, 6/14, to make sure we did not miss anything. > > > > > > David has taken the lead for the CWM FTF on tracking your > > comments. He has > > > done a very admirable job, not only keeping your document but > > also taking > > > down notes during the AB meeting. I am copying David on this > > note so that > > > if you think anything is still missing you can discuss it with David. > > > Please note that the CWM FTF only records and resolves issues of direct > > > relevance to CWM. We do not record nor resolve issues related > > to UML, MOF, > > > XMI, etc. > > > > > > After talking to David (if needed), if you still think you have > > issues, of > > > direct relevance to CWM, not recorded and should be recorded, > > please attend > > > the September CWM FTF so that you can discuss them face to face with the > > > CWM FTF. > > > > > > Regards, Dan > > > > > > e-business Data Standards and Technology > > > IBM Silicon Valley Laboratory > > > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > > > Internet: dtchang@us.ibm.com > > > VM: IBMUSM50(DTCHANG) > > > Phone: (408)-463-2319 > > > > > > ---------------------- Forwarded by Dan Chang/Santa Teresa/IBM on > > > 06/30/2000 02:30 PM --------------------------- > > > > > > "David S. Frankel" on 06/30/2000 01:16:42 PM > > > > > > Please respond to > > > > > > To: Dan Chang/Santa Teresa/IBM@IBMUS > > > cc: > > > Subject: More RE: CWM FTF issues lists > > > > > > Dan-- > > > > > > These issues lists don't appear to cover all of the issues that > > I submitted > > > to you at the time that the final submission came up for AB > > review. I see > > > four issues generally attributed to the "Architecture Board" > > but only one > > > of > > > them is one of my issues. If I am missing something, please explain. > > > > > > For your convenience I have attached the original document that > > conveyed my > > > issues. > > > > > > Thanks. > > > > > > --Dave > > > > > > ================================ > > > David S. Frankel > > > Chief Scientist > > > Genesis Development Corporation > > > An Iona Technologies' Company > > > 741 Santiago Court > > > Chico, CA 95973-8781 USA > > > > > > +1 530 893-1100 voice > > > +1 530 893-1153 fax > > > dfrankel@gendev.com > > > http://www.gendev.com > > > ================================ > > > > > > > -----Original Message----- > > > > From: dtchang@us.ibm.com [mailto:dtchang@us.ibm.com] > > > > Sent: Friday, June 30, 2000 12:04 PM > > > > To: Doug Tolbert; john_poole@hyperion.com; dlast@uk.oracle.com; > > > > hans-peter.hoidn@ubs.com; plongden@gendev.com; > > > > Lynn.Hedegard@SanDiegoCA.NCR.com; chris@dimension-edi.com; > > > > SmithDaveC@JDCORP.deere.com; Barbara.Walters@sas.com; > > > > robinnt@us.ibm.com; lin@de.ibm.com; Don Baisley; > > > > Sridhar.Iyengar2@unisys.com; david_zhang@hyperion.com; > > > > dmellor@us.oracle.com; mhornick@us.oracle.com; Gordon Callan; > > > > jeffrey.peckham@ubs.com; DFrankel@gendev.com; > > > > anders.tornqvist@comfact.com; Craig.Rubendall@sas.com > > > > Subject: CWM FTF issues lists > > > > > > > > > > > > > > > > > > > > Team, > > > > > > > > Attached are the lists (A & B) of CWM FTF issues. We resolved most of > > > them > > > > in Oslo and we will start working on actions to close the > > resolved ones > > > > when Don fixes the CWM Metamodel in Rose, scheduled for 7/21. > > > > Please let me > > > > know if you have comments. > > > > > > > > (See attached file: CWMAIssues.pdf)(See attached file: CWMBIssues.pdf) > > > > > > > > Regards, Dan > > > > > > > > e-business Data Standards and Technology > > > > IBM Silicon Valley Laboratory > > > > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > > > > Internet: dtchang@us.ibm.com > > > > VM: IBMUSM50(DTCHANG) > > > > Phone: (408)-463-2319 > > > > > > > > > > (See attached file: CWMfeedback.rtf) > > > > > > > > ------------------------------------------------------------------------ > > > Name: CWMfeedback.rtf > > > Type: Winword File (application/rtf) > > > CWMfeedback.rtf Encoding: base64 > > > Description: Rich Text Format > > > Download Status: Not downloaded with message > > > X-Authentication-Warning: gendev.com: Host ppp-209-232-193-1.dialup.chic01.pacbell.net [209.232.193.1] claimed to be dfrankel Reply-To: From: "David S. Frankel" To: "Stephen Crawley" Cc: "OMG--MOF RTF" , , "David Last" , , "Doug Tolbert" , "John Poole" , "Don Baisley" Subject: RE: Notation for inherited associations Date: Tue, 4 Jul 2000 08:26:50 -0700 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <200007040109.e6419xb07891@piglet.dstc.edu.au> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: bdm!!Pe?e9Qlpd9`jVd9 Steve-- I accept your position that this is more appropriately taken up by the UML RTF. It isn't just a diagram layout issue though. It is a notation issue. A notation specification would tell you how to notate an association that is not new but just a repetition of an inherited association. Diagram layout would specify how to represent, in the metadata, where that notation was used spatially in relation to the dimensions of the diagram, in relation to the spatial placement of the participating classes, the spatial placement of the association line, etc. --Dave ================================ David S. Frankel Chief Scientist Genesis Development Corporation An Iona Technologies' Company 741 Santiago Court Chico, CA 95973-8781 USA +1 530 893-1100 voice +1 530 893-1153 fax dfrankel@gendev.com http://www.gendev.com ================================ > -----Original Message----- > From: Stephen Crawley [mailto:crawley@dstc.edu.au] > Sent: Monday, July 03, 2000 6:10 PM > To: dfrankel@gendev.com > Cc: OMG--MOF RTF; uml-rtf@omg.org; David Last; dtchang@us.ibm.com; Doug > Tolbert; John Poole; Don Baisley; crawley@dstc.edu.au > Subject: Re: Notation for inherited associations > > > > Dave, > > The MOF spec does no specify a "human usable notation" for MOF > meta-models. The > MOF 1.0 final submitters made a deliberate decision to not standardise any > notation, diagrammatic or textual. The "MOF meta-model as UML > diagram" notation > that CMW is using is loosely defined in the UML spec. If there > are flaws in > this notation, then they should be taken up with the UML RTF in the first > instance. > > I don't think it would be inappropriate to include the "MOF in > UML" notation as > part of the MOF spec ... if other people think this would be a good idea. > However, if this happens, I'd also like to see a textual notation > incorporated > as well. The obvious one is the MODL language, which has been used in the > MOF spec from day 1. > > At this stage, I think that CMW's problem is an issue for the UML > RTF; i.e. how > to represent an inherited Association in a regular UML diagram. > Or maybe this > an implementation issue for UML tool vendors. [Isn't the > decision to display > an inherited Association "just" a diagram presentation issue? In the same > category as the layout of Classes on the page or the amount of > detail shown for > any given Class?] > > -- Steve > > > The CWM submitters needed to display inherited associations on > some class > > diagrams to enhance understandability. These were not intended to be > > derived associations; that is, there was no intention to > specify additional > > computational machinery when showing these inherited associations. > > Unfortunately, the MOF and UML have no succint way to display inherited > > associations. The CWM submitters placed the "/" derived prefix on the > > association end names in the class diagrams. At the same time, > in order to > > prevent the generation of additional computational machinery, > they omitted > > the inherited association from the normative XMI rendition of > the metamodel. > > This was probably a reasonable choice under the circumstances. > However, it > > means that the class diagrams and the XMI representation of the > metamodel > > conflict with one another. > > > > It is very common to need to show inherited associations on a > class diagram. > > We ran into this when we specified the CORBA metamodel for the CORBA > > Component Model submission. We used derived associations in the class > > diagrams as well. However, we retained the derived > associations in the XMI > > rendition of the metamodel. In order to prevent additional > computational > > machinery from being generated, we stereotyped the associations as > > <>. This stereotype is defined in the UML > specification but not > > in the MOF specification and says that an association is only > conceptual and > > not manifest. We then made sure that the generator producing > the IDL and > > XML DTDs was sensitive to the <> stereotype. This had the > > advantage of maintaining consistency between the class diagrams > and the XMI > > rendition of the metamodel. Of course this is also a non-standard > > approach--since <> is not defined in the MOF, we > can't expect MOF > > generators to understand it. > > > > The lack of a standard means for representing inherited associations in > > class diagrams is thus resulting in a proliferation of non-standard > > approaches in adopted OMG metamodels. This could become > unmanageable as the > > number of metamodels grows. A standard means should be specified. > > > > --David Frankel > > > > ================================ > > David S. Frankel > > Chief Scientist > > Genesis Development Corporation > > An Iona Technologies' Company > > 741 Santiago Court > > Chico, CA 95973-8781 USA > > > > +1 530 893-1100 voice > > +1 530 893-1153 fax > > dfrankel@gendev.com > > http://www.gendev.com > > ================================ > > > > > -----Original Message----- > > > From: David Last [mailto:dlast@uk.oracle.com] > > > Sent: Monday, July 03, 2000 7:12 AM > > > To: DFrankel@gendev.com > > > Cc: dtchang@us.ibm.com; Doug Tolbert; John Poole; Don Baisley > > > Subject: Your Feedback on CWM Submission > > > > > > > > > Dave, > > > > > > First of all, thank you for all your feedback on the final submission. > > > > > > As Dan said, we went through your comments at the Oslo meeting. > > > In the attached document I have added notes on our discussion of > > > each of the > > > points you raised. > > > Please do not hesitate to get back to me if you are still > > > concerned on any of > > > these points. > > > > > > The final point was not in the version of your paper that we > > > discussed, so I > > > have recorded this as a new issue B46, to be discussed at the > > > next meeting. > > > > > > Regards, > > > David > > > > > > dtchang@us.ibm.com. wrote: > > > > > > > Dave, > > > > > > > > The CWM FTF has gone over thoroughly your comments during the > > > Oslo meeting > > > > on 6/13. In fact, I personally went over your comments with > David Last > > > > again the next day, 6/14, to make sure we did not miss anything. > > > > > > > > David has taken the lead for the CWM FTF on tracking your > > > comments. He has > > > > done a very admirable job, not only keeping your document but > > > also taking > > > > down notes during the AB meeting. I am copying David on this > > > note so that > > > > if you think anything is still missing you can discuss it > with David. > > > > Please note that the CWM FTF only records and resolves > issues of direct > > > > relevance to CWM. We do not record nor resolve issues related > > > to UML, MOF, > > > > XMI, etc. > > > > > > > > After talking to David (if needed), if you still think you have > > > issues, of > > > > direct relevance to CWM, not recorded and should be recorded, > > > please attend > > > > the September CWM FTF so that you can discuss them face to > face with the > > > > CWM FTF. > > > > > > > > Regards, Dan > > > > > > > > e-business Data Standards and Technology > > > > IBM Silicon Valley Laboratory > > > > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > > > > Internet: dtchang@us.ibm.com > > > > VM: IBMUSM50(DTCHANG) > > > > Phone: (408)-463-2319 > > > > > > > > ---------------------- Forwarded by Dan Chang/Santa Teresa/IBM on > > > > 06/30/2000 02:30 PM --------------------------- > > > > > > > > "David S. Frankel" on 06/30/2000 01:16:42 PM > > > > > > > > Please respond to > > > > > > > > To: Dan Chang/Santa Teresa/IBM@IBMUS > > > > cc: > > > > Subject: More RE: CWM FTF issues lists > > > > > > > > Dan-- > > > > > > > > These issues lists don't appear to cover all of the issues that > > > I submitted > > > > to you at the time that the final submission came up for AB > > > review. I see > > > > four issues generally attributed to the "Architecture Board" > > > but only one > > > > of > > > > them is one of my issues. If I am missing something, > please explain. > > > > > > > > For your convenience I have attached the original document that > > > conveyed my > > > > issues. > > > > > > > > Thanks. > > > > > > > > --Dave > > > > > > > > ================================ > > > > David S. Frankel > > > > Chief Scientist > > > > Genesis Development Corporation > > > > An Iona Technologies' Company > > > > 741 Santiago Court > > > > Chico, CA 95973-8781 USA > > > > > > > > +1 530 893-1100 voice > > > > +1 530 893-1153 fax > > > > dfrankel@gendev.com > > > > http://www.gendev.com > > > > ================================ > > > > > > > > > -----Original Message----- > > > > > From: dtchang@us.ibm.com [mailto:dtchang@us.ibm.com] > > > > > Sent: Friday, June 30, 2000 12:04 PM > > > > > To: Doug Tolbert; john_poole@hyperion.com; dlast@uk.oracle.com; > > > > > hans-peter.hoidn@ubs.com; plongden@gendev.com; > > > > > Lynn.Hedegard@SanDiegoCA.NCR.com; chris@dimension-edi.com; > > > > > SmithDaveC@JDCORP.deere.com; Barbara.Walters@sas.com; > > > > > robinnt@us.ibm.com; lin@de.ibm.com; Don Baisley; > > > > > Sridhar.Iyengar2@unisys.com; david_zhang@hyperion.com; > > > > > dmellor@us.oracle.com; mhornick@us.oracle.com; Gordon Callan; > > > > > jeffrey.peckham@ubs.com; DFrankel@gendev.com; > > > > > anders.tornqvist@comfact.com; Craig.Rubendall@sas.com > > > > > Subject: CWM FTF issues lists > > > > > > > > > > > > > > > > > > > > > > > > > Team, > > > > > > > > > > Attached are the lists (A & B) of CWM FTF issues. We > resolved most of > > > > them > > > > > in Oslo and we will start working on actions to close the > > > resolved ones > > > > > when Don fixes the CWM Metamodel in Rose, scheduled for 7/21. > > > > > Please let me > > > > > know if you have comments. > > > > > > > > > > (See attached file: CWMAIssues.pdf)(See attached file: > CWMBIssues.pdf) > > > > > > > > > > Regards, Dan > > > > > > > > > > e-business Data Standards and Technology > > > > > IBM Silicon Valley Laboratory > > > > > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > > > > > Internet: dtchang@us.ibm.com > > > > > VM: IBMUSM50(DTCHANG) > > > > > Phone: (408)-463-2319 > > > > > > > > > > > > > (See attached file: CWMfeedback.rtf) > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > Name: CWMfeedback.rtf > > > > Type: Winword File (application/rtf) > > > > CWMfeedback.rtf Encoding: base64 > > > > Description: Rich Text Format > > > > Download Status: Not downloaded with message > > > > > > > > > > Date: Tue, 04 Jul 2000 17:56:40 -0400 From: "Chonoles, Michael J" Subject: RE: Notation for inherited associations To: dfrankel@gendev.com, Stephen Crawley Cc: OMG--MOF RTF , uml-rtf@omg.org, David Last , dtchang@us.ibm.com, Doug Tolbert , John Poole , Don Baisley Message-id: <716897408033D111BA8C0000F805CC8406CA5F69@emss04m07.ems.lmco.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-transfer-encoding: 7BIT Content-Type: text/plain; charset=iso-8859-1 X-UIDL: \l)!!7]?!!K)'e9i-U!! I would also agree that this is a notation issue, and somewhat confusing issue. We don't have a notation for inherited attributes or operations. Why should we need a notation for inherited associations? Assuming that we need the notation, The two proposed notations, derived (/) or <> both have their problems. The derived indicator is typically used to indicate a real "thing", such as a precalculated value. Flagging an association as derived is often used to indicate an implemented association that indicates a traversal from A to C that shortcuts the normal path of A to B to C for efficient processing. Thus a derived association would be another association, and distinct from the inherited association. The <> tagged association has the advantage of not being another association. However, <> can be used anytime there is a conceptual but not implemented association, and gives the impression that the traversal is not possible, which it would be in the inherited case. So, I would propose that neither are quite right. Assuming we need a notation, we need it to say, unambiguously, that the navigation from A to B is possible, but that we do not plan to implement another association. Perhaps all we need is {inherited}. I must also note that most uses of inherited associations that I have seen are misleading. An drawn inherited association should really only be a one way association, from the subclass to the original target class. Making a bi-directional association would imply that navigation is allowed directly to the subclass, which is not true. I've seen inherited associations drawn between two subclasses. There are many circumstances where improved notation would clarify some real world situations, such as the very common one where there are parallel inheritance structure and sub classes of A are constrained to communicate to the parallel subclass of B. I think some sort of situation requires a notational idiom that is quick to comprehend (rather than some complex OCL constraint). Michael Chief of Methodology, Lockheed Martin Advanced Concepts Center michael.j.chonoles@LMCO.com 610 992-6212 -----Original Message----- From: David S. Frankel [mailto:dfrankel@gendev.com] Sent: Tue, July 04, 2000 11:27 AM To: Stephen Crawley Cc: OMG--MOF RTF; uml-rtf@omg.org; David Last; dtchang@us.ibm.com; Doug Tolbert; John Poole; Don Baisley Subject: RE: Notation for inherited associations Steve-- I accept your position that this is more appropriately taken up by the UML RTF. It isn't just a diagram layout issue though. It is a notation issue. A notation specification would tell you how to notate an association that is not new but just a repetition of an inherited association. Diagram layout would specify how to represent, in the metadata, where that notation was used spatially in relation to the dimensions of the diagram, in relation to the spatial placement of the participating classes, the spatial placement of the association line, etc. --Dave ================================ David S. Frankel Chief Scientist Genesis Development Corporation An Iona Technologies' Company 741 Santiago Court Chico, CA 95973-8781 USA +1 530 893-1100 voice +1 530 893-1153 fax dfrankel@gendev.com http://www.gendev.com ================================ > -----Original Message----- > From: Stephen Crawley [mailto:crawley@dstc.edu.au] > Sent: Monday, July 03, 2000 6:10 PM > To: dfrankel@gendev.com > Cc: OMG--MOF RTF; uml-rtf@omg.org; David Last; dtchang@us.ibm.com; Doug > Tolbert; John Poole; Don Baisley; crawley@dstc.edu.au > Subject: Re: Notation for inherited associations > > > > Dave, > > The MOF spec does no specify a "human usable notation" for MOF > meta-models. The > MOF 1.0 final submitters made a deliberate decision to not standardise any > notation, diagrammatic or textual. The "MOF meta-model as UML > diagram" notation > that CMW is using is loosely defined in the UML spec. If there > are flaws in > this notation, then they should be taken up with the UML RTF in the first > instance. > > I don't think it would be inappropriate to include the "MOF in > UML" notation as > part of the MOF spec ... if other people think this would be a good idea. > However, if this happens, I'd also like to see a textual notation > incorporated > as well. The obvious one is the MODL language, which has been used in the > MOF spec from day 1. > > At this stage, I think that CMW's problem is an issue for the UML > RTF; i.e. how > to represent an inherited Association in a regular UML diagram. > Or maybe this > an implementation issue for UML tool vendors. [Isn't the > decision to display > an inherited Association "just" a diagram presentation issue? In the same > category as the layout of Classes on the page or the amount of > detail shown for > any given Class?] > > -- Steve > > > The CWM submitters needed to display inherited associations on > some class > > diagrams to enhance understandability. These were not intended to be > > derived associations; that is, there was no intention to > specify additional > > computational machinery when showing these inherited associations. > > Unfortunately, the MOF and UML have no succint way to display inherited > > associations. The CWM submitters placed the "/" derived prefix on the > > association end names in the class diagrams. At the same time, > in order to > > prevent the generation of additional computational machinery, > they omitted > > the inherited association from the normative XMI rendition of > the metamodel. > > This was probably a reasonable choice under the circumstances. > However, it > > means that the class diagrams and the XMI representation of the > metamodel > > conflict with one another. > > > > It is very common to need to show inherited associations on a > class diagram. > > We ran into this when we specified the CORBA metamodel for the CORBA > > Component Model submission. We used derived associations in the class > > diagrams as well. However, we retained the derived > associations in the XMI > > rendition of the metamodel. In order to prevent additional > computational > > machinery from being generated, we stereotyped the associations as > > <>. This stereotype is defined in the UML > specification but not > > in the MOF specification and says that an association is only > conceptual and > > not manifest. We then made sure that the generator producing > the IDL and > > XML DTDs was sensitive to the <> stereotype. This had the > > advantage of maintaining consistency between the class diagrams > and the XMI > > rendition of the metamodel. Of course this is also a non-standard > > approach--since <> is not defined in the MOF, we > can't expect MOF > > generators to understand it. > > > > The lack of a standard means for representing inherited associations in > > class diagrams is thus resulting in a proliferation of non-standard > > approaches in adopted OMG metamodels. This could become > unmanageable as the > > number of metamodels grows. A standard means should be specified. > > > > --David Frankel > > > > ================================ > > David S. Frankel > > Chief Scientist > > Genesis Development Corporation > > An Iona Technologies' Company > > 741 Santiago Court > > Chico, CA 95973-8781 USA > > > > +1 530 893-1100 voice > > +1 530 893-1153 fax > > dfrankel@gendev.com > > http://www.gendev.com > > ================================ > > > > > -----Original Message----- > > > From: David Last [mailto:dlast@uk.oracle.com] > > > Sent: Monday, July 03, 2000 7:12 AM > > > To: DFrankel@gendev.com > > > Cc: dtchang@us.ibm.com; Doug Tolbert; John Poole; Don Baisley > > > Subject: Your Feedback on CWM Submission > > > > > > > > > Dave, > > > > > > First of all, thank you for all your feedback on the final submission. > > > > > > As Dan said, we went through your comments at the Oslo meeting. > > > In the attached document I have added notes on our discussion of > > > each of the > > > points you raised. > > > Please do not hesitate to get back to me if you are still > > > concerned on any of > > > these points. > > > > > > The final point was not in the version of your paper that we > > > discussed, so I > > > have recorded this as a new issue B46, to be discussed at the > > > next meeting. > > > > > > Regards, > > > David > > > > > > dtchang@us.ibm.com. wrote: > > > > > > > Dave, > > > > > > > > The CWM FTF has gone over thoroughly your comments during the > > > Oslo meeting > > > > on 6/13. In fact, I personally went over your comments with > David Last > > > > again the next day, 6/14, to make sure we did not miss anything. > > > > > > > > David has taken the lead for the CWM FTF on tracking your > > > comments. He has > > > > done a very admirable job, not only keeping your document but > > > also taking > > > > down notes during the AB meeting. I am copying David on this > > > note so that > > > > if you think anything is still missing you can discuss it > with David. > > > > Please note that the CWM FTF only records and resolves > issues of direct > > > > relevance to CWM. We do not record nor resolve issues related > > > to UML, MOF, > > > > XMI, etc. > > > > > > > > After talking to David (if needed), if you still think you have > > > issues, of > > > > direct relevance to CWM, not recorded and should be recorded, > > > please attend > > > > the September CWM FTF so that you can discuss them face to > face with the > > > > CWM FTF. > > > > > > > > Regards, Dan > > > > > > > > e-business Data Standards and Technology > > > > IBM Silicon Valley Laboratory > > > > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > > > > Internet: dtchang@us.ibm.com > > > > VM: IBMUSM50(DTCHANG) > > > > Phone: (408)-463-2319 > > > > > > > > ---------------------- Forwarded by Dan Chang/Santa Teresa/IBM on > > > > 06/30/2000 02:30 PM --------------------------- > > > > > > > > "David S. Frankel" on 06/30/2000 01:16:42 PM > > > > > > > > Please respond to > > > > > > > > To: Dan Chang/Santa Teresa/IBM@IBMUS > > > > cc: > > > > Subject: More RE: CWM FTF issues lists > > > > > > > > Dan-- > > > > > > > > These issues lists don't appear to cover all of the issues that > > > I submitted > > > > to you at the time that the final submission came up for AB > > > review. I see > > > > four issues generally attributed to the "Architecture Board" > > > but only one > > > > of > > > > them is one of my issues. If I am missing something, > please explain. > > > > > > > > For your convenience I have attached the original document that > > > conveyed my > > > > issues. > > > > > > > > Thanks. > > > > > > > > --Dave > > > > > > > > ================================ > > > > David S. Frankel > > > > Chief Scientist > > > > Genesis Development Corporation > > > > An Iona Technologies' Company > > > > 741 Santiago Court > > > > Chico, CA 95973-8781 USA > > > > > > > > +1 530 893-1100 voice > > > > +1 530 893-1153 fax > > > > dfrankel@gendev.com > > > > http://www.gendev.com > > > > ================================ > > > > > > > > > -----Original Message----- > > > > > From: dtchang@us.ibm.com [mailto:dtchang@us.ibm.com] > > > > > Sent: Friday, June 30, 2000 12:04 PM > > > > > To: Doug Tolbert; john_poole@hyperion.com; dlast@uk.oracle.com; > > > > > hans-peter.hoidn@ubs.com; plongden@gendev.com; > > > > > Lynn.Hedegard@SanDiegoCA.NCR.com; chris@dimension-edi.com; > > > > > SmithDaveC@JDCORP.deere.com; Barbara.Walters@sas.com; > > > > > robinnt@us.ibm.com; lin@de.ibm.com; Don Baisley; > > > > > Sridhar.Iyengar2@unisys.com; david_zhang@hyperion.com; > > > > > dmellor@us.oracle.com; mhornick@us.oracle.com; Gordon Callan; > > > > > jeffrey.peckham@ubs.com; DFrankel@gendev.com; > > > > > anders.tornqvist@comfact.com; Craig.Rubendall@sas.com > > > > > Subject: CWM FTF issues lists > > > > > > > > > > > > > > > > > > > > > > > > > Team, > > > > > > > > > > Attached are the lists (A & B) of CWM FTF issues. We > resolved most of > > > > them > > > > > in Oslo and we will start working on actions to close the > > > resolved ones > > > > > when Don fixes the CWM Metamodel in Rose, scheduled for 7/21. > > > > > Please let me > > > > > know if you have comments. > > > > > > > > > > (See attached file: CWMAIssues.pdf)(See attached file: > CWMBIssues.pdf) > > > > > > > > > > Regards, Dan > > > > > > > > > > e-business Data Standards and Technology > > > > > IBM Silicon Valley Laboratory > > > > > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > > > > > Internet: dtchang@us.ibm.com > > > > > VM: IBMUSM50(DTCHANG) > > > > > Phone: (408)-463-2319 > > > > > > > > > > > > > (See attached file: CWMfeedback.rtf) > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > Name: CWMfeedback.rtf > > > > Type: Winword File (application/rtf) > > > > CWMfeedback.rtf Encoding: base64 > > > > Description: Rich Text Format > > > > Download Status: Not downloaded with message > > > > > > > > > > X-Authentication-Warning: gendev.com: Host ppp-209-232-193-89.dialup.chic01.pacbell.net [209.232.193.89] claimed to be dfrankel Reply-To: From: "David S. Frankel" To: "Chonoles, Michael J" , "Stephen Crawley" Cc: "OMG--MOF RTF" , , "David Last" , , "Doug Tolbert" , "John Poole" , "Don Baisley" Subject: RE: Notation for inherited associations Date: Wed, 5 Jul 2000 08:48:15 -0700 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <716897408033D111BA8C0000F805CC8406CA5F69@emss04m07.ems.lmco.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ad'e9)nH!!Zfd!!2bS!! Michael-- Thanks for your comments. My responses are in line... > -----Original Message----- > From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] > Sent: Tuesday, July 04, 2000 2:57 PM > To: dfrankel@gendev.com; Stephen Crawley > Cc: OMG--MOF RTF; uml-rtf@omg.org; David Last; dtchang@us.ibm.com; Doug > Tolbert; John Poole; Don Baisley > Subject: RE: Notation for inherited associations > > > I would also agree that this is a notation issue, and somewhat confusing > issue. > > We don't have a notation for inherited attributes or operations. > Why should > we need a notation for inherited associations? [dsf] I don't have a theoretical basis for this requirement. It derives from observing that, in practice, there is often a need to be able to show this in class diagrams to promote understanding of the structure of a system. For example, in the CORBA metamodel, almost all associations--such as between InterfaceDef and AttributeDef--are not really new associations but, rather, are really the association between Container and Contained, respective ancestors of InterfaceDef and AttributeDef. If we did not show the inherited associations then the class diagrams would show very, very few associations and would fail to convey the structure of the system. > Assuming that we need the notation, The two proposed notations, > derived (/) > or <> both have their problems. The derived indicator > is typically > used to indicate a real "thing", such as a precalculated value. > Flagging an > association as derived is often used to indicate an implemented > association > that indicates a traversal from A to C that shortcuts the normal > path of A > to B to C for efficient processing. Thus a derived association > would be > another association, and distinct from the inherited association. [dsf] Agreed. This forced the CWM submitters to remove the association from the model before generating the XMI. > The <> tagged association has the advantage of not being another > association. However, <> can be used anytime there is a > conceptual > but not implemented association, and gives the impression that > the traversal > is not possible, which it would be in the inherited case. [dsf] Agreed, which is why I've raised the issue since there is no clean way to do it right now in UML. > So, I would propose that neither are quite right. Assuming we need a > notation, we need it to say, unambiguously, that the navigation > from A to B > is possible, but that we do not plan to implement another > association. > Perhaps all we need is {inherited}. > > I must also note that most uses of inherited associations that I > have seen > are misleading. An drawn inherited association should really only be > a one > way association, from the subclass to the original target > class. Making a > bi-directional association would imply that navigation is allowed > directly > to the subclass, which is not true. [dsf] I don't quite understand. If the association was declared bi-directional why should it be uni-directional when it's inherited? > I've seen inherited associations drawn between two subclasses. There are > many circumstances where improved notation would clarify some real world > situations, such as the very common one where there are parallel > inheritance > structure and sub classes of A are constrained to communicate to the > parallel subclass of B. I think some sort of situation requires a > notational > idiom that is quick to comprehend (rather than some complex OCL > constraint). [dsf] This is an excellent and more cogent (than mine) expression of the real requirement. Thanks. > Michael > Chief of Methodology, Lockheed Martin Advanced Concepts Center > michael.j.chonoles@LMCO.com > 610 992-6212 > > > -----Original Message----- > From: David S. Frankel [mailto:dfrankel@gendev.com] > Sent: Tue, July 04, 2000 11:27 AM > To: Stephen Crawley > Cc: OMG--MOF RTF; uml-rtf@omg.org; David Last; dtchang@us.ibm.com; > Doug > Tolbert; John Poole; Don Baisley > Subject: RE: Notation for inherited associations > > > Steve-- > > I accept your position that this is more appropriately taken up by > the UML > RTF. It isn't just a diagram layout issue though. It is a > notation issue. > A notation specification would tell you how to notate an > association that is > not new but just a repetition of an inherited association. Diagram > layout > would specify how to represent, in the metadata, where that notation > was > used spatially in relation to the dimensions of the diagram, in > relation to > the spatial placement of the participating classes, the spatial > placement of > the association line, etc. > > --Dave > > ================================ > David S. Frankel > Chief Scientist > Genesis Development Corporation > An Iona Technologies' Company > 741 Santiago Court > Chico, CA 95973-8781 USA > > +1 530 893-1100 voice > +1 530 893-1153 fax > dfrankel@gendev.com > http://www.gendev.com > ================================ > > > -----Original Message----- > > From: Stephen Crawley [mailto:crawley@dstc.edu.au] > > Sent: Monday, July 03, 2000 6:10 PM > > To: dfrankel@gendev.com > > Cc: OMG--MOF RTF; uml-rtf@omg.org; David Last; dtchang@us.ibm.com; > Doug > > Tolbert; John Poole; Don Baisley; crawley@dstc.edu.au > > Subject: Re: Notation for inherited associations > > > > > > > > Dave, > > > > The MOF spec does no specify a "human usable notation" for MOF > > meta-models. The > > MOF 1.0 final submitters made a deliberate decision to not > standardise any > > notation, diagrammatic or textual. The "MOF meta-model as UML > > diagram" notation > > that CMW is using is loosely defined in the UML spec. If there > > are flaws in > > this notation, then they should be taken up with the UML RTF in > the first > > instance. > > > > I don't think it would be inappropriate to include the "MOF in > > UML" notation as > > part of the MOF spec ... if other people think this would be a > good idea. > > However, if this happens, I'd also like to see a textual notation > > incorporated > > as well. The obvious one is the MODL language, which has been > used in the > > MOF spec from day 1. > > > > At this stage, I think that CMW's problem is an issue for the UML > > RTF; i.e. how > > to represent an inherited Association in a regular UML diagram. > > Or maybe this > > an implementation issue for UML tool vendors. [Isn't the > > decision to display > > an inherited Association "just" a diagram presentation issue? > In the same > > category as the layout of Classes on the page or the amount of > > detail shown for > > any given Class?] > > > > -- Steve > > > > > The CWM submitters needed to display inherited associations on > > some class > > > diagrams to enhance understandability. These were not intended > to be > > > derived associations; that is, there was no intention to > > specify additional > > > computational machinery when showing these inherited > associations. > > > Unfortunately, the MOF and UML have no succint way to display > inherited > > > associations. The CWM submitters placed the "/" derived prefix > on the > > > association end names in the class diagrams. At the same time, > > in order to > > > prevent the generation of additional computational machinery, > > they omitted > > > the inherited association from the normative XMI rendition of > > the metamodel. > > > This was probably a reasonable choice under the circumstances. > > However, it > > > means that the class diagrams and the XMI representation of the > > metamodel > > > conflict with one another. > > > > > > It is very common to need to show inherited associations on a > > class diagram. > > > We ran into this when we specified the CORBA metamodel for the > CORBA > > > Component Model submission. We used derived associations in the > class > > > diagrams as well. However, we retained the derived > > associations in the XMI > > > rendition of the metamodel. In order to prevent additional > > computational > > > machinery from being generated, we stereotyped the associations > as > > > <>. This stereotype is defined in the UML > > specification but not > > > in the MOF specification and says that an association is only > > conceptual and > > > not manifest. We then made sure that the generator producing > > the IDL and > > > XML DTDs was sensitive to the <> stereotype. This had > the > > > advantage of maintaining consistency between the class diagrams > > and the XMI > > > rendition of the metamodel. Of course this is also a > non-standard > > > approach--since <> is not defined in the MOF, we > > can't expect MOF > > > generators to understand it. > > > > > > The lack of a standard means for representing inherited > associations in > > > class diagrams is thus resulting in a proliferation of > non-standard > > > approaches in adopted OMG metamodels. This could become > > unmanageable as the > > > number of metamodels grows. A standard means should be > specified. > > > > > > --David Frankel > > > > > > ================================ > > > David S. Frankel > > > Chief Scientist > > > Genesis Development Corporation > > > An Iona Technologies' Company > > > 741 Santiago Court > > > Chico, CA 95973-8781 USA > > > > > > +1 530 893-1100 voice > > > +1 530 893-1153 fax > > > dfrankel@gendev.com > > > http://www.gendev.com > > > ================================ > > > > > > > -----Original Message----- > > > > From: David Last [mailto:dlast@uk.oracle.com] > > > > Sent: Monday, July 03, 2000 7:12 AM > > > > To: DFrankel@gendev.com > > > > Cc: dtchang@us.ibm.com; Doug Tolbert; John Poole; Don Baisley > > > > Subject: Your Feedback on CWM Submission > > > > > > > > > > > > Dave, > > > > > > > > First of all, thank you for all your feedback on the final > submission. > > > > > > > > As Dan said, we went through your comments at the Oslo > meeting. > > > > In the attached document I have added notes on our discussion > of > > > > each of the > > > > points you raised. > > > > Please do not hesitate to get back to me if you are still > > > > concerned on any of > > > > these points. > > > > > > > > The final point was not in the version of your paper that we > > > > discussed, so I > > > > have recorded this as a new issue B46, to be discussed at the > > > > next meeting. > > > > > > > > Regards, > > > > David > > > > > > > > dtchang@us.ibm.com. wrote: > > > > > > > > > Dave, > > > > > > > > > > The CWM FTF has gone over thoroughly your comments during > the > > > > Oslo meeting > > > > > on 6/13. In fact, I personally went over your comments with > > David Last > > > > > again the next day, 6/14, to make sure we did not miss > anything. > > > > > > > > > > David has taken the lead for the CWM FTF on tracking your > > > > comments. He has > > > > > done a very admirable job, not only keeping your document > but > > > > also taking > > > > > down notes during the AB meeting. I am copying David on this > > > > note so that > > > > > if you think anything is still missing you can discuss it > > with David. > > > > > Please note that the CWM FTF only records and resolves > > issues of direct > > > > > relevance to CWM. We do not record nor resolve issues > related > > > > to UML, MOF, > > > > > XMI, etc. > > > > > > > > > > After talking to David (if needed), if you still think you > have > > > > issues, of > > > > > direct relevance to CWM, not recorded and should be > recorded, > > > > please attend > > > > > the September CWM FTF so that you can discuss them face to > > face with the > > > > > CWM FTF. > > > > > > > > > > Regards, Dan > > > > > > > > > > e-business Data Standards and Technology > > > > > IBM Silicon Valley Laboratory > > > > > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > > > > > Internet: dtchang@us.ibm.com > > > > > VM: IBMUSM50(DTCHANG) > > > > > Phone: (408)-463-2319 > > > > > > > > > > ---------------------- Forwarded by Dan Chang/Santa > Teresa/IBM on > > > > > 06/30/2000 02:30 PM --------------------------- > > > > > > > > > > "David S. Frankel" on 06/30/2000 > 01:16:42 PM > > > > > > > > > > Please respond to > > > > > > > > > > To: Dan Chang/Santa Teresa/IBM@IBMUS > > > > > cc: > > > > > Subject: More RE: CWM FTF issues lists > > > > > > > > > > Dan-- > > > > > > > > > > These issues lists don't appear to cover all of the issues > that > > > > I submitted > > > > > to you at the time that the final submission came up for AB > > > > review. I see > > > > > four issues generally attributed to the "Architecture Board" > > > > but only one > > > > > of > > > > > them is one of my issues. If I am missing something, > > please explain. > > > > > > > > > > For your convenience I have attached the original document > that > > > > conveyed my > > > > > issues. > > > > > > > > > > Thanks. > > > > > > > > > > --Dave > > > > > > > > > > ================================ > > > > > David S. Frankel > > > > > Chief Scientist > > > > > Genesis Development Corporation > > > > > An Iona Technologies' Company > > > > > 741 Santiago Court > > > > > Chico, CA 95973-8781 USA > > > > > > > > > > +1 530 893-1100 voice > > > > > +1 530 893-1153 fax > > > > > dfrankel@gendev.com > > > > > http://www.gendev.com > > > > > ================================ > > > > > > > > > > > -----Original Message----- > > > > > > From: dtchang@us.ibm.com [mailto:dtchang@us.ibm.com] > > > > > > Sent: Friday, June 30, 2000 12:04 PM > > > > > > To: Doug Tolbert; john_poole@hyperion.com; > dlast@uk.oracle.com; > > > > > > hans-peter.hoidn@ubs.com; plongden@gendev.com; > > > > > > Lynn.Hedegard@SanDiegoCA.NCR.com; chris@dimension-edi.com; > > > > > > SmithDaveC@JDCORP.deere.com; Barbara.Walters@sas.com; > > > > > > robinnt@us.ibm.com; lin@de.ibm.com; Don Baisley; > > > > > > Sridhar.Iyengar2@unisys.com; david_zhang@hyperion.com; > > > > > > dmellor@us.oracle.com; mhornick@us.oracle.com; Gordon > Callan; > > > > > > jeffrey.peckham@ubs.com; DFrankel@gendev.com; > > > > > > anders.tornqvist@comfact.com; Craig.Rubendall@sas.com > > > > > > Subject: CWM FTF issues lists > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Team, > > > > > > > > > > > > Attached are the lists (A & B) of CWM FTF issues. We > > resolved most of > > > > > them > > > > > > in Oslo and we will start working on actions to close the > > > > resolved ones > > > > > > when Don fixes the CWM Metamodel in Rose, scheduled for > 7/21. > > > > > > Please let me > > > > > > know if you have comments. > > > > > > > > > > > > (See attached file: CWMAIssues.pdf)(See attached file: > > CWMBIssues.pdf) > > > > > > > > > > > > Regards, Dan > > > > > > > > > > > > e-business Data Standards and Technology > > > > > > IBM Silicon Valley Laboratory > > > > > > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > > > > > > Internet: dtchang@us.ibm.com > > > > > > VM: IBMUSM50(DTCHANG) > > > > > > Phone: (408)-463-2319 > > > > > > > > > > > > > > > > (See attached file: CWMfeedback.rtf) > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > Name: CWMfeedback.rtf > > > > > Type: Winword File > (application/rtf) > > > > > CWMfeedback.rtf Encoding: base64 > > > > > Description: Rich Text Format > > > > > Download Status: Not downloaded with > message > > > > > > > > > > > > > > > > > > X-Sender: miller@joaquin.net@pop3.joaquin.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Jul 2000 10:01:44 -0700 To: , From: Joaquin Miller Subject: RE: Notation for inherited associations In-Reply-To: References: <716897408033D111BA8C0000F805CC8406CA5F69@emss04m07.ems.lmco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: *R'!!F7M!!O`Rd9+[0!! At 08:48 AM 7/5/2000, David S. Frankel wrote: >> I must also note that most uses of inherited associations that I have > seen are misleading. A drawn inherited association should really >> only be a one way association, from the subclass to the original >> target class. Making a bi-directional association would imply that >> navigation is allowed directly to the subclass, which is not true. > >[dsf] I don't quite understand. If the association was declared >bi-directional why should it be uni-directional when it's inherited? It is probably just my thick skull, but we have here an example of a whole big class of things people say all the time, that throw me off. I'm not writing about what David does not understand, though i don't understand that either. I'm writing about the phrase "navigation ... directly to the subclass." It's not clear to me what this wants to mean. Here's my point: If i understand 'navigate', we don't navigate between classes. Navigation is between objects. So i want the phrase: "navigation [from the original target class]... directly to the subclass" to be a kind of shorthand for: "navigation from an object of the original target class directly to an object of the subclass." And 'subclass' here must mean subclass of the original source class. So we have: "navigation from an object of the original target class directly to an object of the source subclass." If i understand 'subclass,' an object of the subclass is an object of the parent class. So "navigation from an object of the original target class directly to an object of the source subclass" means navigation from an object of the original target class directly to an object of the original source class. But navigation along a bidirectional link from an object of the "target" class directly to an object of the "source" class... well, that is just what bidirectional means, isn't it? ... Of course, maybe "navigation directly to the subclass" means something different. That may well be. Since (if i am not just dead wrong) we don't navigate to classes, there is a lot of room here for different meanings. I bet it would help to see 'navigate directly' explained in terms of objects (as i tried to do above for one possible meaning). ..... Now, that may seem long winded and obvious. But think about this: Suppose we understood and explained things in terms of objects and links, and then added classes and associations. Might that be easier for us and our users? ============= In any case, i recommend re-reading David's message. He explains the reasons that it is essential that users are allowed to: 1) show inherited associations 2) show that they are inherited Most of the time we do not look at or show to others the whole model. We show pieces. It is important that those pieces are not misleading (a polite term for wrong). Cordially, Joaquin Miller Chief Architect Financial Systems Architects mailto:joaquin@acm.org San Francisco phone: +1 (510) 336-2545 fax: +1 (510) 336-2546 PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 From: "Baisley, Donald E" To: dfrankel@gendev.com, OMG--MOF RTF Cc: David Last , dtchang@us.ibm.com, Doug Tolbert , John Poole Subject: RE: Notation for inherited associations Date: Wed, 5 Jul 2000 15:02:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: JQ7e9FI=!!O>[d9LYUd9 Hello all, Here are a few relevant points: 1. This is a purely notational issue. The same association can appear in multiple diagrams. Its presence in a new diagram does not create a new association. 2. UML stereotypes are model elements that get attached to other model elements. They are part of the semantics of a model or metamodel. Therefore, UML stereotypes are inappropriate for a job which is purely notational. Remember we have a single Association appearing in multiple diagrams (some of which show only subclasses of the connected classes). Putting a stereotype on the Association would affect the model rather than just its appearance in one diagram. It's true that in Rational Rose multiple associations have been created for the same single association, but that's simply because Rose does not directly support displaying inherited associations. But why should it when UML does not yet define the notation? 3. Because this is a notational issue, it is an issue for the UML RTF, not the MOF RTF. 4. Despite the fact that UML does not define a notation for inherited associations, the UML Specification does use a notation for this purpose. The use of "/" in front of association end names for displaying inherited associations is used by the UML Specification in its pictures of the UML logical model (See Fig. 2-17, Collaborations). The CWM folks simply followed UML's example. 5. The use of "/" in front of an association end name has no defined meaning in UML, but its use in other places, such as on an association name, means "derived". So "/" is probably the not a good choice for a symbol, but it's not ambiguous. Regards, Don Baisley Unisys -----Original Message----- From: David S. Frankel [mailto:dfrankel@gendev.com] Sent: Monday, July 03, 2000 10:44 AM To: OMG--MOF RTF Cc: issues@omg.org; David Last; dtchang@us.ibm.com; Doug Tolbert; John Poole; Don Baisley Subject: Notation for inherited associations The CWM submitters needed to display inherited associations on some class diagrams to enhance understandability. These were not intended to be derived associations; that is, there was no intention to specify additional computational machinery when showing these inherited associations. Unfortunately, the MOF and UML have no succint way to display inherited associations. The CWM submitters placed the "/" derived prefix on the association end names in the class diagrams. At the same time, in order to prevent the generation of additional computational machinery, they omitted the inherited association from the normative XMI rendition of the metamodel. This was probably a reasonable choice under the circumstances. However, it means that the class diagrams and the XMI representation of the metamodel conflict with one another. It is very common to need to show inherited associations on a class diagram. We ran into this when we specified the CORBA metamodel for the CORBA Component Model submission. We used derived associations in the class diagrams as well. However, we retained the derived associations in the XMI rendition of the metamodel. In order to prevent additional computational machinery from being generated, we stereotyped the associations as <>. This stereotype is defined in the UML specification but not in the MOF specification and says that an association is only conceptual and not manifest. We then made sure that the generator producing the IDL and XML DTDs was sensitive to the <> stereotype. This had the advantage of maintaining consistency between the class diagrams and the XMI rendition of the metamodel. Of course this is also a non-standard approach--since <> is not defined in the MOF, we can't expect MOF generators to understand it. The lack of a standard means for representing inherited associations in class diagrams is thus resulting in a proliferation of non-standard approaches in adopted OMG metamodels. This could become unmanageable as the number of metamodels grows. A standard means should be specified. --David Frankel ================================ David S. Frankel Chief Scientist Genesis Development Corporation An Iona Technologies' Company 741 Santiago Court Chico, CA 95973-8781 USA +1 530 893-1100 voice +1 530 893-1153 fax dfrankel@gendev.com http://www.gendev.com ================================ > -----Original Message----- > From: David Last [mailto:dlast@uk.oracle.com] > Sent: Monday, July 03, 2000 7:12 AM > To: DFrankel@gendev.com > Cc: dtchang@us.ibm.com; Doug Tolbert; John Poole; Don Baisley > Subject: Your Feedback on CWM Submission > > > Dave, > > First of all, thank you for all your feedback on the final submission. > > As Dan said, we went through your comments at the Oslo meeting. > In the attached document I have added notes on our discussion of > each of the > points you raised. > Please do not hesitate to get back to me if you are still > concerned on any of > these points. > > The final point was not in the version of your paper that we > discussed, so I > have recorded this as a new issue B46, to be discussed at the > next meeting. > > Regards, > David > > dtchang@us.ibm.com. wrote: > > > Dave, > > > > The CWM FTF has gone over thoroughly your comments during the > Oslo meeting > > on 6/13. In fact, I personally went over your comments with David Last > > again the next day, 6/14, to make sure we did not miss anything. > > > > David has taken the lead for the CWM FTF on tracking your > comments. He has > > done a very admirable job, not only keeping your document but > also taking > > down notes during the AB meeting. I am copying David on this > note so that > > if you think anything is still missing you can discuss it with David. > > Please note that the CWM FTF only records and resolves issues of direct > > relevance to CWM. We do not record nor resolve issues related > to UML, MOF, > > XMI, etc. > > > > After talking to David (if needed), if you still think you have > issues, of > > direct relevance to CWM, not recorded and should be recorded, > please attend > > the September CWM FTF so that you can discuss them face to face with the > > CWM FTF. > > > > Regards, Dan > > > > e-business Data Standards and Technology > > IBM Silicon Valley Laboratory > > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > > Internet: dtchang@us.ibm.com > > VM: IBMUSM50(DTCHANG) > > Phone: (408)-463-2319 > > > > ---------------------- Forwarded by Dan Chang/Santa Teresa/IBM on > > 06/30/2000 02:30 PM --------------------------- > > > > "David S. Frankel" on 06/30/2000 01:16:42 PM > > > > Please respond to > > > > To: Dan Chang/Santa Teresa/IBM@IBMUS > > cc: > > Subject: More RE: CWM FTF issues lists > > > > Dan-- > > > > These issues lists don't appear to cover all of the issues that > I submitted > > to you at the time that the final submission came up for AB > review. I see > > four issues generally attributed to the "Architecture Board" > but only one > > of > > them is one of my issues. If I am missing something, please explain. > > > > For your convenience I have attached the original document that > conveyed my > > issues. > > > > Thanks. > > > > --Dave > > > > ================================ > > David S. Frankel > > Chief Scientist > > Genesis Development Corporation > > An Iona Technologies' Company > > 741 Santiago Court > > Chico, CA 95973-8781 USA > > > > +1 530 893-1100 voice > > +1 530 893-1153 fax > > dfrankel@gendev.com > > http://www.gendev.com > > ================================ > > > > > -----Original Message----- > > > From: dtchang@us.ibm.com [mailto:dtchang@us.ibm.com] > > > Sent: Friday, June 30, 2000 12:04 PM > > > To: Doug Tolbert; john_poole@hyperion.com; dlast@uk.oracle.com; > > > hans-peter.hoidn@ubs.com; plongden@gendev.com; > > > Lynn.Hedegard@SanDiegoCA.NCR.com; chris@dimension-edi.com; > > > SmithDaveC@JDCORP.deere.com; Barbara.Walters@sas.com; > > > robinnt@us.ibm.com; lin@de.ibm.com; Don Baisley; > > > Sridhar.Iyengar2@unisys.com; david_zhang@hyperion.com; > > > dmellor@us.oracle.com; mhornick@us.oracle.com; Gordon Callan; > > > jeffrey.peckham@ubs.com; DFrankel@gendev.com; > > > anders.tornqvist@comfact.com; Craig.Rubendall@sas.com > > > Subject: CWM FTF issues lists > > > > > > > > > > > > > > > Team, > > > > > > Attached are the lists (A & B) of CWM FTF issues. We resolved most of > > them > > > in Oslo and we will start working on actions to close the > resolved ones > > > when Don fixes the CWM Metamodel in Rose, scheduled for 7/21. > > > Please let me > > > know if you have comments. > > > > > > (See attached file: CWMAIssues.pdf)(See attached file: CWMBIssues.pdf) > > > > > > Regards, Dan > > > > > > e-business Data Standards and Technology > > > IBM Silicon Valley Laboratory > > > Notes: Dan Chang/Santa Teresa/IBM@IBMUS > > > Internet: dtchang@us.ibm.com > > > VM: IBMUSM50(DTCHANG) > > > Phone: (408)-463-2319 > > > > > > > (See attached file: CWMfeedback.rtf) > > > > > ------------------------------------------------------------------------ > > Name: CWMfeedback.rtf > > Type: Winword File (application/rtf) > > CWMfeedback.rtf Encoding: base64 > > Description: Rich Text Format > > Download Status: Not downloaded with message > X-Mailer: exmh version 2.1.0 09/18/1999 To: Juergen Boldt Cc: "OMG--MOF RTF" , uml-rtf@omg.org Subject: Re: issue 3682 -- MOF RTF issue In-reply-to: Your message of "Fri, 07 Jul 2000 14:26:58 -0400." <4.2.0.58.20000707142619.00bc4ae0@emerald.omg.org> Mime-Version: 1.0 Date: Mon, 10 Jul 2000 12:13:02 +1000 From: Stephen Crawley Content-Type: text/plain; charset=us-ascii X-UIDL: HNXd9ob^d9#-ed9JhF!! Juergen, I don't think this is a MOF RTF issue, and neither does Dave Frankel. See message appended. If it is appropriate for me to ask you to move the issue to the UML RTF, please do so. :-) -- Steve =============================================================================== == Return-path: dfrankel@gendev.com Delivery-date: Wed, 05 Jul 2000 01:28:22 +1000 Received: from gendev.com (gendev.com [192.41.40.108]) by piglet.dstc.edu.au (8.10.1/8.10.1) with ESMTP id e64FSKb09278 for ; Wed, 5 Jul 2000 01:28:20 +1000 (EST) Received: from dfrankel (ppp-209-232-193-1.dialup.chic01.pacbell.net [209.232.193.1]) by gendev.com (8.8.5) id JAA22736; Tue, 4 Jul 2000 09:28:49 -0600 (MDT) X-authentication-warning: gendev.com: Host ppp-209-232-193-1.dialup.chic01.pacb ell.net [209.232.193.1] claimed to be dfrankel Reply-to: Message-id: Mime-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-priority: 3 (Normal) X-msmail-priority: Normal X-mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 In-reply-to: <200007040109.e6419xb07891@piglet.dstc.edu.au> From: "David S. Frankel" To: "Stephen Crawley" Cc: "OMG--MOF RTF" , , "David Last" , , "Doug Tolbert" , "John Poole" , "Don Baisley" Subject: RE: Notation for inherited associations Date: Tue, 4 Jul 2000 08:26:50 -0700 (Wed 01:26 EST) Steve-- I accept your position that this is more appropriately taken up by the UML RTF. It isn't just a diagram layout issue though. It is a notation issue. A notation specification would tell you how to notate an association that is not new but just a repetition of an inherited association. Diagram layout would specify how to represent, in the metadata, where that notation was used spatially in relation to the dimensions of the diagram, in relation to the spatial placement of the participating classes, the spatial placement of the association line, etc. --Dave ================================ David S. Frankel Chief Scientist Genesis Development Corporation An Iona Technologies' Company 741 Santiago Court Chico, CA 95973-8781 USA +1 530 893-1100 voice +1 530 893-1153 fax dfrankel@gendev.com http://www.gendev.com ================================