Issue 6630: UML 2 Super / Classes / dependencies should be unidirectional (uml2-rtf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: In the metamodel, UML::Classes::Dependencies::NamedElement::supplierDependency should not be navigable, as it does not make sense for the supplier of a dependency to know about its dependencies Resolution: see above Revised Text: In figure 15 on page 32, make the association end NamedElement::supplierDependency non-navigable. (According to the convention used in the spec (section 6.5.2), this means that the supplier NamedElement does not have a property that explicitly identifies the set of dependencies that target it.) In section 7.3.33 on page 100 in the Associations subsection of NamedElement, remove the entire “supplierDependency” item. Actions taken: November 26, 2003: received issue August 23, 2006: closed issue Discussion: This is fully consistent with the pattern used for all the other kinds of directed relationships (Generalization, PackageMerge, ElementImport and PackageImport.) Note that this does not prevent tools from readily determining the dependencies targeting a particular model element if necessary, since that information can be easily computed or cached by the tool when the dependency is constructed. End of Annotations:===== ubject: UML 2 Super / Classes / dependencies should be unidirectional X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 26 Nov 2003 05:54:29 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 11/26/2003 05:54:31, Serialize complete at 11/26/2003 05:54:31 In the metamodel, UML::Classes::Dependencies::NamedElement::supplierDependency should not be navigable, as it does not make sense for the supplier of a dependency to know about its dependencies Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 To: "Pete Rivett" Cc: conrad.bock@nist.gov, "Karl Frank" , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 28 Jul 2004 10:23:30 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/28/2004 10:23:34, Serialize complete at 07/28/2004 10:23:34 Here is what I was thinking of: Bran RE Two resolutions for Ballot 1.gif Reply-To: From: "Conrad Bock" To: "Branislav Selic" , "Pete Rivett" Cc: "Karl Frank" , , Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Date: Wed, 28 Jul 2004 10:34:26 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) FYI, the original spec suggested that attributes be shown for navigable ends owned by the class(see bottom of page 85 of the FAS), but the metamodel didn't follow it. The FTF update to that text toned it down slightly (p 33 of 040725 version). Conrad User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 28 Jul 2004 10:36:40 -0400 Subject: Re: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel From: James Odell To: CC: Bran, Has there been a default decided? -Jim On 7/28/04 10:23 AM, "Branislav Selic" indited: Here is what I was thinking of: Bran image.gif Reply-To: From: "Desfray" To: "'Branislav Selic'" , "'Pete Rivett'" Cc: , "'Karl Frank'" , , Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Date: Wed, 28 Jul 2004 17:03:35 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-Virus-Scanned: by amavisd-new at softeam.com I just feel very bad about that and all this navigability discussion. It seems that there is a dangerous mix between the semantics of navigability, from the end user's eyes, and the ownership rules, from the meta-implementer's eyes. Adding notations to indicate ownership rules is pure pollution in a logical model. I would just claim that we should keep close to the end user's semantics (from UML1.4), and explain somewhere that from the metamodel implementation perspective, navigability has an ownership implication. ==================================== Philippe -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 28 juillet 2004 16:24 À : Pete Rivett Cc : conrad.bock@nist.gov; Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Here is what I was thinking of: Bran ATT00153.gif Reply-To: From: "Conrad Bock" To: , Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Date: Wed, 28 Jul 2004 11:29:22 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Philippe, > I just feel very bad about that and all this navigability > discussion. It seems that there is a dangerous mix between the > semantics of navigability, from the end user's eyes, and the > ownership rules, from the meta-implementer's eyes. The resolution of 6243 separated these, they aren't mixed. > Adding notations to indicate ownership rules is pure pollution > in a logical model. Models aren't just logical, unfortunately, they are often used to show implementation. > I would just claim that we should keep close to the end user's > semantics (from UML1.4), and explain somewhere that from the > metamodel implementation perspective, navigability has an > ownership implication. See first comment above, navigation is separate from ownership, as it was in UML 1.4, but now there is more flexibility in ownership. Conrad Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Date: Wed, 28 Jul 2004 10:19:35 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Thread-Index: AcR0tNagVgpksgOcRTWk6L4N4Ch9SwAEiVIw From: "Pidcock, Woody" To: , "Branislav Selic" , "Pete Rivett" Cc: , "Karl Frank" , , X-OriginalArrivalTime: 28 Jul 2004 17:19:35.0672 (UTC) FILETIME=[0E13F780:01C474C7] I agree with Philippe. -----Original Message----- From: Desfray [mailto:Philippe.Desfray@softeam.fr] Sent: Wednesday, July 28, 2004 8:04 AM To: 'Branislav Selic'; 'Pete Rivett' Cc: conrad.bock@nist.gov; 'Karl Frank'; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel I just feel very bad about that and all this navigability discussion. It seems that there is a dangerous mix between the semantics of navigability, from the end user's eyes, and the ownership rules, from the meta-implementer's eyes. Adding notations to indicate ownership rules is pure pollution in a logical model. I would just claim that we should keep close to the end user's semantics (from UML1.4), and explain somewhere that from the metamodel implementation perspective, navigability has an ownership implication. ==================================== Philippe -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 28 juillet 2004 16:24 À : Pete Rivett Cc : conrad.bock@nist.gov; Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Here is what I was thinking of: Bran ATT001531.gif Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Date: Wed, 28 Jul 2004 10:49:39 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Thread-Index: AcR0tNagVgpksgOcRTWk6L4N4Ch9SwAEiVIwAADkWSA= From: "Karl Frank" To: "Pidcock, Woody" , , "Branislav Selic" , "Pete Rivett" Cc: , , X-OriginalArrivalTime: 28 Jul 2004 17:49:47.0783 (UTC) FILETIME=[462E2970:01C474CB] So what's the character data for the dot? I do not like the dot as proposed by Bran below because it is appearing amongst the string markup for line ends, as if an extension to the visibility and property string markup, but it is not a keyboard character. A graphic dot adorning the end of the line graphic itself, analogous to the X for nonnavigable end and the > for navigable, would be acceptable because it is a graphic and hence drawn, no suggestion that it can be typed in. - Karl -------------------------------------------------------------------------------- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Wednesday, 28 July, 2004 1:20 PM To: Philippe.Desfray@softeam.fr; Branislav Selic; Pete Rivett Cc: conrad.bock@nist.gov; Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel I agree with Philippe. -----Original Message----- From: Desfray [mailto:Philippe.Desfray@softeam.fr] Sent: Wednesday, July 28, 2004 8:04 AM To: 'Branislav Selic'; 'Pete Rivett' Cc: conrad.bock@nist.gov; 'Karl Frank'; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel I just feel very bad about that and all this navigability discussion. It seems that there is a dangerous mix between the semantics of navigability, from the end user's eyes, and the ownership rules, from the meta-implementer's eyes. Adding notations to indicate ownership rules is pure pollution in a logical model. I would just claim that we should keep close to the end user's semantics (from UML1.4), and explain somewhere that from the metamodel implementation perspective, navigability has an ownership implication. ==================================== Philippe -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 28 juillet 2004 16:24 À : Pete Rivett Cc : conrad.bock@nist.gov; Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Here is what I was thinking of: Bran ATT001532.gif To: "Pidcock, Woody" Cc: conrad.bock@nist.gov, "Karl Frank" , mu2i-ftf@omg.org, "Pete Rivett" , Philippe.Desfray@softeam.fr, uml2-superstructure-ftf@omg.org Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 28 Jul 2004 14:03:11 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/28/2004 14:03:14, Serialize complete at 07/28/2004 14:03:14 Philippe and Woody, I don't mean to single the two of you out, but the right time to have expressed these reservations would have been when issue 6243 was discussed and also, when it was voted on (Ballot 17 -- a month ago). Regards, Bran "Pidcock, Woody" 07/28/2004 01:19 PM To , Branislav Selic/Ottawa/IBM@IBMCA, "Pete Rivett" cc , "Karl Frank" , , Subject RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel I agree with Philippe. -----Original Message----- From: Desfray [mailto:Philippe.Desfray@softeam.fr] Sent: Wednesday, July 28, 2004 8:04 AM To: 'Branislav Selic'; 'Pete Rivett' Cc: conrad.bock@nist.gov; 'Karl Frank'; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel I just feel very bad about that and all this navigability discussion. It seems that there is a dangerous mix between the semantics of navigability, from the end user's eyes, and the ownership rules, from the meta-implementer's eyes. Adding notations to indicate ownership rules is pure pollution in a logical model. I would just claim that we should keep close to the end user's semantics (from UML1.4), and explain somewhere that from the metamodel implementation perspective, navigability has an ownership implication. ==================================== Philippe -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 28 juillet 2004 16:24 À : Pete Rivett Cc : conrad.bock@nist.gov; Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Here is what I was thinking of: Bran RE Two resolutions for Ballot 2.gif To: "Karl Frank" Cc: conrad.bock@nist.gov, mu2i-ftf@omg.org, "Pete Rivett" , Philippe.Desfray@softeam.fr, uml2-superstructure-ftf@omg.org, "Pidcock, Woody" Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 28 Jul 2004 14:10:10 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/28/2004 14:10:13, Serialize complete at 07/28/2004 14:10:13 Sorry, that WAS a floating black circle, not a character. I just didn't show it very floaty. Also, I am not sure that it is necessarily the best choice, it was just the first one I thought of (I wanted it to be reminiscent of the black diamond). Needs more discussion certainly. Bran "Karl Frank" 07/28/2004 01:49 PM To "Pidcock, Woody" , , Branislav Selic/Ottawa/IBM@IBMCA, "Pete Rivett" cc , , Subject RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel So what's the character data for the dot? I do not like the dot as proposed by Bran below because it is appearing amongst the string markup for line ends, as if an extension to the visibility and property string markup, but it is not a keyboard character. A graphic dot adorning the end of the line graphic itself, analogous to the X for nonnavigable end and the > for navigable, would be acceptable because it is a graphic and hence drawn, no suggestion that it can be typed in. - Karl -------------------------------------------------------------------------------- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Wednesday, 28 July, 2004 1:20 PM To: Philippe.Desfray@softeam.fr; Branislav Selic; Pete Rivett Cc: conrad.bock@nist.gov; Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel I agree with Philippe. -----Original Message----- From: Desfray [mailto:Philippe.Desfray@softeam.fr] Sent: Wednesday, July 28, 2004 8:04 AM To: 'Branislav Selic'; 'Pete Rivett' Cc: conrad.bock@nist.gov; 'Karl Frank'; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel I just feel very bad about that and all this navigability discussion. It seems that there is a dangerous mix between the semantics of navigability, from the end user's eyes, and the ownership rules, from the meta-implementer's eyes. Adding notations to indicate ownership rules is pure pollution in a logical model. I would just claim that we should keep close to the end user's semantics (from UML1.4), and explain somewhere that from the metamodel implementation perspective, navigability has an ownership implication. ==================================== Philippe -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 28 juillet 2004 16:24 À : Pete Rivett Cc : conrad.bock@nist.gov; Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Here is what I was thinking of: Bran RE Two resolutions for Ballot 3.gif Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Date: Wed, 28 Jul 2004 11:13:47 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Thread-Index: AcR0zULvWcYTEm23T1CO7pxRt7CK3wAAIp+A From: "Pidcock, Woody" To: "Branislav Selic" Cc: , "Karl Frank" , , "Pete Rivett" , , X-OriginalArrivalTime: 28 Jul 2004 18:13:47.0881 (UTC) FILETIME=[A08BAD90:01C474CE] I agree that the information about association end ownership should be captured and be unambiguous in the UML metamodel standard. Users should be allowed to make decisions about this and enter those decisions into a UML compliant tool. My concern is with the visualization of this information. The class-association model diagram is already cluttered and information dense. I would prefer displaying this information in a textual table rather than as part of the graphical diagram notation. -Woody -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, July 28, 2004 11:03 AM To: Pidcock, Woody Cc: conrad.bock@nist.gov; Karl Frank; mu2i-ftf@omg.org; Pete Rivett; Philippe.Desfray@softeam.fr; uml2-superstructure-ftf@omg.org Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Philippe and Woody, I don't mean to single the two of you out, but the right time to have expressed these reservations would have been when issue 6243 was discussed and also, when it was voted on (Ballot 17 -- a month ago). Regards, Bran "Pidcock, Woody" 07/28/2004 01:19 PM To , Branislav Selic/Ottawa/IBM@IBMCA, "Pete Rivett" cc , "Karl Frank" , , Subject RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel I agree with Philippe. -----Original Message----- From: Desfray [mailto:Philippe.Desfray@softeam.fr] Sent: Wednesday, July 28, 2004 8:04 AM To: 'Branislav Selic'; 'Pete Rivett' Cc: conrad.bock@nist.gov; 'Karl Frank'; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel I just feel very bad about that and all this navigability discussion. It seems that there is a dangerous mix between the semantics of navigability, from the end user's eyes, and the ownership rules, from the meta-implementer's eyes. Adding notations to indicate ownership rules is pure pollution in a logical model. I would just claim that we should keep close to the end user's semantics (from UML1.4), and explain somewhere that from the metamodel implementation perspective, navigability has an ownership implication. ==================================== Philippe -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 28 juillet 2004 16:24 À : Pete Rivett Cc : conrad.bock@nist.gov; Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Here is what I was thinking of: Bran ATT100760.gif To: "Karl Frank" Cc: mu2i-ftf@omg.org, Pete.Rivett@adaptive.com, uml2-superstructure-ftf@omg.org Subject: Issue 6630 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 28 Jul 2004 17:56:44 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/28/2004 17:56:47, Serialize complete at 07/28/2004 17:56:47 Regarding issue 6630: Kenn Hussey, who is the originator of this issue and the main implementor of the UML 2 Open Source Eclipse project explained to me why this needs to be fixed The problem with leaving NamedElement::supplierDependency navigable is a practical one (uncovered through direct experience) and can be quite serious even though it looks innocuous. Namely, it is often the case in practice that this type of dependency is drawn to an external entity such as another model or elements that belong to another model. For example, we might want to say with the dependency that one model is requirements model for the other, or that one is a more refined version of the other. These are not necessarily formalized dependencies and are often meant to capture some vague notion. After all, dependency was intended to be used in a variety of domain- and application-specific ways, which is why it has hardly any semantics. However, it may happen that the external entity may be write-protected or inaccessible. Even if it is accessible and writeable, drawing a dependency to this element requires that the external entity be opened up so that the back link to the client can be written into it. Depending on the size of that entity, this could add lots of overhead to what should be a lightweight almost semantics-free annotation. We can argue this on the basis of principle all we like, but the above practical issue that the current model presents will not go away. In our experience, the issue can be quite serious and impedes usability. Therefore, I am asking that we set aside our theological hats and respond in a pragmatic way to a pragmatic concern. Thanks, Bran "Karl Frank" 07/28/2004 04:59 PM To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject Another pair of resolutions for Ballot 21 One of these is classified as shared with Infra, but I find there is no problem with the Infra, the fix is local to the superstructure spec. Please see attached. - Karl[attachment "Issues_6630_7355.doc" deleted by Branislav Selic/Ottawa/IBM] Subject: RE: Issue 6630 Date: Wed, 28 Jul 2004 16:14:02 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 6630 Thread-Index: AcR07dtokZ9lA/PFSnmwbPlPQR+0dQACWfIw From: "Pidcock, Woody" To: "Branislav Selic" , "Karl Frank" Cc: , , X-OriginalArrivalTime: 28 Jul 2004 23:14:02.0787 (UTC) FILETIME=[92442F30:01C474F8] I agree there is a need to represent dependency on an external entity without changing that external entity. This was a known issue back in the PCTE days. UML needs to support navigation from a dependency association to an external entity without modifying the definition (properties, attributes, etc.) of the external entity. I am not sure if this needs to be supported in the graphical notation, but will not object if such a graphical notation is proposed and adopted. The user decision to introduce this dependency association without modifying the external entity (e.g., no need for reverse navigation from the external entity) needs to be query-able by others reviewing the model--so including it in the graphical notation rather than in a separate report is acceptable. -Woody -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, July 28, 2004 2:57 PM To: Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: Issue 6630 Regarding issue 6630: Kenn Hussey, who is the originator of this issue and the main implementor of the UML 2 Open Source Eclipse project explained to me why this needs to be fixed The problem with leaving NamedElement::supplierDependency navigable is a practical one (uncovered through direct experience) and can be quite serious even though it looks innocuous. Namely, it is often the case in practice that this type of dependency is drawn to an external entity such as another model or elements that belong to another model. For example, we might want to say with the dependency that one model is requirements model for the other, or that one is a more refined version of the other. These are not necessarily formalized dependencies and are often meant to capture some vague notion. After all, dependency was intended to be used in a variety of domain- and application-specific ways, which is why it has hardly any semantics. However, it may happen that the external entity may be write-protected or inaccessible. Even if it is accessible and writeable, drawing a dependency to this element requires that the external entity be opened up so that the back link to the client can be written into it. Depending on the size of that entity, this could add lots of overhead to what should be a lightweight almost semantics-free annotation. We can argue this on the basis of principle all we like, but the above practical issue that the current model presents will not go away. In our experience, the issue can be quite serious and impedes usability. Therefore, I am asking that we set aside our theological hats and respond in a pragmatic way to a pragmatic concern. Thanks, Bran "Karl Frank" 07/28/2004 04:59 PM To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject Another pair of resolutions for Ballot 21 One of these is classified as shared with Infra, but I find there is no problem with the Infra, the fix is local to the superstructure spec. Please see attached. - Karl[attachment "Issues_6630_7355.doc" deleted by Branislav Selic/Ottawa/IBM] Subject: RE: Issue 6630 Date: Wed, 28 Jul 2004 20:46:46 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 6630 Thread-Index: AcR07xPsVc9FxTHqSpO81ij8S1FciAAEyEUQ From: "Pete Rivett" To: "Branislav Selic" , "Karl Frank" Cc: , X-Virus-Scanned: by amavisd-new at sentraliant.com Sorry if I appear to be repeating myself but this is again based on the original UML2 notion of navigation, and not Conrad's resolution which AFAIK is designed specifically to allow the specification of this sort of navigation without requiring state in the Supplier. As you said yourself, Bran, earlier on this thread, there is nothing to stop tools having their own navigation framework or index structure or lookup table to implement the navigation (and in any case 'navigable' is only advisory). There is certainly no requirement to have anything as part of the state of the supplier object (if there were it would be an ownedMember of the Supplier) or even anything (such as a back link) writeable in the storage/extent of the Supplier. For example one could implement the association with 2-way navigation by having a 2-column association table (or in-memory equivalent) listing linked ids of client and supplier objects. This is very pragmatic indeed: it's been in our MOF product for at least the past 4 years. Cheers Pete 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: Wednesday, July 28, 2004 10:57 PM To: Karl Frank Cc: mu2i-ftf@omg.org; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: Issue 6630 Regarding issue 6630: Kenn Hussey, who is the originator of this issue and the main implementor of the UML 2 Open Source Eclipse project explained to me why this needs to be fixed The problem with leaving NamedElement::supplierDependency navigable is a practical one (uncovered through direct experience) and can be quite serious even though it looks innocuous. Namely, it is often the case in practice that this type of dependency is drawn to an external entity such as another model or elements that belong to another model. For example, we might want to say with the dependency that one model is requirements model for the other, or that one is a more refined version of the other. These are not necessarily formalized dependencies and are often meant to capture some vague notion. After all, dependency was intended to be used in a variety of domain- and application-specific ways, which is why it has hardly any semantics. However, it may happen that the external entity may be write-protected or inaccessible. Even if it is accessible and writeable, drawing a dependency to this element requires that the external entity be opened up so that the back link to the client can be written into it. Depending on the size of that entity, this could add lots of overhead to what should be a lightweight almost semantics-free annotation. We can argue this on the basis of principle all we like, but the above practical issue that the current model presents will not go away. In our experience, the issue can be quite serious and impedes usability. Therefore, I am asking that we set aside our theological hats and respond in a pragmatic way to a pragmatic concern. Thanks, Bran "Karl Frank" 07/28/2004 04:59 PM To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject Another pair of resolutions for Ballot 21 One of these is classified as shared with Infra, but I find there is no problem with the Infra, the fix is local to the superstructure spec. Please see attached. - Karl[attachment "Issues_6630_7355.doc" deleted by Branislav Selic/Ottawa/IBM] To: "Pete Rivett" Cc: "Karl Frank" , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Issue 6630 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 28 Jul 2004 21:42:09 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/28/2004 21:42:13, Serialize complete at 07/28/2004 21:42:13 I think I see your point, Pete. However, doesn't your solution imply that this would be the one case in the entire UML 2.0 metamodel where the navigability and ownership are separated? If so, that would lead to a bunch of implementation issues -- all of them with solutions, but none of them pretty. I would prefer not to have such an exception just for this one case. The point is that the metamodel (and our implementation) were designed from the OO viewpoint and not the database viewpoint. Or did I miss your point after all? Bran "Pete Rivett" 07/28/2004 08:46 PM To Branislav Selic/Ottawa/IBM@IBMCA, "Karl Frank" cc , Subject RE: Issue 6630 Sorry if I appear to be repeating myself but this is again based on the original UML2 notion of navigation, and not Conrad's resolution which AFAIK is designed specifically to allow the specification of this sort of navigation without requiring state in the Supplier. As you said yourself, Bran, earlier on this thread, there is nothing to stop tools having their own navigation framework or index structure or lookup table to implement the navigation (and in any case 'navigable' is only advisory). There is certainly no requirement to have anything as part of the state of the supplier object (if there were it would be an ownedMember of the Supplier) or even anything (such as a back link) writeable in the storage/extent of the Supplier. For example one could implement the association with 2-way navigation by having a 2-column association table (or in-memory equivalent) listing linked ids of client and supplier objects. This is very pragmatic indeed: it's been in our MOF product for at least the past 4 years. Cheers Pete 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: Wednesday, July 28, 2004 10:57 PM To: Karl Frank Cc: mu2i-ftf@omg.org; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: Issue 6630 Regarding issue 6630: Kenn Hussey, who is the originator of this issue and the main implementor of the UML 2 Open Source Eclipse project explained to me why this needs to be fixed The problem with leaving NamedElement::supplierDependency navigable is a practical one (uncovered through direct experience) and can be quite serious even though it looks innocuous. Namely, it is often the case in practice that this type of dependency is drawn to an external entity such as another model or elements that belong to another model. For example, we might want to say with the dependency that one model is requirements model for the other, or that one is a more refined version of the other. These are not necessarily formalized dependencies and are often meant to capture some vague notion. After all, dependency was intended to be used in a variety of domain- and application-specific ways, which is why it has hardly any semantics. However, it may happen that the external entity may be write-protected or inaccessible. Even if it is accessible and writeable, drawing a dependency to this element requires that the external entity be opened up so that the back link to the client can be written into it. Depending on the size of that entity, this could add lots of overhead to what should be a lightweight almost semantics-free annotation. We can argue this on the basis of principle all we like, but the above practical issue that the current model presents will not go away. In our experience, the issue can be quite serious and impedes usability. Therefore, I am asking that we set aside our theological hats and respond in a pragmatic way to a pragmatic concern. Thanks, Bran "Karl Frank" 07/28/2004 04:59 PM To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject Another pair of resolutions for Ballot 21 One of these is classified as shared with Infra, but I find there is no problem with the Infra, the fix is local to the superstructure spec. Please see attached. - Karl[attachment "Issues_6630_7355.doc" deleted by Branislav Selic/Ottawa/IBM] Subject: RE: Issue 6630 Date: Wed, 28 Jul 2004 18:54:16 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 6630 Thread-Index: AcR07dtokZ9lA/PFSnmwbPlPQR+0dQACWfIwAAV9shA= From: "Karl Frank" To: "Pidcock, Woody" , "Branislav Selic" Cc: , , X-OriginalArrivalTime: 29 Jul 2004 01:54:24.0942 (UTC) FILETIME=[F98484E0:01C4750E] I understand perfectly well why supplier Dependency being navigable would be a terrible problem if it were the case. I too have done some analysis and design in my day. Apparently noone on this thread read my discussion, you just read te final line "No change". You cannot leave it navigable if it isn't navigable to begin with. The spec does not say that it is navigable, that is why it doesn't need to be changed. If it does say NamedElement::SupplierDependency is navigable, it is doing so in invisible writing, or at least invisible to me. That is why, on the conference call today I asked whether the ' + ' visibility on the rolename was a secret way of indicating navigability, Everyone agreed it was not. Please explain with reference to the metamodel and the spec where it says that NamedElement::supplierDependency is navigable. - Karl -------------------------------------------------------------------------------- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Wednesday, 28 July, 2004 7:14 PM To: Branislav Selic; Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: RE: Issue 6630 I agree there is a need to represent dependency on an external entity without changing that external entity. This was a known issue back in the PCTE days. UML needs to support navigation from a dependency association to an external entity without modifying the definition (properties, attributes, etc.) of the external entity. I am not sure if this needs to be supported in the graphical notation, but will not object if such a graphical notation is proposed and adopted. The user decision to introduce this dependency association without modifying the external entity (e.g., no need for reverse navigation from the external entity) needs to be query-able by others reviewing the model--so including it in the graphical notation rather than in a separate report is acceptable. -Woody -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, July 28, 2004 2:57 PM To: Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: Issue 6630 Regarding issue 6630: Kenn Hussey, who is the originator of this issue and the main implementor of the UML 2 Open Source Eclipse project explained to me why this needs to be fixed The problem with leaving NamedElement::supplierDependency navigable is a practical one (uncovered through direct experience) and can be quite serious even though it looks innocuous. Namely, it is often the case in practice that this type of dependency is drawn to an external entity such as another model or elements that belong to another model. For example, we might want to say with the dependency that one model is requirements model for the other, or that one is a more refined version of the other. These are not necessarily formalized dependencies and are often meant to capture some vague notion. After all, dependency was intended to be used in a variety of domain- and application-specific ways, which is why it has hardly any semantics. However, it may happen that the external entity may be write-protected or inaccessible. Even if it is accessible and writeable, drawing a dependency to this element requires that the external entity be opened up so that the back link to the client can be written into it. Depending on the size of that entity, this could add lots of overhead to what should be a lightweight almost semantics-free annotation. We can argue this on the basis of principle all we like, but the above practical issue that the current model presents will not go away. In our experience, the issue can be quite serious and impedes usability. Therefore, I am asking that we set aside our theological hats and respond in a pragmatic way to a pragmatic concern. Thanks, Bran "Karl Frank" 07/28/2004 04:59 PM To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject Another pair of resolutions for Ballot 21 One of these is classified as shared with Infra, but I find there is no problem with the Infra, the fix is local to the superstructure spec. Please see attached. - Karl[attachment "Issues_6630_7355.doc" deleted by Branislav Selic/Ottawa/IBM] From: "Thomas Weigert" To: "Karl Frank" , "Pidcock, Woody" , "Branislav Selic" Cc: , , Subject: RE: Issue 6630 Date: Wed, 28 Jul 2004 21:38:44 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Karl, I am looking at p.106 of the FAS (Figure 51), and it shows that NamedElement.supplierDependency is navigable (remember that if you do not show an arrow, then the metaassociation is bidirectionally navigable by our conventions; personally, I never understood why these were adopted, but...). Also, in your resolution you make a point about non-binnary associations. Note that the metaassociation between NavigableElement and Dependency is a binary association, the multiplicities notwithstanding. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Wednesday, July 28, 2004 8:54 PM To: Pidcock, Woody; Branislav Selic Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: RE: Issue 6630 I understand perfectly well why supplier Dependency being navigable would be a terrible problem if it were the case. I too have done some analysis and design in my day. Apparently noone on this thread read my discussion, you just read te final line "No change". You cannot leave it navigable if it isn't navigable to begin with. The spec does not say that it is navigable, that is why it doesn't need to be changed. If it does say NamedElement::SupplierDependency is navigable, it is doing so in invisible writing, or at least invisible to me. That is why, on the conference call today I asked whether the ' + ' visibility on the rolename was a secret way of indicating navigability, Everyone agreed it was not. Please explain with reference to the metamodel and the spec where it says that NamedElement::supplierDependency is navigable. - Karl -------------------------------------------------------------------------------- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Wednesday, 28 July, 2004 7:14 PM To: Branislav Selic; Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: RE: Issue 6630 I agree there is a need to represent dependency on an external entity without changing that external entity. This was a known issue back in the PCTE days. UML needs to support navigation from a dependency association to an external entity without modifying the definition (properties, attributes, etc.) of the external entity. I am not sure if this needs to be supported in the graphical notation, but will not object if such a graphical notation is proposed and adopted. The user decision to introduce this dependency association without modifying the external entity (e.g., no need for reverse navigation from the external entity) needs to be query-able by others reviewing the model--so including it in the graphical notation rather than in a separate report is acceptable. -Woody -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, July 28, 2004 2:57 PM To: Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: Issue 6630 Regarding issue 6630: Kenn Hussey, who is the originator of this issue and the main implementor of the UML 2 Open Source Eclipse project explained to me why this needs to be fixed The problem with leaving NamedElement::supplierDependency navigable is a practical one (uncovered through direct experience) and can be quite serious even though it looks innocuous. Namely, it is often the case in practice that this type of dependency is drawn to an external entity such as another model or elements that belong to another model. For example, we might want to say with the dependency that one model is requirements model for the other, or that one is a more refined version of the other. These are not necessarily formalized dependencies and are often meant to capture some vague notion. After all, dependency was intended to be used in a variety of domain- and application-specific ways, which is why it has hardly any semantics. However, it may happen that the external entity may be write-protected or inaccessible. Even if it is accessible and writeable, drawing a dependency to this element requires that the external entity be opened up so that the back link to the client can be written into it. Depending on the size of that entity, this could add lots of overhead to what should be a lightweight almost semantics-free annotation. We can argue this on the basis of principle all we like, but the above practical issue that the current model presents will not go away. In our experience, the issue can be quite serious and impedes usability. Therefore, I am asking that we set aside our theological hats and respond in a pragmatic way to a pragmatic concern. Thanks, Bran "Karl Frank" 07/28/2004 04:59 PM To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject Another pair of resolutions for Ballot 21 One of these is classified as shared with Infra, but I find there is no problem with the Infra, the fix is local to the superstructure spec. Please see attached. - Karl[attachment "Issues_6630_7355.doc" deleted by Branislav Selic/Ottawa/IBM] To: "Karl Frank" Cc: mu2i-ftf@omg.org, Pete.Rivett@adaptive.com, uml2-superstructure-ftf@omg.org, "Pidcock, Woody" Subject: RE: Issue 6630 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 29 Jul 2004 08:08:14 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/29/2004 08:08:15, Serialize complete at 07/29/2004 08:08:15 I read that part, Karl. However, if you saw the minutes, the convention that I think we agreed on yesterday was that an association with no arrow ends defaults to navigable. It has nothing to do with the visibility of the association end. Cheers, Bran "Karl Frank" 07/28/2004 09:54 PM To "Pidcock, Woody" , Branislav Selic/Ottawa/IBM@IBMCA cc , , Subject RE: Issue 6630 I understand perfectly well why supplier Dependency being navigable would be a terrible problem if it were the case. I too have done some analysis and design in my day. Apparently noone on this thread read my discussion, you just read te final line "No change". You cannot leave it navigable if it isn't navigable to begin with. The spec does not say that it is navigable, that is why it doesn't need to be changed. If it does say NamedElement::SupplierDependency is navigable, it is doing so in invisible writing, or at least invisible to me. That is why, on the conference call today I asked whether the ' + ' visibility on the rolename was a secret way of indicating navigability, Everyone agreed it was not. Please explain with reference to the metamodel and the spec where it says that NamedElement::supplierDependency is navigable. - Karl -------------------------------------------------------------------------------- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Wednesday, 28 July, 2004 7:14 PM To: Branislav Selic; Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: RE: Issue 6630 I agree there is a need to represent dependency on an external entity without changing that external entity. This was a known issue back in the PCTE days. UML needs to support navigation from a dependency association to an external entity without modifying the definition (properties, attributes, etc.) of the external entity. I am not sure if this needs to be supported in the graphical notation, but will not object if such a graphical notation is proposed and adopted. The user decision to introduce this dependency association without modifying the external entity (e.g., no need for reverse navigation from the external entity) needs to be query-able by others reviewing the model--so including it in the graphical notation rather than in a separate report is acceptable. -Woody -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, July 28, 2004 2:57 PM To: Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: Issue 6630 Regarding issue 6630: Kenn Hussey, who is the originator of this issue and the main implementor of the UML 2 Open Source Eclipse project explained to me why this needs to be fixed The problem with leaving NamedElement::supplierDependency navigable is a practical one (uncovered through direct experience) and can be quite serious even though it looks innocuous. Namely, it is often the case in practice that this type of dependency is drawn to an external entity such as another model or elements that belong to another model. For example, we might want to say with the dependency that one model is requirements model for the other, or that one is a more refined version of the other. These are not necessarily formalized dependencies and are often meant to capture some vague notion. After all, dependency was intended to be used in a variety of domain- and application-specific ways, which is why it has hardly any semantics. However, it may happen that the external entity may be write-protected or inaccessible. Even if it is accessible and writeable, drawing a dependency to this element requires that the external entity be opened up so that the back link to the client can be written into it. Depending on the size of that entity, this could add lots of overhead to what should be a lightweight almost semantics-free annotation. We can argue this on the basis of principle all we like, but the above practical issue that the current model presents will not go away. In our experience, the issue can be quite serious and impedes usability. Therefore, I am asking that we set aside our theological hats and respond in a pragmatic way to a pragmatic concern. Thanks, Bran "Karl Frank" 07/28/2004 04:59 PM To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject Another pair of resolutions for Ballot 21 One of these is classified as shared with Infra, but I find there is no problem with the Infra, the fix is local to the superstructure spec. Please see attached. - Karl[attachment "Issues_6630_7355.doc" deleted by Branislav Selic/Ottawa/IBM] Reply-To: From: "Desfray" To: "'Branislav Selic'" , "'Pidcock, Woody'" Cc: , "'Karl Frank'" , , "'Pete Rivett'" , Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Date: Thu, 29 Jul 2004 10:34:14 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-Virus-Scanned: by amavisd-new at softeam.com I know Bran, but the problem is coming again. I do regret not to have intervene regarding this issue. It is voted and passed, let it be ... But adding notations for the ownership rules is another matter, that I do not support. ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 28 juillet 2004 20:03 À : Pidcock, Woody Cc : conrad.bock@nist.gov; Karl Frank; mu2i-ftf@omg.org; Pete Rivett; Philippe.Desfray@softeam.fr; uml2-superstructure-ftf@omg.org Objet : RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Philippe and Woody, I don't mean to single the two of you out, but the right time to have expressed these reservations would have been when issue 6243 was discussed and also, when it was voted on (Ballot 17 -- a month ago). Regards, Bran "Pidcock, Woody" 07/28/2004 01:19 PM To , Branislav Selic/Ottawa/IBM@IBMCA, "Pete Rivett" cc , "Karl Frank" , , Subject RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel I agree with Philippe. -----Original Message----- From: Desfray [mailto:Philippe.Desfray@softeam.fr] Sent: Wednesday, July 28, 2004 8:04 AM To: 'Branislav Selic'; 'Pete Rivett' Cc: conrad.bock@nist.gov; 'Karl Frank'; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel I just feel very bad about that and all this navigability discussion. It seems that there is a dangerous mix between the semantics of navigability, from the end user's eyes, and the ownership rules, from the meta-implementer's eyes. Adding notations to indicate ownership rules is pure pollution in a logical model. I would just claim that we should keep close to the end user's semantics (from UML1.4), and explain somewhere that from the metamodel implementation perspective, navigability has an ownership implication. ==================================== Philippe -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 28 juillet 2004 16:24 À : Pete Rivett Cc : conrad.bock@nist.gov; Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Here is what I was thinking of: Bran ATT00006.gif Subject: RE: Issue 6630 Date: Thu, 29 Jul 2004 08:45:07 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 6630 Thread-Index: AcR1ZMCuKrCzwrR5RXKqi9xaEeYWwwAGjQMQ From: "Karl Frank" To: "Branislav Selic" Cc: , , , "Pidcock, Woody" X-OriginalArrivalTime: 29 Jul 2004 15:45:16.0582 (UTC) FILETIME=[0B691C60:01C47583] OK, so your view is the syntax diagram implies the dependency is navigable from the independent element(s) by means of invisiblie arrowheads. The absence of navigation arrowheads is to be read (in the FAS) as equivalent to their presence. If we are all agreed to that, the resolution to 6630 is to X-out the ends of certain lines in Figure 15, the Dependencies package diagram. This raises the spectre of other invisible navigability arrowheads causing trouble down the line. In reading of the spec to date, our reviewers have not always been assuming navigability where none was explcitly stated, and so there may have been many "secret" navigability problems our issue reports have overlooked which will come up when this new default rule is generally understood. .- Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, 29 July, 2004 8:08 AM To: Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org; Pidcock, Woody Subject: RE: Issue 6630 I read that part, Karl. However, if you saw the minutes, the convention that I think we agreed on yesterday was that an association with no arrow ends defaults to navigable. It has nothing to do with the visibility of the association end. Cheers, Bran "Karl Frank" 07/28/2004 09:54 PM To "Pidcock, Woody" , Branislav Selic/Ottawa/IBM@IBMCA cc , , Subject RE: Issue 6630 I understand perfectly well why supplier Dependency being navigable would be a terrible problem if it were the case. I too have done some analysis and design in my day. Apparently noone on this thread read my discussion, you just read te final line "No change". You cannot leave it navigable if it isn't navigable to begin with. The spec does not say that it is navigable, that is why it doesn't need to be changed. If it does say NamedElement::SupplierDependency is navigable, it is doing so in invisible writing, or at least invisible to me. That is why, on the conference call today I asked whether the ' + ' visibility on the rolename was a secret way of indicating navigability, Everyone agreed it was not. Please explain with reference to the metamodel and the spec where it says that NamedElement::supplierDependency is navigable. - Karl -------------------------------------------------------------------------------- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Wednesday, 28 July, 2004 7:14 PM To: Branislav Selic; Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: RE: Issue 6630 I agree there is a need to represent dependency on an external entity without changing that external entity. This was a known issue back in the PCTE days. UML needs to support navigation from a dependency association to an external entity without modifying the definition (properties, attributes, etc.) of the external entity. I am not sure if this needs to be supported in the graphical notation, but will not object if such a graphical notation is proposed and adopted. The user decision to introduce this dependency association without modifying the external entity (e.g., no need for reverse navigation from the external entity) needs to be query-able by others reviewing the model--so including it in the graphical notation rather than in a separate report is acceptable. -Woody -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, July 28, 2004 2:57 PM To: Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: Issue 6630 Regarding issue 6630: Kenn Hussey, who is the originator of this issue and the main implementor of the UML 2 Open Source Eclipse project explained to me why this needs to be fixed The problem with leaving NamedElement::supplierDependency navigable is a practical one (uncovered through direct experience) and can be quite serious even though it looks innocuous. Namely, it is often the case in practice that this type of dependency is drawn to an external entity such as another model or elements that belong to another model. For example, we might want to say with the dependency that one model is requirements model for the other, or that one is a more refined version of the other. These are not necessarily formalized dependencies and are often meant to capture some vague notion. After all, dependency was intended to be used in a variety of domain- and application-specific ways, which is why it has hardly any semantics. However, it may happen that the external entity may be write-protected or inaccessible. Even if it is accessible and writeable, drawing a dependency to this element requires that the external entity be opened up so that the back link to the client can be written into it. Depending on the size of that entity, this could add lots of overhead to what should be a lightweight almost semantics-free annotation. We can argue this on the basis of principle all we like, but the above practical issue that the current model presents will not go away. In our experience, the issue can be quite serious and impedes usability. Therefore, I am asking that we set aside our theological hats and respond in a pragmatic way to a pragmatic concern. Thanks, Bran "Karl Frank" 07/28/2004 04:59 PM To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject Another pair of resolutions for Ballot 21 One of these is classified as shared with Infra, but I find there is no problem with the Infra, the fix is local to the superstructure spec. Please see attached. - Karl[attachment "Issues_6630_7355.doc" deleted by Branislav Selic/Ottawa/IBM] To: "Karl Frank" Cc: mu2i-ftf@omg.org, Pete.Rivett@adaptive.com, uml2-superstructure-ftf@omg.org, "Pidcock, Woody" Subject: RE: Issue 6630 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 29 Jul 2004 12:10:02 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/29/2004 12:10:03, Serialize complete at 07/29/2004 12:10:03 Karl, One of the things we discussed yesterday was that we would document the diagramming conventions used in the spec. This will inform readers what to expect and how to read the diagrams. As a reminder, here are the conventions that will be used throughout the spec and will be fully documented are: (1) An association with one arrow is to be interpreted as meaning that the arrow end is owned by the classifier at the opposite end and that the association is navigable from that classifier. The opposite association end will be non-navigable and owned by the association (i.e., implicit black dot and X notations). (2) An association with no navigability arrows is to be interpreted as having both ends navigable with each end owned by the classifier at the opposite end. These conventions basically embody the assumptions that were in place prior to the separation of association end ownership and navigability. Note that with these conventions in place, there is no need to use the "X" in the spec (or, for that matter, the black dot). If we were to use this notation, it will cause a problem, albeit a termporary one. At the moment, we use Rose for the metamodel and Rose knows nothing about X's on association ends. Therefore, the XMI that would come out would not include the information on the X's unless we use some other trick. The trick, of course, are the conventions described above, which will be built into the XMI generator as discussed yesterday. Once we decouple the spec from Rose (as we should and must), this will no longer be an issue. But, in the short term, we must do what we have to. Cheers, Bran "Karl Frank" 07/29/2004 11:45 AM To Branislav Selic/Ottawa/IBM@IBMCA cc , , , "Pidcock, Woody" Subject RE: Issue 6630 OK, so your view is the syntax diagram implies the dependency is navigable from the independent element(s) by means of invisiblie arrowheads. The absence of navigation arrowheads is to be read (in the FAS) as equivalent to their presence. If we are all agreed to that, the resolution to 6630 is to X-out the ends of certain lines in Figure 15, the Dependencies package diagram. This raises the spectre of other invisible navigability arrowheads causing trouble down the line. In reading of the spec to date, our reviewers have not always been assuming navigability where none was explcitly stated, and so there may have been many "secret" navigability problems our issue reports have overlooked which will come up when this new default rule is generally understood. .- Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, 29 July, 2004 8:08 AM To: Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org; Pidcock, Woody Subject: RE: Issue 6630 I read that part, Karl. However, if you saw the minutes, the convention that I think we agreed on yesterday was that an association with no arrow ends defaults to navigable. It has nothing to do with the visibility of the association end. Cheers, Bran "Karl Frank" 07/28/2004 09:54 PM To "Pidcock, Woody" , Branislav Selic/Ottawa/IBM@IBMCA cc , , Subject RE: Issue 6630 I understand perfectly well why supplier Dependency being navigable would be a terrible problem if it were the case. I too have done some analysis and design in my day. Apparently noone on this thread read my discussion, you just read te final line "No change". You cannot leave it navigable if it isn't navigable to begin with. The spec does not say that it is navigable, that is why it doesn't need to be changed. If it does say NamedElement::SupplierDependency is navigable, it is doing so in invisible writing, or at least invisible to me. That is why, on the conference call today I asked whether the ' + ' visibility on the rolename was a secret way of indicating navigability, Everyone agreed it was not. Please explain with reference to the metamodel and the spec where it says that NamedElement::supplierDependency is navigable. - Karl -------------------------------------------------------------------------------- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Wednesday, 28 July, 2004 7:14 PM To: Branislav Selic; Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: RE: Issue 6630 I agree there is a need to represent dependency on an external entity without changing that external entity. This was a known issue back in the PCTE days. UML needs to support navigation from a dependency association to an external entity without modifying the definition (properties, attributes, etc.) of the external entity. I am not sure if this needs to be supported in the graphical notation, but will not object if such a graphical notation is proposed and adopted. The user decision to introduce this dependency association without modifying the external entity (e.g., no need for reverse navigation from the external entity) needs to be query-able by others reviewing the model--so including it in the graphical notation rather than in a separate report is acceptable. -Woody -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, July 28, 2004 2:57 PM To: Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: Issue 6630 Regarding issue 6630: Kenn Hussey, who is the originator of this issue and the main implementor of the UML 2 Open Source Eclipse project explained to me why this needs to be fixed The problem with leaving NamedElement::supplierDependency navigable is a practical one (uncovered through direct experience) and can be quite serious even though it looks innocuous. Namely, it is often the case in practice that this type of dependency is drawn to an external entity such as another model or elements that belong to another model. For example, we might want to say with the dependency that one model is requirements model for the other, or that one is a more refined version of the other. These are not necessarily formalized dependencies and are often meant to capture some vague notion. After all, dependency was intended to be used in a variety of domain- and application-specific ways, which is why it has hardly any semantics. However, it may happen that the external entity may be write-protected or inaccessible. Even if it is accessible and writeable, drawing a dependency to this element requires that the external entity be opened up so that the back link to the client can be written into it. Depending on the size of that entity, this could add lots of overhead to what should be a lightweight almost semantics-free annotation. We can argue this on the basis of principle all we like, but the above practical issue that the current model presents will not go away. In our experience, the issue can be quite serious and impedes usability. Therefore, I am asking that we set aside our theological hats and respond in a pragmatic way to a pragmatic concern. Thanks, Bran "Karl Frank" 07/28/2004 04:59 PM To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject Another pair of resolutions for Ballot 21 One of these is classified as shared with Infra, but I find there is no problem with the Infra, the fix is local to the superstructure spec. Please see attached. - Karl[attachment "Issues_6630_7355.doc" deleted by Branislav Selic/Ottawa/IBM] Subject: RE: Issue 6630 Date: Thu, 29 Jul 2004 13:59:11 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 6630 Thread-Index: AcR1ZMCuKrCzwrR5RXKqi9xaEeYWwwAGjQMQAATu6CA= From: "Pete Rivett" To: "Karl Frank" , "Branislav Selic" Cc: , , "Pidcock, Woody" X-Virus-Scanned: by amavisd-new at sentraliant.com IMHO the issue here is not really navigability as newly defined (which as I keep on saying is only advisory anyway) but whether there is a property on the Supplier class that would need to be updated when a new client dependency is added. I think we all agree that is undesirable. So we have 2 choices for the supplier-supplierDependency association: a) make that direction not navigable and not owned by the NamedElement in the supplier role. The arrow notation, with an arrow on the line right next to the word 'supplier', together with our default behavior agreed on the call yesterday, is adequate for this. An additional X at the other end, as Karl suggests, is not wrong though redundant and inconsistent with other diagrams b) make that direction navigable and again not owned by the NamedElement in the supplier role. In this case we need to use Bran's new notation and have a 'dot' right next to the word 'supplier' to show the end, while being navigable, is owned by the Association not the NamedElement. For the client-clientDependency association I assume there is no problem with having both ends navigable and properties of the respective classes so no change is needed: the unadorned line gives us what we need. Where else did you propose to place an X Karl? 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: Thursday, July 29, 2004 4:45 PM To: Branislav Selic Cc: mu2i-ftf@omg.org; Pete Rivett; uml2-superstructure-ftf@omg.org; Pidcock, Woody Subject: RE: Issue 6630 OK, so your view is the syntax diagram implies the dependency is navigable from the independent element(s) by means of invisiblie arrowheads. The absence of navigation arrowheads is to be read (in the FAS) as equivalent to their presence. If we are all agreed to that, the resolution to 6630 is to X-out the ends of certain lines in Figure 15, the Dependencies package diagram. This raises the spectre of other invisible navigability arrowheads causing trouble down the line. In reading of the spec to date, our reviewers have not always been assuming navigability where none was explcitly stated, and so there may have been many "secret" navigability problems our issue reports have overlooked which will come up when this new default rule is generally understood. .- Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, 29 July, 2004 8:08 AM To: Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org; Pidcock, Woody Subject: RE: Issue 6630 I read that part, Karl. However, if you saw the minutes, the convention that I think we agreed on yesterday was that an association with no arrow ends defaults to navigable. It has nothing to do with the visibility of the association end. Cheers, Bran "Karl Frank" 07/28/2004 09:54 PM To "Pidcock, Woody" , Branislav Selic/Ottawa/IBM@IBMCA cc , , Subject RE: Issue 6630 I understand perfectly well why supplier Dependency being navigable would be a terrible problem if it were the case. I too have done some analysis and design in my day. Apparently noone on this thread read my discussion, you just read te final line "No change". You cannot leave it navigable if it isn't navigable to begin with. The spec does not say that it is navigable, that is why it doesn't need to be changed. If it does say NamedElement::SupplierDependency is navigable, it is doing so in invisible writing, or at least invisible to me. That is why, on the conference call today I asked whether the ' + ' visibility on the rolename was a secret way of indicating navigability, Everyone agreed it was not. Please explain with reference to the metamodel and the spec where it says that NamedElement::supplierDependency is navigable. - Karl -------------------------------------------------------------------------------- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Wednesday, 28 July, 2004 7:14 PM To: Branislav Selic; Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: RE: Issue 6630 I agree there is a need to represent dependency on an external entity without changing that external entity. This was a known issue back in the PCTE days. UML needs to support navigation from a dependency association to an external entity without modifying the definition (properties, attributes, etc.) of the external entity. I am not sure if this needs to be supported in the graphical notation, but will not object if such a graphical notation is proposed and adopted. The user decision to introduce this dependency association without modifying the external entity (e.g., no need for reverse navigation from the external entity) needs to be query-able by others reviewing the model--so including it in the graphical notation rather than in a separate report is acceptable. -Woody -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, July 28, 2004 2:57 PM To: Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: Issue 6630 Regarding issue 6630: Kenn Hussey, who is the originator of this issue and the main implementor of the UML 2 Open Source Eclipse project explained to me why this needs to be fixed The problem with leaving NamedElement::supplierDependency navigable is a practical one (uncovered through direct experience) and can be quite serious even though it looks innocuous. Namely, it is often the case in practice that this type of dependency is drawn to an external entity such as another model or elements that belong to another model. For example, we might want to say with the dependency that one model is requirements model for the other, or that one is a more refined version of the other. These are not necessarily formalized dependencies and are often meant to capture some vague notion. After all, dependency was intended to be used in a variety of domain- and application-specific ways, which is why it has hardly any semantics. However, it may happen that the external entity may be write-protected or inaccessible. Even if it is accessible and writeable, drawing a dependency to this element requires that the external entity be opened up so that the back link to the client can be written into it. Depending on the size of that entity, this could add lots of overhead to what should be a lightweight almost semantics-free annotation. We can argue this on the basis of principle all we like, but the above practical issue that the current model presents will not go away. In our experience, the issue can be quite serious and impedes usability. Therefore, I am asking that we set aside our theological hats and respond in a pragmatic way to a pragmatic concern. Thanks, Bran "Karl Frank" 07/28/2004 04:59 PM To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject Another pair of resolutions for Ballot 21 One of these is classified as shared with Infra, but I find there is no problem with the Infra, the fix is local to the superstructure spec. Please see attached. - Karl[attachment "Issues_6630_7355.doc" deleted by Branislav Selic/Ottawa/IBM] Subject: RE: Issue 6630 Date: Thu, 29 Jul 2004 11:53:21 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 6630 Thread-Index: AcR1ZMCuKrCzwrR5RXKqi9xaEeYWwwAGjQMQAATu6CAAAl888A== From: "Karl Frank" To: "Pete Rivett" , "Branislav Selic" Cc: , , "Pidcock, Woody" X-OriginalArrivalTime: 29 Jul 2004 18:53:31.0390 (UTC) FILETIME=[57A409E0:01C4759D] Thanks Pete, you are really adding value to this discussion. Which is to say I find your HO helpful here, and it causes me to change my opinion, the best solution is NOT to X-out anything, but apply the dot as in your option (b). (B) satisfies the original objection, ( that it is highly undesirable to modfiy the supplier to track changes in the set of its clients) and also allows an opening for tools to navigate dependency associations in any direction, as I would desire in answering traceability queries. I say we revise 6630 to incorporate (b) - Have fun, Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, 29 July, 2004 1:59 PM To: Karl Frank; Branislav Selic Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org; Pidcock, Woody Subject: RE: Issue 6630 IMHO the issue here is not really navigability as newly defined (which as I keep on saying is only advisory anyway) but whether there is a property on the Supplier class that would need to be updated when a new client dependency is added. I think we all agree that is undesirable. So we have 2 choices for the supplier-supplierDependency association: a) make that direction not navigable and not owned by the NamedElement in the supplier role. The arrow notation, with an arrow on the line right next to the word 'supplier', together with our default behavior agreed on the call yesterday, is adequate for this. An additional X at the other end, as Karl suggests, is not wrong though redundant and inconsistent with other diagrams b) make that direction navigable and again not owned by the NamedElement in the supplier role. In this case we need to use Bran's new notation and have a 'dot' right next to the word 'supplier' to show the end, while being navigable, is owned by the Association not the NamedElement. For the client-clientDependency association I assume there is no problem with having both ends navigable and properties of the respective classes so no change is needed: the unadorned line gives us what we need. Where else did you propose to place an X Karl? 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: Thursday, July 29, 2004 4:45 PM To: Branislav Selic Cc: mu2i-ftf@omg.org; Pete Rivett; uml2-superstructure-ftf@omg.org; Pidcock, Woody Subject: RE: Issue 6630 OK, so your view is the syntax diagram implies the dependency is navigable from the independent element(s) by means of invisiblie arrowheads. The absence of navigation arrowheads is to be read (in the FAS) as equivalent to their presence. If we are all agreed to that, the resolution to 6630 is to X-out the ends of certain lines in Figure 15, the Dependencies package diagram. This raises the spectre of other invisible navigability arrowheads causing trouble down the line. In reading of the spec to date, our reviewers have not always been assuming navigability where none was explcitly stated, and so there may have been many "secret" navigability problems our issue reports have overlooked which will come up when this new default rule is generally understood. .- Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, 29 July, 2004 8:08 AM To: Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org; Pidcock, Woody Subject: RE: Issue 6630 I read that part, Karl. However, if you saw the minutes, the convention that I think we agreed on yesterday was that an association with no arrow ends defaults to navigable. It has nothing to do with the visibility of the association end. Cheers, Bran "Karl Frank" 07/28/2004 09:54 PM To "Pidcock, Woody" , Branislav Selic/Ottawa/IBM@IBMCA cc , , Subject RE: Issue 6630 I understand perfectly well why supplier Dependency being navigable would be a terrible problem if it were the case. I too have done some analysis and design in my day. Apparently noone on this thread read my discussion, you just read te final line "No change". You cannot leave it navigable if it isn't navigable to begin with. The spec does not say that it is navigable, that is why it doesn't need to be changed. If it does say NamedElement::SupplierDependency is navigable, it is doing so in invisible writing, or at least invisible to me. That is why, on the conference call today I asked whether the ' + ' visibility on the rolename was a secret way of indicating navigability, Everyone agreed it was not. Please explain with reference to the metamodel and the spec where it says that NamedElement::supplierDependency is navigable. - Karl -------------------------------------------------------------------------------- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Wednesday, 28 July, 2004 7:14 PM To: Branislav Selic; Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: RE: Issue 6630 I agree there is a need to represent dependency on an external entity without changing that external entity. This was a known issue back in the PCTE days. UML needs to support navigation from a dependency association to an external entity without modifying the definition (properties, attributes, etc.) of the external entity. I am not sure if this needs to be supported in the graphical notation, but will not object if such a graphical notation is proposed and adopted. The user decision to introduce this dependency association without modifying the external entity (e.g., no need for reverse navigation from the external entity) needs to be query-able by others reviewing the model--so including it in the graphical notation rather than in a separate report is acceptable. -Woody -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, July 28, 2004 2:57 PM To: Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: Issue 6630 Regarding issue 6630: Kenn Hussey, who is the originator of this issue and the main implementor of the UML 2 Open Source Eclipse project explained to me why this needs to be fixed The problem with leaving NamedElement::supplierDependency navigable is a practical one (uncovered through direct experience) and can be quite serious even though it looks innocuous. Namely, it is often the case in practice that this type of dependency is drawn to an external entity such as another model or elements that belong to another model. For example, we might want to say with the dependency that one model is requirements model for the other, or that one is a more refined version of the other. These are not necessarily formalized dependencies and are often meant to capture some vague notion. After all, dependency was intended to be used in a variety of domain- and application-specific ways, which is why it has hardly any semantics. However, it may happen that the external entity may be write-protected or inaccessible. Even if it is accessible and writeable, drawing a dependency to this element requires that the external entity be opened up so that the back link to the client can be written into it. Depending on the size of that entity, this could add lots of overhead to what should be a lightweight almost semantics-free annotation. We can argue this on the basis of principle all we like, but the above practical issue that the current model presents will not go away. In our experience, the issue can be quite serious and impedes usability. Therefore, I am asking that we set aside our theological hats and respond in a pragmatic way to a pragmatic concern. Thanks, Bran "Karl Frank" 07/28/2004 04:59 PM To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject Another pair of resolutions for Ballot 21 One of these is classified as shared with Infra, but I find there is no problem with the Infra, the fix is local to the superstructure spec. Please see attached. - Karl[attachment "Issues_6630_7355.doc" deleted by Branislav Selic/Ottawa/IBM] From: "Thomas Weigert" To: "Karl Frank" , "Branislav Selic" Cc: , , , "Pidcock, Woody" Subject: RE: Issue 6630 Date: Thu, 29 Jul 2004 14:38:18 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) This is not a new agreement, but the way it always has been. Bidirectional associations have no arrows... I don't like it because I think it is confusing, but for whatever it is worth this is the rules we have followed. And yes, the XMI has this as well. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, July 29, 2004 10:45 AM To: Branislav Selic Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org; Pidcock, Woody Subject: RE: Issue 6630 OK, so your view is the syntax diagram implies the dependency is navigable from the independent element(s) by means of invisiblie arrowheads. The absence of navigation arrowheads is to be read (in the FAS) as equivalent to their presence. If we are all agreed to that, the resolution to 6630 is to X-out the ends of certain lines in Figure 15, the Dependencies package diagram. This raises the spectre of other invisible navigability arrowheads causing trouble down the line. In reading of the spec to date, our reviewers have not always been assuming navigability where none was explcitly stated, and so there may have been many "secret" navigability problems our issue reports have overlooked which will come up when this new default rule is generally understood. .- Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, 29 July, 2004 8:08 AM To: Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org; Pidcock, Woody Subject: RE: Issue 6630 I read that part, Karl. However, if you saw the minutes, the convention that I think we agreed on yesterday was that an association with no arrow ends defaults to navigable. It has nothing to do with the visibility of the association end. Cheers, Bran "Karl Frank" 07/28/2004 09:54 PM To "Pidcock, Woody" , Branislav Selic/Ottawa/IBM@IBMCA cc , , Subject RE: Issue 6630 I understand perfectly well why supplier Dependency being navigable would be a terrible problem if it were the case. I too have done some analysis and design in my day. Apparently noone on this thread read my discussion, you just read te final line "No change". You cannot leave it navigable if it isn't navigable to begin with. The spec does not say that it is navigable, that is why it doesn't need to be changed. If it does say NamedElement::SupplierDependency is navigable, it is doing so in invisible writing, or at least invisible to me. That is why, on the conference call today I asked whether the ' + ' visibility on the rolename was a secret way of indicating navigability, Everyone agreed it was not. Please explain with reference to the metamodel and the spec where it says that NamedElement::supplierDependency is navigable. - Karl -------------------------------------------------------------------------------- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Wednesday, 28 July, 2004 7:14 PM To: Branislav Selic; Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: RE: Issue 6630 I agree there is a need to represent dependency on an external entity without changing that external entity. This was a known issue back in the PCTE days. UML needs to support navigation from a dependency association to an external entity without modifying the definition (properties, attributes, etc.) of the external entity. I am not sure if this needs to be supported in the graphical notation, but will not object if such a graphical notation is proposed and adopted. The user decision to introduce this dependency association without modifying the external entity (e.g., no need for reverse navigation from the external entity) needs to be query-able by others reviewing the model--so including it in the graphical notation rather than in a separate report is acceptable. -Woody -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, July 28, 2004 2:57 PM To: Karl Frank Cc: mu2i-ftf@omg.org; Pete.Rivett@adaptive.com; uml2-superstructure-ftf@omg.org Subject: Issue 6630 Regarding issue 6630: Kenn Hussey, who is the originator of this issue and the main implementor of the UML 2 Open Source Eclipse project explained to me why this needs to be fixed The problem with leaving NamedElement::supplierDependency navigable is a practical one (uncovered through direct experience) and can be quite serious even though it looks innocuous. Namely, it is often the case in practice that this type of dependency is drawn to an external entity such as another model or elements that belong to another model. For example, we might want to say with the dependency that one model is requirements model for the other, or that one is a more refined version of the other. These are not necessarily formalized dependencies and are often meant to capture some vague notion. After all, dependency was intended to be used in a variety of domain- and application-specific ways, which is why it has hardly any semantics. However, it may happen that the external entity may be write-protected or inaccessible. Even if it is accessible and writeable, drawing a dependency to this element requires that the external entity be opened up so that the back link to the client can be written into it. Depending on the size of that entity, this could add lots of overhead to what should be a lightweight almost semantics-free annotation. We can argue this on the basis of principle all we like, but the above practical issue that the current model presents will not go away. In our experience, the issue can be quite serious and impedes usability. Therefore, I am asking that we set aside our theological hats and respond in a pragmatic way to a pragmatic concern. Thanks, Bran "Karl Frank" 07/28/2004 04:59 PM To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject Another pair of resolutions for Ballot 21 One of these is classified as shared with Infra, but I find there is no problem with the Infra, the fix is local to the superstructure spec. Please see attached. - Karl[attachment "Issues_6630_7355.doc" deleted by Branislav Selic/Ottawa/IBM] Reply-To: From: "Conrad Bock" To: , Subject: RE: Issue 6630 Date: Thu, 29 Jul 2004 17:06:39 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Karl, et al, > Thanks Pete, you are really adding value to this discussion. > Which is to say I find your HO helpful here, and it causes me to > change my opinion, the best solution is NOT to X-out anything, > but apply the dot as in your option (b). > > (B) satisfies the original objection, ( that it is highly > undesirable to modfiy the supplier to track changes in the set > of its clients) and also allows an opening for tools to navigate > dependency associations in any direction, as I would desire in > answering traceability queries. If we applied this to the rest of the metamodel, we would also make the association between TypedElement and Type bidirectional, so it would be required that tools support finding the places that use a given Type. This would apply all over the metamodel to any "whereused situation". There are goo reasons not to force vendors to provide this information. It's a service they should choose to provide or not. Under our current conventions, it affects both ends unnecessarily (perhaps we should change the conventions). Another reason is that the navigation arrows in the metamodel also serve as to reflect conceptual definition. For example, there is nothing in the concept of Type that requires it be referenced by a typed element. I think it's fine to remove the navigation of NamedElement.supplierDependency. Conrad Subject: RE: Issue 6630 Date: Thu, 29 Jul 2004 14:27:22 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 6630 Thread-Index: AcR1r9gn8wRf6AhsSLWqO6a6H819bgAAktGQ From: "Karl Frank" To: , , X-OriginalArrivalTime: 29 Jul 2004 21:27:24.0959 (UTC) FILETIME=[D746DAF0:01C475B2] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i6TLcolj001830 Conrad, The disadvantage to which you call our attention is purely hypothetical. "If we applied this to the rest of the metamodel..." We do not propose applying it to anywhere except where we say, which right now is to the supplier end in relation to dependency. Noone is proposing to assign dots and reassign ownership of unadorned ends everywhere in the metamodel, and in particular noone is proposing a change wrt TypedElement and Type. So what's the problem? - Karl -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Thursday, July 29, 2004 5:07 PM To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Issue 6630 Karl, et al, > Thanks Pete, you are really adding value to this discussion. > Which is to say I find your HO helpful here, and it causes me to > change my opinion, the best solution is NOT to X-out anything, > but apply the dot as in your option (b). > > (B) satisfies the original objection, ( that it is highly > undesirable to modfiy the supplier to track changes in the set > of its clients) and also allows an opening for tools to navigate > dependency associations in any direction, as I would desire in > answering traceability queries. If we applied this to the rest of the metamodel, we would also make the association between TypedElement and Type bidirectional, so it would be required that tools support finding the places that use a given Type. This would apply all over the metamodel to any "whereused situation". There are goo reasons not to force vendors to provide this information. It's a service they should choose to provide or not. Under our current conventions, it affects both ends unnecessarily (perhaps we should change the conventions). Another reason is that the navigation arrows in the metamodel also serve as to reflect conceptual definition. For example, there is nothing in the concept of Type that requires it be referenced by a typed element. I think it's fine to remove the navigation of NamedElement.supplierDependency. Conrad Reply-To: From: "Conrad Bock" To: , Subject: RE: Issue 6630 Date: Thu, 29 Jul 2004 17:39:27 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) karl, > The disadvantage to which you call our attention is purely hypothetical. > "If we applied this to the rest of the metamodel..." We do not propose > applying it to anywhere except where we say, which right now is to the > supplier end in relation to dependency. That's not consistent. If you have a motivation to support where-used on suppliers, why not other metaassociations? Pick a design principle and follow it. In this particular case, I don't agree with the principle, one-way navigation towards suppliers is a good idea for the reasons Bran mentions. Conrad To: Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Issue 6630 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 29 Jul 2004 17:53:46 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/29/2004 17:53:47, Serialize complete at 07/29/2004 17:53:47 I realize that this is going to sound callous, but is it possible for us to stop raising every little issue to one of basic principle -- especially this late into the process? This was really an issue that required a trivial fix -- the kind of fix we have done dozens of times already. We know that UML is inconsistent, but we also know that it is not something that can be fixed over night. This particular fix is not going to make the situation any worse, so let's get on with it. Bran "Conrad Bock" 07/29/2004 05:39 PM Please respond to conrad.bock To , cc Subject RE: Issue 6630 karl, > The disadvantage to which you call our attention is purely hypothetical. > "If we applied this to the rest of the metamodel..." We do not propose > applying it to anywhere except where we say, which right now is to the > supplier end in relation to dependency. That's not consistent. If you have a motivation to support where-used on suppliers, why not other metaassociations? Pick a design principle and follow it. In this particular case, I don't agree with the principle, one-way navigation towards suppliers is a good idea for the reasons Bran mentions. Conrad Reply-To: From: "Conrad Bock" To: , Subject: RE: Issue 6630 Date: Thu, 29 Jul 2004 18:00:56 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, > I realize that this is going to sound callous, Especially since I was supporting your original suggestion! Just maker supplierDependency nonnavigable and be done with it. There's no need to introduce a distinction between navigation and ownership in this one place in the metamodel to support where-used information, when we don't support where-used information anywhere else. Conrad To: Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Issue 6630 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 29 Jul 2004 18:58:18 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/29/2004 18:58:19, Serialize complete at 07/29/2004 18:58:19 But, this is exactly what Karl was suggesting as well (I think). So, what is the controversy about? I'm tired and going home.... Bran "Conrad Bock" 07/29/2004 06:00 PM Please respond to conrad.bock To , cc Subject RE: Issue 6630 Bran, > I realize that this is going to sound callous, Especially since I was supporting your original suggestion! Just maker supplierDependency nonnavigable and be done with it. There's no need to introduce a distinction between navigation and ownership in this one place in the metamodel to support where-used information, when we don't support where-used information anywhere else. Conrad To: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org, "Karl Frank" Subject: Two resolutions for Ballot 21 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 27 Jul 2004 20:12:50 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/27/2004 20:12:53 Here are two resolution proposals I am hoping to put out for Ballot 21. They are quite minor but were needed for the package merge resolution that I am working on. Karl, they were originally assigned to you, but since they were easy and "along the way" so to speak, I took the liberty of proposing resolutions for them Bran Resolutions.6399.6630.040727.doc OMG Issue No: 6630 Title: UML 2 Super / Classes / dependencies should be unidirectional Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: In the metamodel, UML::Classes::Dependencies::NamedElement::supplierDependency should not be navigable, as it does not make sense for the supplier of a dependency to know about its dependencies Discussion: The problem with the current definition is that the supplier element has to be modified each time another element declares its dependency on that element. This is not only inefficient, it is also breaks accepted concepts of how dependencies work. For example, if a given application is dependent on an operating system, this should not affect the operating system definition in any way. The proposed solution is straightforward: In figure 51 on page 106 of the Superstructure spec, change the navigability of the NamedElement::supplierDependency association end from navigable to non-navigable. Disposition: Resolved Subject: RE: Two resolutions for Ballot 21 Date: Tue, 27 Jul 2004 19:11:34 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Two resolutions for Ballot 21 Thread-Index: AcR0N6JFeA+ywGT7T0KjqwVhqrOTvgAD/lBg From: "Karl Frank" To: "Branislav Selic" , , X-OriginalArrivalTime: 28 Jul 2004 02:11:40.0776 (UTC) FILETIME=[38827E80:01C47448] As a matter of principle I prefer the generality of your proposal, so am inclined to vote for that, but am concerned that Classifier is so general a modelElement it may have some odd and unexpected consequences to enable an interface to nest any kind of Classifier. If we go with your proposal, we will also need the revised text for the nestedClassifier association of Interface. My proposal fixes the missing multiplicities and a typo in the text for Interface attributes, as a passing gesture while adding the needed nested Interface - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, 27 July, 2004 8:13 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org; Karl Frank Subject: Two resolutions for Ballot 21 Here are two resolution proposals I am hoping to put out for Ballot 21. They are quite minor but were needed for the package merge resolution that I am working on. Karl, they were originally assigned to you, but since they were easy and "along the way" so to speak, I took the liberty of proposing resolutions for them Bran :wq Subject: Another pair of resolutions for Ballot 21 Date: Wed, 28 Jul 2004 13:59:21 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Another pair of resolutions for Ballot 21 Thread-Index: AcR0N6JFeA+ywGT7T0KjqwVhqrOTvgArXiUg From: "Karl Frank" To: "Branislav Selic" , , , X-OriginalArrivalTime: 28 Jul 2004 20:59:31.0824 (UTC) FILETIME=[C798F700:01C474E5] One of these is classified as shared with Infra, but I find there is no problem with the Infra, the fix is local to the superstructure spec. Please see attached. - Karl Issues_6630_7355.doc OMG Issue No: 6630 1 MOF/Infra - OMG Issue No: 7355 2 OMG Issue No: 6630 Title: UML 2 Super / Classes / dependencies should be unidirectional Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: In the metamodel, UML::Classes::Dependencies::NamedElement::supplierDependency should not be navigable, as it does not make sense for the supplier of a dependency to know about its dependencies Discussion: Indeed supplierDependency should not be navigable, but because only binary relationships can be navigable. Dependency is not binary. The metamodel (shown below) does not show supplierDependency as navigable (no arrowhead) so there is no issue here. Disposition: Closed, no change To: "Karl Frank" Cc: "Branislav Selic" , conrad.bock@nist.gov, mu2i-ftf@omg.org, "Pete Rivett" , Philippe.Desfray@softeam.fr, uml2-superstructure-ftf@omg.org, "Pidcock, Woody" Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Wed, 4 Aug 2004 11:40:15 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/04/2004 09:40:16, Serialize complete at 08/04/2004 09:40:16 How about using italics for the end name for those cases where a navigable end is not owned by the classifier at the other end? "Karl Frank" 07/28/2004 01:49 PM To "Pidcock, Woody" , , "Branislav Selic" , "Pete Rivett" cc , , Subject RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel So what's the character data for the dot? I do not like the dot as proposed by Bran below because it is appearing amongst the string markup for line ends, as if an extension to the visibility and property string markup, but it is not a keyboard character. A graphic dot adorning the end of the line graphic itself, analogous to the X for nonnavigable end and the > for navigable, would be acceptable because it is a graphic and hence drawn, no suggestion that it can be typed in. - Karl -------------------------------------------------------------------------------- From: Pidcock, Woody [mailto:woody.pidcock@boeing.com] Sent: Wednesday, 28 July, 2004 1:20 PM To: Philippe.Desfray@softeam.fr; Branislav Selic; Pete Rivett Cc: conrad.bock@nist.gov; Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel I agree with Philippe. -----Original Message----- From: Desfray [mailto:Philippe.Desfray@softeam.fr] Sent: Wednesday, July 28, 2004 8:04 AM To: 'Branislav Selic'; 'Pete Rivett' Cc: conrad.bock@nist.gov; 'Karl Frank'; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel I just feel very bad about that and all this navigability discussion. It seems that there is a dangerous mix between the semantics of navigability, from the end user's eyes, and the ownership rules, from the meta-implementer's eyes. Adding notations to indicate ownership rules is pure pollution in a logical model. I would just claim that we should keep close to the end user's semantics (from UML1.4), and explain somewhere that from the metamodel implementation perspective, navigability has an ownership implication. ==================================== Philippe -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 28 juillet 2004 16:24 À : Pete Rivett Cc : conrad.bock@nist.gov; Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : RE: Two resolutions for Ballot 21 - Issue 6630 and navigability again - issue affecting whole metamodel Here is what I was thinking of: Bran To: "Karl Frank" Cc: uml2-superstructure-ftf@omg.org Subject: Resolution to 6630 - problems? X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 6 Aug 2004 10:40:19 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/06/2004 10:40:22, Serialize complete at 08/06/2004 10:40:22 Karl, Note that Dependency is a superclass of several other kinds of directed relationships: InterfaceRealization (the dashed line with a triangle at the other end) Realization Deployment Usage Abstraction Substitution Some of these are quite widely used, such as InterfaceRealization and Usage (the ball and socket stuff). Because you have removed navigability from both the client and the supplier, you have made it more complicated for tool implementors, who will now have to construct special navigation tables so that client elements can find their dependencies. (Note: I am assuming here our agreed on convention that in the spec, a navigability arrow also connotes that the opposite end owns the association end.) Your interpretation of the statement that the assignment of direction is 'arbitrary' is not correct, I believe. The intent there was to say that the meaning of 'client' and 'supplier' may vary with use (although not in the special cases listed above, where the meaning is well defined), not that the direction is not important. I hate to say this after such long discussions, but I really object to the arrow on Dependency::client. I must admit this is the first time I saw that particular arrow proposed, so apologies if I should have complained earlier. Regards, Bran Subject: RE: Resolution to 6630 - problems? Date: Fri, 6 Aug 2004 07:52:21 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resolution to 6630 - problems? Thread-Index: AcR7w0/zcB2os6QNS6eTWtDsfMdjWAAAN4Cw From: "Karl Frank" To: "Branislav Selic" Cc: X-OriginalArrivalTime: 06 Aug 2004 14:52:31.0817 (UTC) FILETIME=[005E4B90:01C47BC5] My view is that the dependencies should be maintainable without requiring modification of the model elements that have the dependencies. On the abstract syntax that I propose, the addition or deletion of dependency relationships to a model changes neither the client nor the supplier. Having the client own a reference to its dependencies (not a reference to the supplier of the dependency, but to the dependency element) seems to me neither necessary nor desirable. I do not see why having to update the client is "easier". Yes, the dependency is the owner of the references to both client and supplier, on the model I am proposing. I propose we will have to let this proposal cook for a while, so maybe it cannot go in the current ballot. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, 06 August, 2004 10:40 AM To: Karl Frank Cc: uml2-superstructure-ftf@omg.org Subject: Resolution to 6630 - problems? Karl, Note that Dependency is a superclass of several other kinds of directed relationships: InterfaceRealization (the dashed line with a triangle at the other end) Realization Deployment Usage Abstraction Substitution Some of these are quite widely used, such as InterfaceRealization and Usage (the ball and socket stuff). Because you have removed navigability from both the client and the supplier, you have made it more complicated for tool implementors, who will now have to construct special navigation tables so that client elements can find their dependencies. (Note: I am assuming here our agreed on convention that in the spec, a navigability arrow also connotes that the opposite end owns the association end.) Your interpretation of the statement that the assignment of direction is 'arbitrary' is not correct, I believe. The intent there was to say that the meaning of 'client' and 'supplier' may vary with use (although not in the special cases listed above, where the meaning is well defined), not that the direction is not important. I hate to say this after such long discussions, but I really object to the arrow on Dependency::client. I must admit this is the first time I saw that particular arrow proposed, so apologies if I should have complained earlier. Regards, Bran To: "Karl Frank" Cc: uml2-superstructure-ftf@omg.org Subject: RE: Resolution to 6630 - problems? X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 6 Aug 2004 13:03:47 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/06/2004 13:03:53, Serialize complete at 08/06/2004 13:03:53 Karl, If we were to be consistent then, and, as you say: "Having the client own a reference to its dependencies (not a reference to the supplier of the dependency, but to the dependency element) seems to me neither necessary nor desirable." would you extend the same principle to Generalizations? The reason I think it IS desireable is one of practicality -- it will make it easier for implementors, since it is a common case where you want to follow a dependency from the client to the supplier (but not the other way around). For example, when I say that a class realizes an interface, I want to see quickly which interface. Bran To: Branislav Selic Cc: "Karl Frank" , uml2-superstructure-ftf@omg.org Subject: RE: Resolution to 6630 - problems? X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Fri, 6 Aug 2004 18:54:17 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/06/2004 16:54:18, Serialize complete at 08/06/2004 16:54:18 I agree with Bran. A source dependency says something about the source and its needs. That is, if you looked inside the source, you'd see the dependency manifest somehow either in structure, behavior, realization, deployment, or something. That isn't true of the target of the dependency. It is generally not even aware of the dependency since it doesn't depend on it in any way. So I think a source should always know its dependencies, and a tool may provide "where referenced" capabilities for dependency targets if that is a useful function. This is not hard to do, and the coupling between source and target resulting from a bi-directional association outweights the benefit. Branislav Selic 08/06/2004 01:03 PM To "Karl Frank" cc uml2-superstructure-ftf@omg.org Subject RE: Resolution to 6630 - problems? Karl, If we were to be consistent then, and, as you say: "Having the client own a reference to its dependencies (not a reference to the supplier of the dependency, but to the dependency element) seems to me neither necessary nor desirable." would you extend the same principle to Generalizations? The reason I think it IS desireable is one of practicality -- it will make it easier for implementors, since it is a common case where you want to follow a dependency from the client to the supplier (but not the other way around). For example, when I say that a class realizes an interface, I want to see quickly which interface. Bran From: "Thomas Weigert" To: "Jim Amsden" , "Branislav Selic" Cc: "Karl Frank" , Subject: RE: Resolution to 6630 - problems? Date: Sun, 8 Aug 2004 13:21:44 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) I think there are two notions of dependency floating around here: (i) if A depends on B, that dependency on B is a property of A (ii) the dependency of A on B is asserted independently of A and B. I can see both models being useful. I have seen people use the concept of dependency in both ways. Th. -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, August 06, 2004 5:54 PM To: Branislav Selic Cc: Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: Resolution to 6630 - problems? I agree with Bran. A source dependency says something about the source and its needs. That is, if you looked inside the source, you'd see the dependency manifest somehow either in structure, behavior, realization, deployment, or something. That isn't true of the target of the dependency. It is generally not even aware of the dependency since it doesn't depend on it in any way. So I think a source should always know its dependencies, and a tool may provide "where referenced" capabilities for dependency targets if that is a useful function. This is not hard to do, and the coupling between source and target resulting from a bi-directional association outweights the benefit. Branislav Selic 08/06/2004 01:03 PM To "Karl Frank" cc uml2-superstructure-ftf@omg.org Subject RE: Resolution to 6630 - problems? Karl, If we were to be consistent then, and, as you say: "Having the client own a reference to its dependencies (not a reference to the supplier of the dependency, but to the dependency element) seems to me neither necessary nor desirable." would you extend the same principle to Generalizations? The reason I think it IS desireable is one of practicality -- it will make it easier for implementors, since it is a common case where you want to follow a dependency from the client to the supplier (but not the other way around). For example, when I say that a class realizes an interface, I want to see quickly which interface. Bran Subject: Updated Issue 6630 Date: Sun, 26 Sep 2004 18:50:19 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Updated Issue 6630 Thread-Index: AcSj3EvvNKoEkGrpQrCyVMHjzZPa5AAU5z/A From: "Karl Frank" To: X-OriginalArrivalTime: 27 Sep 2004 01:50:22.0220 (UTC) FILETIME=[59A114C0:01C4A434] I have discussed this at length with Jim Amsden and Pete Rivett. We have not all agreed on one resolution for this issue, so in the absence of a consensus I have written up the majority view. What does the rest of the FTF think of this? Regards, Karl Frank 6630_ForBallot26.doc OMG Issue No: 6630 Title: UML 2 Super / Classes / dependencies should be unidirectional Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: In the metamodel, UML::Classes::Dependencies::NamedElement::supplierDependency should not be navigable, as it does not make sense for the supplier of a dependency to know about its dependencies Discussion: To understand this issue fully, we note that the wording of the report underplays the issue. The problem is more serious than stated, because one Dependency may have any number of suppliers and clients which would need to .have to know about. any number of dependencies, So the language of the issue is inaccurate in that it refers to .the supplier of a dependency.. Neither clients nor suppliers .know about dependencies.. The issue is really about what model elements should require a mandatory update when a Dependency is added or removed, and what information needs to go into a model interchange serialization. The principle we follow in this resolution is to keep mandatory updates to a minimum and not to degrade the logic of the metamodel by catering to lookup optimizations in particular implementation designs. For the same reason it undesirable to update all the suppliers of a dependency when adding or removing a dependency relationship from a model, it is also undesirable to have to update all the. If the reason for the dependency is that each client already has a reference to the supplier, this is intrinsic to the client with or without the UML dependency relationship being in the model. This is the case, for example, with a Class declaration that includes a reference to another Class. Such dependencies are not references to a UML dependency relationship, and have nothing to do with issue 6630. To consider each of the UML model element clients as requiring internal references to its dependency relationships, is to confuse the UML model elements with compilation units in a programming language, which imply their dependencies by the presence of unresolved references. UML model dependencies are not always like that. (Just read through the text and look at the specializations of Dependency !) The spec states that the direction of a dependency is an arbitrary choice on the part of the modeler. Hence there is no reason to enshrine an assumption that the client will have a reference to something that makes the client .truly. dependent on that something. Putting references to the dependency in the supplier is merely a implementation choice to speedup lookups to find where the supplier is used. Likewise, putting references to the dependency in the client is a common way to facilitate looking up the dependencies it has, but the dependency objects are the only objects one needs in a logical sense, which is the sense that matters in defining the abstract syntax. Any other resolution will limit the ability to exchange partial models meaningfully, since the clients will be referentially incomplete without also exchanging the dependencies. Common use cases for dependency relationships in UML models include adding dependencies (which include abstraction and refinement) to show what requirements a given implementation satisfies. To be unable to exchange the requirement model (a PIM) without the implementation model (a PSM), or the implementation without the requirements would be a serious problem. Tool builders may choose to make it easy to look up dependencies in which a model element plays either a client or a supplier role. They are free to add references to the dependencies to the client, but such references are a implementation detail outside the scope of metamodel comliance, and will not need to be inlcuded in the XMI. Stated otherwise, a .where-used. query is not required to be supported by the client nor the supplier. A dependency is itself responsible for knowing what model elements it connects. Changes in the abstract syntax: The binary associations in the metamodel, connecting Dependency with NamedElement, should require navigable from the Dependency to both clients and suppliers, but not from the NamedElements to Dependencies. Associations in Figure 51, page 106, will comply with what is shown in blue below: Disposition: Resolved From: "Thomas Weigert" To: "'Karl Frank'" , Subject: RE: Updated Issue 6630 Date: Sun, 26 Sep 2004 21:25:34 -0500 X-Mailer: Microsoft Outlook, Build 10.0.6626 Without commenting on the proposal, if you make these associations uni-directional, you do not need (and should not put) names on the non-navigable end. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, September 26, 2004 8:50 PM To: uml2-superstructure-ftf@omg.org Subject: Updated Issue 6630 I have discussed this at length with Jim Amsden and Pete Rivett. We have not all agreed on one resolution for this issue, so in the absence of a consensus I have written up the majority view. What does the rest of the FTF think of this? Regards, Karl Frank Subject: RE: Updated Issue 6630 Date: Sun, 26 Sep 2004 19:29:20 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Issue 6630 Thread-Index: AcSkOT6JKo0vjlG6QAq7FSNWX9s7MAAABfnQ From: "Karl Frank" To: "Thomas Weigert" , X-OriginalArrivalTime: 27 Sep 2004 02:29:20.0853 (UTC) FILETIME=[CB902850:01C4A439] Although not necessary to put the rolenames on the non-navigable ends, I can see nothing wrong with it except that it is out of conformance with the style of the rest of the abstract syntax. Is that why you say I should not do it, because it is style guide issue? Or is there some theoretical reason I am unaware of? There are I know some tools that automatically add reference datamembers named to match rolenames seen on the far end of association lines, etc. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, September 26, 2004 10:26 PM To: Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Without commenting on the proposal, if you make these associations uni-directional, you do not need (and should not put) names on the non-navigable end. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, September 26, 2004 8:50 PM To: uml2-superstructure-ftf@omg.org Subject: Updated Issue 6630 I have discussed this at length with Jim Amsden and Pete Rivett. We have not all agreed on one resolution for this issue, so in the absence of a consensus I have written up the majority view. What does the rest of the FTF think of this? Regards, Karl Frank From: "Thomas Weigert" To: "'Karl Frank'" , Subject: RE: Updated Issue 6630 Date: Sun, 26 Sep 2004 21:48:32 -0500 X-Mailer: Microsoft Outlook, Build 10.0.6626 Just for style consistency... -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, September 26, 2004 9:29 PM To: Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Although not necessary to put the rolenames on the non-navigable ends, I can see nothing wrong with it except that it is out of conformance with the style of the rest of the abstract syntax. Is that why you say I should not do it, because it is style guide issue? Or is there some theoretical reason I am unaware of? There are I know some tools that automatically add reference datamembers named to match rolenames seen on the far end of association lines, etc. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, September 26, 2004 10:26 PM To: Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Without commenting on the proposal, if you make these associations uni-directional, you do not need (and should not put) names on the non-navigable end. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, September 26, 2004 8:50 PM To: uml2-superstructure-ftf@omg.org Subject: Updated Issue 6630 I have discussed this at length with Jim Amsden and Pete Rivett. We have not all agreed on one resolution for this issue, so in the absence of a consensus I have written up the majority view. What does the rest of the FTF think of this? Regards, Karl Frank Subject: RE: Updated Issue 6630 Date: Sun, 26 Sep 2004 22:49:16 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Issue 6630 Thread-Index: AcSkOuoDu44CCtKRTCmPKm08eC45UwAAPHMQ From: "Pete Rivett" To: "Thomas Weigert" , "Karl Frank" , X-Virus-Scanned: by amavisd-new at sentraliant.com I disagree with Thomas' suggestion to not name ends which are owned by Associations (i.e. are the opposite end of a uni-directional association): from an implementation point of view it will still be possible to access these ends via the Association interface: this interface will require names from the Association so why not make the names obvious and explicit rather than relying on default generation rules (e.g. using the name of the target class)? Pete 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: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, September 26, 2004 10:26 PM To: 'Karl Frank'; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Without commenting on the proposal, if you make these associations uni-directional, you do not need (and should not put) names on the non-navigable end. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, September 26, 2004 8:50 PM To: uml2-superstructure-ftf@omg.org Subject: Updated Issue 6630 I have discussed this at length with Jim Amsden and Pete Rivett. We have not all agreed on one resolution for this issue, so in the absence of a consensus I have written up the majority view. What does the rest of the FTF think of this? Regards, Karl Frank Date: Mon, 27 Sep 2004 10:58:18 +0100 From: Guus Ramackers Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Karl Frank CC: uml2-superstructure-ftf@omg.org, Eran Gery Subject: Re: Updated Issue 6630 Karl, Agreed that Dependencies at the logical level can be 'standalone'. Note however that Implementation (where a Class implements an Interface) has been changed in UML 2.0 to be owned by the Class. This is consistent with what happens in many programming languages, e.g. Java, and makes management easier (e.g. deleting the class deletes the Implementation). Also the Class logically needs to comply with the interface - it is not an external relationship. So ideally subtypes of Dependency still need to be able to be owned. Thanks, Guus Karl Frank wrote: I have discussed this at length with Jim Amsden and Pete Rivett. We have not all agreed on one resolution for this issue, so in the absence of a consensus I have written up the majority view. What does the rest of the FTF think of this? Regards, Karl Frank -- __________________________________________________________ Guus Ramackers Product Manager UML and Web Services, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 Subject: RE: Updated Issue 6630 Date: Mon, 27 Sep 2004 04:17:56 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Issue 6630 Thread-Index: AcSkeFdVP2rhPO4OTX+qflNZ/6dyYwACUuEg From: "Karl Frank" To: "Guus Ramackers" Cc: , "Eran Gery" X-OriginalArrivalTime: 27 Sep 2004 11:18:00.0317 (UTC) FILETIME=[A5D642D0:01C4A483] As Guus notes, Implementation of an Interface in UML 1 became owned by the Classifier (and changed name to 'InterfaceRealization') in UML 2. To accommodate Guus' point, we could remove the annotation that says InterfaceRealization "subsets ClientDependency". T Our proposal is consistent with this. We are proposing retaining unchanged the portion of the metamodel where InterfaceRealization further specialize Realization which in turn specializes Dependency. This did not need to be stated in the resolution, I thought, because the proposal does not, so far as I can see, break the metamodel of InterfaceRealization, which is adding that composition to the metamodel which is not there in Dependency. - Karl -------------------------------------------------------------------------------- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Monday, September 27, 2004 5:58 AM To: Karl Frank Cc: uml2-superstructure-ftf@omg.org; Eran Gery Subject: Re: Updated Issue 6630 Karl, Agreed that Dependencies at the logical level can be 'standalone'. Note however that Implementation (where a Class implements an Interface) has been changed in UML 2.0 to be owned by the Class. This is consistent with what happens in many programming languages, e.g. Java, and makes management easier (e.g. deleting the class deletes the Implementation). Also the Class logically needs to comply with the interface - it is not an external relationship. So ideally subtypes of Dependency still need to be able to be owned. Thanks, Guus Karl Frank wrote: I have discussed this at length with Jim Amsden and Pete Rivett. We have not all agreed on one resolution for this issue, so in the absence of a consensus I have written up the majority view. What does the rest of the FTF think of this? Regards, Karl Frank -- __________________________________________________________ Guus Ramackers Product Manager UML and Web Services, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 Subject: RE: Updated Issue 6630 Date: Mon, 27 Sep 2004 04:51:51 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Issue 6630 Thread-Index: AcSkPHXSE8UjLc9+QWSwYeLsigfdnwAS6GGw From: "Karl Frank" To: "Thomas Weigert" , X-OriginalArrivalTime: 27 Sep 2004 11:51:52.0446 (UTC) FILETIME=[611489E0:01C4A488] Thanks Thomas. I will make the improvement you suggest, and also add notes to deal with the point Guus raised re: Interface Implementation, and fix some typos that Pete Rivett brought to my attention, and distribute an improved version in a few hours. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, September 26, 2004 10:49 PM To: Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Just for style consistency... -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, September 26, 2004 9:29 PM To: Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Although not necessary to put the rolenames on the non-navigable ends, I can see nothing wrong with it except that it is out of conformance with the style of the rest of the abstract syntax. Is that why you say I should not do it, because it is style guide issue? Or is there some theoretical reason I am unaware of? There are I know some tools that automatically add reference datamembers named to match rolenames seen on the far end of association lines, etc. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, September 26, 2004 10:26 PM To: Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Without commenting on the proposal, if you make these associations uni-directional, you do not need (and should not put) names on the non-navigable end. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, September 26, 2004 8:50 PM To: uml2-superstructure-ftf@omg.org Subject: Updated Issue 6630 I have discussed this at length with Jim Amsden and Pete Rivett. We have not all agreed on one resolution for this issue, so in the absence of a consensus I have written up the majority view. What does the rest of the FTF think of this? Regards, Karl Frank Subject: RE: Updated Issue 6630 Date: Mon, 27 Sep 2004 05:06:27 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Issue 6630 Thread-Index: AcSkOuoDu44CCtKRTCmPKm08eC45UwAAPHMQABOFi9A= From: "Karl Frank" To: "Pete Rivett" , "Thomas Weigert" , X-OriginalArrivalTime: 27 Sep 2004 12:06:29.0141 (UTC) FILETIME=[6BA19450:01C4A48A] I also disagree with removing the rolenames on the unnavigable ends but for another reason: The InterfaceRealization relationship is specified in terms that remind the reader that one end "{subsets clientDependency}" This appears to me to be useful and accurate info wrt the metamodel and would be impossible if the rolename 'clientDependency' disappeared from the end of the metaassociation. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Sunday, September 26, 2004 10:49 PM To: Thomas Weigert; Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 I disagree with Thomas' suggestion to not name ends which are owned by Associations (i.e. are the opposite end of a uni-directional association): from an implementation point of view it will still be possible to access these ends via the Association interface: this interface will require names from the Association so why not make the names obvious and explicit rather than relying on default generation rules (e.g. using the name of the target class)? Pete 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: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, September 26, 2004 10:26 PM To: 'Karl Frank'; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Without commenting on the proposal, if you make these associations uni-directional, you do not need (and should not put) names on the non-navigable end. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, September 26, 2004 8:50 PM To: uml2-superstructure-ftf@omg.org Subject: Updated Issue 6630 I have discussed this at length with Jim Amsden and Pete Rivett. We have not all agreed on one resolution for this issue, so in the absence of a consensus I have written up the majority view. What does the rest of the FTF think of this? Regards, Karl Frank To: "Karl Frank" Cc: "Pete Rivett" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Mon, 27 Sep 2004 09:48:16 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 09/27/2004 07:48:17, Serialize complete at 09/27/2004 07:48:17 But the subsets constraint doesn't mean very much since the clientDependency isn't navigable. "Karl Frank" 09/27/2004 08:06 AM To "Pete Rivett" , "Thomas Weigert" , cc Subject RE: Updated Issue 6630 I also disagree with removing the rolenames on the unnavigable ends but for another reason: The InterfaceRealization relationship is specified in terms that remind the reader that one end "{subsets clientDependency}" This appears to me to be useful and accurate info wrt the metamodel and would be impossible if the rolename 'clientDependency' disappeared from the end of the metaassociation. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Sunday, September 26, 2004 10:49 PM To: Thomas Weigert; Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 I disagree with Thomas' suggestion to not name ends which are owned by Associations (i.e. are the opposite end of a uni-directional association): from an implementation point of view it will still be possible to access these ends via the Association interface: this interface will require names from the Association so why not make the names obvious and explicit rather than relying on default generation rules (e.g. using the name of the target class)? Pete 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: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, September 26, 2004 10:26 PM To: 'Karl Frank'; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Without commenting on the proposal, if you make these associations uni-directional, you do not need (and should not put) names on the non-navigable end. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, September 26, 2004 8:50 PM To: uml2-superstructure-ftf@omg.org Subject: Updated Issue 6630 I have discussed this at length with Jim Amsden and Pete Rivett. We have not all agreed on one resolution for this issue, so in the absence of a consensus I have written up the majority view. What does the rest of the FTF think of this? Regards, Karl Frank Subject: RE: Updated Issue 6630 Date: Mon, 27 Sep 2004 06:51:10 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Issue 6630 Thread-Index: AcSkmJ+KGp17UUBhR8632JCzBod4YgAADgNg From: "Karl Frank" To: "Jim Amsden" , "Pete Rivett" Cc: "Thomas Weigert" , X-OriginalArrivalTime: 27 Sep 2004 13:51:03.0379 (UTC) FILETIME=[075E5230:01C4A499] I am glad to agree we should keep the model simple and noise free, but compatibility with EMOF is ensured only at Level 0. To limit the UML 2 level 1 compliance to EMOF is contrary to our agreement re resolving compliance. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Monday, September 27, 2004 9:48 AM To: Pete Rivett Cc: Karl Frank; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Association ends are not required to be named so tools will need to be able to deal with unnamed ends regardless of navigability. I think it is more important to keep the model simple, noise free, and compatible with EMOF than it is to optimize for a implementation strategy/convention that has little semantic meaning in the metamodel. There could be cases in a model where the navigability of an end changes up or down a generalization hierarchy. In this case, it may be necessary to have a name of the non-navigable end in order for the end to participate in subsets constraints with other ends that are visible. This would be a questionable modeling practice though as it violates the principle of substitutability and makes properties available in superclasses that aren't available in a subclass. "Pete Rivett" 09/26/2004 10:49 PM To "Thomas Weigert" , "Karl Frank" , cc Subject RE: Updated Issue 6630 I disagree with Thomas' suggestion to not name ends which are owned by Associations (i.e. are the opposite end of a uni-directional association): from an implementation point of view it will still be possible to access these ends via the Association interface: this interface will require names from the Association so why not make the names obvious and explicit rather than relying on default generation rules (e.g. using the name of the target class)? Pete 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: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, September 26, 2004 10:26 PM To: 'Karl Frank'; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Without commenting on the proposal, if you make these associations uni-directional, you do not need (and should not put) names on the non-navigable end. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, September 26, 2004 8:50 PM To: uml2-superstructure-ftf@omg.org Subject: Updated Issue 6630 I have discussed this at length with Jim Amsden and Pete Rivett. We have not all agreed on one resolution for this issue, so in the absence of a consensus I have written up the majority view. What does the rest of the FTF think of this? Regards, Karl Frank Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 27 Sep 2004 08:41:17 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: Updated Issue 6630 Should "will not need to be included in the XMI" instead be "will not be included in the XMI"? To: "Karl Frank" Cc: "Pete Rivett" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Mon, 27 Sep 2004 11:54:08 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 09/27/2004 09:54:09, Serialize complete at 09/27/2004 09:54:09 Karl, The compliance levels have little to do with the UML2 metamodel. It is a CMOF model that is translated to EMOF in order to generate the XSD schema for the compliance levels. The UML2 model is not compliant to EMOF or CMOF, its an instance of a CMOF model. "Karl Frank" 09/27/2004 09:51 AM To Jim Amsden/Raleigh/IBM@IBMUS, "Pete Rivett" cc "Thomas Weigert" , Subject RE: Updated Issue 6630 I am glad to agree we should keep the model simple and noise free, but compatibility with EMOF is ensured only at Level 0. To limit the UML 2 level 1 compliance to EMOF is contrary to our agreement re resolving compliance. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Monday, September 27, 2004 9:48 AM To: Pete Rivett Cc: Karl Frank; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Association ends are not required to be named so tools will need to be able to deal with unnamed ends regardless of navigability. I think it is more important to keep the model simple, noise free, and compatible with EMOF than it is to optimize for a implementation strategy/convention that has little semantic meaning in the metamodel. There could be cases in a model where the navigability of an end changes up or down a generalization hierarchy. In this case, it may be necessary to have a name of the non-navigable end in order for the end to participate in subsets constraints with other ends that are visible. This would be a questionable modeling practice though as it violates the principle of substitutability and makes properties available in superclasses that aren't available in a subclass. "Pete Rivett" 09/26/2004 10:49 PM To "Thomas Weigert" , "Karl Frank" , cc Subject RE: Updated Issue 6630 I disagree with Thomas' suggestion to not name ends which are owned by Associations (i.e. are the opposite end of a uni-directional association): from an implementation point of view it will still be possible to access these ends via the Association interface: this interface will require names from the Association so why not make the names obvious and explicit rather than relying on default generation rules (e.g. using the name of the target class)? Pete 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: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, September 26, 2004 10:26 PM To: 'Karl Frank'; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Without commenting on the proposal, if you make these associations uni-directional, you do not need (and should not put) names on the non-navigable end. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, September 26, 2004 8:50 PM To: uml2-superstructure-ftf@omg.org Subject: Updated Issue 6630 I have discussed this at length with Jim Amsden and Pete Rivett. We have not all agreed on one resolution for this issue, so in the absence of a consensus I have written up the majority view. What does the rest of the FTF think of this? Regards, Karl Frank Subject: RE: Updated Issue 6630 Date: Mon, 27 Sep 2004 08:59:45 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Issue 6630 Thread-Index: AcSkqjU+xgnhoWT3TEeqv6GyE38UnAAAEiMw From: "Karl Frank" To: "Jim Amsden" Cc: "Pete Rivett" , "Thomas Weigert" , X-OriginalArrivalTime: 27 Sep 2004 15:59:47.0584 (UTC) FILETIME=[035A7800:01C4A4AB] Understood. And what you say is, I thought, my point. The UML 2 metamodel is a CMOF model. You are arguing that we must not put anything into the abstract syntax of UML 2 that cannot be expressed in EMF, and this is afaik not an agreed policy, and a constraining one. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Monday, September 27, 2004 11:54 AM To: Karl Frank Cc: Pete Rivett; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Karl, The compliance levels have little to do with the UML2 metamodel. It is a CMOF model that is translated to EMOF in order to generate the XSD schema for the compliance levels. The UML2 model is not compliant to EMOF or CMOF, its an instance of a CMOF model. "Karl Frank" 09/27/2004 09:51 AM To Jim Amsden/Raleigh/IBM@IBMUS, "Pete Rivett" cc "Thomas Weigert" , Subject RE: Updated Issue 6630 I am glad to agree we should keep the model simple and noise free, but compatibility with EMOF is ensured only at Level 0. To limit the UML 2 level 1 compliance to EMOF is contrary to our agreement re resolving compliance. - Karl -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Monday, September 27, 2004 9:48 AM To: Pete Rivett Cc: Karl Frank; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Association ends are not required to be named so tools will need to be able to deal with unnamed ends regardless of navigability. I think it is more important to keep the model simple, noise free, and compatible with EMOF than it is to optimize for a implementation strategy/convention that has little semantic meaning in the metamodel. There could be cases in a model where the navigability of an end changes up or down a generalization hierarchy. In this case, it may be necessary to have a name of the non-navigable end in order for the end to participate in subsets constraints with other ends that are visible. This would be a questionable modeling practice though as it violates the principle of substitutability and makes properties available in superclasses that aren't available in a subclass. "Pete Rivett" 09/26/2004 10:49 PM To "Thomas Weigert" , "Karl Frank" , cc Subject RE: Updated Issue 6630 I disagree with Thomas' suggestion to not name ends which are owned by Associations (i.e. are the opposite end of a uni-directional association): from an implementation point of view it will still be possible to access these ends via the Association interface: this interface will require names from the Association so why not make the names obvious and explicit rather than relying on default generation rules (e.g. using the name of the target class)? Pete 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: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, September 26, 2004 10:26 PM To: 'Karl Frank'; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Without commenting on the proposal, if you make these associations uni-directional, you do not need (and should not put) names on the non-navigable end. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, September 26, 2004 8:50 PM To: uml2-superstructure-ftf@omg.org Subject: Updated Issue 6630 I have discussed this at length with Jim Amsden and Pete Rivett. We have not all agreed on one resolution for this issue, so in the absence of a consensus I have written up the majority view. What does the rest of the FTF think of this? Regards, Karl Frank Subject: RE: Updated Issue 6630 Date: Mon, 27 Sep 2004 13:13:44 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Issue 6630 Thread-Index: AcSkmkp+gQRfKyT9Sme1U735hqx1uQAGipVb From: "Pete Rivett" To: "Jim Amsden" Cc: "Karl Frank" , "Thomas Weigert" , X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i8RHKq1U014976 Jim, When you say 'navigability' I don't think you mean the new definition of navigability. We need to remain clear as to when we mean navigability (as per the new meaning) and when property ownership (which is what I think all the recent discussion has been about). What will happen when generating APIs (and also XMI come to it) is that names will need to be auto-generated for ends unnamed on diagrams: it seems better to make them visible rather than expecting people to remember the rules. Also OCL allows ends to be included in constraints whether or not there is an explicit property. Pete -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Mon 9/27/2004 9:48 AM To: Pete Rivett Cc: Karl Frank; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Association ends are not required to be named so tools will need to be able to deal with unnamed ends regardless of navigability. I think it is more important to keep the model simple, noise free, and compatible with EMOF than it is to optimize for a implementation strategy/convention that has little semantic meaning in the metamodel. There could be cases in a model where the navigability of an end changes up or down a generalization hierarchy. In this case, it may be necessary to have a name of the non-navigable end in order for the end to participate in subsets constraints with other ends that are visible. This would be a questionable modeling practice though as it violates the principle of substitutability and makes properties available in superclasses that aren't available in a subclass. "Pete Rivett" 09/26/2004 10:49 PM To "Thomas Weigert" , "Karl Frank" , cc Subject RE: Updated Issue 6630 I disagree with Thomas' suggestion to not name ends which are owned by Associations (i.e. are the opposite end of a uni-directional association): from an implementation point of view it will still be possible to access these ends via the Association interface: this interface will require names from the Association so why not make the names obvious and explicit rather than relying on default generation rules (e.g. using the name of the target class)? Pete 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: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, September 26, 2004 10:26 PM To: 'Karl Frank'; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Without commenting on the proposal, if you make these associations uni-directional, you do not need (and should not put) names on the non-navigable end. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, September 26, 2004 8:50 PM To: uml2-superstructure-ftf@omg.org Subject: Updated Issue 6630 I have discussed this at length with Jim Amsden and Pete Rivett. We have not all agreed on one resolution for this issue, so in the absence of a consensus I have written up the majority view. What does the rest of the FTF think of this? Regards, Karl Frank Subject: RE: Super FTF telecon on Wed. Aug. 18 - Issue 6630 again Date: Tue, 17 Aug 2004 22:07:34 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Super FTF telecon on Wed. Aug. 18 - Issue 6630 again Thread-Index: AcSEq6tJmHZRZUA0TjG654DVOeIB5QADuBpQ From: "Pete Rivett" To: "Branislav Selic" , "Karl Frank" Cc: , X-Virus-Scanned: by amavisd-new at sentraliant.com Let's be careful about the phrase 'A knows about B' since it could now mean either of two quite orthogonal things: a) A has a Property whose type is B in its set of ownedAttributes b) A has a Property whose type is B in its set of attributes (but not ownedAttributes - meaning the Property is owned by the Association) and this Property is navigable With respect to b) here is a reminder of the new definition of navigable introduced with the resolution to 6460: A navigable end of an association means that it is intended to be traversed at runtime from objects participating in links at the other end(s) of the association to objects participating in links at the navigable end. This is independent of ownership of the end. I find the anthropomorphic implications of 'know' unhelpful and potentially misleading in such discussions. IMHO we should treat the UML metamodel as a UML model that is the specification of the static structure of a system representing a generic modeling tool/repository. The typical 'runtime' for such a system is when a modeler is using the modeling tool/repository to model/analyze a 'real' application system. The question then becomes, would we expect a modeling tool to be able to traverse dependencies in both directions (e.g. to do 'where used'). I would say 'yes', for any but the most crude modeling tool (and such tools will probably be at L0 compliance which des not include Dependency anyway). In which case all ends of the client and supplier associations should be navigable. However this does not imply that the ends should be ownedAttributes of the NamedElement metaclass. This is in essence Karl's proposal. However I do not have a problem with the clientDependency end being an ownedAttribute of NamedElement and, as Bran points out, this minimizes fall-out to the rest of the spec: Karl's proposed replacement 'text', consisting only of a diagram change is certainly not adequate in any case (the property definitions in the text would also need to change). In which case we need to show the following in the diagram, deploying the new 'dot' notation: - the client---clientDependency line has no adornments at all: the association is navigable in both directions and both ends are ownedAttributes of NamedElement and Dependency respectively. - the supplier---supplierDependency line has no navigability arrow but has a 'dot' at the 'supplierDependency' end: the association is navigable in both directions and supplier is an ownedAttributes of Dependency but 'supplierDependency' is not an ownedAttribute of NamedElement. So this I think preserves the main intent of Karl's proposal (related to navigability) and addresses Bran's concerns (related to end ownership). And at least tries to put the discussion on a better footing (treating the metamodel as a UML static model for a hypothetical tool) than the confusion related to use of 'know'. Hope that helps, Pete 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: Tuesday, August 17, 2004 11: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] Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 02:22:18 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 24 draft Thread-Index: AcSGUaOOvWEvXmwvTEeA2cPkA+ZL9gAHR9rg Priority: Urgent From: "Pete Rivett" To: "Branislav Selic" , , X-Virus-Scanned: by amavisd-new at sentraliant.com 3391: I don't really like the idea of 2 separate sequences (one for body one for language) which must be kept in sync. It seems to me each (body+language) pair should be a structure/tuple: was this considered? I don't think the resolution should be pulled just on my objection but do think that at the very minimum the language property should be unique; and there should be a constraint that the size of the 2 sequences must be equal. 3398: the discussion (and hence the disposition) do not address the issue raised which is that the XMI spec specifies a number of tags that may be attached to metamodel elements in order to tailor the XMI Schema or Documents. While most of these have sensible defaults, there are others that do not. Prime examples are the XML namespace URI (e.g. http://schema.omg.org/spec/UML/2.0) and the namespace prefix (e.g. UML). Such values should certainly be included in the XMI for the metamodel and also in the specification document (a good place would be Appendix F). 5977: two problems are raised by the resolution: a) isUnique=true is the default for MultiplicityElement so we have a problem in that AFAIK (looking at resolution to 7575 in this set of issues) there is no notation to specify non-default multiplicity: the of {unique} is pointless since that's the default anyway! b) whether or not {nonunique} has an explicit notation the point raised by the issue still stands at the metamodel level: there should be a constraint to say that if one end of an association has isUnique=false then the other end must also have isUnique=false. 5979: also requires an Infra change 6171: In the last sentence, rather than saying 'Such rules are beyond the scope of UML' could they not be made a semantic variation point? A precedent is in 7.8.3 where there is a SVP related to compatibility of redefinitions. (I don't feel strongly about this) 6409, 6430, 6452: The discussion gives the reason for deferral as the OCL 2.0 spec not having been adopted; in fact it was adopted at the same time as Super. The declared intention of the submission teams on adoption was for the FTFs to perform a reconciliation between the largely stable adopted specs: OCL in particular has had virtually no changes. In any case the differences in OCL 2.0 are not great and it is not the case AFAIK that 'the vast majority of constraints are likely have to be rewritten'. If we've run out of time let's say that rather than raise unwarranted concerns (e.g. to AB) that major reconciliation work is still required with OCL. 6616: (minor typo) the discussion states: "and provides yet another way to introduce inconsistencies into a model, declaring a node a root when it in fact has children." In fact the inconsistency would be if the node had parent(s) 6630: I'm not very happy with the resolution since it continues to ignore the point I've been trying to make about the distinction between navigability and ownership (you can have navigability without an owned property): and I did not see any objection to my proposal of using the new dot notation to show non-ownership. It would be nice to have a response to that though I will not continue to object on this point. However I do strongly object to removing the name of association end supplierDependency on the basis that " by naming the supplierDependency end, the metamodel would invite constraints to be written involving it, etc". (this from an email between those word-smithing the issue) My objections are: a) the issue did not cite any problem with this being named b) I think it's acknowledged that some tools at least would like to do 'where used' navigations - and recent discussions on MDA have stressed the need for traceability: removing the association end name is actively hostile to such tools c) the only people who will be writing constraints on this association end would be ourselves or a successor RTF d) taking this rule as a precedent would involve deleting large numbers of other association end names from the metamodel. e) the resolution does not even make explicit that this name is being removed 7400: Misses the point of the issue: I wrote an email to explain the issue and the change needed (which is to have AssociationClass::ownedEnd subsetting AssociationClass::ownedAttribute). Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 7:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 draft Attached, please find the draft of ballot 24. There are 66 resolutions in this one -- good work! Reminder: voting on this ballot will commence on Friday at 6 pm EDT. If you have any complaints or suggestions, please submit them by tomorrow noon EDT. Regards, Bran Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 04:54:15 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 24 draft Thread-Index: AcSGUaOOvWEvXmwvTEeA2cPkA+ZL9gAHR9rgAA6L76A= From: "Karl Frank" To: "Pete Rivett" , "Branislav Selic" , , X-OriginalArrivalTime: 20 Aug 2004 11:54:17.0929 (UTC) FILETIME=[6C18FB90:01C486AC] wrt the ones I wrote up: 1. 6616 Right. More dyslexia than typo, the reversal of parent and child in 6616, will change. 2. 6171. Thomas made the same point. Agreed. 3. 6630: I agree with you on this, but removed the navigability supported by association ownership from my proposal because Conrad objected to it, and because I felt the new dot navigability notation would then constitute a quite different sort of change than the original issue was asking for. Then I thought, well if a product supports a where-used query which the spec does not require, this does not constitute non-compliance, it is a case of going beyond what is required. As you can see, I am in favor especially of providing for the dot notation (in my opinion a square dot would be better becauase of the ball end of IDEF/1 notation) but see it as a distinct issue. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 20, 2004 2:22 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Ballot 24 draft Importance: High 3391: I don't really like the idea of 2 separate sequences (one for body one for language) which must be kept in sync. It seems to me each (body+language) pair should be a structure/tuple: was this considered? I don't think the resolution should be pulled just on my objection but do think that at the very minimum the language property should be unique; and there should be a constraint that the size of the 2 sequences must be equal. 3398: the discussion (and hence the disposition) do not address the issue raised which is that the XMI spec specifies a number of tags that may be attached to metamodel elements in order to tailor the XMI Schema or Documents. While most of these have sensible defaults, there are others that do not. Prime examples are the XML namespace URI (e.g. http://schema.omg.org/spec/UML/2.0) and the namespace prefix (e.g. UML). Such values should certainly be included in the XMI for the metamodel and also in the specification document (a good place would be Appendix F). 5977: two problems are raised by the resolution: a) isUnique=true is the default for MultiplicityElement so we have a problem in that AFAIK (looking at resolution to 7575 in this set of issues) there is no notation to specify non-default multiplicity: the of {unique} is pointless since that's the default anyway! b) whether or not {nonunique} has an explicit notation the point raised by the issue still stands at the metamodel level: there should be a constraint to say that if one end of an association has isUnique=false then the other end must also have isUnique=false. 5979: also requires an Infra change 6171: In the last sentence, rather than saying 'Such rules are beyond the scope of UML' could they not be made a semantic variation point? A precedent is in 7.8.3 where there is a SVP related to compatibility of redefinitions. (I don't feel strongly about this) 6409, 6430, 6452: The discussion gives the reason for deferral as the OCL 2.0 spec not having been adopted; in fact it was adopted at the same time as Super. The declared intention of the submission teams on adoption was for the FTFs to perform a reconciliation between the largely stable adopted specs: OCL in particular has had virtually no changes. In any case the differences in OCL 2.0 are not great and it is not the case AFAIK that 'the vast majority of constraints are likely have to be rewritten'. If we've run out of time let's say that rather than raise unwarranted concerns (e.g. to AB) that major reconciliation work is still required with OCL. 6616: (minor typo) the discussion states: "and provides yet another way to introduce inconsistencies into a model, declaring a node a root when it in fact has children." In fact the inconsistency would be if the node had parent(s) 6630: I'm not very happy with the resolution since it continues to ignore the point I've been trying to make about the distinction between navigability and ownership (you can have navigability without an owned property): and I did not see any objection to my proposal of using the new dot notation to show non-ownership. It would be nice to have a response to that though I will not continue to object on this point. However I do strongly object to removing the name of association end supplierDependency on the basis that " by naming the supplierDependency end, the metamodel would invite constraints to be written involving it, etc". (this from an email between those word-smithing the issue) My objections are: a) the issue did not cite any problem with this being named b) I think it's acknowledged that some tools at least would like to do 'where used' navigations - and recent discussions on MDA have stressed the need for traceability: removing the association end name is actively hostile to such tools c) the only people who will be writing constraints on this association end would be ourselves or a successor RTF d) taking this rule as a precedent would involve deleting large numbers of other association end names from the metamodel. e) the resolution does not even make explicit that this name is being removed 7400: Misses the point of the issue: I wrote an email to explain the issue and the change needed (which is to have AssociationClass::ownedEnd subsetting AssociationClass::ownedAttribute). Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 7:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 draft Attached, please find the draft of ballot 24. There are 66 resolutions in this one -- good work! Reminder: voting on this ballot will commence on Friday at 6 pm EDT. If you have any complaints or suggestions, please submit them by tomorrow noon EDT. Regards, Bran Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 18:42:11 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 24 draft Thread-Index: AcSGUaOOvWEvXmwvTEeA2cPkA+ZL9gAHR9rgAA6L76AAFxq2EA== From: "Pete Rivett" To: "Karl Frank" Cc: "Branislav Selic" , , X-Virus-Scanned: by amavisd-new at sentraliant.com On 6630 you did not address my strong objection to removing the association end name - which is orthogonal to the navigability issue and was not called for by the issue or anyone else apart, apparently, from Jim A. 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: Friday, August 20, 2004 6:54 AM To: Pete Rivett; Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Ballot 24 draft wrt the ones I wrote up: 1. 6616 Right. More dyslexia than typo, the reversal of parent and child in 6616, will change. 2. 6171. Thomas made the same point. Agreed. 3. 6630: I agree with you on this, but removed the navigability supported by association ownership from my proposal because Conrad objected to it, and because I felt the new dot navigability notation would then constitute a quite different sort of change than the original issue was asking for. Then I thought, well if a product supports a where-used query which the spec does not require, this does not constitute non-compliance, it is a case of going beyond what is required. As you can see, I am in favor especially of providing for the dot notation (in my opinion a square dot would be better becauase of the ball end of IDEF/1 notation) but see it as a distinct issue. - Karl -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Friday, August 20, 2004 2:22 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Ballot 24 draft Importance: High 3391: I don't really like the idea of 2 separate sequences (one for body one for language) which must be kept in sync. It seems to me each (body+language) pair should be a structure/tuple: was this considered? I don't think the resolution should be pulled just on my objection but do think that at the very minimum the language property should be unique; and there should be a constraint that the size of the 2 sequences must be equal. 3398: the discussion (and hence the disposition) do not address the issue raised which is that the XMI spec specifies a number of tags that may be attached to metamodel elements in order to tailor the XMI Schema or Documents. While most of these have sensible defaults, there are others that do not. Prime examples are the XML namespace URI (e.g. http://schema.omg.org/spec/UML/2.0) and the namespace prefix (e.g. UML). Such values should certainly be included in the XMI for the metamodel and also in the specification document (a good place would be Appendix F). 5977: two problems are raised by the resolution: a) isUnique=true is the default for MultiplicityElement so we have a problem in that AFAIK (looking at resolution to 7575 in this set of issues) there is no notation to specify non-default multiplicity: the of {unique} is pointless since that's the default anyway! b) whether or not {nonunique} has an explicit notation the point raised by the issue still stands at the metamodel level: there should be a constraint to say that if one end of an association has isUnique=false then the other end must also have isUnique=false. 5979: also requires an Infra change 6171: In the last sentence, rather than saying 'Such rules are beyond the scope of UML' could they not be made a semantic variation point? A precedent is in 7.8.3 where there is a SVP related to compatibility of redefinitions. (I don't feel strongly about this) 6409, 6430, 6452: The discussion gives the reason for deferral as the OCL 2.0 spec not having been adopted; in fact it was adopted at the same time as Super. The declared intention of the submission teams on adoption was for the FTFs to perform a reconciliation between the largely stable adopted specs: OCL in particular has had virtually no changes. In any case the differences in OCL 2.0 are not great and it is not the case AFAIK that 'the vast majority of constraints are likely have to be rewritten'. If we've run out of time let's say that rather than raise unwarranted concerns (e.g. to AB) that major reconciliation work is still required with OCL. 6616: (minor typo) the discussion states: "and provides yet another way to introduce inconsistencies into a model, declaring a node a root when it in fact has children." In fact the inconsistency would be if the node had parent(s) 6630: I'm not very happy with the resolution since it continues to ignore the point I've been trying to make about the distinction between navigability and ownership (you can have navigability without an owned property): and I did not see any objection to my proposal of using the new dot notation to show non-ownership. It would be nice to have a response to that though I will not continue to object on this point. However I do strongly object to removing the name of association end supplierDependency on the basis that " by naming the supplierDependency end, the metamodel would invite constraints to be written involving it, etc". (this from an email between those word-smithing the issue) My objections are: a) the issue did not cite any problem with this being named b) I think it's acknowledged that some tools at least would like to do 'where used' navigations - and recent discussions on MDA have stressed the need for traceability: removing the association end name is actively hostile to such tools c) the only people who will be writing constraints on this association end would be ourselves or a successor RTF d) taking this rule as a precedent would involve deleting large numbers of other association end names from the metamodel. e) the resolution does not even make explicit that this name is being removed 7400: Misses the point of the issue: I wrote an email to explain the issue and the change needed (which is to have AssociationClass::ownedEnd subsetting AssociationClass::ownedAttribute). Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 7:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 draft Attached, please find the draft of ballot 24. There are 66 resolutions in this one -- good work! Reminder: voting on this ballot will commence on Friday at 6 pm EDT. If you have any complaints or suggestions, please submit them by tomorrow noon EDT. Regards, Bran Subject: Revision of 6630 incorporating feedback Date: Mon, 27 Sep 2004 12:56:32 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Revision of 6630 incorporating feedback Thread-Index: AcSj+p8nBUJY0LDuTJmJ9869YNb26QAzeq2g From: "Karl Frank" To: "Thomas Weigert" , "Joaquin Miller" , "UML Superstructure FTF" , "Guus Ramackers" , "Jim Amsden" , "Pete Rivett" X-OriginalArrivalTime: 27 Sep 2004 19:56:45.0570 (UTC) FILETIME=[1DEEF620:01C4A4CC] Despite the fact that I (and Pete) did not see the need, Jim Amsden and Thomas had reasons for removing the rolenames form the ends that that are not represented by properties in the client and in the supplier, so those have been removed in response to Jim's and Thomas' points. Joaquin and Pete had various editing improvements which I have made. Guus had a point with respect to Interface realization which I added. So here is the current version of this proposal. Pete Rivett has correctly observed that issue 6243 changed the model of navigability as it relates to properties, and that this has an impact on the accurate statement of this issue. this might provide a superior resolution, but so far I have only addressed this by a paragraph added to the attached. There is an outstanding discussion with Jim Amsden that is not resolved in this proposal, which may lead to further changes before Ballot 26 is sent out. Regards, Karl Frank 6630_ForBallot26_v2.doc OMG Issue No: 6630 Title: UML 2 Super / Classes / dependencies should be unidirectional Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: In the metamodel, UML::Classes::Dependencies::NamedElement::supplierDependency should not be navigable, as it does not make sense for the supplier of a dependency to know about its dependencies Discussion: To understand this issue fully, we note that the wording of the report underplays its severity. This is because one Dependency may have any number of suppliers and clients, all which would .have to know about. it, and perhaps also any number of other distinct dependencies, So the language of the issue is inaccurate in that it refers to .the supplier of a dependency.. Neither clients nor suppliers .know about dependencies.. The issue is really about what model elements should require a mandatory update when a Dependency is added or removed, and what information needs to go into a model interchange serialization. Further, the issue is not really about navigability. The changes already adopted in respect to issue 6243 changed the old view of navigability. The issue really is whether the navigability should be supported by properties in the client and the supplier. The principle we follow in this resolution is to keep mandatory updates to a minimum and not to degrade the logic of the metamodel by catering to lookup optimizations in particular implementation designs. For the same reason it undesirable to update all the suppliers of a dependency when adding or removing a dependency relationship from a model, it is also undesirable to have to update all the clients. If the reason for the dependency is that each client already has a reference to the supplier, this is intrinsic to the client with or without the UML dependency relationship being in the model. This is the case, for example, with a Class declaration that includes a reference to another Class. Such dependencies are not references to a UML Dependency element, and have nothing to do with issue 6630. To consider each of the UML model element clients as requiring internal references to its dependency relationships, is to confuse the UML model elements with compilation units in a programming language, which imply their dependencies by the presence of unresolved references. UML model dependencies are not always like that. (Just read through the text and look at the specializations of Dependency !) The spec states that the direction of a dependency is an arbitrary choice on the part of the modeler. Hence there is no reason to enshrine an assumption that the client will have a reference to something that makes the client .truly. dependent on that something. Putting references to the dependency in the supplier is merely a implementation choice to speedup lookups to find where the supplier is used. Likewise, putting references to the dependency in the client is a common way to facilitate looking up the dependencies it has, but the dependency objects are the only objects one needs in a logical sense, which is the sense that matters in defining the abstract syntax. Any other resolution will limit the ability to exchange partial models meaningfully, since the clients will be referentially incomplete without also exchanging the dependencies. Common use cases for dependency relationships in UML models include adding dependencies (which include abstraction and refinement) to show what requirements a given implementation satisfies. To be unable to exchange the requirement model (a PIM) without the implementation model (a PSM), or the implementation without the requirements would be a serious problem. Tool builders may wish to make it easy to look up dependencies in which a given model element plays either a client or a supplier role. To support this, they are free to add references to the dependencies in their client elements, but such references are a implementation detail outside the scope of metamodel compliance, and will not be included in the XMI. Stated otherwise, a .where-used. query is not required to be supported by the client nor the supplier. A dependency is itself responsible for knowing what model elements it connects. There is substantive impact of this resolution on other portions of the abstract syntax. In particular, we retain unchanged the portion of the metamodel where InterfaceRealization further specializes Realization, which in turn specializes Dependency. However, although there is no substantive impact, the removal of the rolename .clientDependency. means the annotation {subsets clientDependency} must be removed from the metamodel in the Interfaces Diagram with respect to InterfaceRealization. Changes in the abstract syntax: The annotation .subsets clientDependency. shall be removed from the list of properties for the association end for interfaceRealization, Figure 16, on page 33 of the 040828 convenience document. The binary associations in the metamodel, connecting Dependency with NamedElement, should require properties to navigate from the Dependency to both clients and suppliers, but not from the NamedElements to Dependencies. Associations in Figure 51, page 106 FAS, (Figure 15, page 32 of the 040828 convenience document) , will comply with what is shown in blue below: Disposition: Resolved To: "Karl Frank" Cc: "Guus Ramackers" , "Jim Amsden" , "Joaquin Miller" , "Pete Rivett" , "Thomas Weigert" , "UML Superstructure FTF" Subject: Re: Revision of 6630 incorporating feedback X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 27 Sep 2004 16:41:29 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/27/2004 16:41:32, Serialize complete at 09/27/2004 16:41:32 Karl, I don't understand why you say that removing of association end names implies removing of the "subsets" annotations on those ends. I don't see how the "subsets" is dependent in any way on the association end having a name. Bran "Karl Frank" 09/27/2004 03:56 PM To "Thomas Weigert" , "Joaquin Miller" , "UML Superstructure FTF" , "Guus Ramackers" , "Jim Amsden" , "Pete Rivett" cc Subject Revision of 6630 incorporating feedback Despite the fact that I (and Pete) did not see the need, Jim Amsden and Thomas had reasons for removing the rolenames form the ends that that are not represented by properties in the client and in the supplier, so those have been removed in response to Jim's and Thomas' points. Joaquin and Pete had various editing improvements which I have made. Guus had a point with respect to Interface realization which I added. So here is the current version of this proposal. Pete Rivett has correctly observed that issue 6243 changed the model of navigability as it relates to properties, and that this has an impact on the accurate statement of this issue. this might provide a superior resolution, but so far I have only addressed this by a paragraph added to the attached. There is an outstanding discussion with Jim Amsden that is not resolved in this proposal, which may lead to further changes before Ballot 26 is sent out. Regards, Karl Frank[attachment "6630_ForBallot26_v2.doc" deleted by Branislav Selic/Ottawa/IBM] Subject: RE: Revision of 6630 incorporating feedback Date: Mon, 27 Sep 2004 14:00:03 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revision of 6630 incorporating feedback Thread-Index: AcSk0l0zQAkdmjMCSqmFrTGzNjnEyQAAnadg From: "Karl Frank" To: "Branislav Selic" Cc: "Guus Ramackers" , "Jim Amsden" , "Joaquin Miller" , "Pete Rivett" , "Thomas Weigert" , "UML Superstructure FTF" X-OriginalArrivalTime: 27 Sep 2004 21:00:07.0740 (UTC) FILETIME=[F8340FC0:01C4A4D4] The removed name was used further down in the hierarchy. Not removing the entire subset annotation, only the part that references the clientDependency. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, September 27, 2004 4:41 PM To: Karl Frank Cc: Guus Ramackers; Jim Amsden; Joaquin Miller; Pete Rivett; Thomas Weigert; UML Superstructure FTF Subject: Re: Revision of 6630 incorporating feedback Karl, I don't understand why you say that removing of association end names implies removing of the "subsets" annotations on those ends. I don't see how the "subsets" is dependent in any way on the association end having a name. Bran "Karl Frank" 09/27/2004 03:56 PM To "Thomas Weigert" , "Joaquin Miller" , "UML Superstructure FTF" , "Guus Ramackers" , "Jim Amsden" , "Pete Rivett" cc Subject Revision of 6630 incorporating feedback Despite the fact that I (and Pete) did not see the need, Jim Amsden and Thomas had reasons for removing the rolenames form the ends that that are not represented by properties in the client and in the supplier, so those have been removed in response to Jim's and Thomas' points. Joaquin and Pete had various editing improvements which I have made. Guus had a point with respect to Interface realization which I added. So here is the current version of this proposal. Pete Rivett has correctly observed that issue 6243 changed the model of navigability as it relates to properties, and that this has an impact on the accurate statement of this issue. this might provide a superior resolution, but so far I have only addressed this by a paragraph added to the attached. There is an outstanding discussion with Jim Amsden that is not resolved in this proposal, which may lead to further changes before Ballot 26 is sent out. Regards, Karl Frank[attachment "6630_ForBallot26_v2.doc" deleted by Branislav Selic/Ottawa/IBM] To: "Pete Rivett" Cc: "Karl Frank" , "Thomas Weigert" , Subject: RE: Updated Issue 6630 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Mon, 27 Sep 2004 17:55:25 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 09/27/2004 15:55:27, Serialize complete at 09/27/2004 15:55:27 Pete, My point is that non-navigable ends don't get generated regardless of property ownership. Note EMOF doesn't have associations and therefore still commingles navigation and property ownership. Note also that I still do not believe property ownership dictates any particular implementation. But I could never get that across. So non-navigable ends should not have names unless absolutely necessary because they will be lost when translating from CMOF to EMOF (which I do for generating the EMOF instance and XSD schema for the compliance levels). "Pete Rivett" 09/27/2004 01:13 PM To Jim Amsden/Raleigh/IBM@IBMUS cc "Karl Frank" , "Thomas Weigert" , Subject RE: Updated Issue 6630 Jim, When you say 'navigability' I don't think you mean the new definition of navigability. We need to remain clear as to when we mean navigability (as per the new meaning) and when property ownership (which is what I think all the recent discussion has been about). What will happen when generating APIs (and also XMI come to it) is that names will need to be auto-generated for ends unnamed on diagrams: it seems better to make them visible rather than expecting people to remember the rules. Also OCL allows ends to be included in constraints whether or not there is an explicit property. Pete -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Mon 9/27/2004 9:48 AM To: Pete Rivett Cc: Karl Frank; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Association ends are not required to be named so tools will need to be able to deal with unnamed ends regardless of navigability. I think it is more important to keep the model simple, noise free, and compatible with EMOF than it is to optimize for a implementation strategy/convention that has little semantic meaning in the metamodel. There could be cases in a model where the navigability of an end changes up or down a generalization hierarchy. In this case, it may be necessary to have a name of the non-navigable end in order for the end to participate in subsets constraints with other ends that are visible. This would be a questionable modeling practice though as it violates the principle of substitutability and makes properties available in superclasses that aren't available in a subclass. "Pete Rivett" 09/26/2004 10:49 PM To "Thomas Weigert" , "Karl Frank" , cc Subject RE: Updated Issue 6630 I disagree with Thomas' suggestion to not name ends which are owned by Associations (i.e. are the opposite end of a uni-directional association): from an implementation point of view it will still be possible to access these ends via the Association interface: this interface will require names from the Association so why not make the names obvious and explicit rather than relying on default generation rules (e.g. using the name of the target class)? Pete 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: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, September 26, 2004 10:26 PM To: 'Karl Frank'; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Without commenting on the proposal, if you make these associations uni-directional, you do not need (and should not put) names on the non-navigable end. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, September 26, 2004 8:50 PM To: uml2-superstructure-ftf@omg.org Subject: Updated Issue 6630 I have discussed this at length with Jim Amsden and Pete Rivett. We have not all agreed on one resolution for this issue, so in the absence of a consensus I have written up the majority view. What does the rest of the FTF think of this? Regards, Karl Frank Subject: RE: Updated Issue 6630 Date: Mon, 27 Sep 2004 19:05:40 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Issue 6630 Thread-Index: AcSk3lpNC8OEMVm9RQ+TQd5+fykezwAAU/9w From: "Pete Rivett" To: "Jim Amsden" Cc: "Karl Frank" , "Thomas Weigert" , X-Virus-Scanned: by amavisd-new at sentraliant.com Hi Jim, EMOF does not have Associations therefore has no notion whatsoever of 'navigability' (in the new sense): it is not co-mingled, it is absent. I agree that property ownership does not require a particular implementation. However whatever the implementation it will still be the case that updating a property of an element will be seen logically as an update to that element. So the user will need to be granted update access to that element in the same logical sense and possibly have it checked out to them or whatever (depending on the development environment). So Karl's argument still applies. I'm not sure about your claim that names are lost when translating from CMOF to EMOF. The reason for not being sure is that this CMOF to EMOF translation is not documented anywhere that I'm aware of. And AFAIK it's certainly not being standardized. A legitimate, non-lossy translation might be to translate each CMOF Association into a separate Class in EMOF: in this case the names would be essential (I'm not arguing for such a translation just saying that, lacking a normative translation, it's quite legitimate and just as valid as the one you assume). And as I wrote before, a CMOF implementation would definitely need the names so it seems a bit perverse to insist that they are not documented in the specification: UML is after all a CMOF metamodel. To use your phrase the names are 'absolutely necessary': though the diagrams do not require the names for Associations and Ends, the CMOF XMI does. Otherwise the normative metamodel in the XMI file is not valid - see Issue 7105 (raised against Infra/MOF FTF). Lacking explicit names they need to be generated using some default rules which can get quite ugly-looking. In summary, why make things difficult/hard to understand for CMOF when EMOF either just ignores the names anyway (based on your assumed translation) or needs them as much as CMOF (based on an alternative translation such as that I mention above). Regards Pete 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: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Monday, September 27, 2004 5:55 PM To: Pete Rivett Cc: Karl Frank; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Pete, My point is that non-navigable ends don't get generated regardless of property ownership. Note EMOF doesn't have associations and therefore still commingles navigation and property ownership. Note also that I still do not believe property ownership dictates any particular implementation. But I could never get that across. So non-navigable ends should not have names unless absolutely necessary because they will be lost when translating from CMOF to EMOF (which I do for generating the EMOF instance and XSD schema for the compliance levels). "Pete Rivett" 09/27/2004 01:13 PM To Jim Amsden/Raleigh/IBM@IBMUS cc "Karl Frank" , "Thomas Weigert" , Subject RE: Updated Issue 6630 Jim, When you say 'navigability' I don't think you mean the new definition of navigability. We need to remain clear as to when we mean navigability (as per the new meaning) and when property ownership (which is what I think all the recent discussion has been about). What will happen when generating APIs (and also XMI come to it) is that names will need to be auto-generated for ends unnamed on diagrams: it seems better to make them visible rather than expecting people to remember the rules. Also OCL allows ends to be included in constraints whether or not there is an explicit property. Pete -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Mon 9/27/2004 9:48 AM To: Pete Rivett Cc: Karl Frank; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Association ends are not required to be named so tools will need to be able to deal with unnamed ends regardless of navigability. I think it is more important to keep the model simple, noise free, and compatible with EMOF than it is to optimize for a implementation strategy/convention that has little semantic meaning in the metamodel. There could be cases in a model where the navigability of an end changes up or down a generalization hierarchy. In this case, it may be necessary to have a name of the non-navigable end in order for the end to participate in subsets constraints with other ends that are visible. This would be a questionable modeling practice though as it violates the principle of substitutability and makes properties available in superclasses that aren't available in a subclass. "Pete Rivett" 09/26/2004 10:49 PM To "Thomas Weigert" , "Karl Frank" , cc Subject RE: Updated Issue 6630 I disagree with Thomas' suggestion to not name ends which are owned by Associations (i.e. are the opposite end of a uni-directional association): from an implementation point of view it will still be possible to access these ends via the Association interface: this interface will require names from the Association so why not make the names obvious and explicit rather than relying on default generation rules (e.g. using the name of the target class)? Pete 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: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, September 26, 2004 10:26 PM To: 'Karl Frank'; uml2-superstructure-ftf@omg.org Subject: RE: Updated Issue 6630 Without commenting on the proposal, if you make these associations uni-directional, you do not need (and should not put) names on the non-navigable end. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, September 26, 2004 8:50 PM To: uml2-superstructure-ftf@omg.org Subject: Updated Issue 6630 I have discussed this at length with Jim Amsden and Pete Rivett. We have not all agreed on one resolution for this issue, so in the absence of a consensus I have written up the majority view. What does the rest of the FTF think of this? Regards, Karl Frank Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 27 Sep 2004 16:50:32 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: Re: Revision of 6630 incorporating feedback I don't understand why you say that removing of association end names implies removing of the "subsets" annotations on those ends. I don't see how the "subsets" is dependent in any way on the association end having a name. The question would be: Subsets what? (or am i missing something?) Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 27 Sep 2004 16:52:47 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: Updated Issue 6630 So non-navigable ends should not have names unless absolutely necessary because they will be lost when translating from CMOF to EMOF What damage is done when useful names are lost upon translation from a richer language to a minimalist one? Subject: Date: Mon, 27 Sep 2004 17:27:35 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Index: AcSk8fNWtag+LxXkSJapdmMquujfLw== From: "Karl Frank" To: "UML Superstructure FTF" X-OriginalArrivalTime: 28 Sep 2004 00:27:36.0432 (UTC) FILETIME=[F433B700:01C4A4F1] Jim Amsden, by a question, indirectly called to my attention that I had left out a critical word, "no" from the last paragraph, where I meant to say there was NO substantive implication of the resolution elsewhere n the model. The attached fixes that, and I believe answers the questions Jim Amsden raised about the resolution. Any more objections? - Regards, Karl cashing in for the night..... Karl Frank Principal Architect, Together Business Unit Borland Software Corp. Landline: 978 283 4656 Cell: 978 853 3592 (By default, assume I am in Eastern Time Zone, GMT - 5) 6630_ForBallot26_v3.doc OMG Issue No: 6630 Title: UML 2 Super / Classes / dependencies should be unidirectional Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: In the metamodel, UML::Classes::Dependencies::NamedElement::supplierDependency should not be navigable, as it does not make sense for the supplier of a dependency to know about its dependencies Discussion: To understand this issue fully, we note that the wording of the report underplays its severity. This is because one Dependency may have any number of suppliers and clients, all which would .have to know about. it, and perhaps also any number of other distinct dependencies, So the language of the issue is inaccurate in that it refers to .the supplier of a dependency.. Neither clients nor suppliers .know about dependencies.. The issue is really about what model elements should require a mandatory update when a Dependency is added or removed, and what information needs to go into a model interchange serialization. Further, the issue is not really about navigability. The changes already adopted in respect to issue 6243 changed the old view of navigability. The issue really is whether the navigability should be supported by properties in the client and the supplier. The principles we follow in this resolution are: (1) to keep mandatory updates to a minimum and (2) not to degrade the logic of the metamodel by catering to lookup optimizations in particular implementation designs. For the same reason it undesirable to update all the suppliers of a dependency when adding or removing a dependency relationship from a model, it is also undesirable to have to update all the clients. If the reason for the dependency is that each client already has a reference to the dependency.s suppliers, this is intrinsic to the client with or without the UML dependency relationship being in the model. This is the case, for example, with Class declarations that include references to other Classes. Such dependencies are not references to a UML Dependency element, and have nothing to do with issue 6630, although they can be modeled using a UML Dependency, they remain even when such a Dependency model element is removed. To consider each of the UML model element clients as requiring internal references to its dependency relationships, is to confuse the UML model elements with compilation units in a programming language, which imply their dependencies by the presence of unresolved references. UML model dependencies are not always like that. (Just read through the text and look at the specializations of Dependency !) The spec states that the direction of a dependency is an arbitrary choice on the part of the modeler. Hence there is no reason to enshrine an assumption that the client will have a reference to something that makes the client .truly. dependent on that something. Putting references to the dependency in the supplier is merely a implementation choice to speedup lookups to find where the supplier is used. Likewise, putting references to its dependencies in clients is a common way to facilitate looking up the dependencies, but the dependency objects are the only objects one needs in a logical sense, which is the sense that matters in defining the abstract syntax. If iterating through them is slow, this is a performance issue to be solved by implementation strategies, not by changing the logical metamodel. Any resolution other than the one proposed here will limit the ability to exchange partial models meaningfully, since the clients will be referentially incomplete without also exchanging the dependencies. Common use cases for dependency relationships in UML models include adding dependencies (which include abstraction and refinement) to show what requirements a given implementation satisfies. To be unable to exchange the requirement model (a PIM) without the implementation model (a PSM), or the implementation without the requirements would be a serious problem. Tool builders may wish to make it easy to look up dependencies in which a given model element plays either a client or a supplier role. To support this, they are free to add references to the dependencies in their client elements, but such references are a implementation detail outside the scope of metamodel compliance, and will not be included in the XMI. Stated otherwise, a .where-used. query is not required to be supported by the client nor the supplier. A dependency is itself responsible for knowing what model elements it connects. There is little impact of this resolution on other portions of the abstract syntax. In particular, we retain unchanged the portion of the metamodel where InterfaceRealization further specializes Realization, which in turn specializes Dependency. However, although there is no substantive impact, our resolution results in removing the rolename .clientDependency., and that was used further down in the hierarchy, so that usage must be removed. This means the annotation {subsets clientDependency} must be removed from the metamodel in the Interfaces Diagram with respect to InterfaceRealization. The rest of the annotation, {subsets ownedElement} remains. Changes in the abstract syntax: The annotation .subsets clientDependency. shall be removed from the list of properties for the association end for interfaceRealization, Figure 16, on page 33 of the 040828 convenience document. The binary associations in the metamodel, connecting Dependency with NamedElement, should require properties to navigate from the Dependency to both clients and suppliers, but not from the NamedElements to Dependencies. Associations in Figure 51, page 106 FAS, (Figure 15, page 32 of the 040828 convenience document) , will comply with what is shown in blue below: Disposition: Resolved Subject: issue 6630, v3 [was RE: 4th draft of Ballot 26] Date: Mon, 27 Sep 2004 18:20:36 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: issue 6630, v3 [was RE: 4th draft of Ballot 26] Thread-Index: AcSk1KJK4A+fVAQeTnacbT4qg+EuigAJIfCw From: "Karl Frank" To: "Branislav Selic" , Cc: X-OriginalArrivalTime: 28 Sep 2004 01:20:36.0918 (UTC) FILETIME=[5BEB5D60:01C4A4F9] Attached is a revision of issue 6630 incorporating a new last paragraph to answer a point raised by Jim Amsden Regards, Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, September 27, 2004 4:55 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: 4th draft of Ballot 26 There still seems to be a bit of churn (and confusion on my part) around some of the issues in ballot 26. Therefore, I have postponed the start of the vote by 1 day, till Tuesday at 6 PM EDT. Apologies for any inconvenience. BTW, I still plan to have the vote closing on Friday, Oct. 1 -- unless people feel that this is inadequate. If you do, please tell me. So, here is a more complete draft of the ballot with all the deferred issues as well -- but please note that this may still not be the final version. Apologies if I've screwed up (I'm still partly on Tokyo time and I am feeling a bit groggy). Regards, Bran 6630_ForBallot26_v32.doc OMG Issue No: 6630 Title: UML 2 Super / Classes / dependencies should be unidirectional Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: In the metamodel, UML::Classes::Dependencies::NamedElement::supplierDependency should not be navigable, as it does not make sense for the supplier of a dependency to know about its dependencies Discussion: To understand this issue fully, we note that the wording of the report underplays its severity. This is because one Dependency may have any number of suppliers and clients, all which would .have to know about. it, and perhaps also any number of other distinct dependencies, So the language of the issue is inaccurate in that it refers to .the supplier of a dependency.. Neither clients nor suppliers .know about dependencies.. The issue is really about what model elements should require a mandatory update when a Dependency is added or removed, and what information needs to go into a model interchange serialization. Further, the issue is not really about navigability. The changes already adopted in respect to issue 6243 changed the old view of navigability. The issue really is whether the navigability should be supported by properties in the client and the supplier. The principles we follow in this resolution are: (1) to keep mandatory updates to a minimum and (2) not to degrade the logic of the metamodel by catering to lookup optimizations in particular implementation designs. For the same reason it undesirable to update all the suppliers of a dependency when adding or removing a dependency relationship from a model, it is also undesirable to have to update all the clients. If the reason for the dependency is that each client already has a reference to the dependency.s suppliers, this is intrinsic to the client with or without the UML dependency relationship being in the model. This is the case, for example, with Class declarations that include references to other Classes. Such dependencies are not references to a UML Dependency element, and have nothing to do with issue 6630, although they can be modeled using a UML Dependency, they remain even when such a Dependency model element is removed. To consider each of the UML model element clients as requiring internal references to its dependency relationships, is to confuse the UML model elements with compilation units in a programming language, which imply their dependencies by the presence of unresolved references. UML model dependencies are not always like that. (Just read through the text and look at the specializations of Dependency !) The spec states that the direction of a dependency is an arbitrary choice on the part of the modeler. Hence there is no reason to enshrine an assumption that the client will have a reference to something that makes the client .truly. dependent on that something. Putting references to the dependency in the supplier is merely a implementation choice to speedup lookups to find where the supplier is used. Likewise, putting references to its dependencies in clients is a common way to facilitate looking up the dependencies, but the dependency objects are the only objects one needs in a logical sense, which is the sense that matters in defining the abstract syntax. If iterating through them is slow, this is a performance issue to be solved by implementation strategies, not by changing the logical metamodel. Any resolution other than the one proposed here will limit the ability to exchange partial models meaningfully, since the clients will be referentially incomplete without also exchanging the dependencies. Common use cases for dependency relationships in UML models include adding dependencies (which include abstraction and refinement) to show what requirements a given implementation satisfies. To be unable to exchange the requirement model (a PIM) without the implementation model (a PSM), or the implementation without the requirements would be a serious problem. Tool builders may wish to make it easy to look up dependencies in which a given model element plays either a client or a supplier role. To support this, they are free to add references to the dependencies in their client elements, but such references are a implementation detail outside the scope of metamodel compliance, and will not be included in the XMI. Stated otherwise, a .where-used. query is not required to be supported by the client nor the supplier. A dependency is itself responsible for knowing what model elements it connects. There is little impact of this resolution on other portions of the abstract syntax. In particular, we retain unchanged the portion of the metamodel where InterfaceRealization further specializes Realization, which in turn specializes Dependency. However, although there is no substantive impact, our resolution results in removing the rolename .clientDependency., and that was used further down in the hierarchy, so that usage must be removed. This means the annotation {subsets clientDependency} must be removed from the metamodel in the Interfaces Diagram with respect to InterfaceRealization. The rest of the annotation, {subsets ownedElement} remains. Changes in the abstract syntax: The annotation .subsets clientDependency. shall be removed from the list of properties for the association end for interfaceRealization, Figure 16, on page 33 of the 040828 convenience document. The binary associations in the metamodel, connecting Dependency with NamedElement, should require properties to navigate from the Dependency to both clients and suppliers, but not from the NamedElements to Dependencies. Associations in Figure 51, page 106 FAS, (Figure 15, page 32 of the 040828 convenience document) , will comply with what is shown in blue below: Disposition: Resolved To: Joaquin Miller Cc: UML Superstructure FTF Subject: Re: Revision of 6630 incorporating feedback X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 28 Sep 2004 07:22:04 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/28/2004 07:22:04, Serialize complete at 09/28/2004 07:22:04 In a {subsets X} annotation of an association end, the X is a reference to a super-association end. The subsetting end does not have to have a name, unless it is referenced in some sub-association. Bran Joaquin Miller 09/27/2004 07:50 PM Please respond to Joaquin Miller To UML Superstructure FTF cc Subject Re: Revision of 6630 incorporating feedback I don't understand why you say that removing of association end names implies removing of the "subsets" annotations on those ends. I don't see how the "subsets" is dependent in any way on the association end having a name. The question would be: Subsets what? (or am i missing something?) Subject: RE: Revision of 6630 incorporating feedback Date: Tue, 28 Sep 2004 04:41:54 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revision of 6630 incorporating feedback Thread-Index: AcSlTXQjOYkiy9rlRACanniFFXEJAgAAbg2Q From: "Karl Frank" To: "Branislav Selic" , "Joaquin Miller" Cc: "UML Superstructure FTF" X-OriginalArrivalTime: 28 Sep 2004 11:41:55.0116 (UTC) FILETIME=[2774F6C0:01C4A550] Yes. In the case in point in the proposed resolution to 6630, it is the super-association end, the subsetee, that lost its name, not the subsetting end. The superassociation end had been named 'clientDependency,' and that was removed at the request of Jim and Thomas. Hence it was impossible for the subsetting end to be annotated as {subsets } because there was no reference to put in for . But there is a named association end further up the heirarchy, ownedMember, and the interfaceRealization end will, with this resolution, be annotated as subsetting ownedMember. The latest revision of 6630, v3, perhaps makes this clearer. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, September 28, 2004 7:22 AM To: Joaquin Miller Cc: UML Superstructure FTF Subject: Re: Revision of 6630 incorporating feedback In a {subsets X} annotation of an association end, the X is a reference to a super-association end. The subsetting end does not have to have a name, unless it is referenced in some sub-association. Bran Joaquin Miller 09/27/2004 07:50 PM Please respond to Joaquin Miller To UML Superstructure FTF cc Subject Re: Revision of 6630 incorporating feedback I don't understand why you say that removing of association end names implies removing of the "subsets" annotations on those ends. I don't see how the "subsets" is dependent in any way on the association end having a name. The question would be: Subsets what? (or am i missing something?) Subject: 6630 not in the 4th draft of Ballot 26 Date: Tue, 28 Sep 2004 05:39:33 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6630 not in the 4th draft of Ballot 26 Thread-Index: AcSk1KJK4A+fVAQeTnacbT4qg+EuigAgLUGw From: "Karl Frank" To: "Branislav Selic" , Cc: X-OriginalArrivalTime: 28 Sep 2004 12:39:35.0849 (UTC) FILETIME=[3636E990:01C4A558] The v3 that I circulated last night answered all substantive questions and incorporated all edit suggestions received so far. IBM has voiced a strong objection to the resolution for 6630. It's time we hashed those out. The text of the resolution follows, as numbered and labeled parts. What part of this does IBM disagree with? 1. Analysis of the issue report: multiplicity. To understand this issue fully, we note that the wording of the report underplays its severity. This is because one Dependency may have any number of suppliers and clients, all which would .have to know about. it, and perhaps also any number of other distinct dependencies, So the language of the issue is inaccurate in that it refers to .the supplier of a dependency.. 2. Analysis of the issue report: personification. Neither clients nor suppliers .know about dependencies.. The issue is really about what model elements should require a mandatory update when a Dependency is added or removed, and what information needs to go into a model interchange serialization. 3. Analysis of the issue report: navigability not equivalent to property in the associated classes. Further, the issue is not really about navigability. The changes already adopted in respect to issue 6243 changed the old view of navigability. The issue really is whether the navigability should be supported by properties in the client and the supplier. 4. Guiding principles: The principles we follow in this resolution are: (1) to keep mandatory updates to a minimum and (2) not to degrade the logic of the metamodel by catering to lookup optimizations in particular implementation designs. 5. Summary of the resolution For the same reason it undesirable to update all the suppliers of a dependency when adding or removing a dependency relationship from a model, it is also undesirable to have to update all the clients. 6. Dependency is not a direct reference to Supplier in the Client. If the reason for the dependency is that each client already has a reference to the dependency.s suppliers, this is intrinsic to the client with or without the UML dependency relationship being in the model. This is the case, for example, with Class declarations that include references to other Classes. Such dependencies are not references to a UML Dependency element, and have nothing to do with issue 6630, although they can be modeled using a UML Dependency, they remain even when such a Dependency model element is removed. To consider each of the UML model element clients as requiring internal references to its dependency relationships, is to confuse the UML model elements with compilation units in a programming language, which imply their dependencies by the presence of unresolved references. UML model dependencies are not always like that. (Just read through the text and look at the specializations of Dependency !) 7. Consistency with text requires equal handling of client and supplier. The spec states that the direction of a dependency is an arbitrary choice on the part of the modeler. Hence there is no reason to enshrine an assumption that the client will have a reference to something that makes the client .truly. dependent on that something. 8. Motivation for properties to support navigability is lookup optimization Putting references to the dependency in the supplier is merely a implementation choice to speedup lookups to find where the supplier is used. Likewise, putting references to its dependencies in clients is a common way to facilitate looking up the dependencies, but the dependency objects are the only objects one needs in a logical sense, which is the sense that matters in defining the abstract syntax. If iterating through them is slow, this is a performance issue to be solved by implementation strategies, not by changing the logical metamodel. 9. Resolution must support exchange of partial models. Any resolution other than the one proposed here will limit the ability to exchange partial models meaningfully, since the clients will be referentially incomplete without also exchanging the dependencies. Common use cases for dependency relationships in UML models include adding dependencies (which include abstraction and refinement) to show what requirements a given implementation satisfies. To be unable to exchange the requirement model (a PIM) without the implementation model (a PSM), or the implementation without the requirements would be a serious problem. 10. Consistent with right of vendors to optimize lookups thru references. Tool builders may wish to make it easy to look up dependencies in which a given model element plays either a client or a supplier role. To support this, they are free to add references to the dependencies in their client elements, but such references are a implementation detail outside the scope of metamodel compliance, and will not be included in the XMI. Stated otherwise, a .where-used. query is not required to be supported by the client nor the supplier. A dependency is itself responsible for knowing what model elements it connects. 11. Scope of impact of this resolution on the rest of the metamodel. There is little impact of this resolution on other portions of the abstract syntax. In particular, we retain unchanged the portion of the metamodel where InterfaceRealization further specializes Realization, which in turn specializes Dependency. However, although there is no substantive impact, our resolution results in removing the rolename .clientDependency., and that was used further down in the hierarchy, so that usage must be removed. This means the annotation {subsets clientDependency} must be removed from the metamodel in the Interfaces Diagram with respect to InterfaceRealization. The rest of the annotation, {subsets ownedElement} remains. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, September 27, 2004 4:55 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: 4th draft of Ballot 26 There still seems to be a bit of churn (and confusion on my part) around some of the issues in ballot 26. Therefore, I have postponed the start of the vote by 1 day, till Tuesday at 6 PM EDT. Apologies for any inconvenience. BTW, I still plan to have the vote closing on Friday, Oct. 1 -- unless people feel that this is inadequate. If you do, please tell me. So, here is a more complete draft of the ballot with all the deferred issues as well -- but please note that this may still not be the final version. Apologies if I've screwed up (I'm still partly on Tokyo time and I am feeling a bit groggy). Regards, Bran To: "Karl Frank" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: 6630 not in the 4th draft of Ballot 26 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 28 Sep 2004 10:54:00 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/28/2004 10:54:01, Serialize complete at 09/28/2004 10:54:01 Thanks, Karl, for the analysis and the opportunity to comment on it. My feedback is embedded below: > IBM has voiced a strong objection to the resolution for 6630. It's > time we hashed those out. > > The text of the resolution follows, as numbered and labeled parts. > > What part of this does IBM disagree with? > > 1. Analysis of the issue report: multiplicity. > > To understand this issue fully, we note that the wording of the > report underplays its severity. This is because one Dependency may > have any number of suppliers and clients, all which would â..have to > know aboutâ. it, and perhaps also any number of other distinct > dependencies, So the language of the issue is inaccurate in that it > refers to â..the supplier of a dependencyâ.. It is indeed the case that there can be multiple suppliers and multiple clients and that the issue formulation is imprecise on this point. However, I really don't think that this is germane to the central issue raised. > 2. Analysis of the issue report: personification. > Neither clients nor suppliers â..know about dependencies.â. The issue > is really about what model elements should require a mandatory > update when a Dependency is added or removed, and what information > needs to go into a model interchange serialization. This looks like another distracting nitpick regarding the wording of the issue. Setting that aside, however, I disagree with your characterization of the issue. I think that you are confusing causes and effects when you say that the issue is about what gets updated, and I don't at all see what model interchange has to do with it. The central issue is about the semantics of Dependency. My desktop dictionary defines "dependency" as "the state of being dependent", which implies that a dependent is directly affected by its dependencies. The notion that a dependency is something that can be added or removed without affecting the dependent is patently illogical. My point is that, by its very definition, a dependency is structurally a part of the dependent. The fact that some UML concepts, such as Abstraction, are incorrectly modeled as kinds of Dependency is a separate issue that should be dealt with separately. So, please let us not use this example of bad modeling as an argument in this discussion. > 3. Analysis of the issue report: navigability not equivalent to > property in the associated classes. > Further, the issue is not really about navigability. The changes > already adopted in respect to issue 6243 changed the old view of > navigability. The issue really is whether the navigability should > be supported by properties in the client and the supplier. Note that the issue was raised before the navigability/ownership split was even discussed. But, as I stated above, the issue is not about navigability. > 4. Guiding principles: > The principles we follow in this resolution are: (1) to keep > mandatory updates to a minimum and (2) not to degrade the logic of > the metamodel by catering to lookup optimizations in particular > implementation designs. I really don't know what you mean by the above. The change you are proposing is actually more extensive than the one that I would like to see, since completely changes the meaning of Dependency with respect to both the original FAS definition and the UML 1.x definition (it also introduces more changes than my proposal). I am not sure how one judges the extent to which a model is "degraded" since that implies some kind of value judgement. However, it certainly seems to me that your proposal is much more of a degradation if the above criteria are applied (a degradation of the concept at the very least). > 5. Summary of the resolution > For the same reason it undesirable to update all the suppliers of a > dependency when adding or removing a dependency relationship from a > model, it is also undesirable to have to update all the clients. As I argued above, it is nonsensical to equate the clients and the suppliers of a dependency. The whole notion of dependency is founded on this differentiation. Your view of a dependency as an optional semantics-free model element, which can be added and removed without effect, completely decouples it from its common and intuitive interpretation. This is my main objection. The concept you seem to be looking for here is not Dependency but Association which owns its ends. Since we now have such a concept, I see no reason to change Dependency just to provide the same capability. This redundancy will certainly lead to confusion. > 6. Dependency is not a direct reference to Supplier in the Client. > If the reason for the dependency is that each client already has a > reference to the dependencyâ..s suppliers, this is intrinsic to the > client with or without the UML dependency relationship being in the > model. This is the case, for example, with Class declarations that > include references to other Classes. Such dependencies are not > references to a UML Dependency element, and have nothing to do with > issue 6630, although they can be modeled using a UML Dependency, > they remain even when such a Dependency model element is removed. > To consider each of the UML model element clients as requiring > internal references to its dependency relationships, is to confuse > the UML model elements with compilation units in a programming > language, which imply their dependencies by the presence of > unresolved references. UML model dependencies are not always like > that. (Just read through the text and look at the specializations of > Dependency !) I repeat what I said above: a few of the specializations of Dependency are misguided and should not be used as a justification for further any model changes. > 7. Consistency with text requires equal handling of client and supplier. > The spec states that the direction of a dependency is an arbitrary > choice on the part of the modeler. Hence there is no reason to > enshrine an assumption that the client will have a reference to > something that makes the client â..trulyâ. dependent on that something. This is a repeat of your point 6, relly. In effect, it argues that, rather than fix the problem with mis-specialization of Dependency, we should apply such misuse consistently. > 8. Motivation for properties to support navigability is lookup optimization > Putting references to the dependency in the supplier is merely a > implementation choice to speedup lookups to find where the supplier > is used. Likewise, putting references to its dependencies in > clients is a common way to facilitate looking up the dependencies, > but the dependency objects are the only objects one needs in a > logical sense, which is the sense that matters in defining the > abstract syntax. If iterating through them is slow, this is a > performance issue to be solved by implementation strategies, not by > changing the logical metamodel. That is your interpretation of the motivation, but as I hope I cleared up above, the reasons are different: (1) To ensure that the concept of Dependency has a semantics that match what most people expect (2) To avoid redundant modeling concepts (since we can already achieve what your proposal does with Associations) > 9. Resolution must support exchange of partial models. > Any resolution other than the one proposed here will limit the > ability to exchange partial models meaningfully, since the clients > will be referentially incomplete without also exchanging the dependencies. This is a red herring. The problem of partial models is orthogonal and will not disappear if we change the definition of Dependency. > Common use cases for dependency relationships in UML models include > adding dependencies (which include abstraction and refinement) to > show what requirements a given implementation satisfies. To be > unable to exchange the requirement model (a PIM) without the > implementation model (a PSM), or the implementation without the > requirements would be a serious problem. I don't understand your example. It seems to me that the Dependency would normally be from a PSM to a PIM (I thought we are discouraging the use of these terms) not the other way around. > 10. Consistent with right of vendors to optimize lookups thru references. Again, I don't understand what is intended here. Vendors can certainly do that, whatever choice we make in this case. > Tool builders may wish to make it easy to look up dependencies in > which a given model element plays either a client or a supplier > role. To support this, they are free to add references to the > dependencies in their client elements, but such references are a > implementation detail outside the scope of metamodel compliance, and > will not be included in the XMI. You are really confusing me here. The information on the targets and sources of dependencies has to be in the model somewhere, so it will be in the XMI in one form of another. To summarize: I really think that your resolution will make a bad situation (i.e., the misuse of the current Dependency concept to model things such as "trace") worse. It will also change the expected intuitive meaning of the Dependency concept and also render it completely redundant. I think that these are serious issues. Regards, Bran Subject: RE: 6630 not in the 4th draft of Ballot 26 Date: Tue, 28 Sep 2004 08:31:15 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6630 not in the 4th draft of Ballot 26 Thread-Index: AcSlavioaH76QA79SzS0VJRE/e05uwAAMuMg From: "Karl Frank" To: "Branislav Selic" Cc: , X-OriginalArrivalTime: 28 Sep 2004 15:31:18.0875 (UTC) FILETIME=[334BEAB0:01C4A570] Good. My responses are likewise inline. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, September 28, 2004 10:54 AM To: Karl Frank Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: 6630 not in the 4th draft of Ballot 26 > 4. Guiding principles: > The principles we follow in this resolution are: (1) to keep > mandatory updates to a minimum and (2) not to degrade the logic of > the metamodel by catering to lookup optimizations in particular > implementation designs. I really don't know what you mean by the above. The change you are proposing is actually more extensive than the one that I would like to see, fair enough, you would like to see only one association change in the metamodel, and I am proposing two. I should have said a little more. The principal is NOT to minimize changes to the METAMODEL, I am trying to minimize updates to model elements upon the introduction and removal of dependencies from the users model. since completely changes the meaning of Dependency with respect to both the original FAS definition and the UML 1.x definition (it also introduces more changes than my proposal). I am not sure how one judges the extent to which a model is "degraded" since that implies some kind of value judgement. However, it certainly seems to me that your proposal is much more of a degradation if the above criteria are applied (a degradation of the concept at the very least). When a class contains a reference to another class, one doesn't need a UML dependency element in the model for the dependency to be there. In such a case, there is a straight reference from the client to the supplier, and no intermediary UML Dependency element is involved. the IBM counterproposal is founded on confusing the purpose and use of the UML Dependency element, which will be used to assert the traceability of one model element to another, with actual dependencies found in compilation units.. > 5. Summary of the resolution > For the same reason it undesirable to update all the suppliers of a > dependency when adding or removing a dependency relationship from a > model, it is also undesirable to have to update all the clients. As I argued above, it is nonsensical to equate the clients and the suppliers of a dependency. It would be nonsensical to equate the clients and suppliers, dependency is not a symmetrical relationship. but I am not proposing we equate them. I am arguing here that 1. The text says it can be a modeler's choice whether he/she chooses (for example) to say that the PIM element depends on the PSM (as an abstraction, say) or whether the PSM depends on the PIM, as a realization. And that being the case, it is clear that there is NO INTRINSIC reference in the client that has to point at the supplier. 2. if there are problems in having suppliers support "where used" by storing references, there are also problems in having clients do the same.. Keeping The whole notion of dependency is founded on this differentiation. Your view of a dependency as an optional semantics-free model element, which can be added and removed without effect, completely decouples it from its common and intuitive interpretation. This is my main objection. The concept you seem to be looking for here is not Dependency but Association which owns its ends. Since we now have such a concept, I see no reason to change Dependency just to provide the same capability. This redundancy will certainly lead to confusion. > 6. Dependency is not a direct reference to Supplier in the Client. > If the reason for the dependency is that each client already has a > reference to the dependency.s suppliers, this is intrinsic to the > client with or without the UML dependency relationship being in the > model. This is the case, for example, with Class declarations that > include references to other Classes. Such dependencies are not > references to a UML Dependency element, and have nothing to do with > issue 6630, although they can be modeled using a UML Dependency, > they remain even when such a Dependency model element is removed. > To consider each of the UML model element clients as requiring > internal references to its dependency relationships, is to confuse > the UML model elements with compilation units in a programming > language, which imply their dependencies by the presence of > unresolved references. UML model dependencies are not always like > that. (Just read through the text and look at the specializations of > Dependency !) I repeat what I said above: a few of the specializations of Dependency are misguided and should not be used as a justification for further any model changes. > 7. Consistency with text requires equal handling of client and supplier. > The spec states that the direction of a dependency is an arbitrary > choice on the part of the modeler. Hence there is no reason to > enshrine an assumption that the client will have a reference to > something that makes the client .truly. dependent on that something. This is a repeat of your point 6, relly. In effect, it argues that, rather than fix the problem with mis-specialization of Dependency, we should apply such misuse consistently. > 8. Motivation for properties to support navigability is lookup optimization > Putting references to the dependency in the supplier is merely a > implementation choice to speedup lookups to find where the supplier > is used. Likewise, putting references to its dependencies in > clients is a common way to facilitate looking up the dependencies, > but the dependency objects are the only objects one needs in a > logical sense, which is the sense that matters in defining the > abstract syntax. If iterating through them is slow, this is a > performance issue to be solved by implementation strategies, not by > changing the logical metamodel. That is your interpretation of the motivation, but as I hope I cleared up above, the reasons are different: (1) To ensure that the concept of Dependency has a semantics that match what most people expect (2) To avoid redundant modeling concepts (since we can already achieve what your proposal does with Associations) > 9. Resolution must support exchange of partial models. > Any resolution other than the one proposed here will limit the > ability to exchange partial models meaningfully, since the clients > will be referentially incomplete without also exchanging the dependencies. This is a red herring. The problem of partial models is orthogonal and will not disappear if we change the definition of Dependency. The problem of partial models in this particular case is not orthogonal. IBM's counterproposal will demonstrably and certainly make it impossible to exchange a model of a client without also including all the dependencies to which it contains references, and those dependencies in turn will require the inclusion of all the suppliers to which they refer. Keeping the client and supplier with references to their dependencies is a simpler case of expanding the network of what is required for referential integrity. This will play havoc with the ability to exhange models, and will lead to people working around by not using dependencies to show traceability. > Common use cases for dependency relationships in UML models include > adding dependencies (which include abstraction and refinement) to > show what requirements a given implementation satisfies. To be > unable to exchange the requirement model (a PIM) without the > implementation model (a PSM), or the implementation without the > requirements would be a serious problem. I don't understand your example. It seems to me that the Dependency would normally be from a PSM to a PIM (I thought we are discouraging the use of these terms) not the other way around. Fine, supposing the dependency is from the PSM to the PIM, the PSM will not be able to be exchanged without including the PIM along with it, because the PIM will be left with unresolved references to the dependency elements. > 10. Consistent with right of vendors to optimize lookups thru references. Again, I don't understand what is intended here. Vendors can certainly do that, whatever choice we make in this case. What is intended here, is that if IBM wants to make clients include references to dependency relationships, IBM is free to do so, as long as that reference doesn't get into the XMI and the UML 2 Metamodel. > Tool builders may wish to make it easy to look up dependencies in > which a given model element plays either a client or a supplier > role. To support this, they are free to add references to the > dependencies in their client elements, but such references are a > implementation detail outside the scope of metamodel compliance, and > will not be included in the XMI. You are really confusing me here. The information on the targets and sources of dependencies has to be in the model somewhere, so it will be in the XMI in one form of another. To summarize: I really think that your resolution will make a bad situation (i.e., the misuse of the current Dependency concept to model things such as "trace") worse. It will also change the expected intuitive meaning of the Dependency concept and also render it completely redundant. I think that these are serious issues. Regards, Bran To: "Karl Frank" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: 6630 not in the 4th draft of Ballot 26 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 28 Sep 2004 13:11:54 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/28/2004 13:11:55, Serialize complete at 09/28/2004 13:11:55 Karl, I just noticed that, by removing the "clientDependency" role name, you would invalidate other parts of the metamodel, some OCL constraints, and a some text in the spec all of which reference this role name. Your resolution mention only one of these places (the change to the Interfaces diagram), but there are 11 places in the spec where this role name is referenced. Your resolution should include the requisite changes for these other cases as well (just do a global search on the role name in the latest version of the spec). I am not sure, however, how you plan to deal with these cases. The rest is my response to your response: > I should have said a little more. The principal is NOT to minimize > changes to the METAMODEL, I am trying to minimize updates to model > elements upon the introduction and removal of dependencies from the > users model. But, this exemplifies the problem with how you view dependencies. The vast majority of dependencies are not semantic-free elements so that, in general, adding them to or removing them from a model is typically rife with side effects. For instance, when I draw a realization arrow from a Class to an Interface, this has all kinds of semantic implications on the class. (In some tools, this may be interpreted as a directive to auto-generate a set of corresponding features for the class.) For those dependencies for which we have no semantics (such as trace or abstraction), it should be argued that they are not dependencies at all but either kinds of directed relationship or, possibly, stereotypes of Association. > When a class contains a reference to another class, one doesn't need > a UML dependency element in the model for the dependency to be > there. In such a case, there is a straight reference from the > client to the supplier, and no intermediary UML Dependency element > is involved. That depends on the kind of reference. For instance, an InterfaceRealization, Usage, Substitution all require a dependency element and they all have semantic side-effects. > the IBM counterproposal is founded on confusing the purpose and use > of the UML Dependency element, which will be used to assert the > traceability of one model element to another, with actual > dependencies found in compilation units.. There you go again: you have a very narrow view of what dependencies are for. In fact, you have chose one of the worst examples of the misuse of the concept to make your point: trace. (In my view, trace should have never been a kind of dependency.) Remember that things such as InterfaceRealization, Usage, Substitution are also kinds of Dependency and they have nothing to do with traces. > It would be nonsensical to equate the clients and suppliers, > dependency is not a symmetrical relationship. > but I am not proposing we equate them. > I am arguing here that > 1. The text says it can be a modeler's choice whether he/she chooses > (for example) to say that the PIM element depends on the PSM (as an > abstraction, say) or whether the PSM depends on the PIM, as a > realization. And that being the case, it is clear that there is NO > INTRINSIC reference in the client that has to point at the supplier. ...and my point was that this is bad text and needs to be fixed. We should not exacerbate and institutionalize a bad decisions. > 2. if there are problems in having suppliers support "where used" by > storing references, there are also problems in having clients do the same.. This is only true in cases where the dependency is free of semantics -- in which case, there really is no asymmetry between clients and suppliers. I am arguing that we need to distinguish Dependencies (such as InterfaceRealization, for which we have clear semantics) from other kinds of relationships (such as Trace or Derive) for which we have not specified any meaningful semantics. However, this is not something we can do in the FTF. > The problem of partial models in this particular case is not > orthogonal. IBM's counterproposal will demonstrably and certainly > make it impossible to exchange a model of a client without also > including all the dependencies to which it contains references, and > those dependencies in turn will require the inclusion of all the > suppliers to which they refer. > > Keeping the client and supplier with references to their > dependencies is a simpler case of expanding the network of what is > required for referential integrity. This will play havoc with the > ability to exhange models, and will lead to people working around by > not using dependencies to show traceability. I don't think this is an issue. Even in UML 1.x it was possible to exchange partial models (e.g., Rose). I fail to see how my proposal makes this situation any different. By their very nature, partial models will have dangling references that tools have to resolve in one way or another. Whether those dangling references belong to dependencies or not is moot. > Fine, supposing the dependency is from the PSM to the PIM, the PSM > will not be able to be exchanged without including the PIM along > with it, because the PIM will be left with unresolved references to > the dependency elements. Unresolved references are something that tools will have to deal with, as I said. It is a known issue and, fortunately, so are the solutions. They are actually not that difficult to implement. It's done all the time. > > 10. Consistent with right of vendors to optimize lookups thru references. > > Again, I don't understand what is intended here. Vendors can > certainly do that, whatever choice we make in this case. > > What is intended here, is that if IBM wants to make clients include > references to dependency relationships, IBM is free to do so, as > long as that reference doesn't get into the XMI and the UML 2 Metamodel. I don't believe that there is a requirement that an XMI of a model needs to be referentially complete. If so, you can forget about partial models. Cheers...Bran Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 28 Sep 2004 10:14:13 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: Revision of 6630 incorporating feedback In the case in point in the proposed resolution to 6630, it is the super-association end, the subsetee, that lost its name, not the subsetting end. The superassociation end had been named 'clientDependency,' and that was removed at the request of Jim and Thomas. Hence it was impossible for the subsetting end to be annotated as {subsets } because there was no reference to put in for . But there is a named association end further up the heirarchy, ownedMember, and the interfaceRealization end will, with this resolution, be annotated as subsetting ownedMember. This, though, changes the meaning of the model, right? We will say {subsets ownedMember} which is not the same constraint as {subsets clientDependency}, but only half the story. 6.5.1 of Super book 040829 tells us that {subsets ownedMember} means this association specializes ownedMember. 6.5.2 says "The constraint {subsets endA} means that the association end to which this constraint is applied is a specialization of association end endA that is part of the association being specialized." It could be argued: Well, yes, this does not directly specialize ownedMember, it is true that it actually specializes theEndFormerlyKnownAsClientDependency; but it is an indirect specialization of ownedMember. When we see this kind of rationalization in politics, we accept it as par for the course, when in advertising, we feel cheated, and when in the courtroom, we regard it as perjury. Another approach is, along with the truth and nothing but the truth, to tell the whole truth. But that requires a role name. Some may feel that the class inheritance implies the true association specialization. I can't find any text that says this, certainly not at 7.3.3, and i don't have any proof that the implication is valid. Whether implied or not, it would be kind to our readers to specify this, if it is what we intend. And to explain in detail how to read the spec in these cases. Yes, that is a different issue. But, missing that specification and explanation, i feel we should have the end names we need to say the whole of what we mean. Cordially, Joaquin Subject: RE: 6630 not in the 4th draft of Ballot 26 Date: Tue, 28 Sep 2004 11:37:29 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6630 not in the 4th draft of Ballot 26 Thread-Index: AcSlfj4p9PQ6M/wYTgihrHDQbXaVpgACe+qw From: "Karl Frank" To: "Branislav Selic" Cc: , X-OriginalArrivalTime: 28 Sep 2004 18:37:32.0697 (UTC) FILETIME=[3769D890:01C4A58A] Some answers inline, but a compromise offered in last line. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, September 28, 2004 1:12 PM To: Karl Frank Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: 6630 not in the 4th draft of Ballot 26 Karl, I just noticed that, by removing the "clientDependency" role name, you would invalidate other parts of the metamodel, some OCL constraints, and a some text in the spec all of which reference this role name. Exactly the same holds of removing the "supplierDependency" role name. It too is is used in an OCL constraint and so on. We can never fix issues without such fixes. Your resolution mention only one of these places (the change to the Interfaces diagram), Fair enough. I will add those places to what needs to change. but there are 11 places in the spec where this role name is referenced. Your resolution should include the requisite changes for these other cases as well (just do a global search on the role name in the latest version of the spec). I am not sure, however, how you plan to deal with these cases. They are simple to deal with because they are just more of the same. For example, the metamodel assumes that the location for a deployment needs to know about the deployments that will use that location, and depends upon what is to be deployed there. this is a good example of what is wrong with the clientDependency property in the client modelElement. to have the model of your deployment locations depend on the dependencies that use that location is very bad modeling. IMHO. The rest is my response to your response: > I should have said a little more. The principal is NOT to minimize > changes to the METAMODEL, I am trying to minimize updates to model > elements upon the introduction and removal of dependencies from the > users model. But, this exemplifies the problem with how you view dependencies. It is clear that you want to model dependencies by actually making the client dependent. The paradigm for this approach is generalization. And it is clear to me that users of UML already do and in future will continue to put into models various kinds of trace relationships that do not actually change the properties of the clients. You have cited trace as an example of the problem, and I agree that it is an example of the problem for the IBM theory of dependency. Maybe we can compromise. There are extraneous and redundant subclasses of dependency. By eliminating one of them, we could add a distinction between the IBM kind of dependency and the Borland kind, without actually increasing the number of dependency metaclasses. To: "Karl Frank" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: 6630 not in the 4th draft of Ballot 26 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 28 Sep 2004 15:14:47 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/28/2004 15:14:48, Serialize complete at 09/28/2004 15:14:48 Karl, > I am not sure, however, how you > plan to deal with these cases. > > They are simple to deal with because they are just more of the > same. For example, the metamodel assumes that the location for a > deployment needs to know about the deployments that will use that > location, and depends upon what is to be deployed there. this is a > good example of what is wrong with the clientDependency property in > the client modelElement. to have the model of your deployment > locations depend on the dependencies that use that location is very > bad modeling. IMHO. I am not sure that this is what was intended in the model (remember this was done when navigability was tied to ownership). But my point was that changing the Components and Deployment sections should not be done without some discussion and I we've run out of time for that. > It is clear that you want to model dependencies by actually making > the client dependent. It is not just what I want, but what is already in the spec for at least some kinds of Dependency. Unfortunately, the metamodel is not consistent in this. > And it is clear to me that users of UML already do and in future > will continue to put into models various kinds of trace > relationships that do not actually change the properties of the clients. 100% agreement. What I want to say, though, is that I don't think such traces should be kinds of Dependency. > You have cited trace as an example of the problem, and I agree that > it is an example of the problem for the IBM theory of dependency. > > Maybe we can compromise. There are extraneous and redundant > subclasses of dependency. By eliminating one of them, we could add > a distinction between the IBM kind of dependency and the Borland > kind, without actually increasing the number of dependency metaclasses. I am not sure which one you want to eliminate (Realization? Usage?) but I don't see how it solves the problem and, again, I don't think we can do anything that radical without a substantial discussion. It really looks like an RTF item. What I would like to do is to separate out true Dependencies from other warm-fuzzy kinds of relationships (trace, refine, derive, etc.) in which the link between client and supplier is loosely defined at best. Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 28 Sep 2004 11:01:24 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: updating all the mystery items Draft Ballot 26 Issue 6630 "For the same reason it undesirable to update all the suppliers of a dependency when adding or removing a dependency relationship from a model, it is also undesirable to have to update all the ." Cordially, Joaquin Subject: RE: Resolution proposals for classes and Infrastructure Date: Thu, 11 Aug 2005 20:08:59 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resolution proposals for classes and Infrastructure Thread-Index: AcWewITOG6i8q30ITySBu+6d0nZeUwACOzWA From: "Pete Rivett" To: "Branislav Selic" , X-Virus-Scanned: by amavisd-new at sentraliant.com This is generally OK - some minor comments (and philosophy - sorry) below. In 6630 there is a slight lack of clarity in the resolution as to whether the property is only to be made non-navigable (for which we have no notation) or in addition whether its ownership should be changed from the Class to the Association: I think the latter is intended but it could be made clearer. Even if we do clarify I'd probably abstain on the issue: I can see the argument for the resolution in terms of consistency, but remain unhappy about how the new definition of navigability is applied in the UML metamodel itself (in fact it has not been explicitly applied - we kept the metamodel as it was despite changing what navigability meant). The original issue 6630 is IMHO somewhat muddled when it refers to an element 'knowing about its dependencies': model elements cannot 'know' anything and IMHO such anthropomorphic phrasing tends to really cloud discussion. In practice any model-processing application/tool (for which the UML metamodel is really the design/specification model) will need to have direct access to the elements at both ends of any such Dependency (if only to allow the user to draw the line). And the intention of UML is to allow such tools to perform impact analysis etc (i.e. bidirectional navigation): so the fact that we don't reflect that expected access in the metamodel is a shame: we're not talking about a 'real' business application here. -------- For 6692 I agree that it should be Close no change, but don't think the response really answers the question of when to use derived attributes vs operations. I don't agree that ". Derived attributes are typically used when the computation is judged to be inefficient in some sense. " One reason could be if there is the possibility of setting the value (which we have in the metamodel itself). Another if there may be the need to serialize it (e.g. via XMI). My own view is that if something represents 'data' then it should be a derived attribute since it gives a lot more capability and provides a more uniform interface to client tools. In fact I don't think we do have any (non-helper) operations as part of the metamodel itself. In the specific case of lowerBound() the reason for an operation is that this is not a true part of the metamodel but a helper operation used only in the constraint for specifying the derived attribute. --------- There is a typo in 8015: there is an extraneous 'in' before 'with': "Compositions may be linked in a directed acyclic graph in with transitive deletion characteristics" -------- One thing we need to add, I suggest to the resolution to 6492, is the convention for naming Associations: CMOF requires all Associations to have a name, and none at all are explicitly named in the Infra or Super specs. The convention I used in creating the XMI (which was also used in the UML 1.x XMI) is to name associations as "A_" followed by the name of the 1st end followed by "_" followed by the name of the 2nd end (where the name ends are as per the current proposed resolution if not explicit). PS we may want to add something to the following in the 6492 resolution text "in general, there is no need to refer to them explicitly either in the text or in formal constraints" while true, there is the need to refer to them in generated MOF language bindings for the UML metamodel (which is why CMOF requires the names). So I suggest adding "though they may be needed for other purposes such as MOF language bindings that use the metamodel." Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, 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 11, 2005 10:42 PM To: uml2-rtf@omg.org Subject: Resolution proposals for classes and Infrastructure Here are 10 resolution proposals that I hope to submit to ballot 8. Most of them are in the Classes and Infrastructure areas, so they should probably be carefully scrutinized. Cheers, Bran To: "Pete Rivett" Cc: uml2-rtf@omg.org Subject: RE: Resolution proposals for classes and Infrastructure X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 12 Aug 2005 19:22:32 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/12/2005 19:22:34, Serialize complete at 08/12/2005 19:22:34 Thanks for the feedback, Pete. > In 6630 there is a slight lack of clarity in the resolution as to > whether the property is only to be made non-navigable (for which we > have no notation) or in addition whether its ownership should be > changed from the Class to the Association: I think the latter is > intended but it could be made clearer. I have added some text to clarify both the intent and the meaning of the resolution. > -------- > For 6692 I agree that it should be Close no change, but don't think > the response really answers the question of when to use derived > attributes vs operations. I don't agree that ". Derived attributes > are typically used when the computation is judged to be inefficient > in some sense. " > One reason could be if there is the possibility of setting the value > (which we have in the metamodel itself). I believe that I mentioned this reason. > Another if there may be the > need to serialize it (e.g. via XMI). Can you please clarify the above point? I am not following the reasoning. > My own view is that if > something represents 'data' then it should be a derived attribute > since it gives a lot more capability and provides a more uniform > interface to client tools. I completely am missing your point on this one as well. > In fact I don't think we do have any > (non-helper) operations as part of the metamodel itself. Not directly in the metamodel, but certainly in the spec. > There is a typo in 8015: there is an extraneous 'in' before 'with': " > Compositions may be linked in a directed acyclic graph in with > transitive deletion characteristics" fixed. Thanks. > One thing we need to add, I suggest to the resolution to 6492, is > the convention for naming Associations: CMOF requires all > Associations to have a name, and none at all are explicitly named in > the Infra or Super specs. > The convention I used in creating the XMI (which was also used in > the UML 1.x XMI) is to name associations as "A_" followed by the > name of the 1st end followed by "_" followed by the name of the 2nd > end (where the name ends are as per the current proposed resolution > if not explicit). Included. > PS we may want to add something to the following in the 6492 resolution text " > in general, there is no need to refer to them explicitly either in > the text or in formal constraints" while true, there is the need to > refer to them in generated MOF language bindings for the UML > metamodel (which is why CMOF requires the names). So I suggest > adding "though they may be needed for other purposes such as MOF > language bindings that use the metamodel." This too was included in the latest version. Thanks again...Bran e-mail: bselic@ca.ibm.com