Issue 6460: UML 2 Issue: definition of navigability (uml2-rtf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: PROBLEM STATEMENT There is no definition for navigability or navigation in the Spec. Other concepts of similar importance, such as visibility, multiplicity, etc., are defined in the Spec, so it is not clear why it should be assumed that this concept does not require a definition. PROPOSED SOLUTION Add definition in Section 4 (Terms and definitions): The navigability of a binary association specifies the ability of an instance of the source classifier to access the instances of the target classifier by means of the association instances (links) that connect them. Navigability is closely related to the possibility of sending messages through associations (a message cannot be sent through an association instance against its navigability, that is, navigability is required for sending messages through associations), but they remain nonetheless different concepts. Resolution: Discussion: This issue was resolved in UML 2.1 where an explanation of navigability was provided (see page 41 top in formal/07-02/05) Revised Text: N/A Disposition: Closed, no change Revised Text: Actions taken: November 7, 2003: received issue February 18, 2005: moved from infrastructure October 27, 2008: closed issue Discussion: End of Annotations:===== ubject: Fw: UML 2 Issue: definition of navigability X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 7 Nov 2003 08:30:39 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 11/07/2003 08:30:44, Serialize complete at 11/07/2003 08:30:44 Issue raised by Gonzalo Genova. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com ----- Forwarded by Branislav Selic/Ottawa/IBM on 11/07/2003 07:45 AM ----- Gonzalo Genova 11/06/2003 01:32 PM To: "'issues@omg.org'" , Branislav Selic/Ottawa/IBM@IBMCA, "'joaquin@acm.org'" cc: "Juan Llorens (inf)" , "J.Miguel Fuentes Torres" Subject: UML 2 Issue: definition of navigability This issue refers to UML 2.0 Infrastructure Specification (ptc/03-09-15) and UML 2.0 Superstructure Specification (ptc/03-08-02). PROBLEM STATEMENT There is no definition for navigability or navigation in the Spec. Other concepts of similar importance, such as visibility, multiplicity, etc., are defined in the Spec, so it is not clear why it should be assumed that this concept does not require a definition. PROPOSED SOLUTION Add definition in Section 4 (Terms and definitions): The navigability of a binary association specifies the ability of an instance of the source classifier to access the instances of the target classifier by means of the association instances (links) that connect them. Navigability is closely related to the possibility of sending messages through associations (a message cannot be sent through an association instance against its navigability, that is, navigability is required for sending messages through associations), but they remain nonetheless different concepts. Issue 6460: UML 2 Issue: definition of navigability (mu2i-ftf) Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: There is no definition for navigability or navigation in the Spec. Other concepts of similar importance, such as visibility, multiplicity, etc., are defined in the Spec, so it is not clear why it should be assumed that this concept does not require a definition. Proposed Solution Add definition in Section 4 (Terms and definitions): The navigability of a binary association specifies the ability of an instance of the source classifier to access the instances of the target classifier by means of the association instances (links) that connect them. Navigability is closely related to the possibility of sending messages through associations (a message cannot be sent through an association instance against its navigability, that is, navigability is required for sending messages through associations), but they remain nonetheless different concepts. Discussion: The following factors are relevant for defining navigability (based on the proposal above, and FTF discussion): § Navigability defines the capability for traversal of associations in that an instance of the source classifier can identify the instances of the target classifier by means of the association instances (links) that connect them; § Navigability defines the capability to send messages: given that traversal provides the ability to identify, then it follows that messages can be sent to the target instances. It should be noted that the converse is not true: instances can send messages based on other forms of target identification, e.g. an instance reference may be passed in as a parameter to an operation, enabling message sending, without an explicit association having been defined. § Navigability does not mean that implementations cannot provide more general access, e.g. 'reverse' traversal. One example is the MOF API, which allows traversal even if an association is not navigable. § Navigability applies to o Binary associations and N-ary associations o Associations where the associationEnds are owned by Classes and associations where the ends are owned by an Association Based on these statements, insert in the Association class, in semantics, as a new paragraph after the first one: A navigable association end means that it is possible to traverse from objects participating in links at the other end(s) of the association to objects participating in links at the navigable end. Disposition: Accepted Issue 6460: UML 2 Issue: definition of navigability (mu2i-ftf) Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: There is no definition for navigability or navigation in the Spec. Other concepts of similar importance, such as visibility, multiplicity, etc., are defined in the Spec, so it is not clear why it should be assumed that this concept does not require a definition. Proposed Solution Add definition in Section 4 (Terms and definitions): The navigability of a binary association specifies the ability of an instance of the source classifier to access the instances of the target classifier by means of the association instances (links) that connect them. Navigability is closely related to the possibility of sending messages through associations (a message cannot be sent through an association instance against its navigability, that is, navigability is required for sending messages through associations), but they remain nonetheless different concepts. Discussion: The following factors are relevant for defining navigability (based on the proposal above, and FTF discussion): § Navigability defines the capability for traversal of associations in that an instance of the source classifier can identify the instances of the target classifier by means of the association instances (links) that connect them; § Navigability defines the capability to send messages: given that traversal provides the ability to identify, then it follows that messages can be sent to the target instances. It should be noted that the converse is not true: instances can send messages based on other forms of target identification, e.g. an instance reference may be passed in as a parameter to an operation, enabling message sending, without an explicit association having been defined. § Navigability does not mean that implementations cannot provide more general access, e.g. 'reverse' traversal. One example is the MOF API, which allows traversal even if an association is not navigable. § Navigability applies to o Binary associations and N-ary associations o Associations where the associationEnds are owned by Classes and associations where the ends are owned by an Association Based on these statements, insert in the Association class, in semantics, as a new paragraph after the first one: A navigable association end means that it is possible to traverse from objects participating in links at the other end(s) of the association to objects participating in links at the navigable end. Disposition: Accepted Issue 6460: UML 2 Issue: definition of navigability (mu2i-ftf) Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: There is no definition for navigability or navigation in the Spec. Other concepts of similar importance, such as visibility, multiplicity, etc., are defined in the Spec, so it is not clear why it should be assumed that this concept does not require a definition. Proposed Solution Add definition in Section 4 (Terms and definitions): The navigability of a binary association specifies the ability of an instance of the source classifier to access the instances of the target classifier by means of the association instances (links) that connect them. Navigability is closely related to the possibility of sending messages through associations (a message cannot be sent through an association instance against its navigability, that is, navigability is required for sending messages through associations), but they remain nonetheless different concepts. Discussion: The following factors are relevant for defining navigability (based on the proposal above, and FTF discussion): § Navigability defines the capability for traversal of associations in that an instance of the source classifier can identify the instances of the target classifier by means of the association instances (links) that connect them; § Navigability defines the capability to send messages: given that traversal provides the ability to identify, then it follows that messages can be sent to the target instances. It should be noted that the converse is not true: instances can send messages based on other forms of target identification, e.g. an instance reference may be passed in as a parameter to an operation, enabling message sending, without an explicit association having been defined. § Navigability does not mean that implementations cannot provide more general access, e.g. 'reverse' traversal. One example is the MOF API, which allows traversal even if an association is not navigable. § Navigability applies to o Binary associations and N-ary associations o Associations where the associationEnds are owned by Classes and associations where the ends are owned by an Association Based on these statements, insert in the Association class, in semantics, as a new paragraph after the first one: A navigable association end means that it is possible to traverse from objects participating in links at the other end(s) of the association to objects participating in links at the navigable end. Disposition: Accepted Issue 6460: UML 2 Issue: definition of navigability (mu2i-ftf) Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: There is no definition for navigability or navigation in the Spec. Other concepts of similar importance, such as visibility, multiplicity, etc., are defined in the Spec, so it is not clear why it should be assumed that this concept does not require a definition. Proposed Solution Add definition in Section 4 (Terms and definitions): The navigability of a binary association specifies the ability of an instance of the source classifier to access the instances of the target classifier by means of the association instances (links) that connect them. Navigability is closely related to the possibility of sending messages through associations (a message cannot be sent through an association instance against its navigability, that is, navigability is required for sending messages through associations), but they remain nonetheless different concepts. Discussion: The following factors are relevant for defining navigability (based on the proposal above, and FTF discussion): § Navigability defines the capability for traversal of associations in that an instance of the source classifier can identify the instances of the target classifier by means of the association instances (links) that connect them; § Navigability defines the capability to send messages: given that traversal provides the ability to identify, then it follows that messages can be sent to the target instances. It should be noted that the converse is not true: instances can send messages based on other forms of target identification, e.g. an instance reference may be passed in as a parameter to an operation, enabling message sending, without an explicit association having been defined. § Navigability does not mean that implementations cannot provide more general access, e.g. 'reverse' traversal. One example is the MOF API, which allows traversal even if an association is not navigable. § Navigability applies to o Binary associations and N-ary associations o Associations where the associationEnds are owned by Classes and associations where the ends are owned by an Association Based on these statements, insert in the Association class, in semantics, as a new paragraph after the first one: A navigable end of an association means that it is possible to traverse from objects participating in links at the other end(s) of the association to objects participating in links at the navigable end. Disposition: Accepted Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6242 (Association not affecting ends), 6460 (definition of navigation), proposed resolutions Date: Tue, 25 May 2004 09:39:25 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIME-Autoconverted: from quoted-printable to 8bit by meles1.mel.nist.gov id i2M6AHPQ000794 X-MailScanner: , Found to be clean, Found to be clean X-NIST-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.9, required 6,autolearn=not spam, BAYES_00 -4.90), X-MailScanner-Information: Please contact your ISP for more information X-MailScanner-From: pete.rivett@adaptive.com X-MS-Has-Attach: X-MS-TNEF-Correlator: Hi all, After discussion with interested folks, here are the proposals for: Super 6243 (Association not affecting ends) Infra 6460 (definition of navigation) The first only affects superstructure, though infrastructure should consider making the same change. The second is a change to shared text in infra and super. Bran, 6243 and 6460 are for super ballot 16. Pete, what is the appropriate time to ballot 6460 in infra? Conrad issueresolution-6243.doc issueresolution-6460.doc Issue 6460: UML 2 Issue: definition of navigability (mu2i-ftf) Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: There is no definition for navigability or navigation in the Spec. Other concepts of similar importance, such as visibility, multiplicity, etc., are defined in the Spec, so it is not clear why it should be assumed that this concept does not require a definition. Proposed Solution Add definition in Section 4 (Terms and definitions): The navigability of a binary association specifies the ability of an instance of the source classifier to access the instances of the target classifier by means of the association instances (links) that connect them. Navigability is closely related to the possibility of sending messages through associations (a message cannot be sent through an association instance against its navigability, that is, navigability is required for sending messages through associations), but they remain nonetheless different concepts. Discussion: The following factors are relevant for defining navigability (based on the proposal above, and FTF discussion): § Navigability defines the capability for traversal of associations in that an instance of the source classifier can identify the instances of the target classifier by means of the association instances (links) that connect them; § Navigability defines the capability to send messages: given that traversal provides the ability to identify, then it follows that messages can be sent to the target instances. It should be noted that the converse is not true: instances can send messages based on other forms of target identification, e.g. an instance reference may be passed in as a parameter to an operation, enabling message sending, without an explicit association having been defined. § Navigability does not mean that implementations cannot provide more general access, e.g. 'reverse' traversal. One example is the MOF API, which allows traversal even if an association is not navigable. § Navigability applies to o Binary associations and N-ary associations o Associations where the associationEnds are owned by Classes and associations where the ends are owned by an Association Based on these statements, insert in the Association class, in semantics, as a new paragraph after the first one: A navigable end of an association means that it is possible to traverse 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. Associations can have navigable ends regardless of how many ends they have. Implementations can support traversal across non-navigable ends, but it is not required. Once an object is found by traversal, messages can be sent to it like any other object. Issue 6460: UML 2 Issue: definition of navigability (mu2i-ftf) Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: There is no definition for navigability or navigation in the Spec. Other concepts of similar importance, such as visibility, multiplicity, etc., are defined in the Spec, so it is not clear why it should be assumed that this concept does not require a definition. Discussion: Based on these statements, insert in the Association class, in semantics, as a new paragraph after the first one: A navigable end of an association means that it is possible to traverse at runtime from objects participating in links at the other end(s) of the association to objects participating in links at the navigable end. A navigable end of an n-ary association means that it is possible to traverse at runtime from a tuple of (n-1) objects participating in links at the other end(s) of th association to the associated object participating in links at the navigable end. If n =2, the case is a binary association, and so it is possible to traverse at runtime from any one object at the other end, to the associated object at the navigable end. This is independent of ownership of the end. Associations can have navigable ends regardless of how many ends they have. Implementations can support traversal across non-navigable ends, but it is not required. Once an object is found by traversal, messages can be sent to it like any other object. Disposition: Resolved Disposition: Resolved Reply-To: From: "Conrad Bock" To: , , Subject: RE: , cl, Issues 6243 (Association not affecting ends), 6460 (defintion of navigation), proposed resolutions Date: Thu, 27 May 2004 14:07:15 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Navigators, Per the joint telecon today, here are the updates to: - 6243 (Association not affecting ends) This is in two versions, one for infra and one for super. The infra proposal includes some minor textual changes to MOF 2 Core. - 6460 (definition of navigation) This is in one version for super and infra. It does not affect MOF 2 Core. Change bars are from the last revision of the proposal. The changes are proposed for infra, super, and MOF 2 Core. Infra will go to ballot next week, and super in ballot 16. Let me know if there are any other comments. Thanks, Conrad issueresolution-6243-super.doc issueresolution-6243-infra.doc Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 May 2004 13:51:55 -0700 To: UML Superstructure FTF , MOF UML Infrastructure FTF From: Joaquin Miller Subject: RE: , cl, Issues 6243 (Association not affecting ends), 6460 (defintion of navigation), proposed resolutions Good work, Conrad and all. 6460: Traversal of an n-ary association towards a navigable end requires that first the objects first be provided for at the remaining n-1 ends be identified. The result of traversal is a collection of objects for the navigable end derived from links in which the other n-1 objects participate. For binary associations n=2, in which case traversal proceeds from one object at the other end to a collection of objects at the navigable end. The objects need not be provided; they must be identified. 6243 (just editing): 1) It was less appropriate for object-oriented applications, which expected that specification of the navigationbility of an association would modify the source class of the navigation by defining an attribute on it to support runtime traversal from instances of the class. 2) The UML 1.x model also separated attributes and associations, even though these are usually different views of the same underlying semantic. That can't be right. Should it be this? The UML 1.x model also separated attributes and association ends, even though these are usually different views of the same underlying semantic. 3) As a separate question: could you go with this? The UML 1.x model also separated attributes and associations, even though these are usually different views of the same underlying semantic. This text is only a discussion, so i don't want to push this suggestion. But attributes and associations do not (necessarily) have the same meaning. 4) It is less appropriate for relational applications and derived associations, which expect that the navigation of an association does not necessarily modify the source class of the navigabilitytion. 5) However, this prevents navigation from both teachers and courses, or at least does not require it in the generated implementation. How about: However, this declares that the association is not navigable from teachers nor from courses, or at least does not require support for navigability in the generated implementation. Or even better: However, this declares that the association is not navigable from teachers nor from courses. To: Edwin Seidewitz Cc: "'conrad.bock@nist.gov'" , "'mof2xmi-ftf@omg.org'" , "'mu2i-ftf@omg.org'" , "'uml2-superstructure-ftf@omg.org'" Subject: RE: , cl, Issues 6242 (Association not affecting ends), 6460 (de finition of navigation), proposed resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 27 May 2004 18:33:01 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 05/27/2004 18:33:06, Serialize complete at 05/27/2004 18:33:06 On a separate topic related to OCL style, and prompted by Ed's comment: > I would note, though, that the resolution to Issue 6242 should include > changing constraint 4 of ReadLinkAction (Section 11.3.28) to replace > "isNavigable = #true" with "isNavigable()". A search of the document seems > to indicate that this is the only current reference to "isNavigable" I learned early in my computing practice that checks of Booleans of the form: (isNavigable = #true) //where isNavigable is a Boolean are redundant, because it is sufficient to say: isNavigable to get the same effect. I am surprised how many experts still make this elementary mistake. There are numerous instances of it in the OCL in the spec. Ed, of course, got it right. Issue 6460: UML 2 Issue: definition of navigability (mu2i-ftf) Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: There is no definition for navigability or navigation in the Spec. Other concepts of similar importance, such as visibility, multiplicity, etc., are defined in the Spec, so it is not clear why it should be assumed that this concept does not require a definition. Proposed Solution Add definition in Section 4 (Terms and definitions): The navigability of a binary association specifies the ability of an instance of the source classifier to access the instances of the target classifier by means of the association instances (links) that connect them. Navigability is closely related to the possibility of sending messages through associations (a message cannot be sent through an association instance against its navigability, that is, navigability is required for sending messages through associations), but they remain nonetheless different concepts. Discussion: The following factors are relevant for defining navigability (based on the proposal above, and FTF discussion): § Navigability defines the capability for traversal of associations in that an instance of the source classifier can identify the instances of the target classifier by means of the association instances (links) that connect them; § Navigability defines the capability to send messages: given that traversal provides the ability to identify, then it follows that messages can be sent to the target instances. It should be noted that the converse is not true: instances can send messages based on other forms of target identification, e.g. an instance reference may be passed in as a parameter to an operation, enabling message sending, without an explicit association having been defined. § Navigability does not mean that implementations cannot provide more general access, e.g. 'reverse' traversal. One example is the MOF API, which allows traversal even if an association is not navigable. § Navigability applies to o Binary associations and N-ary associations o Associations where the associationEnds are owned by Classes and associations where the ends are owned by an Association The changes below reflect these statements. In the Association class: Description section, second paragraph, remove the sentence .Only binary associations may have navigable ends.. Semantics section: Before fourth paragraph, add a new paragraph: 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. Associations can have navigable ends regardless of how many ends they have. Implementations can support traversal across non-navigable ends, but it is not required. Once an object is found by traversal, messages can be sent to it like any other object. In fourth paragraph (counting before above insertion), replace the first and second sentences with: Traversal of an n-ary association towards a navigable end requires that objects first be identified for the remaining n-1 ends. The result of traversal is a collection of objects for the navigable end derived from links in which the other n-1 objects participate. For binary associations n=2, in which case traversal proceeds from one object at the other end to a collection of objects at the navigable end. Disposition: Resolved Bran