Issue 8921: Meaning of navigability (uml2-rtf) Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: The resolution to issue 6460 in the InfrastructureLibrary specification indicates "Implementation 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." This statement may lead to interoperability problems between implementations, is not included in the adopted Superstructure specification, and contradicts constraint [4] for ReadLinkAction which states the end must be navigable. Infrastructure also does not define what it means to send messages to an object so it is not clear what these statements actually mean. It is possible that the resolution to issue 6243 traded coupling between navigability and property ownership for coupling between navigability and tool implementations. Navigability no longer has any well-defined semantics and becomes simply a hint to tool implementors that the traversal should be efficient. I believe this is quite unfortunate and can be avoided by decoupling tool implementations that manipulate models from the meaning of the models themselves. Navigability should continue to mean semantically traversable as specified by ReadLinkAction. This will establish an interoperable meaning across all tools and preserve an important and commonly used semantic. If tools wish to support efficient traversal to non-navigable ends for their purposes, they should feel free to do so. This can be done by maintaining additional information in associations for the non-navigable ends for the tools purpose, or by using crawlers that examine the model and cache information for specific tool purposes. This is manipulating the model for very different purposes than the meaning of the model itself. If it is desired to have some standard means of indicating to tool vendors where non-navigable association ends should be efficiently traversable, this should be done by a separate property perhaps available through the standard profile. It should not be coupled with the semantic meaning of navigability. Resolution: Revised Text: Actions taken: July 1, 2005: received issue Discussion: End of Annotations:===== ubject: Meaning of navigability X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Fri, 1 Jul 2005 11:57:44 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 07/01/2005 09:57:45, Serialize complete at 07/01/2005 09:57:45 The resolution to issue 6460 in the InfrastructureLibrary specification indicates "Implementation 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." This statement may lead to interoperability problems between implementations, is not included in the adopted Superstructure specification, and contradicts constraint [4] for ReadLinkAction which states the end must be navigable. Infrastructure also does not define what it means to send messages to an object so it is not clear what these statements actually mean. It is possible that the resolution to issue 6243 traded coupling between navigability and property ownership for coupling between navigability and tool implementations. Navigability no longer has any well-defined semantics and becomes simply a hint to tool implementors that the traversal should be efficient. Subject: [issue 8921] Meaning of navigability Date: Fri, 1 Aug 2008 16:37:06 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [issue 8921] Meaning of navigability Thread-Index: Acjz5BJR2uw+gXy4Sk+aoLLB47CwWQ== From: "BERNARD, Yves" To: X-OriginalArrivalTime: 01 Aug 2008 14:37:06.0678 (UTC) FILETIME=[12654960:01C8F3E4] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m71EdRqm002681 Hello, I would be very interested to know what is the current state of your thinking about this point. Since the concept (?) of navigability has been decoupled from the end's ownership, it's no more clear to me. No more clear also, what is the impact of the navigability on the dependencies between the associated classes. Inspecting the UML meta-model to get a better understanding, I've noticed the following points that, from my point of view, are more or less related to this issue: 1. Except if I'm wrong, a class that doesn't own the end (property) of one of its associations has no reference (i.e. no "visibility") to this association => how to "navigate"? 2. According to the "Namespace" definition, the only means to be "member" of a Namespace is either to be imported (through an explict import relationship) or to be owned (directly or through inheritance). This definition of the "member" property isn't modified in derived meta-classes (like "Class") => Assuming that no "import" relationship seems specify by the meta-model, how a property could be both "owned" by a class and "member" of an association? 3. There is also something strange with the "Property" meta-class, which is described in the text as a relationship (cf. "Description", §7.3.44, p123) but which has not the "Relationship" meta-class in the list of its ancestors. Regards, Yves BERNARD Avionic Engineering Research Leader AIRBUS France EDYYAI - Engineering, PM & Avionics Research Phone: 33 (0)5 67 19 45 32 Fax: 33 (0)5 61 93 08 83 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=4YuzwJ+XRNsMsVBR4OevFRhM550tQdjl3DAJUsaWJzU=; b=L1M+ZGcbDxCx8Zjgk6um6w+vm2Qk7DeQYKOS2s+psbCtVMjyZ7iFYahSHyrw/UY/WO e2fRt1LInzMWnCBfYsqH1ACGVF0/8sk4/3cIqpbgXHgfsn1PyKFj1UUMBAU7Eci3qQ+r XyxIc1yBuKgLcS6J+LsY8YwlbQri0bqwCVTqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=sTDlOzNAJpuJLayojLOOGL8dNLgC86WbcN6MEQoMuT77g6O3a/18hRbnAUXif/Fgxi dHdc38i58SMp4xowcTC0fCBkt0N68f72mAjc8AvIEQRey4CZPsdTIJUjJ/aNWlUfObcp 95S5cZdREAoy3pQkPlYXkmzSyGdLQbfMn2nFA= Date: Wed, 6 Aug 2008 16:05:41 -0400 From: "Bran Selic" To: "BERNARD, Yves" Subject: Re: [issue 8921] Meaning of navigability Cc: uml2-rtf@omg.org hello M. Bernard, I reply to your query: On Fri, Aug 1, 2008 at 10:37 AM, BERNARD, Yves wrote: Hello, I would be very interested to know what is the current state of your thinking about this point. Since the concept (?) of navigability has been decoupled from the end's ownership, it's no more clear to me. No more clear also, what is the impact of the navigability on the dependencies between the associated classes. The essential idea behind this decoupling is that, in the abstract, navigability should not necessarily have any structural effects on the participating classes -- although it might. That is, navigability is currently defined as the ability to "directly" locate the entity that sits at the opposite end of a navigable link, once one has the the handle (id) of the object at the source of the link. (The term "directly" is quite problematic, as we shall see.) In UML 1, which was very much influenced by the OO languages of the day, navigability was assumed to mean that the object at the source end of the link necessarily had a reference or a pointer to the entities at the opposite end. Consequently, navigability had a direct impact on the structure of the class since it implied ownership of a structural attribute that contained the reference or pointer. However, relatively late in the definition of UML 2, it was pointed out that in database systems, links were realized using means other than pointers or references. For example, a link can be realized by a table entry that is defined independently of either of the classes involved in an association. In such cases, navigability (as defined above), can be achieved without requiring appropriate structural attributes in the associated classes. At the time, we felt that it was necessary to be able to explicitly model both possibilities: the OO model and the database model (a design choice that should, possibly, be reconsidered in the future). To do that, it was decided to allow for explicit specification of who owns the association end: (1) the object (e.g., in the form of a structural attribute representing a reference or a pointer) or (2) the association (e.g., in the form of a database table entry). A new notation was introduced for the second form with the implication being that, if that notation is not used, then the first form applies (i.e., the object owns the association end, and, hence, there is a structural attribute). It is clear that both of these models support navigability as defined above. Consequently, navigability lost much of its significance, since it was originally intended as a means of distinguishing between the two variants of association end ownership -- but was, unfortunately, masked out by a misleading generalization. In my view, the latest definition of navigability means that is not a particularly useful notion -- especially given the difficulty of defining what "direct" access to the entity at the opposite end means in any practical sense. End ownership is a much more important concept, since it has an impact on the structure of a class definition. However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit caveat about this in section 6). The misfortune here is that this problem was identified too late in the evolution of UML and that the old convention was far too established to be easily eradicated. Cheers, -- Bran Selic Malina Software Corp. Subject: RE: [issue 8921] Meaning of navigability Date: Thu, 7 Aug 2008 10:09:09 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [issue 8921] Meaning of navigability Thread-Index: Acj3/878y/2mpoJ4Tm6U+skONytpSQAWktHg From: "BERNARD, Yves" To: "Bran Selic" Cc: X-OriginalArrivalTime: 07 Aug 2008 08:09:09.0561 (UTC) FILETIME=[DEA19A90:01C8F864] Thank you very much for this focus. I've a better understanding of the situation, now ! I agree on the ambiguity of "directly" and I would add that, as is, the definition of the navigability is incomplete because the starting point for the localization is not specified: is it the opposite end or the association itself? It cannot be "locate in the absolute" for serveral reasons. One of them is that "directly" implies to have a starting point for reference. According to the current UML meta-model, we can say that it's always possible to locate in a very simple way ("directly"?) any association ends from the association, are they owned or not, thank to the memberEnd association role of the Association meta-class. In the case of an association implemented in a separate database table, the only way to "locate" the associated entities is to "start" from the association. Indeed, assuming that the association has no impact on the structure of the associated table implies that they have no means to store information about associations of their individuals. This association table, definitely, uses a reference/pointer (called "foreign key") that is no more than the Property of the corresponding association end that is owned by... the association table ! ;o) Regarding the new notation, I've not the same understanding than yours. Cf. §7.3.3, p42: "the absence of the dot signifies ownership by the association. Stated otherwise, when applying this notation to a binary association in a user model, the dot will be omitted only for ends which are not owned by a classifier " Then, the new notation is not corresponding to the ownership by the association (your "(2)") but to the ownership by the associated classifier (your "(1)") what could generate ascending compatibility issues... Cheers, Yves -----Message d'origine----- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : mercredi 6 août 2008 22:06 À : BERNARD, Yves Cc : uml2-rtf@omg.org Objet : Re: [issue 8921] Meaning of navigability hello M. Bernard, I reply to your query: On Fri, Aug 1, 2008 at 10:37 AM, BERNARD, Yves wrote: Hello, I would be very interested to know what is the current state of your thinking about this point. Since the concept (?) of navigability has been decoupled from the end's ownership, it's no more clear to me. No more clear also, what is the impact of the navigability on the dependencies between the associated classes. The essential idea behind this decoupling is that, in the abstract, navigability should not necessarily have any structural effects on the participating classes -- although it might. That is, navigability is currently defined as the ability to "directly" locate the entity that sits at the opposite end of a navigable link, once one has the the handle (id) of the object at the source of the link. (The term "directly" is quite problematic, as we shall see.) In UML 1, which was very much influenced by the OO languages of the day, navigability was assumed to mean that the object at the source end of the link necessarily had a reference or a pointer to the entities at the opposite end. Consequently, navigability had a direct impact on the structure of the class since it implied ownership of a structural attribute that contained the reference or pointer. However, relatively late in the definition of UML 2, it was pointed out that in database systems, links were realized using means other than pointers or references. For example, a link can be realized by a table entry that is defined independently of either of the classes involved in an association. In such cases, navigability (as defined above), can be achieved without requiring appropriate structural attributes in the associated classes. At the time, we felt that it was necessary to be able to explicitly model both possibilities: the OO model and the database model (a design choice that should, possibly, be reconsidered in the future). To do that, it was decided to allow for explicit specification of who owns the association end: (1) the object (e.g., in the form of a structural attribute representing a reference or a pointer) or (2) the association (e.g., in the form of a database table entry). A new notation was introduced for the second form with the implication being that, if that notation is not used, then the first form applies (i.e., the object owns the association end, and, hence, there is a structural attribute). It is clear that both of these models support navigability as defined above. Consequently, navigability lost much of its significance, since it was originally intended as a means of distinguishing between the two variants of association end ownership -- but was, unfortunately, masked out by a misleading generalization. In my view, the latest definition of navigability means that is not a particularly useful notion -- especially given the difficulty of defining what "direct" access to the entity at the opposite end means in any practical sense. End ownership is a much more important concept, since it has an impact on the structure of a class definition. However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit caveat about this in section 6). The misfortune here is that this problem was identified too late in the evolution of UML and that the old convention was far too established to be easily eradicated. Cheers, -- Bran Selic Malina Software Corp. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=gHuL6SwOuq6sxhojsxq/udT3VH8eNPIstnTeZD7yQnU=; b=Sg+/07Sm16wJcmvvb9RIYThaTXm+t6jtSNkUNFTMWraEM733dbnc+5BH0wjQ35JDS3 uIqTtNmnrihy4N1e8QGSFYbVefTEwdwcvhh1gnTi1SozQBYyfTPHFJq+IhuIPVwBRDeL f9ye0/LbyqT/p869yabm670ZficiWgNqi/TiY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=mF4j+DVhj6AGOFoXk2DzilK5k+V2BXp3Dcldj6VZU0oYsl7Ae16/PFJUsCDqf1dRBS 3isI0z+sB8iVN7YFseUOH11hkcpKmo2GCdU/9diN1O/gWjWXhvxlIFejIYY1vbiTuq92 CiopE8YPGQScmLpcYmjwJyiP79TYO5AJVRtrE= Date: Thu, 7 Aug 2008 06:00:23 -0400 From: "Bran Selic" To: "BERNARD, Yves" Subject: Re: [issue 8921] Meaning of navigability Cc: uml2-rtf@omg.org On Thu, Aug 7, 2008 at 4:09 AM, BERNARD, Yves wrote: Regarding the new notation, I've not the same understanding than yours. Cf. §7.3.3, p42: "the absence of the dot signifies ownership by the association. Stated otherwise, when applying this notation to a binary association in a user model, the dot will be omitted only for ends which are not owned by a classifier " Then, the new notation is not corresponding to the ownership by the association (your "(2)") but to the ownership by the associated classifier (your "(1)") what could generate ascending compatibility issues... My apologies for the incorrect statement there. This notation is so new and so little used that I'd forgotten the details and was too lazy to check. Thanks for the correction. Cheers...Bran Cheers, Yves -----Message d'origine----- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : mercredi 6 août 2008 22:06 À : BERNARD, Yves Cc : uml2-rtf@omg.org Objet : Re: [issue 8921] Meaning of navigability hello M. Bernard, I reply to your query: On Fri, Aug 1, 2008 at 10:37 AM, BERNARD, Yves wrote: Hello, I would be very interested to know what is the current state of your thinking about this point. Since the concept (?) of navigability has been decoupled from the end's ownership, it's no more clear to me. No more clear also, what is the impact of the navigability on the dependencies between the associated classes. The essential idea behind this decoupling is that, in the abstract, navigability should not necessarily have any structural effects on the participating classes -- although it might. That is, navigability is currently defined as the ability to "directly" locate the entity that sits at the opposite end of a navigable link, once one has the the handle (id) of the object at the source of the link. (The term "directly" is quite problematic, as we shall see.) In UML 1, which was very much influenced by the OO languages of the day, navigability was assumed to mean that the object at the source end of the link necessarily had a reference or a pointer to the entities at the opposite end. Consequently, navigability had a direct impact on the structure of the class since it implied ownership of a structural attribute that contained the reference or pointer. However, relatively late in the definition of UML 2, it was pointed out that in database systems, links were realized using means other than pointers or references. For example, a link can be realized by a table entry that is defined independently of either of the classes involved in an association. In such cases, navigability (as defined above), can be achieved without requiring appropriate structural attributes in the associated classes. At the time, we felt that it was necessary to be able to explicitly model both possibilities: the OO model and the database model (a design choice that should, possibly, be reconsidered in the future). To do that, it was decided to allow for explicit specification of who owns the association end: (1) the object (e.g., in the form of a structural attribute representing a reference or a pointer) or (2) the association (e.g., in the form of a database table entry). A new notation was introduced for the second form with the implication being that, if that notation is not used, then the first form applies (i.e., the object owns the association end, and, hence, there is a structural attribute). It is clear that both of these models support navigability as defined above. Consequently, navigability lost much of its significance, since it was originally intended as a means of distinguishing between the two variants of association end ownership -- but was, unfortunately, masked out by a misleading generalization. In my view, the latest definition of navigability means that is not a particularly useful notion -- especially given the difficulty of defining what "direct" access to the entity at the opposite end means in any practical sense. End ownership is a much more important concept, since it has an impact on the structure of a class definition. However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit caveat about this in section 6). The misfortune here is that this problem was identified too late in the evolution of UML and that the old convention was far too established to be easily eradicated. Cheers, -- Bran Selic Malina Software Corp. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. -- Bran Selic Malina Software Corp. From: "Nerijus Jankevicius" To: "Bran Selic" , "BERNARD, Yves" Cc: Subject: Re: [issue 8921] Meaning of navigability Date: Tue, 12 Aug 2008 15:03:56 +0300 X-Mailer: Microsoft Windows Mail 6.0.6000.16480 Bran, >>However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used >>in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit >>caveat about this in section 6). Our tool supports this notation since introduction, but it is disabled by default (is optional), because it will distort all old customers diagrams (dot on association will be added on ALL diagrams). Actually, for me it always look like it is an error in the spec, because this notation is added on regular case (when end is owned by classifier) instead of specific case (property is owned by association). As I see from your email, you intuitive would like to see this notation when end is owned by association also. Maybe this is misunderstanding and we should change that? Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Bran Selic To: BERNARD, Yves Cc: uml2-rtf@omg.org Sent: Wednesday, August 06, 2008 11:05 PM Subject: Re: [issue 8921] Meaning of navigability hello M. Bernard, I reply to your query: On Fri, Aug 1, 2008 at 10:37 AM, BERNARD, Yves wrote: Hello, I would be very interested to know what is the current state of your thinking about this point. Since the concept (?) of navigability has been decoupled from the end's ownership, it's no more clear to me. No more clear also, what is the impact of the navigability on the dependencies between the associated classes. The essential idea behind this decoupling is that, in the abstract, navigability should not necessarily have any structural effects on the participating classes -- although it might. That is, navigability is currently defined as the ability to "directly" locate the entity that sits at the opposite end of a navigable link, once one has the the handle (id) of the object at the source of the link. (The term "directly" is quite problematic, as we shall see.) In UML 1, which was very much influenced by the OO languages of the day, navigability was assumed to mean that the object at the source end of the link necessarily had a reference or a pointer to the entities at the opposite end. Consequently, navigability had a direct impact on the structure of the class since it implied ownership of a structural attribute that contained the reference or pointer. However, relatively late in the definition of UML 2, it was pointed out that in database systems, links were realized using means other than pointers or references. For example, a link can be realized by a table entry that is defined independently of either of the classes involved in an association. In such cases, navigability (as defined above), can be achieved without requiring appropriate structural attributes in the associated classes. At the time, we felt that it was necessary to be able to explicitly model both possibilities: the OO model and the database model (a design choice that should, possibly, be reconsidered in the future). To do that, it was decided to allow for explicit specification of who owns the association end: (1) the object (e.g., in the form of a structural attribute representing a reference or a pointer) or (2) the association (e.g., in the form of a database table entry). A new notation was introduced for the second form with the implication being that, if that notation is not used, then the first form applies (i.e., the object owns the association end, and, hence, there is a structural attribute). It is clear that both of these models support navigability as defined above. Consequently, navigability lost much of its significance, since it was originally intended as a means of distinguishing between the two variants of association end ownership -- but was, unfortunately, masked out by a misleading generalization. In my view, the latest definition of navigability means that is not a particularly useful notion -- especially given the difficulty of defining what "direct" access to the entity at the opposite end means in any practical sense. End ownership is a much more important concept, since it has an impact on the structure of a class definition. However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit caveat about this in section 6). The misfortune here is that this problem was identified too late in the evolution of UML and that the old convention was far too established to be easily eradicated. Cheers, -- Bran Selic Malina Software Corp. Subject: RE: [issue 8921] Meaning of navigability Date: Tue, 12 Aug 2008 09:11:49 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [issue 8921] Meaning of navigability thread-index: Acj8dTJUhdfkZW80SJm9i2FL9eYfywABoZkn From: "Ed Seidewitz" To: "Nerijus Jankevicius" , "Bran Selic" , "BERNARD, Yves" Cc: Actually, in UML 1, association ends where really, in effect, _always_ owned by the _association_. Remember that in UML 1 there was no general concept of "property" and attributes were formalized in the abstract syntax separately from association ends (known as "association roles" in UML 1). The idea in UML 1 that associations where parallel modeling constructs to classes, not a reflection of the OO concept of "referential attributes" owned by classes, came from the work of Rumbaug, Blaha, et al. So, the argument was that making classifiers own navigable associations by default in UML 2 was actually in unwarranted change to what had been the norm for UML 1. With the new notation, leaving the dot off gives diagrams that look like UML 1 with a similar semantics for associations to UML 1, Putting the dot on gives the new UML 2 semantics of association ends owned by classifiers. Of course, to be honest, the majority of casual modelers, I think, did not look at associations in UML 1 in the "official" way. Instead, they looked at them as a reflection of the typical OOP implementation they gave them. This seems to have been reflected in the original default "navigation is ownership" rule in UML 2. So, the current ownership notation may or may not be intuitive for current UML modelers. But it is a consistent, upward compatible change from UML 1. And it, despite the confusion it does seem to cause, the current rule was not a mistake or accident. (By the way, I don't particularly like the notation myself, but that is a different matter!) -- Ed -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Tue 8/12/2008 8:03 AM To: Bran Selic; BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: [issue 8921] Meaning of navigability Bran, >>However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used >>in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit >>caveat about this in section 6). Our tool supports this notation since introduction, but it is disabled by default (is optional), because it will distort all old customers diagrams (dot on association will be added on ALL diagrams). Actually, for me it always look like it is an error in the spec, because this notation is added on regular case (when end is owned by classifier) instead of specific case (property is owned by association). As I see from your email, you intuitive would like to see this notation when end is owned by association also. Maybe this is misunderstanding and we should change that? Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Bran Selic To: BERNARD, Yves Cc: uml2-rtf@omg.org Sent: Wednesday, August 06, 2008 11:05 PM Subject: Re: [issue 8921] Meaning of navigability hello M. Bernard, I reply to your query: On Fri, Aug 1, 2008 at 10:37 AM, BERNARD, Yves wrote: Hello, I would be very interested to know what is the current state of your thinking about this point. Since the concept (?) of navigability has been decoupled from the end's ownership, it's no more clear to me. No more clear also, what is the impact of the navigability on the dependencies between the associated classes. The essential idea behind this decoupling is that, in the abstract, navigability should not necessarily have any structural effects on the participating classes -- although it might. That is, navigability is currently defined as the ability to "directly" locate the entity that sits at the opposite end of a navigable link, once one has the the handle (id) of the object at the source of the link. (The term "directly" is quite problematic, as we shall see.) In UML 1, which was very much influenced by the OO languages of the day, navigability was assumed to mean that the object at the source end of the link necessarily had a reference or a pointer to the entities at the opposite end. Consequently, navigability had a direct impact on the structure of the class since it implied ownership of a structural attribute that contained the reference or pointer. However, relatively late in the definition of UML 2, it was pointed out that in database systems, links were realized using means other than pointers or references. For example, a link can be realized by a table entry that is defined independently of either of the classes involved in an association. In such cases, navigability (as defined above), can be achieved without requiring appropriate structural attributes in the associated classes. At the time, we felt that it was necessary to be able to explicitly model both possibilities: the OO model and the database model (a design choice that should, possibly, be reconsidered in the future). To do that, it was decided to allow for explicit specification of who owns the association end: (1) the object (e.g., in the form of a structural attribute representing a reference or a pointer) or (2) the association (e.g., in the form of a database table entry). A new notation was introduced for the second form with the implication being that, if that notation is not used, then the first form applies (i.e., the object owns the association end, and, hence, there is a structural attribute). It is clear that both of these models support navigability as defined above. Consequently, navigability lost much of its significance, since it was originally intended as a means of distinguishing between the two variants of association end ownership -- but was, unfortunately, masked out by a misleading generalization. In my view, the latest definition of navigability means that is not a particularly useful notion -- especially given the difficulty of defining what "direct" access to the entity at the opposite end means in any practical sense. End ownership is a much more important concept, since it has an impact on the structure of a class definition. However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit caveat about this in section 6). The misfortune here is that this problem was identified too late in the evolution of UML and that the old convention was far too established to be easily eradicated. Cheers, -- Bran Selic Malina Software Corp. From: "Nerijus Jankevicius" To: "Ed Seidewitz" , "Bran Selic" , "BERNARD, Yves" Cc: Subject: Re: [issue 8921] Meaning of navigability Date: Tue, 12 Aug 2008 16:32:43 +0300 X-Mailer: Microsoft Windows Mail 6.0.6000.16480 Ed, I agree with you, but... The problem is that diagrams are ambiguous now. If you have printed diagram, you don't know - is it "UML 1 style" or properties are really owned by association (totally opposite). It is unacceptable for "formal" language/notation. Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Ed Seidewitz To: Nerijus Jankevicius ; Bran Selic ; BERNARD, Yves Cc: uml2-rtf@omg.org Sent: Tuesday, August 12, 2008 4:11 PM Subject: RE: [issue 8921] Meaning of navigability Actually, in UML 1, association ends where really, in effect, _always_ owned by the _association_. Remember that in UML 1 there was no general concept of "property" and attributes were formalized in the abstract syntax separately from association ends (known as "association roles" in UML 1). The idea in UML 1 that associations where parallel modeling constructs to classes, not a reflection of the OO concept of "referential attributes" owned by classes, came from the work of Rumbaug, Blaha, et al. So, the argument was that making classifiers own navigable associations by default in UML 2 was actually in unwarranted change to what had been the norm for UML 1. With the new notation, leaving the dot off gives diagrams that look like UML 1 with a similar semantics for associations to UML 1, Putting the dot on gives the new UML 2 semantics of association ends owned by classifiers. Of course, to be honest, the majority of casual modelers, I think, did not look at associations in UML 1 in the "official" way. Instead, they looked at them as a reflection of the typical OOP implementation they gave them. This seems to have been reflected in the original default "navigation is ownership" rule in UML 2. So, the current ownership notation may or may not be intuitive for current UML modelers. But it is a consistent, upward compatible change from UML 1. And it, despite the confusion it does seem to cause, the current rule was not a mistake or accident. (By the way, I don't particularly like the notation myself, but that is a different matter!) -- Ed -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Tue 8/12/2008 8:03 AM To: Bran Selic; BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: [issue 8921] Meaning of navigability Bran, >>However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used >>in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit >>caveat about this in section 6). Our tool supports this notation since introduction, but it is disabled by default (is optional), because it will distort all old customers diagrams (dot on association will be added on ALL diagrams). Actually, for me it always look like it is an error in the spec, because this notation is added on regular case (when end is owned by classifier) instead of specific case (property is owned by association). As I see from your email, you intuitive would like to see this notation when end is owned by association also. Maybe this is misunderstanding and we should change that? Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Bran Selic To: BERNARD, Yves Cc: uml2-rtf@omg.org Sent: Wednesday, August 06, 2008 11:05 PM Subject: Re: [issue 8921] Meaning of navigability hello M. Bernard, I reply to your query: On Fri, Aug 1, 2008 at 10:37 AM, BERNARD, Yves wrote: Hello, I would be very interested to know what is the current state of your thinking about this point. Since the concept (?) of navigability has been decoupled from the end's ownership, it's no more clear to me. No more clear also, what is the impact of the navigability on the dependencies between the associated classes. The essential idea behind this decoupling is that, in the abstract, navigability should not necessarily have any structural effects on the participating classes -- although it might. That is, navigability is currently defined as the ability to "directly" locate the entity that sits at the opposite end of a navigable link, once one has the the handle (id) of the object at the source of the link. (The term "directly" is quite problematic, as we shall see.) In UML 1, which was very much influenced by the OO languages of the day, navigability was assumed to mean that the object at the source end of the link necessarily had a reference or a pointer to the entities at the opposite end. Consequently, navigability had a direct impact on the structure of the class since it implied ownership of a structural attribute that contained the reference or pointer. However, relatively late in the definition of UML 2, it was pointed out that in database systems, links were realized using means other than pointers or references. For example, a link can be realized by a table entry that is defined independently of either of the classes involved in an association. In such cases, navigability (as defined above), can be achieved without requiring appropriate structural attributes in the associated classes. At the time, we felt that it was necessary to be able to explicitly model both possibilities: the OO model and the database model (a design choice that should, possibly, be reconsidered in the future). To do that, it was decided to allow for explicit specification of who owns the association end: (1) the object (e.g., in the form of a structural attribute representing a reference or a pointer) or (2) the association (e.g., in the form of a database table entry). A new notation was introduced for the second form with the implication being that, if that notation is not used, then the first form applies (i.e., the object owns the association end, and, hence, there is a structural attribute). It is clear that both of these models support navigability as defined above. Consequently, navigability lost much of its significance, since it was originally intended as a means of distinguishing between the two variants of association end ownership -- but was, unfortunately, masked out by a misleading generalization. In my view, the latest definition of navigability means that is not a particularly useful notion -- especially given the difficulty of defining what "direct" access to the entity at the opposite end means in any practical sense. End ownership is a much more important concept, since it has an impact on the structure of a class definition. However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit caveat about this in section 6). The misfortune here is that this problem was identified too late in the evolution of UML and that the old convention was far too established to be easily eradicated. Cheers, -- Bran Selic Malina Software Corp. Subject: RE: [issue 8921] Meaning of navigability Date: Tue, 12 Aug 2008 15:59:57 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [issue 8921] Meaning of navigability Thread-Index: Acj8f+fS+UunuUNORTaF+Kx7Iw/UkwAAheNw From: "BERNARD, Yves" To: "Nerijus Jankevicius" , "Ed Seidewitz" , "Bran Selic" Cc: X-OriginalArrivalTime: 12 Aug 2008 13:59:58.0112 (UTC) FILETIME=[B49C5A00:01C8FC83] I fully agree the ascending compatibility is an important point, nevertheless it's not the fundamental question here. If you don't mind, I would like to re-center the discution on the initial point: what is exaclty the concept of "navigability" and is it actually disctinct from the concept of " association end ownership"? Once this will be clear we will know what should really be the metamodel and how to use the related concepts in our day-to-day modeling work. ;o) Thanks for your interest on this subject. Cheers, Yves -----Message d'origine----- De : Nerijus Jankevicius [mailto:nerijus@nomagic.com] Envoyé : mardi 12 août 2008 15:33 À : Ed Seidewitz; Bran Selic; BERNARD, Yves Cc : uml2-rtf@omg.org Objet : Re: [issue 8921] Meaning of navigability Ed, I agree with you, but... The problem is that diagrams are ambiguous now. If you have printed diagram, you don't know - is it "UML 1 style" or properties are really owned by association (totally opposite). It is unacceptable for "formal" language/notation. Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Ed Seidewitz To: Nerijus Jankevicius ; Bran Selic ; BERNARD, Yves Cc: uml2-rtf@omg.org Sent: Tuesday, August 12, 2008 4:11 PM Subject: RE: [issue 8921] Meaning of navigability Actually, in UML 1, association ends where really, in effect, _always_ owned by the _association_. Remember that in UML 1 there was no general concept of "property" and attributes were formalized in the abstract syntax separately from association ends (known as "association roles" in UML 1). The idea in UML 1 that associations where parallel modeling constructs to classes, not a reflection of the OO concept of "referential attributes" owned by classes, came from the work of Rumbaug, Blaha, et al. So, the argument was that making classifiers own navigable associations by default in UML 2 was actually in unwarranted change to what had been the norm for UML 1. With the new notation, leaving the dot off gives diagrams that look like UML 1 with a similar semantics for associations to UML 1, Putting the dot on gives the new UML 2 semantics of association ends owned by classifiers. Of course, to be honest, the majority of casual modelers, I think, did not look at associations in UML 1 in the "official" way. Instead, they looked at them as a reflection of the typical OOP implementation they gave them. This seems to have been reflected in the original default "navigation is ownership" rule in UML 2. So, the current ownership notation may or may not be intuitive for current UML modelers. But it is a consistent, upward compatible change from UML 1. And it, despite the confusion it does seem to cause, the current rule was not a mistake or accident. (By the way, I don't particularly like the notation myself, but that is a different matter!) -- Ed -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Tue 8/12/2008 8:03 AM To: Bran Selic; BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: [issue 8921] Meaning of navigability Bran, >>However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used >>in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit >>caveat about this in section 6). Our tool supports this notation since introduction, but it is disabled by default (is optional), because it will distort all old customers diagrams (dot on association will be added on ALL diagrams). Actually, for me it always look like it is an error in the spec, because this notation is added on regular case (when end is owned by classifier) instead of specific case (property is owned by association). As I see from your email, you intuitive would like to see this notation when end is owned by association also. Maybe this is misunderstanding and we should change that? Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Bran Selic To: BERNARD, Yves Cc: uml2-rtf@omg.org Sent: Wednesday, August 06, 2008 11:05 PM Subject: Re: [issue 8921] Meaning of navigability hello M. Bernard, I reply to your query: On Fri, Aug 1, 2008 at 10:37 AM, BERNARD, Yves wrote: Hello, I would be very interested to know what is the current state of your thinking about this point. Since the concept (?) of navigability has been decoupled from the end's ownership, it's no more clear to me. No more clear also, what is the impact of the navigability on the dependencies between the associated classes. The essential idea behind this decoupling is that, in the abstract, navigability should not necessarily have any structural effects on the participating classes -- although it might. That is, navigability is currently defined as the ability to "directly" locate the entity that sits at the opposite end of a navigable link, once one has the the handle (id) of the object at the source of the link. (The term "directly" is quite problematic, as we shall see.) In UML 1, which was very much influenced by the OO languages of the day, navigability was assumed to mean that the object at the source end of the link necessarily had a reference or a pointer to the entities at the opposite end. Consequently, navigability had a direct impact on the structure of the class since it implied ownership of a structural attribute that contained the reference or pointer. However, relatively late in the definition of UML 2, it was pointed out that in database systems, links were realized using means other than pointers or references. For example, a link can be realized by a table entry that is defined independently of either of the classes involved in an association. In such cases, navigability (as defined above), can be achieved without requiring appropriate structural attributes in the associated classes. At the time, we felt that it was necessary to be able to explicitly model both possibilities: the OO model and the database model (a design choice that should, possibly, be reconsidered in the future). To do that, it was decided to allow for explicit specification of who owns the association end: (1) the object (e.g., in the form of a structural attribute representing a reference or a pointer) or (2) the association (e.g., in the form of a database table entry). A new notation was introduced for the second form with the implication being that, if that notation is not used, then the first form applies (i.e., the object owns the association end, and, hence, there is a structural attribute). It is clear that both of these models support navigability as defined above. Consequently, navigability lost much of its significance, since it was originally intended as a means of distinguishing between the two variants of association end ownership -- but was, unfortunately, masked out by a misleading generalization. In my view, the latest definition of navigability means that is not a particularly useful notion -- especially given the difficulty of defining what "direct" access to the entity at the opposite end means in any practical sense. End ownership is a much more important concept, since it has an impact on the structure of a class definition. However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit caveat about this in section 6). The misfortune here is that this problem was identified too late in the evolution of UML and that the old convention was far too established to be easily eradicated. Cheers, -- Bran Selic Malina Software Corp. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Guus Ramackers To: Ed Seidewitz Subject: Re: [issue 8921] Meaning of navigability Date: Tue, 12 Aug 2008 16:27:49 +0100 Cc: Nerijus Jankevicius , Bran Selic , "BERNARD, Yves" , "" X-Mailer: iPhone Mail (5A347) X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE I concur with Ed's analysis. Guus Ramackers JDeveloper PM On 12 Aug 2008, at 14:11, Ed Seidewitz wrote: Actually, in UML 1, association ends where really, in effect, _always_ owned by the _association_. Remember that in UML 1 there was no general concept of "property" and attributes were formalized in the abstract syntax separately from association ends (known as "association roles" in UML 1). The idea in UML 1 that associations where parallel modeling constructs to classes, not a reflection of the OO concept of "referential attributes" owned by classes, came from the work of Rumbaug, Blaha, et al. So, the argument was that making classifiers own navigable associations by default in UML 2 was actually in unwarranted change to what had been the norm for UML 1. With the new notation, leaving the dot off gives diagrams that look like UML 1 with a similar semantics for associations to UML 1, Putting the dot on gives the new UML 2 semantics of association ends owned by classifiers. Of course, to be honest, the majority of casual modelers, I think, did not look at associations in UML 1 in the "official" way. Instead, they looked at them as a reflection of the typical OOP implementation they gave them. This seems to have been reflected in the original default "navigation is ownership" rule in UML 2. So, the current ownership notation may or may not be intuitive for current UML modelers. But it is a consistent, upward compatible change from UML 1. And it, despite the confusion it does seem to cause, the current rule was not a mistake or accident. (By the way, I don't particularly like the notation myself, but that is a different matter!) -- Ed -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Tue 8/12/2008 8:03 AM To: Bran Selic; BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: [issue 8921] Meaning of navigability Bran, >>However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used >>in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit >>caveat about this in section 6). Our tool supports this notation since introduction, but it is disabled by default (is optional), because it will distort all old customers diagrams (dot on association will be added on ALL diagrams). Actually, for me it always look like it is an error in the spec, because this notation is added on regular case (when end is owned by classifier) instead of specific case (property is owned by association). As I see from your email, you intuitive would like to see this notation when end is owned by association also. Maybe this is misunderstanding and we should change that? Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Bran Selic To: BERNARD, Yves Cc: uml2-rtf@omg.org Sent: Wednesday, August 06, 2008 11:05 PM Subject: Re: [issue 8921] Meaning of navigability hello M. Bernard, I reply to your query: On Fri, Aug 1, 2008 at 10:37 AM, BERNARD, Yves wrote: Hello, I would be very interested to know what is the current state of your thinking about this point. Since the concept (?) of navigability has been decoupled from the end's ownership, it's no more clear to me. No more clear also, what is the impact of the navigability on the dependencies between the associated classes. The essential idea behind this decoupling is that, in the abstract, navigability should not necessarily have any structural effects on the participating classes -- although it might. That is, navigability is currently defined as the ability to "directly" locate the entity that sits at the opposite end of a navigable link, once one has the the handle (id) of the object at the source of the link. (The term "directly" is quite problematic, as we shall see.) In UML 1, which was very much influenced by the OO languages of the day, navigability was assumed to mean that the object at the source end of the link necessarily had a reference or a pointer to the entities at the opposite end. Consequently, navigability had a direct impact on the structure of the class since it implied ownership of a structural attribute that contained the reference or pointer. However, relatively late in the definition of UML 2, it was pointed out that in database systems, links were realized using means other than pointers or references. For example, a link can be realized by a table entry that is defined independently of either of the classes involved in an association. In such cases, navigability (as defined above), can be achieved without requiring appropriate structural attributes in the associated classes. At the time, we felt that it was necessary to be able to explicitly model both possibilities: the OO model and the database model (a design choice that should, possibly, be reconsidered in the future). To do that, it was decided to allow for explicit specification of who owns the association end: (1) the object (e.g., in the form of a structural attribute representing a reference or a pointer) or (2) the association (e.g., in the form of a database table entry). A new notation was introduced for the second form with the implication being that, if that notation is not used, then the first form applies (i.e., the object owns the association end, and, hence, there is a structural attribute). It is clear that both of these models support navigability as defined above. Consequently, navigability lost much of its significance, since it was originally intended as a means of distinguishing between the two variants of association end ownership -- but was, unfortunately, masked out by a misleading generalization. In my view, the latest definition of navigability means that is not a particularly useful notion -- especially given the difficulty of defining what "direct" access to the entity at the opposite end means in any practical sense. End ownership is a much more important concept, since it has an impact on the structure of a class definition. However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit caveat about this in section 6). The misfortune here is that this problem was identified too late in the evolution of UML and that the old convention was far too established to be easily eradicated. Cheers, -- Bran Selic Malina Software Corp. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=2yt7/Mf9agjrCsDDId+Lk0wAo+eS/lYDThKZxXOFamI=; b=JerFOZMGY+qhuVQr+1YHB0XvFMmh5Wdcejj4cZDyNJosuiDoJzV3J/LQa+uprAowKh ZbkLx1iP6hR7oyB8burX3WIdV7YcgRFBlvpdXBTZfhsCHoeNotwLIFjST2w44n7SqfGo odw9RmW+cs1GXQL4tTNOUbOZOSbeuc30a7Edc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=Ty+5ONOFrlWtTu8/S7x8tRR84hqAqzvJwYP9O7+g3RPBhT5rtEp9vPpRhL8MAqgg6c xI7Ezf5yncJQl1h4zojYmF6a/QVzgPuKlS68ZbYxVJIcGpb/Eq0VVLWM1Vn87XxwbnYF ifVYxu2LJFIGadj36YxNcfC6Uvg2Eyr+cggRs= Date: Tue, 12 Aug 2008 12:53:16 -0400 From: "Bran Selic" To: "BERNARD, Yves" Subject: Re: [issue 8921] Meaning of navigability Cc: "Nerijus Jankevicius" , "Ed Seidewitz" , uml2-rtf@omg.org Guus had already pointed out in a private e-mail my original mistake in claiming that ends were owned by the classifiers in UML 1 (my apologies for this misleading bit of information). They were, indeed, owned by the associations but, "in the namespace of the classifier" -- a formulation that was so vague as to be almost useless. But, as Yves points out, this is not the issue that he was raising about the meaning of navigability. So, to recenter the discussion on the original issue: My claim is that the current definition of navigability is also an example of a concept that is so vaguely defined as to be useless for any practical work. We should get rid of it. If we did that, then we could dispense with the silly dot notation on association ends and, thereby, get rid of the problem of backward compatibility that Nerijus noted. (An aside: like Ed I think the new notation sucks.) Cheers...Bran On Tue, Aug 12, 2008 at 9:59 AM, BERNARD, Yves wrote: I fully agree the ascending compatibility is an important point, nevertheless it's not the fundamental question here. If you don't mind, I would like to re-center the discution on the initial point: what is exaclty the concept of "navigability" and is it actually disctinct from the concept of " association end ownership"? Once this will be clear we will know what should really be the metamodel and how to use the related concepts in our day-to-day modeling work. ;o) Thanks for your interest on this subject. Cheers, Yves -----Message d'origine----- De : Nerijus Jankevicius [mailto:nerijus@nomagic.com] Envoyé : mardi 12 août 2008 15:33 À : Ed Seidewitz; Bran Selic; BERNARD, Yves Cc : uml2-rtf@omg.org Objet : Re: [issue 8921] Meaning of navigability Ed, I agree with you, but... The problem is that diagrams are ambiguous now. If you have printed diagram, you don't know - is it "UML 1 style" or properties are really owned by association (totally opposite). It is unacceptable for "formal" language/notation. Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Ed Seidewitz To: Nerijus Jankevicius ; Bran Selic ; BERNARD, Yves Cc: uml2-rtf@omg.org Sent: Tuesday, August 12, 2008 4:11 PM Subject: RE: [issue 8921] Meaning of navigability Actually, in UML 1, association ends where really, in effect, _always_ owned by the _association_. Remember that in UML 1 there was no general concept of "property" and attributes were formalized in the abstract syntax separately from association ends (known as "association roles" in UML 1). The idea in UML 1 that associations where parallel modeling constructs to classes, not a reflection of the OO concept of "referential attributes" owned by classes, came from the work of Rumbaug, Blaha, et al. So, the argument was that making classifiers own navigable associations by default in UML 2 was actually in unwarranted change to what had been the norm for UML 1. With the new notation, leaving the dot off gives diagrams that look like UML 1 with a similar semantics for associations to UML 1, Putting the dot on gives the new UML 2 semantics of association ends owned by classifiers. Of course, to be honest, the majority of casual modelers, I think, did not look at associations in UML 1 in the "official" way. Instead, they looked at them as a reflection of the typical OOP implementation they gave them. This seems to have been reflected in the original default "navigation is ownership" rule in UML 2. So, the current ownership notation may or may not be intuitive for current UML modelers. But it is a consistent, upward compatible change from UML 1. And it, despite the confusion it does seem to cause, the current rule was not a mistake or accident. (By the way, I don't particularly like the notation myself, but that is a different matter!) -- Ed -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Tue 8/12/2008 8:03 AM To: Bran Selic; BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: [issue 8921] Meaning of navigability Bran, >>However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used >>in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit >>caveat about this in section 6). Our tool supports this notation since introduction, but it is disabled by default (is optional), because it will distort all old customers diagrams (dot on association will be added on ALL diagrams). Actually, for me it always look like it is an error in the spec, because this notation is added on regular case (when end is owned by classifier) instead of specific case (property is owned by association). As I see from your email, you intuitive would like to see this notation when end is owned by association also. Maybe this is misunderstanding and we should change that? Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Bran Selic To: BERNARD, Yves Cc: uml2-rtf@omg.org Sent: Wednesday, August 06, 2008 11:05 PM Subject: Re: [issue 8921] Meaning of navigability hello M. Bernard, I reply to your query: On Fri, Aug 1, 2008 at 10:37 AM, BERNARD, Yves wrote: Hello, I would be very interested to know what is the current state of your thinking about this point. Since the concept (?) of navigability has been decoupled from the end's ownership, it's no more clear to me. No more clear also, what is the impact of the navigability on the dependencies between the associated classes. The essential idea behind this decoupling is that, in the abstract, navigability should not necessarily have any structural effects on the participating classes -- although it might. That is, navigability is currently defined as the ability to "directly" locate the entity that sits at the opposite end of a navigable link, once one has the the handle (id) of the object at the source of the link. (The term "directly" is quite problematic, as we shall see.) In UML 1, which was very much influenced by the OO languages of the day, navigability was assumed to mean that the object at the source end of the link necessarily had a reference or a pointer to the entities at the opposite end. Consequently, navigability had a direct impact on the structure of the class since it implied ownership of a structural attribute that contained the reference or pointer. However, relatively late in the definition of UML 2, it was pointed out that in database systems, links were realized using means other than pointers or references. For example, a link can be realized by a table entry that is defined independently of either of the classes involved in an association. In such cases, navigability (as defined above), can be achieved without requiring appropriate structural attributes in the associated classes. At the time, we felt that it was necessary to be able to explicitly model both possibilities: the OO model and the database model (a design choice that should, possibly, be reconsidered in the future). To do that, it was decided to allow for explicit specification of who owns the association end: (1) the object (e.g., in the form of a structural attribute representing a reference or a pointer) or (2) the association (e.g., in the form of a database table entry). A new notation was introduced for the second form with the implication being that, if that notation is not used, then the first form applies (i.e., the object owns the association end, and, hence, there is a structural attribute). It is clear that both of these models support navigability as defined above. Consequently, navigability lost much of its significance, since it was originally intended as a means of distinguishing between the two variants of association end ownership -- but was, unfortunately, masked out by a misleading generalization. In my view, the latest definition of navigability means that is not a particularly useful notion -- especially given the difficulty of defining what "direct" access to the entity at the opposite end means in any practical sense. End ownership is a much more important concept, since it has an impact on the structure of a class definition. However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit caveat about this in section 6). The misfortune here is that this problem was identified too late in the evolution of UML and that the old convention was far too established to be easily eradicated. Cheers, -- Bran Selic Malina Software Corp. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. -- Bran Selic Malina Software Corp. To: uml2-rtf@omg.org Subject: Re: [issue 8921] Meaning of navigability X-KeepSent: 7ABB1B43:3846BAAD-852574A3:00706D79; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Jim Amsden Date: Tue, 12 Aug 2008 16:48:10 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V85_M1_05262008|May 26, 2008) at 08/12/2008 14:48:18, Serialize complete at 08/12/2008 14:48:18 I thought navigability meant that you could "get there from here". Consider the navigable association Student takes Course with navigable end Student::enrolledCourses. Assume also the association isn't navigable the other way. Given aStudent: Student, I could write OCL expressions (or action language expressions when we have one) like aStudent.enrolledCourses and get back some collection (bag or set) of Courses. But given aCourse: Course, I couldn't write aCourse.student (whatever the name of the ownedEnd of the Association might be) because the association isn't navigable in that direction. Courses don't know the students enrolled in them. Enrolling a student in a course doesn't "change" the course in any way - its just like it was before. The takes association is still available in the package, so its is possible to determine what students are enrolled in a course by examining the association's ownedEnd. Implementations can make either of these operations efficient, but would probably favor aStudent.enrolledCourses since the modeler indicated this was the navigable direction to be used. These examples abound in all models, so it seems like the concept of navigability is quite semantically useful. The distinction between OO references vs. database database foreign keys came up, and resulted in the issue of controlling property ownership. I think this was always irrelevant. Navigability defined semantics, not structure. Property ownership doesn't need to have anything to do with pointers or foreign keys - it has to do with defining precise semantics of navigability or accessibility. Pointers and foreign keys are PSM concepts. It is quite easy to transform UML models using the concept of navigability to effective OO and relational systems without having to introduce a distinction between property ownership and navigability. In fact, doing so would have made it much more difficult to use the same model for both platforms since the implementation ownership models are different. So I think this was never an issue, and the resolution to introduce property ownership and make navigability essentially meaningless may have been unnecessary. Now if we remove navigability from the spec because its no longer meaningful, then I bet people will start using property ownership (probably using arrows instead of the dots) to mean what we always through navigability meant, and we'd be right back were we started. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 From: "Bran Selic" To: "BERNARD, Yves" Cc: "Nerijus Jankevicius" , "Ed Seidewitz" , uml2-rtf@omg.org Date: 08/12/2008 01:12 PM Subject: Re: [issue 8921] Meaning of navigability -------------------------------------------------------------------------------- Guus had already pointed out in a private e-mail my original mistake in claiming that ends were owned by the classifiers in UML 1 (my apologies for this misleading bit of information). They were, indeed, owned by the associations but, "in the namespace of the classifier" -- a formulation that was so vague as to be almost useless. But, as Yves points out, this is not the issue that he was raising about the meaning of navigability. So, to recenter the discussion on the original issue: My claim is that the current definition of navigability is also an example of a concept that is so vaguely defined as to be useless for any practical work. We should get rid of it. If we did that, then we could dispense with the silly dot notation on association ends and, thereby, get rid of the problem of backward compatibility that Nerijus noted. (An aside: like Ed I think the new notation sucks.) Cheers...Bran On Tue, Aug 12, 2008 at 9:59 AM, BERNARD, Yves wrote: I fully agree the ascending compatibility is an important point, nevertheless it's not the fundamental question here. If you don't mind, I would like to re-center the discution on the initial point: what is exaclty the concept of "navigability" and is it actually disctinct from the concept of " association end ownership"? Once this will be clear we will know what should really be the metamodel and how to use the related concepts in our day-to-day modeling work. ;o) Thanks for your interest on this subject. Cheers, Yves -----Message d'origine----- De : Nerijus Jankevicius [mailto:nerijus@nomagic.com] Envoyé : mardi 12 août 2008 15:33 À : Ed Seidewitz; Bran Selic; BERNARD, Yves Cc : uml2-rtf@omg.org Objet : Re: [issue 8921] Meaning of navigability Ed, I agree with you, but... The problem is that diagrams are ambiguous now. If you have printed diagram, you don't know - is it "UML 1 style" or properties are really owned by association (totally opposite). It is unacceptable for "formal" language/notation. Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Ed Seidewitz To: Nerijus Jankevicius ; Bran Selic ; BERNARD, Yves Cc: uml2-rtf@omg.org Sent: Tuesday, August 12, 2008 4:11 PM Subject: RE: [issue 8921] Meaning of navigability Actually, in UML 1, association ends where really, in effect, _always_ owned by the _association_. Remember that in UML 1 there was no general concept of "property" and attributes were formalized in the abstract syntax separately from association ends (known as "association roles" in UML 1). The idea in UML 1 that associations where parallel modeling constructs to classes, not a reflection of the OO concept of "referential attributes" owned by classes, came from the work of Rumbaug, Blaha, et al. So, the argument was that making classifiers own navigable associations by default in UML 2 was actually in unwarranted change to what had been the norm for UML 1. With the new notation, leaving the dot off gives diagrams that look like UML 1 with a similar semantics for associations to UML 1, Putting the dot on gives the new UML 2 semantics of association ends owned by classifiers. Of course, to be honest, the majority of casual modelers, I think, did not look at associations in UML 1 in the "official" way. Instead, they looked at them as a reflection of the typical OOP implementation they gave them. This seems to have been reflected in the original default "navigation is ownership" rule in UML 2. So, the current ownership notation may or may not be intuitive for current UML modelers. But it is a consistent, upward compatible change from UML 1. And it, despite the confusion it does seem to cause, the current rule was not a mistake or accident. (By the way, I don't particularly like the notation myself, but that is a different matter!) -- Ed -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Tue 8/12/2008 8:03 AM To: Bran Selic; BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: [issue 8921] Meaning of navigability Bran, >>However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used >>in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit >>caveat about this in section 6). Our tool supports this notation since introduction, but it is disabled by default (is optional), because it will distort all old customers diagrams (dot on association will be added on ALL diagrams). Actually, for me it always look like it is an error in the spec, because this notation is added on regular case (when end is owned by classifier) instead of specific case (property is owned by association). As I see from your email, you intuitive would like to see this notation when end is owned by association also. Maybe this is misunderstanding and we should change that? Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Bran Selic To: BERNARD, Yves Cc: uml2-rtf@omg.org Sent: Wednesday, August 06, 2008 11:05 PM Subject: Re: [issue 8921] Meaning of navigability hello M. Bernard, I reply to your query: On Fri, Aug 1, 2008 at 10:37 AM, BERNARD, Yves wrote: Hello, I would be very interested to know what is the current state of your thinking about this point. Since the concept (?) of navigability has been decoupled from the end's ownership, it's no more clear to me. No more clear also, what is the impact of the navigability on the dependencies between the associated classes. The essential idea behind this decoupling is that, in the abstract, navigability should not necessarily have any structural effects on the participating classes -- although it might. That is, navigability is currently defined as the ability to "directly" locate the entity that sits at the opposite end of a navigable link, once one has the the handle (id) of the object at the source of the link. (The term "directly" is quite problematic, as we shall see.) In UML 1, which was very much influenced by the OO languages of the day, navigability was assumed to mean that the object at the source end of the link necessarily had a reference or a pointer to the entities at the opposite end. Consequently, navigability had a direct impact on the structure of the class since it implied ownership of a structural attribute that contained the reference or pointer. However, relatively late in the definition of UML 2, it was pointed out that in database systems, links were realized using means other than pointers or references. For example, a link can be realized by a table entry that is defined independently of either of the classes involved in an association. In such cases, navigability (as defined above), can be achieved without requiring appropriate structural attributes in the associated classes. At the time, we felt that it was necessary to be able to explicitly model both possibilities: the OO model and the database model (a design choice that should, possibly, be reconsidered in the future). To do that, it was decided to allow for explicit specification of who owns the association end: (1) the object (e.g., in the form of a structural attribute representing a reference or a pointer) or (2) the association (e.g., in the form of a database table entry). A new notation was introduced for the second form with the implication being that, if that notation is not used, then the first form applies (i.e., the object owns the association end, and, hence, there is a structural attribute). It is clear that both of these models support navigability as defined above. Consequently, navigability lost much of its significance, since it was originally intended as a means of distinguishing between the two variants of association end ownership -- but was, unfortunately, masked out by a misleading generalization. In my view, the latest definition of navigability means that is not a particularly useful notion -- especially given the difficulty of defining what "direct" access to the entity at the opposite end means in any practical sense. End ownership is a much more important concept, since it has an impact on the structure of a class definition. However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit caveat about this in section 6). The misfortune here is that this problem was identified too late in the evolution of UML and that the old convention was far too established to be easily eradicated. Cheers, -- Bran Selic Malina Software Corp. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. -- Bran Selic Malina Software Corp. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=BTRLa/+7eM6YxxJi+/Y3MG9QBy/v9lAIgQGVx5yOZAw=; b=H85qOWqQt4a5+Op3urAKf0HfxsMntxEs5MvAYMmhMkrHWRf1stK+fZKKOJvOIZSUZN N6VlBP9AUA2ijkyt8IBtS6wcbWvTM2iTsh9tZlF3TmlgMMd69i9cXYU88/MUSa7bzq8E Nw/szLSedo1lr6jqTalUrvZ1/5zdeMV+QjiCc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=l1n/w9Q2YtQtt2TVuyH1Nkez56n3k2e4SFk7E3EyY93rFnlUO2BfP/XRGe1ONUDI1B yZOayk4MKWc9YQ8pR/uV/bsbZCvy/UnlrhXYlz/zspEpY08R8lBva6f1zmJ46o3FapTv NBASep/S2mNXWeqr338qO+C+/t6RVFmkoLZyY= Date: Tue, 12 Aug 2008 17:18:10 -0400 From: "Bran Selic" To: "Jim Amsden" Subject: Re: [issue 8921] Meaning of navigability Cc: uml2-rtf@omg.org Jim, In response to your comments: On Tue, Aug 12, 2008 at 4:48 PM, Jim Amsden wrote: I thought navigability meant that you could "get there from here". Actually, that's not what it means. As currently defined, it merely means that you can "get there from here to there efficiently". Note that, in principle, if you know one end of a link, it is always possible to come up with ways of locating the other end of the link -- although such mechanisms may not be very efficient (e.g., by raw exhaustive search). Hence, the use of the term "efficient" in the definition.The problem is that it is not possible to define "efficiently" in any qualitatively distinguishable manner. Consider the navigable association Student takes Course with navigable end Student::enrolledCourses. Assume also the association isn't navigable the other way. Given aStudent: Student, I could write OCL expressions (or action language expressions when we have one) like aStudent.enrolledCourses and get back some collection (bag or set) of Courses. But given aCourse: Course, I couldn't write aCourse.student (whatever the name of the ownedEnd of the Association might be) because the association isn't navigable in that direction. No. As of OCL 2, OCL completely ignores navigability.That is, you are free to write OCL constraints in either direction, regardless of navigability. X-MailScanner-Watermark: 1219181085.07944@CjqeWef02LtOTJ/1J77vww Reply-To: From: "Conrad Bock" To: "'Jim Amsden'" , Subject: RE: [issue 8921] Meaning of navigability Date: Tue, 12 Aug 2008 17:24:40 -0400 X-Mailer: Microsoft Office Outlook 11 thread-index: Acj8vmlCt6eQxPOjTn+aa4vBH4eB/wAAd2Hw X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner-ID: m7CLOeI6030885 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-Spam-Status: No Jim, > The distinction between OO references vs. database database foreign > keys came up, and resulted in the issue of controlling property > ownership. I think this was always irrelevant. Navigability defined > semantics, not structure. Property ownership doesn't need to have > anything to do with pointers or foreign keys - it has to do with > defining precise semantics of navigability or accessibility. > Pointers and foreign keys are PSM concepts. It is quite easy to > transform UML models using the concept of navigability to effective > OO and relational systems without having to introduce a distinction > between property ownership and navigability. In fact, doing so would > have made it much more difficult to use the same model for both > platforms since the implementation ownership models are different. This is exactly why the unfinalized UML 2 model need to be corrected. It tied navagilibility to property ownership. The resolution of Issue 6243 (Association not affecting ends) in the FTF corrected that, see the discussion in the FTF report (http://doc.omg.org/ptc/04-10-01). > So I think this was never an issue, and the resolution to introduce > property ownership and make navigability essentially meaningless may > have been unnecessary. It was only an issue with the unfinalized UML 2. > Now if we remove navigability from the spec because its no longer > meaningful, then I bet people will start using property ownership > (probably using arrows instead of the dots) to mean what we always > through navigability meant, and we'd be right back were we started. The definition is basically your intuition above, perfectly meaningful. I'm with Ed and Guus that the resolution of issue 6243 is consistent with that definition and UML 1. Even if I don't like the dot notation. :) Conrad X-MailScanner-Watermark: 1219181397.99556@E/f7VYnRqyZJ7WAx3EWDeQ Reply-To: From: "Conrad Bock" To: "'Nerijus Jankevicius'" , "'Bran Selic'" , "'BERNARD, Yves'" Cc: Subject: RE: [issue 8921] Meaning of navigability Date: Tue, 12 Aug 2008 17:29:56 -0400 X-Mailer: Microsoft Office Outlook 11 thread-index: Acj8dUITuNNQH+IkR8iYOISL639BrgATQbDQ X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner-ID: m7CLTuH1031402 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-Spam-Status: No Nerijus, > Actually, for me it always look like it is an error in the > spec, because this notation is added on regular case (when > end is owned by classifier) instead of specific case > (property is owned by association). As I see from your > email, you intuitive would like to see this notation when > end is owned by association also. Which is the the regular case depends on whether you're an OO or database modeler. My preference would have been to depart from UML 1 and use the dot notation when the property is owned by association. Conrad X-Virus-Scanned: by amavisd-new at softeam.com From: "DESFRAY Philippe" To: "'Jim Amsden'" , Subject: RE: [issue 8921] Meaning of navigability Date: Mon, 25 Aug 2008 10:55:25 +0200 Organization: Softeam X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj8vp5OEy0GPrWXQoazeSfeocPu1AJ0R2jw I second Jim here : Navigability is a very important notion, much used in practice, may be ill defined by the spec. Jim provides a semantics that I would call .logical semantics.. In addition, you can add a .conceptual. semantics : that is a concept is based on another concept (a library is based on the book concept). So efforts on the semantics caould be done, ditching navigability would be a loss. >>> I think this was always irrelevant. Navigability defined semantics, not structure. Property ownership doesn't need to have anything to do with pointers or foreign keys - it has to do with defining precise semantics of navigability or accessibility. I heart fully agree with this, I was at the introduction time of this silly dot opposed to this physical subtility within UML. I am still opposed to it : it brings confusion to end users and is a waste of time to tool implementers. Philippe De : Jim Amsden [mailto:jamsden@us.ibm.com] Envoyé : mardi 12 août 2008 22:48 À : uml2-rtf@omg.org Objet : Re: [issue 8921] Meaning of navigability I thought navigability meant that you could "get there from here". Consider the navigable association Student takes Course with navigable end Student::enrolledCourses. Assume also the association isn't navigable the other way. Given aStudent: Student, I could write OCL expressions (or action language expressions when we have one) like aStudent.enrolledCourses and get back some collection (bag or set) of Courses. But given aCourse: Course, I couldn't write aCourse.student (whatever the name of the ownedEnd of the Association might be) because the association isn't navigable in that direction. Courses don't know the students enrolled in them. Enrolling a student in a course doesn't "change" the course in any way - its just like it was before. The takes association is still available in the package, so its is possible to determine what students are enrolled in a course by examining the association's ownedEnd. Implementations can make either of these operations efficient, but would probably favor aStudent.enrolledCourses since the modeler indicated this was the navigable direction to be used. These examples abound in all models, so it seems like the concept of navigability is quite semantically useful. The distinction between OO references vs. database database foreign keys came up, and resulted in the issue of controlling property ownership. I think this was always irrelevant. Navigability defined semantics, not structure. Property ownership doesn't need to have anything to do with pointers or foreign keys - it has to do with defining precise semantics of navigability or accessibility. Pointers and foreign keys are PSM concepts. It is quite easy to transform UML models using the concept of navigability to effective OO and relational systems without having to introduce a distinction between property ownership and navigability. In fact, doing so would have made it much more difficult to use the same model for both platforms since the implementation ownership models are different. So I think this was never an issue, and the resolution to introduce property ownership and make navigability essentially meaningless may have been unnecessary. Now if we remove navigability from the spec because its no longer meaningful, then I bet people will start using property ownership (probably using arrows instead of the dots) to mean what we always through navigability meant, and we'd be right back were we started. Jim Amsden STSM, Solution Architect jamsden@us.ibm.com Jim Amsden/Raleigh/IBM 919-461-3919 From: "Bran Selic" To: "BERNARD, Yves" Cc: "Nerijus Jankevicius" , "Ed Seidewitz" , uml2-rtf@omg.org Date: 08/12/2008 01:12 PM Subject: Re: [issue 8921] Meaning of navigability -------------------------------------------------------------------------------- Guus had already pointed out in a private e-mail my original mistake in claiming that ends were owned by the classifiers in UML 1 (my apologies for this misleading bit of information). They were, indeed, owned by the associations but, "in the namespace of the classifier" -- a formulation that was so vague as to be almost useless. But, as Yves points out, this is not the issue that he was raising about the meaning of navigability. So, to recenter the discussion on the original issue: My claim is that the current definition of navigability is also an example of a concept that is so vaguely defined as to be useless for any practical work. We should get rid of it. If we did that, then we could dispense with the silly dot notation on association ends and, thereby, get rid of the problem of backward compatibility that Nerijus noted. (An aside: like Ed I think the new notation sucks.) Cheers...Bran On Tue, Aug 12, 2008 at 9:59 AM, BERNARD, Yves wrote: I fully agree the ascending compatibility is an important point, nevertheless it's not the fundamental question here. If you don't mind, I would like to re-center the discution on the initial point: what is exaclty the concept of "navigability" and is it actually disctinct from the concept of " association end ownership"? Once this will be clear we will know what should really be the metamodel and how to use the related concepts in our day-to-day modeling work. ;o) Thanks for your interest on this subject. Cheers, Yves -----Message d'origine----- De : Nerijus Jankevicius [mailto:nerijus@nomagic.com] Envoyé : mardi 12 août 2008 15:33 À : Ed Seidewitz; Bran Selic; BERNARD, Yves Cc : uml2-rtf@omg.org Objet : Re: [issue 8921] Meaning of navigability Ed, I agree with you, but... The problem is that diagrams are ambiguous now. If you have printed diagram, you don't know - is it "UML 1 style" or properties are really owned by association (totally opposite). It is unacceptable for "formal" language/notation. Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Ed Seidewitz To: Nerijus Jankevicius ; Bran Selic ; BERNARD, Yves Cc: uml2-rtf@omg.org Sent: Tuesday, August 12, 2008 4:11 PM Subject: RE: [issue 8921] Meaning of navigability Actually, in UML 1, association ends where really, in effect, _always_ owned by the _association_. Remember that in UML 1 there was no general concept of "property" and attributes were formalized in the abstract syntax separately from association ends (known as "association roles" in UML 1). The idea in UML 1 that associations where parallel modeling constructs to classes, not a reflection of the OO concept of "referential attributes" owned by classes, came from the work of Rumbaug, Blaha, et al. So, the argument was that making classifiers own navigable associations by default in UML 2 was actually in unwarranted change to what had been the norm for UML 1. With the new notation, leaving the dot off gives diagrams that look like UML 1 with a similar semantics for associations to UML 1, Putting the dot on gives the new UML 2 semantics of association ends owned by classifiers. Of course, to be honest, the majority of casual modelers, I think, did not look at associations in UML 1 in the "official" way. Instead, they looked at them as a reflection of the typical OOP implementation they gave them. This seems to have been reflected in the original default "navigation is ownership" rule in UML 2. So, the current ownership notation may or may not be intuitive for current UML modelers. But it is a consistent, upward compatible change from UML 1. And it, despite the confusion it does seem to cause, the current rule was not a mistake or accident. (By the way, I don't particularly like the notation myself, but that is a different matter!) -- Ed -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Tue 8/12/2008 8:03 AM To: Bran Selic; BERNARD, Yves Cc: uml2-rtf@omg.org Subject: Re: [issue 8921] Meaning of navigability Bran, >>However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used >>in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit >>caveat about this in section 6). Our tool supports this notation since introduction, but it is disabled by default (is optional), because it will distort all old customers diagrams (dot on association will be added on ALL diagrams). Actually, for me it always look like it is an error in the spec, because this notation is added on regular case (when end is owned by classifier) instead of specific case (property is owned by association). As I see from your email, you intuitive would like to see this notation when end is owned by association also. Maybe this is misunderstanding and we should change that? Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Bran Selic To: BERNARD, Yves Cc: uml2-rtf@omg.org Sent: Wednesday, August 06, 2008 11:05 PM Subject: Re: [issue 8921] Meaning of navigability hello M. Bernard, I reply to your query: On Fri, Aug 1, 2008 at 10:37 AM, BERNARD, Yves wrote: Hello, I would be very interested to know what is the current state of your thinking about this point. Since the concept (?) of navigability has been decoupled from the end's ownership, it's no more clear to me. No more clear also, what is the impact of the navigability on the dependencies between the associated classes. The essential idea behind this decoupling is that, in the abstract, navigability should not necessarily have any structural effects on the participating classes -- although it might. That is, navigability is currently defined as the ability to "directly" locate the entity that sits at the opposite end of a navigable link, once one has the the handle (id) of the object at the source of the link. (The term "directly" is quite problematic, as we shall see.) In UML 1, which was very much influenced by the OO languages of the day, navigability was assumed to mean that the object at the source end of the link necessarily had a reference or a pointer to the entities at the opposite end. Consequently, navigability had a direct impact on the structure of the class since it implied ownership of a structural attribute that contained the reference or pointer. However, relatively late in the definition of UML 2, it was pointed out that in database systems, links were realized using means other than pointers or references. For example, a link can be realized by a table entry that is defined independently of either of the classes involved in an association. In such cases, navigability (as defined above), can be achieved without requiring appropriate structural attributes in the associated classes. At the time, we felt that it was necessary to be able to explicitly model both possibilities: the OO model and the database model (a design choice that should, possibly, be reconsidered in the future). To do that, it was decided to allow for explicit specification of who owns the association end: (1) the object (e.g., in the form of a structural attribute representing a reference or a pointer) or (2) the association (e.g., in the form of a database table entry). A new notation was introduced for the second form with the implication being that, if that notation is not used, then the first form applies (i.e., the object owns the association end, and, hence, there is a structural attribute). It is clear that both of these models support navigability as defined above. Consequently, navigability lost much of its significance, since it was originally intended as a means of distinguishing between the two variants of association end ownership -- but was, unfortunately, masked out by a misleading generalization. In my view, the latest definition of navigability means that is not a particularly useful notion -- especially given the difficulty of defining what "direct" access to the entity at the opposite end means in any practical sense. End ownership is a much more important concept, since it has an impact on the structure of a class definition. However, I don't know of any tools on the market that currently support the new notation for end ownership, so that the old interpretation is still used in pretty much all tools (it is also the reason why the UML 2 specs still use the old "navigability = ownership" convention -- although there is an explicit caveat about this in section 6). The misfortune here is that this problem was identified too late in the evolution of UML and that the old convention was far too established to be easily eradicated. Cheers, -- Bran Selic Malina Software Corp. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. -- Bran Selic Malina Software Corp. X-Virus-Scanned: by amavisd-new at softeam.com From: "DESFRAY Philippe" To: "'Bran Selic'" , "'Jim Amsden'" Cc: Subject: RE: [issue 8921] Meaning of navigability Date: Mon, 25 Aug 2008 10:59:14 +0200 Organization: Softeam X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj8w4pZFSuXnP6NSAStMh9pQExMmAJzONUg Right Bran, or we could say that the model facilitates this navigation direction (efficiency may not be appropriate at this level of modeling . it is rather a QOS notion). De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : mardi 12 août 2008 23:18 À : Jim Amsden Cc : uml2-rtf@omg.org Objet : Re: [issue 8921] Meaning of navigability Jim, In response to your comments: On Tue, Aug 12, 2008 at 4:48 PM, Jim Amsden wrote: I thought navigability meant that you could "get there from here". Actually, that's not what it means. As currently defined, it merely means that you can "get there from here to there efficiently". Note that, in principle, if you know one end of a link, it is always possible to come up with ways of locating the other end of the link -- although such mechanisms may not be very efficient (e.g., by raw exhaustive search). Hence, the use of the term "efficient" in the definition.The problem is that it is not possible to define "efficiently" in any qualitatively distinguishable manner. Consider the navigable association Student takes Course with navigable end Student::enrolledCourses. Assume also the association isn't navigable the other way. Given aStudent: Student, I could write OCL expressions (or action language expressions when we have one) like aStudent.enrolledCourses and get back some collection (bag or set) of Courses. But given aCourse: Course, I couldn't write aCourse.student (whatever the name of the ownedEnd of the Association might be) because the association isn't navigable in that direction. No. As of OCL 2, OCL completely ignores navigability.That is, you are free to write OCL constraints in either direction, regardless of navigability. I believe this is quite unfortunate and can be avoided by decoupling tool implementations that manipulate models from the meaning of the models themselves. Navigability should continue to mean semantically traversable as specified by ReadLinkAction. This will establish an interoperable meaning across all tools and preserve an important and commonly used semantic. If tools wish to support efficient traversal to non-navigable ends for their purposes, they should feel free to do so. This can be done by maintaining additional information in associations for the non-navigable ends for the tools purpose, or by using crawlers that examine the model and cache information for specific tool purposes. This is manipulating the model for very different purposes than the meaning of the model itself. If it is desired to have some standard means of indicating to tool vendors where non-navigable association ends should be efficiently traversable, this should be done by a separate property perhaps available through the standard profile. It should not be coupled with the semantic meaning of navigability.