Issue 13656: UML 2 - appearance of Association Ends as members of the related classes (uml2-rtf) Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org) Nature: Uncategorized Issue Severity: Minor Summary: Since the dot notation was introduced to represent ownership of association ends separately from navigability, it appears that the following is the case: a navigable association end that is owned by the association does not appear in the namespace of the class from which it is navigable. How, then, can it be said to be navigable? I believe that all navigable ends should appear in the namespace of the class from which they are navigable, regardless of who owns the ends. Resolution: Revised Text: Actions taken: March 3, 2009: received issue Discussion: End of Annotations:===== m: Steve Cook To: "issues@omg.org" Date: Tue, 3 Mar 2009 14:01:57 +0000 Subject: UML 2 - appearance of Association Ends as members of the related classes Thread-Topic: UML 2 - appearance of Association Ends as members of the related classes Thread-Index: AcmcCJ2EHzeru3BFStOlYnWqyT4Z0w== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Since the dot notation was introduced to represent ownership of association ends separately from navigability, it appears that the following is the case: a navigable association end that is owned by the association does not appear in the namespace of the class from which it is navigable. How, then, can it be said to be navigable? I believe that all navigable ends should appear in the namespace of the class from which they are navigable, regardless of who owns the ends. Subject: FW: Association End Ownership and Navigability Date: Mon, 9 Mar 2009 16:22:30 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Association End Ownership and Navigability Thread-Index: Acmg07sPFFYM/tgmQWC0tdYzCnfpGQAGBuNgAAITXeA= From: "Ed Seidewitz" To: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cPYFf/VH7UpqrDgqep3YPYYQ/2zS0FUOeLDZYvSLP2A=; b=M87A2R2w+kTxqJDEC2787JLJCgD7LVhJhOFXgqEIXzVwfxI1DqWJzVCa1zLiJDkeLR ZwDmD70BM+GEl8dtHJbdrTzmJrcg+kSSVxWgKzSp9+KawX8aZpRRKoW6vMZJD29NU9FP yP/GgX68/ffhM016wzYy1fUP0tH0L/XCgwdLY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DyLrQ23PZpXgSHiZ6N+2tlnJtRwO7lcz1s61cy3dtmAkfBIT+oyona7wXX4MTq8pgw zsAuR1MC+0ADpcBYB07vETFG5JMVOIU2n5g09UNMeWmBa0U1zgxNrQw/74j4GU64QmrR Agtr64LWBNkCTcyd5gF+JBV7p6+AVPO+HNylU= Date: Mon, 9 Mar 2009 17:08:51 -0400 Subject: Re: FW: Association End Ownership and Navigability From: Bran Selic To: Ed Seidewitz Cc: uml2-rtf@omg.org For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed Subject: RE: FW: Association End Ownership and Navigability Date: Mon, 9 Mar 2009 17:29:02 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: Acmg+0cH9KBBG1bGSESOX+QtKxEX4AAAYv/A From: "Ed Seidewitz" To: "Bran Selic" Cc: Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed Subject: RE: FW: Association End Ownership and Navigability Date: Mon, 9 Mar 2009 23:36:39 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: Acmg+0cH9KBBG1bGSESOX+QtKxEX4AAAYv/AAAKqHfA= From: "BERNARD, Yves" To: "Ed Seidewitz" , "Bran Selic" Cc: X-OriginalArrivalTime: 09 Mar 2009 22:36:40.0486 (UTC) FILETIME=[83CCF460:01C9A107] Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. Subject: RE: FW: Association End Ownership and Navigability Date: Mon, 9 Mar 2009 19:19:19 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: Acmg+0cH9KBBG1bGSESOX+QtKxEX4AAAYv/AAAKqHfAAAW0F0A== From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. To: "Ed Seidewitz" Cc: "Bran Selic" , uml2-rtf@omg.org, "BERNARD, Yves" Subject: RE: FW: Association End Ownership and Navigability X-KeepSent: 614539FE:835AE743-85257574:00819EF9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Jim Amsden Date: Mon, 9 Mar 2009 19:40:43 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 03/09/2009 17:40:47, Serialize complete at 03/09/2009 17:40:47 I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reassonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 Ã. : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I donâ..t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differentlyy for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always â..ownedâ. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you canâ..t actually â..find the opposite end by doing a searchâ., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isnâ..t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I donâ..t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isnâ..t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what â..applied at the level of complete associations or higherâ. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary association shown witth no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasnâ..t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The â..not classifier->isEmpty()â. part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is nno arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you canâ..t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steveâ..s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you donâ..t need to use a name to reference something in UML â.. references are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesnâ..t have to do with the ability to name an opposite end, but, rather, on whether one can navigable â..efficientlyâ. across a link of the association at runtime. Unfortunately, the meaning of â..efficient accessâ. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . buut, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the â..data base viewpointâ., versus the â..object orientedâ. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. Subject: RE: FW: Association End Ownership and Navigability Date: Tue, 10 Mar 2009 08:27:41 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhEHx2J1iPecy7SsWQdwW2SgnkowAPQ7GQ From: "BERNARD, Yves" To: "Jim Amsden" , "Ed Seidewitz" Cc: "Bran Selic" , X-OriginalArrivalTime: 10 Mar 2009 07:27:41.0708 (UTC) FILETIME=[B2919CC0:01C9A151] Ed, I think that what people was complaining about was not about the arrow notation by itself, but about the correlation that was made between the so-called "navigability" and the association ends ownership. Jim, Please, would you clarify your point: "It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction". Does "it" stand for "navigability"? Except if I'm wrong, an owned property is always visible/accessible (what is the difference ?) from its owning class as a structural feature (i.e. no need to refer to the link). I would also add that if the ability of UML to address very high levels of abstraction is invaluable, it should also provide the fundamentals to specify implementations with on reasonable common basis. Cheers, Yves -----Message d'origine----- De : Jim Amsden [mailto:jamsden@us.ibm.com] Envoyé : mardi 10 mars 2009 00:41 À : Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reassonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the am ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if therre is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . referrences are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case tthe end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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: "DESFRAY Philippe" To: "'Jim Amsden'" , "'Ed Seidewitz'" Cc: "'Bran Selic'" , , "'BERNARD, Yves'" Subject: RE: FW: Association End Ownership and Navigability Date: Tue, 10 Mar 2009 10:43:37 +0100 Organization: Softeam X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmhEP4EYxcNX3pEQqCBfr9hzXITvgAUuFUQ X-Softeam.fr-MailScanner: Found to be clean X-Softeam.fr-MailScanner-SpamCheck: n'est pas un polluriel (inscrit sur la liste blanche), SpamAssassin (not cached, score=0.221, requis 3.5, AWL 0.11, BAYES_00 -2.60, HTML_MESSAGE 0.00, HTML_TAG_BALANCE_BODY 1.26, MSGID_MULTIPLE_AT 1.45) X-Softeam.fr-MailScanner-From: philippe.desfray@softeam.fr X-Spam-Status: No Is anyone aware of real people having used the .dot. notation for real usages? My experience is that its recognition (of the dot notation) on the market equal 0 (or almost). I am curious to know if there is some enthusiasm of end users eagerly wanting that feature. ========================================= Philippe De : Jim Amsden [mailto:jamsden@us.ibm.com] Envoyé : mardi 10 mars 2009 00:41 À : Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonable, of courrse! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for diifferent people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntax representatioon, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. Subject: RE: FW: Association End Ownership and Navigability Date: Tue, 10 Mar 2009 11:00:48 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhEP4EYxcNX3pEQqCBfr9hzXITvgAUuFUQAACc8PA= From: "BERNARD, Yves" To: "DESFRAY Philippe" , "Jim Amsden" , "Ed Seidewitz" Cc: "Bran Selic" , X-OriginalArrivalTime: 10 Mar 2009 10:01:07.0767 (UTC) FILETIME=[21CEBC70:01C9A167] Hi Philippe, This notation is available in TOPCASED UML editor where it's implemented as an "echo" of the owner-end ownership. What users (like me) actually need is a convenient and unambiguous means to specify the ownership of association ends ! ;o) -----Message d'origine----- De : DESFRAY Philippe [mailto:philippe.desfray@softeam.fr] Envoyé : mardi 10 mars 2009 10:44 À : 'Jim Amsden'; 'Ed Seidewitz' Cc : 'Bran Selic'; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Is anyone aware of real people having used the .dot. notation for real usages? My experience is that its recognition (of the dot notation) on the market equal 0 (or almost). I am curious to know if there is some enthusiasm of end users eagerly wanting that feature. ========================================= Philippe De : Jim Amsden [mailto:jamsden@us.ibm.com] Envoyé : mardi 10 mars 2009 00:41 À : Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (II, myself, am always completely reasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for differeent people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets.> In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through linnks in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, ass I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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: Steve Cook To: Jim Amsden , Ed Seidewitz CC: Bran Selic , "uml2-rtf@omg.org" , "BERNARD, Yves" Date: Tue, 10 Mar 2009 10:08:17 +0000 Subject: RE: FW: Association End Ownership and Navigability Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhERT2GvUGnIpTT423PjYzA0+O8QAVo9wQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reeasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently foor different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a bi binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) > So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links iin the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the eend is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. Subject: RE: FW: Association End Ownership and Navigability Date: Tue, 10 Mar 2009 11:21:48 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhERT2GvUGnIpTT423PjYzA0+O8QAVo9wQAAAx1VA= From: "BERNARD, Yves" To: "Steve Cook" , "Jim Amsden" , "Ed Seidewitz" Cc: "Bran Selic" , X-OriginalArrivalTime: 10 Mar 2009 10:22:14.0676 (UTC) FILETIME=[14F1B540:01C9A16A] I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonaable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran .> Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingraiined differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.).< Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary association shown with nno arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Notee that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . referennces are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted abovee, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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: Steve Cook To: "BERNARD, Yves" , Jim Amsden , Ed Seidewitz CC: Bran Selic , "uml2-rtf@omg.org" Date: Tue, 10 Mar 2009 11:04:24 +0000 Subject: RE: FW: Association End Ownership and Navigability Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhERT2GvUGnIpTT423PjYzA0+O8QAVo9wQAAAx1VAAAZvxUA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonable, of couurse! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for different peopple! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary associationn shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, thheir cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract ssyntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . bbut, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. Subject: RE: FW: Association End Ownership and Navigability Date: Tue, 10 Mar 2009 12:31:03 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhERT2GvUGnIpTT423PjYzA0+O8QAVo9wQAAAx1VAAAZvxUAADG6HA From: "Hains, Ralph" To: "Steve Cook" , "BERNARD, Yves" , "Jim Amsden" , "Ed Seidewitz" Cc: "Bran Selic" , And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . thouugh a bit worse than . the ambiguity of a binary associiation shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . referennces are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . butt, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. Reply-To: From: "Conrad Bock" To: "'Hains, Ralph'" , "'Steve Cook'" , "'BERNARD, Yves'" , "'Jim Amsden'" , "'Ed Seidewitz'" Cc: "'Bran Selic'" , Subject: RE: FW: Association End Ownership and Navigability Date: Tue, 10 Mar 2009 09:54:35 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmhERT2GvUGnIpTT423PjYzA0+O8QAVo9wQAAAx1VAAAZvxUAADG6HAAAMLMXA= X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n2ADsZDC013540 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1237298079.26336@D4X0LXnXl36RPduMFVlzeA X-Spam-Status: No X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n2AE2DFO027089 Ed, et al, I think the definition of navigation fits the typical modelers intention, even though there is of course no precise definition of "efficient". It commits the implementation to provide this efficiency in the stated direction (which doesn't prevent efficiency in the other direction, as Bran said, but doesn't require it either). I don't agree that the definition was a stepping stone to deprecation, it filled a gap in the earlier specs. > [Yves] So, it seems that in most people minds and in most tool > implementations the "arrow" notation is actually linked to the > (opposite) end ownership. Then I strongly support Bran's proposal to > get rid of this "non-concept" of navigability and to restaure > understandability and consistency to this part of the UML > specification. For OO implementations, but not relational. See the discussion of of Issue 6243 (Association not affecting ends) in in http://doc.omg.org/ptc/04-10-01. I have some slides form the discussion also, if anyone is interested. > [Jim A] I would recommend removing the dots and the changes relating > to property ownership. Property ownership is a manifestation of > navigability - indicated by the arrow. It means the property is > visible and accessible from the owning class and can be obtained > through a ReadLinkAction. That's all it means. It doesn't have > anything to do with correlation tables, foreign keys, nor does it > constrain any implementation in any way other than for accessibility > through a ReadLinkAction without a search or accessing indirectly > through the association somehow. Tools would be free to implement > every owned property in a correlation table if that met their needs. > [Steve C] Personally I think the dot notation is absurd. Ownership > is a property of the model, not of the system being modelled. > Ownership means that model serialization formats are nested and model > element deletion is propagated. Why this should be pushed in the > face of the modeller is beyond me. ... As Jim says, its relationship > to foreign keys, tables, classes etc is wholly secondary and entirely > in the mind of the modeller, or manifested by some translation > technology. Many if not most modelers take ownership in the model as "ownership" at runtime, because they take the model as a sort of "map" of runtime. Agreed we'd like everyone to take a pure MDA view of models, but that's not how it is. These modelers were hampered by having navigation tied to model ownership, and Issue 6243 addressed that. > [Yves] I think that what people was complaining about was not about > the arrow notation by itself, but about the correlation that was made > between the so-called "navigability" and the association ends > ownership. Yes, Issue 6243 corrected this. > [Yves] What users (like me) actually need is a convenient and > unambiguous means to specify the ownership of association ends ! ;o) This is what the dot notation provides, if it is used as spec'd. tation for real usages? My experience is that its recognition (of > the dot notation) on the market equal 0 (or almost). I am curious to > know if there is some enthusiasm of end users eagerly wanting that > feature. My guess is most people do what the UML spec did, they take a convention about what the lack of dot mt least no with UML > actions. That is the case when both ends of the association are > non-navigable, in which case neither end is readable, even by read > link action. If the association is an association class, you can loop through the instances to navigate the association. Reply-To: From: "Conrad Bock" To: "'Hains, Ralph'" , "'Steve Cook'" , "'BERNARD, Yves'" , "'Jim Amsden'" , "'Ed Seidewitz'" Cc: "'Bran Selic'" , Subject: RE: FW: Association End Ownership and Navigability, so much navigation, so few properties Date: Tue, 10 Mar 2009 10:23:39 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmhERT2GvUGnIpTT423PjYzA0+O8QAVo9wQAAAx1VAAAZvxUAADG6HAAAO2P6A= X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n2AENeql018132 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1237299826.51534@pVK+acNlstkv73WsFXeyyw X-Spam-Status: No P.S. Since everyone is posting their beefs about navigation, I'll post mine. :) There are actually six navigations for binary association, see the first three figures in http://www.conradbock.org/relation2.html (http://www.conradbock.org/rel2fig1.gif http://www.conradbock.org/rel2fig2.gif http://www.conradbock.org/rel2fig3.gif) UML currently squeezes them into two properties instead of the six actually needed (SysML added a couple more to partially address this, see the Participant Property stereotype in http://doc.omg.org/formal/08-11-02). Pete filed a related issue at http://www.omg.org/issues/issue9374.txt. I think the problem is largely due to UML's schizophrenia between relational and OO applications. One of its precursors started in relational (see the article by David Oliver in INCOSE Insight, 7:2, July 2004, at the end). Presumably this is why the association ends appear notationally on the opposite side from where an OO modeler would expect them. Conrad Subject: RE: FW: Association End Ownership and Navigability Date: Tue, 10 Mar 2009 16:38:21 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhERT2GvUGnIpTT423PjYzA0+O8QAVo9wQAAAx1VAAAZvxUAADG6HAAABolyA= From: "BERNARD, Yves" To: "Hains, Ralph" , "Steve Cook" , "Jim Amsden" , "Ed Seidewitz" Cc: "Bran Selic" , X-OriginalArrivalTime: 10 Mar 2009 15:38:22.0544 (UTC) FILETIME=[3EACAD00:01C9A196] And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myyself, am always completely reasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). > Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though aa bit worse than . the ambiguity of a binary assocciation shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no aarrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted abbove, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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: Steve Cook To: "BERNARD, Yves" , "Hains, Ralph" , Jim Amsden , Ed Seidewitz CC: Bran Selic , "uml2-rtf@omg.org" Date: Tue, 10 Mar 2009 15:56:29 +0000 Subject: RE: FW: Association End Ownership and Navigability Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhERT2GvUGnIpTT423PjYzA0+O8QAVo9wQAAAx1VAAAZvxUAADG6HAAABolyAABppB0A== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for differennt people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . thoough a bit worse than . the ambiguity of a binary assocciation shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arroow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the absttract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. Subject: RE: FW: Association End Ownership and Navigability Date: Tue, 10 Mar 2009 13:25:58 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhERT2GvUGnIpTT423PjYzA0+O8QAVo9wQAAAx1VAAAZvxUAADG6HAAAMLMXAABwA7sA== From: "Ed Seidewitz" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n2AHRK6Z007116 Conrad -- Just a couple of comments. > This is what the dot notation provides, if it is used as spec'd. > Non-navigable ends must be owned by the association, navigable ends can > be owned by the association or the end classifier, depending on the dot. > Which case is ambiguous? The case that is ambiguous is when no dots are shown on an association. Per the spec, this can mean either that both association ends are owned by the association, or that the dot notation is not being used and you can't draw any conclusions about the end owners. Worse, the spec seems to imply that you can use the dot notation for some associations in a model but not others, which means that this ambiguity exists even if you can see the dot notation used on some associations in the model. > If the association is an association class, you can loop through the > instances to navigate the association. Yes, you are right. But what I said is still true if the association is not an association class: there is no way to read the links of an association all of whose ends are non-navigable. Read link action can't be used (because of the non-navigability), and you can't iterate over the association extent and use read structural feature action (because the links of an association that is not an association class are not objects). I don't think this was the intent. I think it was intended that it be possible to check for the existence of a link, even if its ends are not navigable. Would you agree with that? If so, then the navigability constraint on read link action should be removed. (Which would mean that navigability really would not have any impact all on UML execution semantics...) -- Ed Subject: RE: FW: Association End Ownership and Navigability Date: Tue, 10 Mar 2009 18:34:13 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhERT2GvUGnIpTT423PjYzA0+O8QAVo9wQAAAx1VAAAZvxUAADG6HAAABolyAABppB0AAAsK5w From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , "Jim Amsden" , "Ed Seidewitz" Cc: "Bran Selic" , X-OriginalArrivalTime: 10 Mar 2009 17:34:14.0817 (UTC) FILETIME=[6E8D5910:01C9A1A6] Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 À : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself,, am always completely reasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differenntly for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary associatioon shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is nno arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I nnoted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. To: "BERNARD, Yves" Cc: "Bran Selic" , "Ed Seidewitz" , "Hains, Ralph" , "Steve Cook" , uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability X-KeepSent: 7C779C74:A4D7596C-85257575:0063D4CF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Jim Amsden Date: Tue, 10 Mar 2009 12:16:34 -0600 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 03/10/2009 12:16:38, Serialize complete at 03/10/2009 12:16:38 I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 Ã. : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 Ã. : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be â..strongly linked to the concept of composite aggregationâ. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I donâ..t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 Ã. : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reeasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 Ã. : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I donâ..t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for different peoople! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always â..ownedâ. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you canâ..t actually â..find the opposite end by doing a searchâ., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isnâ..t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I donâ..t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isnâ..t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what â..applied at the level of complete associations or higherâ. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . thouugh a bit worse than . the ambiguity of a binary associiation shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasnâ..t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The â..not classifier->isEmpty()â. part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . iff there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you canâ..t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steveâ..s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you donâ..t need to use a name to reference something in UML . references are through links in the abstract synntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesnâ..t have to do with the ability to name an opposite end, but, rather, on whether one can navigable â..efficientlyâ. across a link of the association at runtime. Unfortunately, the meaning of â..efficient accessâ. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted abovee, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the â..data base viewpointâ., versus the â..object orientedâ. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. Subject: RE: FW: Association End Ownership and Navigability Date: Tue, 10 Mar 2009 17:45:39 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhrISRX8BiV+k7SBKeNZDglsMAzAAHEgbg From: "Ed Seidewitz" To: "Jim Amsden" Cc: Well, one would presume that an action language integrated with UML activities would follow the abstract syntax and semantics of UML actions. In that case, the only action explicitly affected by navigability is read link action. So, if, in .aStudent.professor.salary., .professor. and .salary. are structural features, and they are being read using read structural feature actions, then navigability is not an issue (though visibility is). Either the ends .professor. and .salary. are classifier-owned ends, in which case navigability is automatic, or they are owned by an association class, in which case navigability doesn.t matter (at least as things stand now). On the other hand, if .aStudent.professor.salary. is the surface syntax for using read link actions, then navigability does matter: .professor. and .salary. must be navigable in order to be read. -- Ed -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, March 10, 2009 2:17 PM To: BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 À : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. Subject: RE: FW: Association End Ownership and Navigability Date: Tue, 10 Mar 2009 14:50:03 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhrISRX8BiV+k7SBKeNZDglsMAzAAHEgbgAABGIVA= From: "Pete Rivett" To: "Ed Seidewitz" , "Jim Amsden" Cc: It seems as if the resolution to 6243 forgot about read link action: with the new definition of navigability it seems to no longer make sense to restrict it to navigable properties. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 10 March 2009 14:46 To: Jim Amsden Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Well, one would presume that an action language integrated with UML activities would follow the abstract syntax and semantics of UML actions. In that case, the only action explicitly affected by navigability is read link action. So, if, in .aStudent.professor.salary., .professor. and .salary. are structural features, and they are being read using read structural feature actions, then navigability is not an issue (though visibility is). Either the ends .professor. and .salary. are classifier-owned ends, in which case navigability is automatic, or they are owned by an association class, in which case navigability doesn.t matter (at least as things stand now). On the other hand, if .aStudent.professor.salary. is the surface syntax for using read link actions, then navigability does matter: .professor. and .salary. must be navigable in order to be read. -- Ed -------------------------------------------------------------------------------- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, March 10, 2009 2:17 PM To: BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 À : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. Subject: RE: FW: Association End Ownership and Navigability Date: Tue, 10 Mar 2009 15:26:24 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhrJ3eGOKx+65ORtCnYI654QVXuwAFadzQ From: "Pete Rivett" To: "Jim Amsden" , "BERNARD, Yves" Cc: "Bran Selic" , "Ed Seidewitz" , "Hains, Ralph" , "Steve Cook" , Jim, That might be what you do but that does not seem to be using the information available in the UML model: you are in effect ignoring the fact that navigability and property ownership are now orthogonal and can be separately modeled. Though I.m not entirely clear what you mean by .translate. and .switching physical ownership in relational systems. (are you referring to the process of generating a relational PSM from a platform-agnostic PIM?). How for example would your approach cope with something like the association between a Stereotype instance and the instance of the metaclass to which it is applied? In this case there is no Property on the metaclass, but in any UML tool (which is the .runtime. application) it is clearly important to allow efficient access from a model element to its applied stereotypes. An example of such a pattern in a business model might be the association between a Person class and a PayrollRecord class . where there is no propertty Person.payrollRecord (because this might represent an existing Directory structure) but efficient access is required to the PayrollRecord for a Person. To Yves. original question in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? The UML spec has almost nothing to say about the semantics of .ownership.. It has little enough to say about composition (on which it is based) beyond .An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.. And in addition ownership has a naming aspect: A namespace provides a container for named elements. It provides a means for resolving composite names, such as name1::name2::name3. The member association identifies all named elements in a namespace called N that can be referred to by a composite name of the form N::. Note that this is different from all of the names that can be referred to unqualified within N, because that set also includes all unhidden members of enclosing namespaces. Although naming is not really related to .semantics. . since the semantics are largely governed by the Acttions in UML which reference elements directly not by name. Thus the decision as to ownership will be largely determined by considerations of model management rather than of business meaning. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 10 March 2009 11:17 To: BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 À : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonable, oof course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently ffor different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. < In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . t the ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted abovee, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jBmslKHw4sjMS+5L6rRHn4fIRt8tXhKkLQ+uuhhb1Z8=; b=YnvvI2bHAtY0vr++lGA68PNJpmAjLv8dihbSOp4XDNm5VZtKiEQxzDRIUygAf2dWnN j1R4zhL+M13NUSmdQ6t7JeVtP6I5Lfb8ajbtgrPK/OpuGtUDqxpFhKeVFjpTzmIFiBdd uaT0pApPXgJ8U2u6NyHlvn8zEsFINoQGu9sec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YyYHG2XZZ0MnHeNjf7sbkrv0UJiJ2atiozA9bzsgKwlj4qSYOVNiQILBzTlMztkQSo DerezB+Q6avzi3KRl6aOg6gOrBop/msjQaoxoje39zAvb7iVPwMOiDi/u7kGYn2lmmay 2fnho0IxpdSujT6K3iIDgC1WlhEIaV7caEPak= Date: Tue, 10 Mar 2009 20:51:06 -0400 Subject: Re: FW: Association End Ownership and Navigability, so much navigation, so few properties From: Bran Selic To: conrad.bock@nist.gov Cc: "Hains, Ralph" , Steve Cook , "BERNARD, Yves" , Jim Amsden , Ed Seidewitz , uml2-rtf@omg.org Conrad, You are absolutely right that the problem stems from the tension between the OO and relational paradigms. In UML 1 navigability was intended to capture a characteristic that, as of UML 2, is being captured through the concept of association end ownership. If an object owns the end of a link, then it clearly has an access path to the opposite end. As a result, navigability lost its purpose, but was retained for backward compatibility reasons (cultural rather than technical). As someone suggested (Jim?), perhaps we should get rid of the dot notation and change the meaning of the presence or absence of an arrow to capture whether the end is owned by the link or the object -- as was assumed before? Any navigability implications of this can be a semantic variation point, for those who feel that they need the concept. Navigability was never a well defined notion, or even a necessary one. Who is doing the navigating anyway? Is it the object or some thread that is executing the object or the link? Cheers...Bran On Tue, Mar 10, 2009 at 10:23 AM, Conrad Bock wrote: P.S. Since everyone is posting their beefs about navigation, I'll post mine. :) There are actually six navigations for binary association, see the first three figures in http://www.conradbock.org/relation2.html (http://www.conradbock.org/rel2fig1.gif http://www.conradbock.org/rel2fig2.gif http://www.conradbock.org/rel2fig3.gif) UML currently squeezes them into two properties instead of the six actually needed (SysML added a couple more to partially address this, see the Participant Property stereotype in http://doc.omg.org/formal/08-11-02). Pete filed a related issue at http://www.omg.org/issues/issue9374.txt. I think the problem is largely due to UML's schizophrenia between relational and OO applications. One of its precursors started in relational (see the article by David Oliver in INCOSE Insight, 7:2, July 2004, at the end). Presumably this is why the association ends appear notationally on the opposite side from where an OO modeler would expect them. Conrad To: Bran Selic Cc: conrad.bock@nist.gov, Ed Seidewitz , "Hains, Ralph" , Steve Cook , uml2-rtf@omg.org, "BERNARD, Yves" Subject: Re: FW: Association End Ownership and Navigability, so much navigation, so few properties X-KeepSent: 968BBA51:EC44CC3C-85257576:0005F1CA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Jim Amsden Date: Tue, 10 Mar 2009 21:12:52 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 03/10/2009 19:12:55, Serialize complete at 03/10/2009 19:12:55 Bran, Navigation becomes important when we distinguish the definition of a property from its use. Navigation use to say what properties were accessible, subject to visibility. That was manifest in UML2 by property ownership as a way of capturing the accessibility using properties. But somehow we got the idea that property ownership implied some constraints on model-to-model transforms that prevented tool vendors from exploiting associations or mapping to relational system because the properties were "owned" by the wrong thing. I chose to think of property ownership as simply a means of formalizing the semantics of accessible navigation in the context of a namespace. PIM to PSM transforms I my mind are free to translate this to whatever works in the PSM environment, just like anything else in the PSM. So I never saw an issue with object/relational mapping in UML2. From: Bran Selic To: conrad.bock@nist.gov Cc: "Hains, Ralph" , Steve Cook , "BERNARD, Yves" , Jim Amsden/Raleigh/IBM@IBMUS, Ed Seidewitz , uml2-rtf@omg.org Date: 03/10/2009 08:52 PM Subject: Re: FW: Association End Ownership and Navigability, so much navigation, so few properties -------------------------------------------------------------------------------- Conrad, You are absolutely right that the problem stems from the tension between the OO and relational paradigms. In UML 1 navigability was intended to capture a characteristic that, as of UML 2, is being captured through the concept of association end ownership. If an object owns the end of a link, then it clearly has an access path to the opposite end. As a result, navigability lost its purpose, but was retained for backward compatibility reasons (cultural rather than technical). As someone suggested (Jim?), perhaps we should get rid of the dot notation and change the meaning of the presence or absence of an arrow to capture whether the end is owned by the link or the object -- as was assumed before? Any navigability implications of this can be a semantic variation point, for those who feel that they need the concept. Navigability was never a well defined notion, or even a necessary one. Who is doing the navigating anyway? Is it the object or some thread that is executing the object or the link? Cheers...Bran On Tue, Mar 10, 2009 at 10:23 AM, Conrad Bock wrote: P.S. Since everyone is posting their beefs about navigation, I'll post mine. :) There are actually six navigations for binary association, see the first three figures in http://www.conradbock.org/relation2.html (http://www.conradbock.org/rel2fig1.gif http://www.conradbock.org/rel2fig2.gif http://www.conradbock.org/rel2fig3.gif) UML currently squeezes them into two properties instead of the six actually needed (SysML added a couple more to partially address this, see the Participant Property stereotype in http://doc.omg.org/formal/08-11-02). Pete filed a related issue at http://www.omg.org/issues/issue9374.txt. I think the problem is largely due to UML's schizophrenia between relational and OO applications. One of its precursors started in relational (see the article by David Oliver in INCOSE Insight, 7:2, July 2004, at the end). Presumably this is why the association ends appear notationally on the opposite side from where an OO modeler would expect them. Conrad Subject: RE: FW: Association End Ownership and Navigability Date: Wed, 11 Mar 2009 07:52:53 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhrJ3eGOKx+65ORtCnYI654QVXuwAFadzQAAOmdrA= From: "BERNARD, Yves" To: "Pete Rivett" , "Jim Amsden" Cc: "Bran Selic" , "Ed Seidewitz" , "Hains, Ralph" , "Steve Cook" , X-OriginalArrivalTime: 11 Mar 2009 06:52:53.0676 (UTC) FILETIME=[006AF6C0:01C9A216] Pete, So if we agree to say that the concept of ownership "is based on" the concept of composition it means that the semantic of composition applies. Then strictly speaking, when an association is deleted, the properties (=the "ends") that it owns should be deleted, right ? But nothing implies that the "ends" that are owned by the classifiers are also deleted. That is : depending on the association end ownership the, same action (e.g. DestroyLinkAction), which could also append at run time, will not have the same result on the system. That is why I believe we cannot say that the ownership has no business meaning. Yves -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 10 mars 2009 23:26 À : Jim Amsden; BERNARD, Yves Cc : Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Jim, That might be what you do but that does not seem to be using the information available in the UML model: you are in effect ignoring the fact that navigability and property ownership are now orthogonal and can be separately modeled. Though I.m not entirely clear what you mean by .translate. and .switching physical ownership in relational systems. (are you referring to the process of generating a relational PSM from a platform-agnostic PIM?). How for example would your approach cope with something like the association between a Stereotype instance and the instance of the metaclass to which it is applied? In this case there is no Property on the metaclass, but in any UML tool (which is the .runtime. application) it is clearly important to allow efficient access from a model element to its applied stereotypes. An example of such a pattern in a business model might be the association between a Person class and a PayrollRecord class . where there is no property Perrson.payrollRecord (because this might represent an existing Directory structure) but efficient access is required to the PayrollRecord for a Person. To Yves. original question in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? The UML spec has almost nothing to say about the semantics of .ownership.. It has little enough to say about composition (on which it is based) beyond .An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.. And in addition ownership has a naming aspect: A namespace provides a container for named elements. It provides a means for resolving composite names, such as name1::name2::name3. The member association identifies all named elements in a namespace called N that can be referred to by a composite name of the form N::. Note that this is different from all of the names that can be referred to unqualified within N, because that set also includes all unhidden members of enclosing namespaces. Although naming is not really related to .semantics. . since the semanttics are largely governed by the Actions in UML which reference elements directly not by name. Thus the decision as to ownership will be largely determined by considerations of model management rather than of business meaning. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 10 March 2009 11:17 To: BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 À : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, aam always completely reasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for different people! I rremember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. < In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a biit worse than . the ambiguity of a binary associatioon shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract ssyntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. 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. Subject: RE: FW: Association End Ownership and Navigability Date: Wed, 11 Mar 2009 01:17:38 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhrJ3eGOKx+65ORtCnYI654QVXuwAFadzQAAOmdrAAE+ldkA== From: "Pete Rivett" To: "BERNARD, Yves" , "Jim Amsden" Cc: "Bran Selic" , "Ed Seidewitz" , "Hains, Ralph" , "Steve Cook" , Yves, As Steve said (attached) you.re not at the right meta-level. That the Association owns its ends only means that in the Model itself, deleting the Association will delete its Properties. i.e. to do with model management. It says nothing at all at the business level . that would be represented by whether tthese Properties themselves have isComposite=true (i.e. whether the specific Association is drawn with a black diamond). You can have a black diamond regardless of whether those Properties/ends are owned by the Class or the Association. The only .application. that the UML metamodel governs the runtime behavior of is a UML tool: i.e. the UML metamodel is the (structural) business model specifying (some aspects of) a UML tool (which is why I.d argue that all Associations in the UML metamodel itself should be navigable . since tools shouuld be able to traverse models efficiently in both directions). Hope that helps Pete From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 23:53 To: Pete Rivett; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, So if we agree to say that the concept of ownership "is based on" the concept of composition it means that the semantic of composition applies. Then strictly speaking, when an association is deleted, the properties (=the "ends") that it owns should be deleted, right ? But nothing implies that the "ends" that are owned by the classifiers are also deleted. That is : depending on the association end ownership the, same action (e.g. DestroyLinkAction), which could also append at run time, will not have the same result on the system. That is why I believe we cannot say that the ownership has no business meaning. Yves -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 10 mars 2009 23:26 À : Jim Amsden; BERNARD, Yves Cc : Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Jim, That might be what you do but that does not seem to be using the information available in the UML model: you are in effect ignoring the fact that navigability and property ownership are now orthogonal and can be separately modeled. Though I.m not entirely clear what you mean by .translate. and .switching physical ownership in relational systems. (are you referring to the process of generating a relational PSM from a platform-agnostic PIM?). How for example would your approach cope with something like the association between a Stereotype instance and the instance of the metaclass to which it is applied? In this case there is no Property on the metaclass, but in any UML tool (which is the .runtime. application) it is clearly important to allow efficient access from a model element to its applied stereotypes. An example of such a pattern in a business model might be the association between a Person class and a PayrollRecord class . where there is no property Person.ppayrollRecord (because this might represent an existing Directory structure) but efficient access is required to the PayrollRecord for a Person. To Yves. original question in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? The UML spec has almost nothing to say about the semantics of .ownership.. It has little enough to say about composition (on which it is based) beyond .An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.. And in addition ownership has a naming aspect: A namespace provides a container for named elements. It provides a means for resolving composite names, such as name1::name2::name3. The member association identifies all named elements in a namespace called N that can be referred to by a composite name of the form N::. Note that this is different from all of the names that can be referred to unqualified within N, because that set also includes all unhidden members of enclosing namespaces. Although naming is not really related to .semantics. . since the semantics are largely governed by the Actions in UML which reference elements directly not by name. Thus the decision as to ownership will be largely determined by considerations of model management rather than of business meaning. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 10 March 2009 11:17 To: BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 À : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for differrent people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. > In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are throough links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in thatt case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. 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. Received: from EXSMTPD001-2.DEX001.intermedia.net ([64.78.19.139]) by DHOST001-50.DEX001.intermedia.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 09:00:35 -0700 Received: from exmfd001-1.intermedia.net ([64.78.61.164]) by EXSMTPD001-2.DEX001.intermedia.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 09:00:35 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C9A199.58E15380" Received: from localhost (localhost.localdomain [127.0.0.1]) by exmfd001-1.intermedia.net (Postfix) with ESMTP id A070FA5A3; Tue, 10 Mar 2009 09:00:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from exmfd001-1.intermedia.net ([127.0.0.1]) by localhost (exmfd001-1.intermedia.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMiVevKtrbW8; Tue, 10 Mar 2009 08:59:54 -0700 (PDT) Received: from amethyst.omg.org (amethyst.omg.org [192.67.184.64]) by exmfd001-1.intermedia.net (Postfix) with ESMTP id 9EE96A360; Tue, 10 Mar 2009 08:59:53 -0700 (PDT) Received: from serpentine.omg.org (serpentine.omg.org [192.67.184.8]) by amethyst.omg.org (8.13.8/8.12.11) with ESMTP id n2AFu1PS017716 for ; Tue, 10 Mar 2009 11:56:01 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by serpentine.omg.org (Postfix) with ESMTP id 75B473E60F0 for ; Tue, 10 Mar 2009 11:57:50 -0400 (EDT) Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by serpentine.omg.org (Postfix) with ESMTP id 6BB573E60E6 for ; Tue, 10 Mar 2009 11:56:37 -0400 (EDT) Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 10 Mar 2009 15:56:36 +0000 Received: from ea-exmsg-c331.europe.corp.microsoft.com ([169.254.1.218]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Tue, 10 Mar 2009 15:56:32 +0000 Content-class: urn:content-classes:message Subject: RE: FW: Association End Ownership and Navigability Date: Tue, 10 Mar 2009 08:56:29 -0700 Message-ID: <7887BB6F749C784D97A4F08D419801603B4B245860@EA-EXMSG-C331.europe.corp.microsoft.com> In-Reply-To: <32D05B7C1B5C8A4683E438B424FC33CD07A429D1@fr0-mailmb12.res.airbus.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhERT2GvUGnIpTT423PjYzA0+O8QAVo9wQAAAx1VAAAZvxUAADG6HAAABolyAABppB0A== References: <32D05B7C1B5C8A4683E438B424FC33CD07A429D1@fr0-mailmb12.res.airbus.corp> From: "Steve Cook" To: "BERNARD, Yves" , "Hains, Ralph" , "Jim Amsden" , "Ed Seidewitz" Cc: "Bran Selic" , Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonnable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for diifferent people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binaryy association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is nno arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in thhe abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end iis, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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: Steve Cook To: Pete Rivett , "BERNARD, Yves" , Jim Amsden CC: Bran Selic , Ed Seidewitz , "Hains, Ralph" , "uml2-rtf@omg.org" Date: Wed, 11 Mar 2009 10:20:26 +0000 Subject: RE: FW: Association End Ownership and Navigability Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhrJ3eGOKx+65ORtCnYI654QVXuwAFadzQAAOmdrAAE+ldkAAEfTxQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Pete, very well said. A couple of questions for the group: If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 11 March 2009 08:18 To: BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves, As Steve said (attached) you.re not at the right meta-level. That the Association owns its ends only means that in the Model itself, deleting the Association will delete its Properties. i.e. to do with model management. It says nothing at all at the business level . that would be reepresented by whether these Properties themselves have isComposite=true (i.e. whether the specific Association is drawn with a black diamond). You can have a black diamond regardless of whether those Properties/ends are owned by the Class or the Association. The only .application. that the UML metamodel governs the runtime behavior of is a UML tool: i.e. the UML metamodel is the (structural) business model specifying (some aspects of) a UML tool (which is why I.d argue that all Associations in the UML metamodel itself should be navigable . since tools should be aable to traverse models efficiently in both directions). Hope that helps Pete From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 23:53 To: Pete Rivett; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, So if we agree to say that the concept of ownership "is based on" the concept of composition it means that the semantic of composition applies. Then strictly speaking, when an association is deleted, the properties (=the "ends") that it owns should be deleted, right ? But nothing implies that the "ends" that are owned by the classifiers are also deleted. That is : depending on the association end ownership the, same action (e.g. DestroyLinkAction), which could also append at run time, will not have the same result on the system. That is why I believe we cannot say that the ownership has no business meaning. Yves -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 10 mars 2009 23:26 À : Jim Amsden; BERNARD, Yves Cc : Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Jim, That might be what you do but that does not seem to be using the information available in the UML model: you are in effect ignoring the fact that navigability and property ownership are now orthogonal and can be separately modeled. Though I.m not entirely clear what you mean by .translate. and .switching physical ownership in relational systems. (are you referring to the process of generating a relational PSM from a platform-agnostic PIM?). How for example would your approach cope with something like the association between a Stereotype instance and the instance of the metaclass to which it is applied? In this case there is no Property on the metaclass, but in any UML tool (which is the .runtime. application) it is clearly important to allow efficient access from a model element to its applied stereotypes. An example of such a pattern in a business model might be the association between a Person class and a PayrollRecord class . where there is no property Person.paayrollRecord (because this might represent an existing Directory structure) but efficient access is required to the PayrollRecord for a Person. To Yves. original question in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? The UML spec has almost nothing to say about the semantics of .ownership.. It has little enough to say about composition (on which it is based) beyond .An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.. And in addition ownership has a naming aspect: A namespace provides a container for named elements. It provides a means for resolving composite names, such as name1::name2::name3. The member association identifies all named elements in a namespace called N that can be referred to by a composite name of the form N::. Note that this is different from all of the names that can be referred to unqualified within N, because that set also includes all unhidden members of enclosing namespaces. Although naming is not really related to .semantics. . since the semantics aree largely governed by the Actions in UML which reference elements directly not by name. Thus the decision as to ownership will be largely determined by considerations of model management rather than of business meaning. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 10 March 2009 11:17 To: BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 À : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always coompletely reasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . justt ingrained differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if tthere is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract synttax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end iis, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. 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. ConradGeans. Some take it in the OO sense, others in the relational sctually > nse. pposite end by doing a search required to use it. > [Ed] Note that there is at least one case in which you can be owned by the association or the end classifier, depending on the dot. do Subject: RE: FW: Association End Ownership and Navigability Date: Wed, 11 Mar 2009 03:48:26 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhrJ3eGOKx+65ORtCnYI654QVXuwAFadzQAAOmdrAAE+ldkAAEfTxQAAAr+/A= From: "Pete Rivett" To: "Steve Cook" , "BERNARD, Yves" , "Jim Amsden" Cc: "Bran Selic" , "Ed Seidewitz" , "Hains, Ralph" , Ø If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? When you say .the association is deleted. I think this could mean two things: a) The user performs some action offered by a tool user interface (e.g. right click on the line representing the association and selecting .Delete. from pop-up menu, or selecting the association line and just pressing the Delete key, or right clicking on the association in a tree browser of the whole model). b) An action is performed against the model being managed by the tool: in this case the action would be CMOF::Element::delete() (interestingly EMOF has no such delete operation!). Case b) is more straightforward: I think the classifier would be left owning the association end Property with all meta-attributes (multiplicity, visibility, constraints etc) retained apart from Property::association which would be unset, and Property::/opposite which would implicitly be unset through its derivation. That includes Property::type being retained (I had to think a bit about this last). I don.t think the effect on this Property differs depending on whether the other end is owned by the Association (and so will be deleted) or the other classifier. ** This is a compliance matter but actually one of MOF compliance, since UML itself does not define such actions at the metamodel level. Case a) provides room for the tool to do something .smart. and possibly even to prompt the user for an option. For example, to check whether the association should be deleted from the current diagram only or the whole model (and hence any other diagrams). Or to check whether the association end properties should also be deleted, though it would not be wrong to automatically delete the ends without prompting (regardless of the ownership of the ends . which arguablyy is a subtlety many vendors would not want to expose to their users). This is not a compliance matter: user interface behavior of UML tools is out of scope. There is no necessity (only an expectation) that there is any connection at all with the .delete. at the user interface and the .delete(). operation on the model described in b). For example the .delete from diagram only. option does not touch the model at all in the sense of b). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 11 March 2009 03:20 To: Pete Rivett; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, very well said. A couple of questions for the group: If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 11 March 2009 08:18 To: BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves, As Steve said (attached) you.re not at the right meta-level. That the Association owns its ends only means that in the Model itself, deleting the Association will delete its Properties. i.e. to do with model management. It says nothing at all at the business level . that would be reppresented by whether these Properties themselves have isComposite=true (i.e. whether the specific Association is drawn with a black diamond). You can have a black diamond regardless of whether those Properties/ends are owned by the Class or the Association. The only .application. that the UML metamodel governs the runtime behavior of is a UML tool: i.e. the UML metamodel is the (structural) business model specifying (some aspects of) a UML tool (which is why I.d argue that all Associations in the UML metamodel itself should be navigable . since tools should be able to traverse models eefficiently in both directions). Hope that helps Pete From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 23:53 To: Pete Rivett; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, So if we agree to say that the concept of ownership "is based on" the concept of composition it means that the semantic of composition applies. Then strictly speaking, when an association is deleted, the properties (=the "ends") that it owns should be deleted, right ? But nothing implies that the "ends" that are owned by the classifiers are also deleted. That is : depending on the association end ownership the, same action (e.g. DestroyLinkAction), which could also append at run time, will not have the same result on the system. That is why I believe we cannot say that the ownership has no business meaning. Yves -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 10 mars 2009 23:26 À : Jim Amsden; BERNARD, Yves Cc : Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Jim, That might be what you do but that does not seem to be using the information available in the UML model: you are in effect ignoring the fact that navigability and property ownership are now orthogonal and can be separately modeled. Though I.m not entirely clear what you mean by .translate. and .switching physical ownership in relational systems. (are you referring to the process of generating a relational PSM from a platform-agnostic PIM?). How for example would your approach cope with something like the association between a Stereotype instance and the instance of the metaclass to which it is applied? In this case there is no Property on the metaclass, but in any UML tool (which is the .runtime. application) it is clearly important to allow efficient access from a model element to its applied stereotypes. An example of such a pattern in a business model might be the association between a Person class and a PayrollRecord class . where there is no property Person.payrollRecord (because this might represent an existing Directory structure) but efficient access is required to the PayrollRecord for a Person. To Yves. original question in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? The UML spec has almost nothing to say about the semantics of .ownership.. It has little enough to say about composition (on which it is based) beyond .An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.. And in addition ownership has a naming aspect: A namespace provides a container for named elements. It provides a means for resolving composite names, such as name1::name2::name3. The member association identifies all named elements in a namespace called N that can be referred to by a composite name of the form N::. Note that this is different from all of the names that can be referred to unqualified within N, because that set also includes all unhidden members of enclosing namespaces. Although naming is not really related to .semantics. . since the semantics are largelyy governed by the Actions in UML which reference elements directly not by name. Thus the decision as to ownership will be largely determined by considerations of model management rather than of business meaning. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 10 March 2009 11:17 To: BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 À : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonablee, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differentlly for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than .. the ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a doot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.)) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . referencces are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted abbove, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. 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. Subject: RE: FW: Association End Ownership and Navigability Date: Thu, 12 Mar 2009 02:06:09 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhrJ3eGOKx+65ORtCnYI654QVXuwAFadzQAAOmdrAAE+ldkAAEfTxQAAAr+/AAAcKhEAABJmcA From: "Pete Rivett" To: "Steve Cook" , "BERNARD, Yves" , "Jim Amsden" Cc: "Bran Selic" , "Ed Seidewitz" , "Hains, Ralph" , People have attached other .model management. behavior to end ownership . though this is not mandated by sppecs. For example you.d need .permission. to do certain updates . e.g. youu could add an association-owned-end to a class without needing .permission. to update the class, but you could not add a class-owned end. Likewise adding the class-owned-end would be seen as .changing. the class so would require it (or more likely its containing package) to be checked out of a CM system. Some people talk in terms of whether the class should .know about. certain things it.s related to: the principle is that a class should only own ends for related objects it .should know about.. An example phrase from people using such a anthropomorphic methodology is .a Car should not know who its legalOwner is. as a way of determining that class Car should not have a property legalOwner (but conversely the class Party should have a property ownedCar). I mention this only in passing as another usage made of end ownership. Finally, end ownership will affect how the model is serialized . ends will be nested in tthe class/association that owns them. So these are reasons I can think of why end ownership might be important to be able to specify in UML. In addition to the traditional one that only owned properties become direct members of a generated programming language class (or indeed database table). As a historical aside: UML 1.x had distinct Attributes and Association Ends (the latter which could be navigable). MOF 1.x had the same but in addition a Class could have References which were explicit structural properties which gave access to a specific association end. Thus realizing explicitly the assumption people often had about what .navigability. meant. Regards Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 11 March 2009 04:29 To: Pete Rivett; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, thanks. I agree fully. In which case I think the material question is whether it is appropriate in UML to put dots on the end of associations to specify whether the model management behaviour is (b) below, or the alternative behaviour that the end is deleted along with the association. The argument that this .dot. information is to do with mapping to particular technologies is deeply unconvincing to me. If people want to attach information to UML models to enable it to map accurately to specific target technologies (relational databases, OO programs, html pages or anything else) that information belongs in profiles. Strategically if we want to beef up profiles so they can add dots and change deletion behaviour that is fine with me. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 11 March 2009 10:48 To: Steve Cook; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Ø If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? When you say .the association is deleted. I think this could mean two things: a) The user performs some action offered by a tool user interface (e.g. right click on the line representing the association and selecting .Delete. from pop-up menu, or selecting the association line and just pressing the Delete key, or right clicking on the association in a tree browser of the whole model). b) An action is performed against the model being managed by the tool: in this case the action would be CMOF::Element::delete() (interestingly EMOF has no such delete operation!). Case b) is more straightforward: I think the classifier would be left owning the association end Property with all meta-attributes (multiplicity, visibility, constraints etc) retained apart from Property::association which would be unset, and Property::/opposite which would implicitly be unset through its derivation. That includes Property::type being retained (I had to think a bit about this last). I don.t think the effect on this Property differs depending on whether the other end is owned by the Association (and so will be deleted) or the other classifier. ** This is a compliance matter but actually one of MOF compliance, since UML itself does not define such actions at the metamodel level. Case a) provides room for the tool to do something .smart. and possibly even to prompt the user for an option. For example, to check whether the association should be deleted from the current diagram only or the whole model (and hence any other diagrams). Or to check whether the association end properties should also be deleted, though it would not be wrong to automatically delete the ends without prompting (regardless of the ownership of the ends . which arguably is a suubtlety many vendors would not want to expose to their users). This is not a compliance matter: user interface behavior of UML tools is out of scope. There is no necessity (only an expectation) that there is any connection at all with the .delete. at the user interface and the .delete(). operation on the model described in b). For example the .delete from diagram only. option does not touch the model at all in the sense of b). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 11 March 2009 03:20 To: Pete Rivett; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, very well said. A couple of questions for the group: If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 11 March 2009 08:18 To: BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves, As Steve said (attached) you.re not at the right meta-level. That the Association owns its ends only means that in the Model itself, deleting the Association will delete its Properties. i.e. to do with model management. It says nothing at all at the business level . that would be representedd by whether these Properties themselves have isComposite=true (i.e. whether the specific Association is drawn with a black diamond). You can have a black diamond regardless of whether those Properties/ends are owned by the Class or the Association. The only .application. that the UML metamodel governs the runtime behavior of is a UML tool: i.e. the UML metamodel is the (structural) business model specifying (some aspects of) a UML tool (which is why I.d argue that all Associations in the UML metamodel itself should be navigable .. since tools should be able to traverse models efficiently in both directions). Hope that helps Pete From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 23:53 To: Pete Rivett; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, So if we agree to say that the concept of ownership "is based on" the concept of composition it means that the semantic of composition applies. Then strictly speaking, when an association is deleted, the properties (=the "ends") that it owns should be deleted, right ? But nothing implies that the "ends" that are owned by the classifiers are also deleted. That is : depending on the association end ownership the, same action (e.g. DestroyLinkAction), which could also append at run time, will not have the same result on the system. That is why I believe we cannot say that the ownership has no business meaning. Yves -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 10 mars 2009 23:26 À : Jim Amsden; BERNARD, Yves Cc : Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Jim, That might be what you do but that does not seem to be using the information available in the UML model: you are in effect ignoring the fact that navigability and property ownership are now orthogonal and can be separately modeled. Though I.m not entirely clear what you mean by .translate. and .switching physical ownership in relational systems. (are you referring to the process of generating a relational PSM from a platform-agnostic PIM?). How for example would your approach cope with something like the association between a Stereotype instance and the instance of the metaclass to which it is applied? In this case there is no Property on the metaclass, but in any UML tool (which is the .runtime. application) it is clearly important to allow efficient access from a model element to its applied stereotypes. An example of such a pattern in a business model might be the association between a Person class and a PayrollRecord class . where there is no pproperty Person.payrollRecord (because this might represent an existing Directory structure) but efficient access is required to the PayrollRecord for a Person. To Yves. original question in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? The UML spec has almost nothing to say about the semantics of .ownership.. It has little enough to say about composition (on which it is based) beyond .An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.. And in addition ownership has a naming aspect: A namespace provides a container for named elements. It provides a means for resolving composite names, such as name1::name2::name3. The member association identifies all named elements in a namespace called N that can be referred to by a composite name of the form N::. Note that this is different from all of the names that can be referred to unqualified within N, because that set also includes all unhidden members of enclosing namespaces. Although naming is not really related to .semantics. . since the semantics are largely governned by the Actions in UML which reference elements directly not by name. Thus the decision as to ownership will be largely determined by considerations of model management rather than of business meaning. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 10 March 2009 11:17 To: BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 À : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonable, of coourse! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for ddifferent people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ae ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Notee that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.)> So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, inn that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. 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. Subject: RE: FW: Association End Ownership and Navigability Date: Thu, 12 Mar 2009 12:26:49 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhrJ3eGOKx+65ORtCnYI654QVXuwAFadzQAAOmdrAAE+ldkAAEfTxQAAAr+/AAAcKhEAABJmcAADEH3DA= From: "BERNARD, Yves" To: "Pete Rivett" , "Steve Cook" , "Jim Amsden" Cc: "Bran Selic" , "Ed Seidewitz" , "Hains, Ralph" , X-OriginalArrivalTime: 12 Mar 2009 11:26:49.0816 (UTC) FILETIME=[6F88A580:01C9A305] There would be so much to discuss about associations... The point is that the specification seems very ambiguous and sometime inconsistent on some subjects (including this one) and people trying to get accurate information on the semantic are sometime more perplexed after the reading than before (cf. also the last mail from Cory on that subject). I would be happy to have a wide exchange on that subject but I'm not sure this mailing list is the right place. If yes it's ok for me, if no what about having it on an UML forum ? Cheers, Yves -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : jeudi 12 mars 2009 10:06 À : Steve Cook; BERNARD, Yves; Jim Amsden Cc : Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability People have attached other .model management. behavior to end ownership . though this is not mandated by specs. For example you.d need .permission. to do certain updates . e.g. you could add an association-owned-endd to a class without needing .permission. to update the class, but you could not add a class-owned end. Likewise adding the class-owned-end would be seen as .changing. the class so would require it (or more likely its containing package) to be checked out of a CM system. Some people talk in terms of whether the class should .know about. certain things it.s related to: the principle is that a class should only own ends for related objects it .should know about.. An example phrase from people using such a anthropomorphic methodology is .a Car should not know who its legalOwner is. as a way of determining that class Car should not have a property legalOwner (but conversely the class Party should have a property ownedCar). I mention this only in passing as another usage made of end ownership. Finally, end ownership will affect how the model is serialized . ends wwill be nested in the class/association that owns them. So these are reasons I can think of why end ownership might be important to be able to specify in UML. In addition to the traditional one that only owned properties become direct members of a generated programming language class (or indeed database table). As a historical aside: UML 1.x had distinct Attributes and Association Ends (the latter which could be navigable). MOF 1.x had the same but in addition a Class could have References which were explicit structural properties which gave access to a specific association end. Thus realizing explicitly the assumption people often had about what .navigability. meant. Regards Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 11 March 2009 04:29 To: Pete Rivett; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, thanks. I agree fully. In which case I think the material question is whether it is appropriate in UML to put dots on the end of associations to specify whether the model management behaviour is (b) below, or the alternative behaviour that the end is deleted along with the association. The argument that this .dot. information is to do with mapping to particular technologies is deeply unconvincing to me. If people want to attach information to UML models to enable it to map accurately to specific target technologies (relational databases, OO programs, html pages or anything else) that information belongs in profiles. Strategically if we want to beef up profiles so they can add dots and change deletion behaviour that is fine with me. -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 11 March 2009 10:48 To: Steve Cook; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Ø If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? When you say .the association is deleted. I think this could mean two things: a) The user performs some action offered by a tool user interface (e.g. right click on the line representing the association and selecting .Delete. from pop-up menu, or selecting the association line and just pressing the Delete key, or right clicking on the association in a tree browser of the whole model). b) An action is performed against the model being managed by the tool: in this case the action would be CMOF::Element::delete() (interestingly EMOF has no such delete operation!). Case b) is more straightforward: I think the classifier would be left owning the association end Property with all meta-attributes (multiplicity, visibility, constraints etc) retained apart from Property::association which would be unset, and Property::/opposite which would implicitly be unset through its derivation. That includes Property::type being retained (I had to think a bit about this last). I don.t think the effect on this Property differs depending on whether the other end is owned by the Association (and so will be deleted) or the other classifier. ** This is a compliance matter but actually one of MOF compliance, since UML itself does not define such actions at the metamodel level. Case a) provides room for the tool to do something .smart. and possibly even to prompt the user for an option. For example, to check whether the association should be deleted from the current diagram only or the whole model (and hence any other diagrams). Or to check whether the association end properties should also be deleted, though it would not be wrong to automatically delete the ends without prompting (regardless of the ownership of the ends . which arguably is a subtlety manny vendors would not want to expose to their users). This is not a compliance matter: user interface behavior of UML tools is out of scope. There is no necessity (only an expectation) that there is any connection at all with the .delete. at the user interface and the .delete(). operation on the model described in b). For example the .delete from diagram only. option does not touch the model at all in the sense of b). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 11 March 2009 03:20 To: Pete Rivett; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, very well said. A couple of questions for the group: If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 11 March 2009 08:18 To: BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves, As Steve said (attached) you.re not at the right meta-level. That the Association owns its ends only means that in the Model itself, deleting the Association will delete its Properties. i.e. to do with model management. It says nothing at all at the business level . thaat would be represented by whether these Properties themselves have isComposite=true (i.e. whether the specific Association is drawn with a black diamond). You can have a black diamond regardless of whether those Properties/ends are owned by the Class or the Association. The only .application. that the UML metamodel governs the runtime behavior of is a UML tool: i.e. the UML metamodel is the (structural) business model specifying (some aspects of) a UML tool (which is why I.d argue that all Associations in the UML metamodel itself should be navigable . sinnce tools should be able to traverse models efficiently in both directions). Hope that helps Pete From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 23:53 To: Pete Rivett; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, So if we agree to say that the concept of ownership "is based on" the concept of composition it means that the semantic of composition applies. Then strictly speaking, when an association is deleted, the properties (=the "ends") that it owns should be deleted, right ? But nothing implies that the "ends" that are owned by the classifiers are also deleted. That is : depending on the association end ownership the, same action (e.g. DestroyLinkAction), which could also append at run time, will not have the same result on the system. That is why I believe we cannot say that the ownership has no business meaning. Yves -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 10 mars 2009 23:26 À : Jim Amsden; BERNARD, Yves Cc : Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Jim, That might be what you do but that does not seem to be using the information available in the UML model: you are in effect ignoring the fact that navigability and property ownership are now orthogonal and can be separately modeled. Though I.m not entirely clear what you mean by .translate. and .switching physical ownership in relational systems. (are you referring to the process of generating a relational PSM from a platform-agnostic PIM?). How for example would your approach cope with something like the association between a Stereotype instance and the instance of the metaclass to which it is applied? In this case there is no Property on the metaclass, but in any UML tool (which is the .runtime. application) it is clearly important to allow efficient access from a model element to its applied stereotypes. An example of such a pattern in a business model might be the association between a Person class and a PayrollRecord class . where there is no property Personn.payrollRecord (because this might represent an existing Directory structure) but efficient access is required to the PayrollRecord for a Person. To Yves. original question in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? The UML spec has almost nothing to say about the semantics of .ownership.. It has little enough to say about composition (on which it is based) beyond .An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.. And in addition ownership has a naming aspect: A namespace provides a container for named elements. It provides a means for resolving composite names, such as name1::name2::name3. The member association identifies all named elements in a namespace called N that can be referred to by a composite name of the form N::. Note that this is different from all of the names that can be referred to unqualified within N, because that set also includes all unhidden members of enclosing namespaces. Although naming is not really related to .semantics. . since thee semantics are largely governed by the Actions in UML which reference elements directly not by name. Thus the decision as to ownership will be largely determined by considerations of model management rather than of business meaning. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 10 March 2009 11:17 To: BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 À : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always complettely reasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingraiined differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worrse than . the ambiguity of a binary association shown wwith no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannnot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) < So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links iin the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. 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. 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. Subject: RE: FW: Association End Ownership and Navigability Date: Thu, 12 Mar 2009 12:15:19 -0000 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhrJ3eGOKx+65ORtCnYI654QVXuwAFadzQAAOmdrAAE+ldkAAEfTxQAAAr+/AADChPEAAp0EEw From: "Hains, Ralph" To: "Cory Casanave" , "Pete Rivett - Adaptive" , "Steve Cook" , "BERNARD, Yves" , "Jim Amsden" Cc: "Bran Selic" , "Ed Seidewitz" , Many of the newbies I train need to have the difference below explained 2, 3 or sometimes even more times before they get it. Possibly because I always try to do it (initially) without using a programming language metaphor. I usually give up (and use C++!). Yes I agree 90% that 90% end users will be confused (the 10% in me says 99% of end users will be confused!) Ralph From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: 11 March 2009 16:47 To: Pete Rivett - Adaptive; Steve Cook; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, etc: I have one basic question . will users need and understand the fine distinctions being talked about on this thread? The entire concept of ownership of .ends. at any meta level seems beyond the level of detail most modelers will want or understand. The idea of this significant dot is, perhaps, indicating that there is more being put on a diagram than practical. A model management issue being intertwined with model subject issues seems confusing. Navigability: At the level of abstract information modeling these ideas of navigability and information ownership are not relevant . I am all in favor of being able to model at this level. However when UML is being used to model an information system (of objects, tables or paper forms), such decisions are relevant. For many .technologies. for information management (including paper ones) the architectural decisions about the ability to traverse from one unit of information to another is very relevant. The idea that .somehow. you can always trace backwards is in theory only, once you transition from the abstract to a design it can matter quire a bit. In some technologies (like some repositories) it may not, but in many it does. For example . can you provide a list of all the instances of UML classifier . anywhere? What about Java.Iterator? I think people understand and need some way to express navigability where it is relevant to the kind of design they are creating. People understand the idea that an .employee action. form has some way to reference the employee. They also understand that they may or may not be able to find all of the employee action forms for an employee? The difference is important and may be a reason for a system to be designed. Ownership: Once you are designing units of information or objects, how that information is managed also matters . so there is a real decision that has to be made with regard to an association; is it an independent unit of information or part of the information units at the ends? Once you have to deal with management of information such things matter. This, to me, is the only distinction that makes sense for ownership . anything finer grain seems impractical. In UML this is probably best captured by the unpopular association Vs. association class distinction. That, for model management purposes, an association is not a unified and managed piece of information seems very counter intuitive, a poor way to work around more general model management issues of information ownership. I.m not discounting some of the use cases that have had us come to these conclusion, I am sure many of them are valid. I would just like to encourage a focus on good language design and practical concepts for the modeler. If this group is 10% confused the masses will be 90% confused. -Cory -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Wednesday, March 11, 2009 6:48 AM To: Steve Cook; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Ø If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? When you say .the association is deleted. I think this could mean two things: a) The user performs some action offered by a tool user interface (e.g. right click on the line representing the association and selecting .Delete. from pop-up menu, or selecting the association line and just pressing the Delete key, or right clicking on the association in a tree browser of the whole model). b) An action is performed against the model being managed by the tool: in this case the action would be CMOF::Element::delete() (interestingly EMOF has no such delete operation!). Case b) is more straightforward: I think the classifier would be left owning the association end Property with all meta-attributes (multiplicity, visibility, constraints etc) retained apart from Property::association which would be unset, and Property::/opposite which would implicitly be unset through its derivation. That includes Property::type being retained (I had to think a bit about this last). I don.t think the effect on this Property differs depending on whether the other end is owned by the Association (and so will be deleted) or the other classifier. ** This is a compliance matter but actually one of MOF compliance, since UML itself does not define such actions at the metamodel level. Case a) provides room for the tool to do something .smart. and possibly even to prompt the user for an option. For example, to check whether the association should be deleted from the current diagram only or the whole model (and hence any other diagrams). Or to check whether the association end properties should also be deleted, though it would not be wrong to automatically delete the ends without prompting (regardless of the ownership of the ends . which arguably is a subtlety many vendors would not want to expose to their users). This is not a compliance matter: user interface behavior of UML tools is out of scope. There is no necessity (only an expectation) that there is any connection at all with the .delete. at the user interface and the .delete(). operation on the model described in b). For example the .delete from diagram only. option does not touch the model at all in the sense of b). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 11 March 2009 03:20 To: Pete Rivett; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, very well said. A couple of questions for the group: If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 11 March 2009 08:18 To: BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves, As Steve said (attached) you.re not at the right meta-level. That the Association owns its ends only means that in the Model itself, deleting the Association will delete its Properties. i.e. to do with model management. It says nothing at all at the business level . that would be represented by whether these Properties themselves have isComposite=true (i.e. whether the specific Association is drawn with a black diamond). You can have a black diamond regardless of whether those Properties/ends are owned by the Class or the Association. The only .application. that the UML metamodel governs the runtime behavior of is a UML tool: i.e. the UML metamodel is the (structural) business model specifying (some aspects of) a UML tool (which is why I.d argue that all Associations in the UML metamodel itself should be navigable . since tools should be able to traverse models efficiently in both directions). Hope that helps Pete From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 23:53 To: Pete Rivett; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, So if we agree to say that the concept of ownership "is based on" the concept of composition it means that the semantic of composition applies. Then strictly speaking, when an association is deleted, the properties (=the "ends") that it owns should be deleted, right ? But nothing implies that the "ends" that are owned by the classifiers are also deleted. That is : depending on the association end ownership the, same action (e.g. DestroyLinkAction), which could also append at run time, will not have the same result on the system. That is why I believe we cannot say that the ownership has no business meaning. Yves -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 10 mars 2009 23:26 À : Jim Amsden; BERNARD, Yves Cc : Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Jim, That might be what you do but that does not seem to be using the information available in the UML model: you are in effect ignoring the fact that navigability and property ownership are now orthogonal and can be separately modeled. Though I.m not entirely clear what you mean by .translate. and .switching physical ownership in relational systems. (are you referring to the process of generating a relational PSM from a platform-agnostic PIM?). How for example would your approach cope with something like the association between a Stereotype instance and the instance of the metaclass to which it is applied? In this case there is no Property on the metaclass, but in any UML tool (which is the .runtime. application) it is clearly important to allow efficient access from a model element to its applied stereotypes. An example of such a pattern in a business model might be the association between a Person class and a PayrollRecord class . where there is no property Person.payrollRecord (because this might represent an existing Directory structure) but efficient access is required to the PayrollRecord for a Person. To Yves. original question in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? The UML spec has almost nothing to say about the semantics of .ownership.. It has little enough to say about composition (on which it is based) beyond .An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.. And in addition ownership has a naming aspect: A namespace provides a container for named elements. It provides a means for resolving composite names, such as name1::name2::name3. The member association identifies all named elements in a namespace called N that can be referred to by a composite name of the form N::. Note that this is different from all of the names that can be referred to unqualified within N, because that set also includes all unhidden members of enclosing namespaces. Although naming is not really related to .semantics. . since the semantics are largely governed by the Actions in UML which reference elements directly not by name. Thus the decision as to ownership will be largely determined by considerations of model management rather than of business meaning. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 10 March 2009 11:17 To: BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 À : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. 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. __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com Subject: RE: FW: Association End Ownership and Navigability Date: Thu, 12 Mar 2009 13:51:06 +0100 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmhrJ3eGOKx+65ORtCnYI654QVXuwAFadzQAAOmdrAAE+ldkAAEfTxQAAAr+/AADChPEAAp0EEwAAFyoYA= From: "BERNARD, Yves" To: "Hains, Ralph" , "Cory Casanave" , "Pete Rivett - Adaptive" , "Steve Cook" , "Jim Amsden" Cc: "Bran Selic" , "Ed Seidewitz" , X-OriginalArrivalTime: 12 Mar 2009 12:51:06.0869 (UTC) FILETIME=[35C5B250:01C9A311] I would do it like this: In the second diagram Class2 is defined "in the context of" Class1. Imagine we have a third Class named "Bridge" to model the object used to cross a river. If Class1 is "Network" we can define a local concept named "Bridge" (like the third Class) to model a means to connect two physical networks. The concept of "Bridge" as define by the nested class exits only in the context of Class1 ("Network") With this example, in the first diagram with the current value of the multiplicity we specify that: "a Network has one and only one Bridge". It would be clearer if the multiplicits is change for "0..*" => "A Network has 0 to n Bridge" In summary: the second diagram define the concept of Class2 in a specific context (Class1) but does not implies that Class1 have any part of that type. The first one define a part of Class1 whom the type can be specific to the Class1 or not. Cheers, Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : jeudi 12 mars 2009 13:15 À : Cory Casanave; Pete Rivett - Adaptive; Steve Cook; BERNARD, Yves; Jim Amsden Cc : Bran Selic; Ed Seidewitz; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Many of the newbies I train need to have the difference below explained 2, 3 or sometimes even more times before they get it. Possibly because I always try to do it (initially) without using a programming language metaphor. I usually give up (and use C++!). Yes I agree 90% that 90% end users will be confused (the 10% in me says 99% of end users will be confused!) Ralph From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: 11 March 2009 16:47 To: Pete Rivett - Adaptive; Steve Cook; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, etc: I have one basic question . will users need and understand the fine distinctions being talked about on this thread? The entire concept of ownership of .ends. at any meta level seems beyond the level of detail most modelers will want or understand. The idea of this significant dot is, perhaps, indicating that there is more being put on a diagram than practical. A model management issue being intertwined with model subject issues seems confusing. Navigability: At the level of abstract information modeling these ideas of navigability and information ownership are not relevant . I am all in favor of being able to model at this level. However when UML is being used to model an information system (of objects, tables or paper forms), such decisions are relevant. For many .technologies. for information management (including paper ones) the architectural decisions about the ability to traverse from one unit of information to another is very relevant. The idea that .somehow. you can always trace backwards is in theory only, once you transition from the abstract to a design it can matter quire a bit. In some technologies (like some repositories) it may not, but in many it does. For example . can you provide a list of all the instances of UML classifier . anywhere? What about Java.Iterator? I think people understand and need some way to express navigability where it is relevant to the kind of design they are creating. People understand the idea that an .employee action. form has some way to reference the employee. They also understand that they may or may not be able to find all of the employee action forms for an employee? The difference is important and may be a reason for a system to be designed. Ownership: Once you are designing units of information or objects, how that information is managed also matters . so there is a real decision that has to be made with regard to an association; is it an independent unit of information or part of the information units at the ends? Once you have to deal with management of information such things matter. This, to me, is the only distinction that makes sense for ownership . anything finer grain seems impractical. In UML this is probably best captured by the unpopular association Vs. association class distinction. That, for model management purposes, an association is not a unified and managed piece of information seems very counter intuitive, a poor way to work around more general model management issues of information ownership. I.m not discounting some of the use cases that have had us come to these conclusion, I am sure many of them are valid. I would just like to encourage a focus on good language design and practical concepts for the modeler. If this group is 10% confused the masses will be 90% confused. -Cory -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Wednesday, March 11, 2009 6:48 AM To: Steve Cook; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Ø If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? When you say .the association is deleted. I think this could mean two things: a) The user performs some action offered by a tool user interface (e.g. right click on the line representing the association and selecting .Delete. from pop-up menu, or selecting the association line and just pressing the Delete key, or right clicking on the association in a tree browser of the whole model). b) An action is performed against the model being managed by the tool: in this case the action would be CMOF::Element::delete() (interestingly EMOF has no such delete operation!). Case b) is more straightforward: I think the classifier would be left owning the association end Property with all meta-attributes (multiplicity, visibility, constraints etc) retained apart from Property::association which would be unset, and Property::/opposite which would implicitly be unset through its derivation. That includes Property::type being retained (I had to think a bit about this last). I don.t think the effect on this Property differs depending on whether the other end is owned by the Association (and so will be deleted) or the other classifier. ** This is a compliance matter but actually one of MOF compliance, since UML itself does not define such actions at the metamodel level. Case a) provides room for the tool to do something .smart. and possibly even to prompt the user for an option. For example, to check whether the association should be deleted from the current diagram only or the whole model (and hence any other diagrams). Or to check whether the association end properties should also be deleted, though it would not be wrong to automatically delete the ends without prompting (regardless of the ownership of the ends . which arguably is a subtlety many vendors would not want to expose to their users). This is not a compliance matter: user interface behavior of UML tools is out of scope. There is no necessity (only an expectation) that there is any connection at all with the .delete. at the user interface and the .delete(). operation on the model described in b). For example the .delete from diagram only. option does not touch the model at all in the sense of b). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 11 March 2009 03:20 To: Pete Rivett; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, very well said. A couple of questions for the group: If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 11 March 2009 08:18 To: BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves, As Steve said (attached) you.re not at the right meta-level. That the Association owns its ends only means that in the Model itself, deleting the Association will delete its Properties. i.e. to do with model management. It says nothing at all at the business level . that would be represented by whether these Properties themselves have isComposite=true (i.e. whether the specific Association is drawn with a black diamond). You can have a black diamond regardless of whether those Properties/ends are owned by the Class or the Association. The only .application. that the UML metamodel governs the runtime behavior of is a UML tool: i.e. the UML metamodel is the (structural) business model specifying (some aspects of) a UML tool (which is why I.d argue that all Associations in the UML metamodel itself should be navigable . since tools should be able to traverse models efficiently in both directions). Hope that helps Pete From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 23:53 To: Pete Rivett; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, So if we agree to say that the concept of ownership "is based on" the concept of composition it means that the semantic of composition applies. Then strictly speaking, when an association is deleted, the properties (=the "ends") that it owns should be deleted, right ? But nothing implies that the "ends" that are owned by the classifiers are also deleted. That is : depending on the association end ownership the, same action (e.g. DestroyLinkAction), which could also append at run time, will not have the same result on the system. That is why I believe we cannot say that the ownership has no business meaning. Yves -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 10 mars 2009 23:26 À : Jim Amsden; BERNARD, Yves Cc : Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Jim, That might be what you do but that does not seem to be using the information available in the UML model: you are in effect ignoring the fact that navigability and property ownership are now orthogonal and can be separately modeled. Though I.m not entirely clear what you mean by .translate. and .switching physical ownership in relational systems. (are you referring to the process of generating a relational PSM from a platform-agnostic PIM?). How for example would your approach cope with something like the association between a Stereotype instance and the instance of the metaclass to which it is applied? In this case there is no Property on the metaclass, but in any UML tool (which is the .runtime. application) it is clearly important to allow efficient access from a model element to its applied stereotypes. An example of such a pattern in a business model might be the association between a Person class and a PayrollRecord class . where there is no property Person.payrollRecord (because this might represent an existing Directory structure) but efficient access is required to the PayrollRecord for a Person. To Yves. original question in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? The UML spec has almost nothing to say about the semantics of .ownership.. It has little enough to say about composition (on which it is based) beyond .An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.. And in addition ownership has a naming aspect: A namespace provides a container for named elements. It provides a means for resolving composite names, such as name1::name2::name3. The member association identifies all named elements in a namespace called N that can be referred to by a composite name of the form N::. Note that this is different from all of the names that can be referred to unqualified within N, because that set also includes all unhidden members of enclosing namespaces. Although naming is not really related to .semantics. . since the semantics are largely governed by the Actions in UML which reference elements directly not by name. Thus the decision as to ownership will be largely determined by considerations of model management rather than of business meaning. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 10 March 2009 11:17 To: BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 À : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. 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. __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com 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. To: "BERNARD, Yves" Cc: "Bran Selic" , "Cory Casanave" , "Ed Seidewitz" , "Pete Rivett - Adaptive" , "Hains, Ralph" , "Steve Cook" , uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability X-KeepSent: ABEDCEAB:73678306-85257577:0048BADE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Jim Amsden Date: Thu, 12 Mar 2009 07:23:14 -0600 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 03/12/2009 07:23:18, Serialize complete at 03/12/2009 07:23:18 Yves, This diagram represents two completely different and unrelated concepts concerning instance and class. The one of the left indicates Class1 has an unnamed property of type Class2 by a composition association. That means deletion of an instance of Class1 implies a deletion of the instance of Class2 it contains. The diagram also indicates an instance of Class1 must have an instance of Class2, the property cannot be null. Deleting Class1 from the model has no effect on Class2. The second diagram says Class1 contains a nested class called Class2. This is a namespace concept. It does not imply that an instance of Class1 has any property defined by Class2. Nor does it have any implications about the deletion semantics of instances of Class2. It does mean that if you delete Class1 from the model, Class2 will be deleted also. It means that to reference Class2 (assuming it has public visibility) you have to use Class1::Class2 outside the context of Class1. From: "BERNARD, Yves" To: "Hains, Ralph" , "Cory Casanave" , "Pete Rivett - Adaptive" , "Steve Cook" , Jim Amsden/Raleigh/IBM@IBMUS Cc: "Bran Selic" , "Ed Seidewitz" , Date: 03/12/2009 09:07 AM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- I would do it like this: In the second diagram Class2 is defined "in the context of" Class1. Imagine we have a third Class named "Bridge" to model the object used to cross a river. If Class1 is "Network" we can define a local concept named "Bridge" (like the third Class) to model a means to connect two physical networks. The concept of "Bridge" as define by the nested class exits only in the context of Class1 ("Network") With this example, in the first diagram with the current value of the multiplicity we specify that: "a Network has one and only one Bridge". It would be clearer if the multiplicits is change for "0..*" => "A Network has 0 to n Bridge" In summary: the second diagram define the concept of Class2 in a specific context (Class1) but does not implies that Class1 have any part of that type. The first one define a part of Class1 whom the type can be specific to the Class1 or not. Cheers, Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : jeudi 12 mars 2009 13:15 Ã. : Cory Casanave; Pete Rivett - Adaptive; Steve Cook; BERNARD, Yves; Jim Amsden Cc : Bran Selic; Ed Seidewitz; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Many of the newbies I train need to have the difference below explained 2, 3 or sometimes even more times before they get it. Possibly because I always try to do it (initially) without using a programming language metaphor. I usually give up (and use C++!). Yes I agree 90% that 90% end users will be confused (the 10% in me says 99% of end users will be confused!) Ralph From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: 11 March 2009 16:47 To: Pete Rivett - Adaptive; Steve Cook; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, etc: I have one basic question . will users need and undderstand the fine distinctions being talked about on this thread? The entire concept of ownership of â..endsâ. at any meta level seems beyond the level of detail most modelers will want or understand. The idea of this significant dot is, perhaps, indicating that there is more being put on a diagram than practical. A model management issue being intertwined with model subject issues seems confusing. Navigability: At the level of abstract information modeling these ideas of navigability and information ownership are not relevant . I am all in favor of being able to model at this level. However when UML is being used to model an information system (of objects, tables or paper forms), such decisions are relevant. For many â..technologiesâ. for information management (including paper ones) the architectural decisions about the ability to traverse from one unit of information to another is very relevant. The idea that â..somehowâ. you can always trace backwards is in theory only, once you transition from the abstract to a design it can matter quire a bit. In some technologies (like some repositories) it may not, but in many it does. For example . can you provide a list of alll the instances of UML classifier . anywhere? What abouut Java.Iterator? I think people understand and need some way to express navigability where it is relevant to the kind of design they are creating. People understand the idea that an â..employee actionâ. form has some way to reference the employee. They also understand that they may or may not be able to find all of the employee action forms for an employee? The difference is important and may be a reason for a system to be designed. Ownership: Once you are designing units of information or objects, how that information is managed also matters . so there is a real decision that has to be made wiith regard to an association; is it an independent unit of information or part of the information units at the ends? Once you have to deal with management of information such things matter. This, to me, is the only distinction that makes sense for ownership . anythingg finer grain seems impractical. In UML this is probably best captured by the unpopular association Vs. association class distinction. That, for model management purposes, an association is not a unified and managed piece of information seems very counter intuitive, a poor way to work around more general model management issues of information ownership. Iâ..m not discounting some of the use cases that have had us come to these conclusion, I am sure many of them are valid. I would just like to encourage a focus on good language design and practical concepts for the modeler. If this group is 10% confused the masses will be 90% confused. -Cory -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Wednesday, March 11, 2009 6:48 AM To: Steve Cook; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Ã. If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? When you say â..the association is deletedâ.. I think this could mean two things: a) The user performs some action offered by a tool user interface (e.g. right click on the line representing the association and selecting â..Deleteâ.. from pop-up menu, or selecting the association line and just pressing the Delete key, or right clicking on the association in a tree browser of the whole model). b) An action is performed against the model being managed by the tool: in this case the action would be CMOF::Element::delete() (interestingly EMOF has no such delete operation!). Case b) is more straightforward: I think the classifier would be left owning the association end Property with all meta-attributes (multiplicity, visibility, constraints etc) retained apart from Property::association which would be unset, and Property::/opposite which would implicitly be unset through its derivation. That includes Property::type being retained (I had to think a bit about this last). I donâ..t think the effect on this Property differs depending on whether the other end is owned by the Association (and so will be deleted) or the other classifier. ** This is a compliance matter but actually one of MOF compliance, since UML itself does not define such actions at the metamodel level. Case a) provides room for the tool to do something â..smartâ.. and possibly even to prompt the user for an option. For example, to check whether the association should be deleted from the current diagram only or the whole model (and hence any other diagrams). Or to check whether the association end properties should also be deleted, though it would not be wrong to automatically delete the ends without prompting (regardless of the ownership of the ends . which arguably is a subtlety manny vendors would not want to expose to their users). This is not a compliance matter: user interface behavior of UML tools is out of scope. There is no necessity (only an expectation) that there is any connection at all with the â..deleteâ.. at the user interface and the â..delete()â.. operation on the model described in b). For example the â..delete from diagram onlyâ.. option does not touch the model at all in the sense of b). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 11 March 2009 03:20 To: Pete Rivett; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, very well said. A couple of questions for the group: If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 11 March 2009 08:18 To: BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves, As Steve said (attached) youâ..re not at the right meta-level. That the Association owns its ends only means that in the Model itself, deleting the Association will delete its Properties. i.e. to do with model management. It says nothing at all at the business level . that would be reppresented by whether these Properties themselves have isComposite=true (i.e. whether the specific Association is drawn with a black diamond). You can have a black diamond regardless of whether those Properties/ends are owned by the Class or the Association. The only â..applicationâ.. that the UML metamodel governs the runtime behavior of is a UML tool: i.e. the UML metamodel is the (structural) business model specifying (some aspects of) a UML tool (which is why Iâ..d argue that all Associations in the UML metamodel itself should be navigable . since tools should be able to traverse modeels efficiently in both directions). Hope that helps Pete From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 23:53 To: Pete Rivett; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, So if we agree to say that the concept of ownership "is based on" the concept of composition it means that the semantic of composition applies. Then strictly speaking, when an association is deleted, the properties (=the "ends") that it owns should be deleted, right ? But nothing implies that the "ends" that are owned by the classifiers are also deleted. That is : depending on the association end ownership the, same action (e.g. DestroyLinkAction), which could also append at run time, will not have the same result on the system. That is why I believe we cannot say that the ownership has no business meaning. Yves -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 10 mars 2009 23:26 Ã. : Jim Amsden; BERNARD, Yves Cc : Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Jim, That might be what you do but that does not seem to be using the information available in the UML model: you are in effect ignoring the fact that navigability and property ownership are now orthogonal and can be separately modeled. Though Iâ..m not entirely clear what you mean by â..translateâ.. and â..switching physical ownership in relational systemsâ.. (are you referring to the process of generating a relational PSM from a platform-agnostic PIM?). How for example would your approach cope with something like the association between a Stereotype instance and the instance of the metaclass to which it is applied? In this case there is no Property on the metaclass, but in any UML tool (which is the â..runtimeâ.. application) it is clearly important to allow efficient access from a model element to its applied stereotypes. An example of such a pattern in a business model might be the association between a Person class and a PayrollRecord class . where there is no property Person.payrollRecord (because this might represent an existing Directory structure) but efficient access is required to the PayrollRecord for a Person. To Yvesâ.. original question in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? The UML spec has almost nothing to say about the semantics of â..ownershipâ... It has little enough to say about composition (on which it is based) beyond â..An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.â. And in addition ownership has a naming aspect: A namespace provides a container for named elements. It provides a means for resolving composite names, such as name1::name2::name3. The member association identifies all named elements in a namespace called N that can be referred to by a composite name of the form N::. Note that this is different from all of the names that can be referred to unqualified within N, because that set also includes all unhidden members of enclosing namespaces. Although naming is not really related to â..semanticsâ.. . since the semantics are largely ggoverned by the Actions in UML which reference elements directly not by name. Thus the decision as to ownership will be largely determined by considerations of model management rather than of business meaning. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 10 March 2009 11:17 To: BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 Ã. : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 Ã. : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be â..strongly linked to the concept of composite aggregationâ. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I donâ..t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 Ã. : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reassonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 Ã. : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran .< Yeah, I remember those discussions. Myself, I donâ..t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for different ppeople! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always â..ownedâ. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you canâ..t actually â..find the opposite end by doing a searchâ., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isnâ..t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I donâ..t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isnâ..t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what â..applied at the level of complete associations or higherâ. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasnâ..t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The â..not classifier->isEmpty()â. part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you canâ..t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steveâ..s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you donâ..t need to use a name to reference something in UML . references aare through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesnâ..t have to do with the ability to name an opposite end, but, rather, on whether one can navigable â..efficientlyâ. across a link of the association at runtime. Unfortunately, the meaning of â..efficient accessâ. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the â..data base viewpointâ., versus the â..object orientedâ. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. 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. __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com 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. Subject: RE: FW: Association End Ownership and Navigability Date: Thu, 12 Mar 2009 13:40:36 -0000 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmjFbpE6w1CMP6BTlWgVObyOvvbHQAAZeIA From: "Hains, Ralph" To: "Jim Amsden" , "BERNARD, Yves" Cc: "Bran Selic" , "Cory Casanave" , "Ed Seidewitz" , "Pete Rivett - Adaptive" , "Steve Cook" , Sorry, I did not mean this to start another debate (but thank you for both of your explanations anyway, which both have merit). All I meant to say is that if end users have an issue with this case (completely clear in my head) they will have a field day with ownership versus navigability. I was just agreeing with Cory on this. Next time I will just say .I agree!. From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 12 March 2009 13:23 To: BERNARD, Yves Cc: Bran Selic; Cory Casanave; Ed Seidewitz; Pete Rivett - Adaptive; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves, This diagram represents two completely different and unrelated concepts concerning instance and class. The one of the left indicates Class1 has an unnamed property of type Class2 by a composition association. That means deletion of an instance of Class1 implies a deletion of the instance of Class2 it contains. The diagram also indicates an instance of Class1 must have an instance of Class2, the property cannot be null. Deleting Class1 from the model has no effect on Class2. The second diagram says Class1 contains a nested class called Class2. This is a namespace concept. It does not imply that an instance of Class1 has any property defined by Class2. Nor does it have any implications about the deletion semantics of instances of Class2. It does mean that if you delete Class1 from the model, Class2 will be deleted also. It means that to reference Class2 (assuming it has public visibility) you have to use Class1::Class2 outside the context of Class1. From: "BERNARD, Yves" To: "Hains, Ralph" , "Cory Casanave" , "Pete Rivett - Adaptive" , "Steve Cook" , Jim Amsden/Raleigh/IBM@IBMUS Cc: "Bran Selic" , "Ed Seidewitz" , Date: 03/12/2009 09:07 AM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- I would do it like this: In the second diagram Class2 is defined "in the context of" Class1. Imagine we have a third Class named "Bridge" to model the object used to cross a river. If Class1 is "Network" we can define a local concept named "Bridge" (like the third Class) to model a means to connect two physical networks. The concept of "Bridge" as define by the nested class exits only in the context of Class1 ("Network") With this example, in the first diagram with the current value of the multiplicity we specify that: "a Network has one and only one Bridge". It would be clearer if the multiplicits is change for "0..*" => "A Network has 0 to n Bridge" In summary: the second diagram define the concept of Class2 in a specific context (Class1) but does not implies that Class1 have any part of that type. The first one define a part of Class1 whom the type can be specific to the Class1 or not. Cheers, Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : jeudi 12 mars 2009 13:15 À : Cory Casanave; Pete Rivett - Adaptive; Steve Cook; BERNARD, Yves; Jim Amsden Cc : Bran Selic; Ed Seidewitz; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Many of the newbies I train need to have the difference below explained 2, 3 or sometimes even more times before they get it. Possibly because I always try to do it (initially) without using a programming language metaphor. I usually give up (and use C++!). Yes I agree 90% that 90% end users will be confused (the 10% in me says 99% of end users will be confused!) Ralph From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: 11 March 2009 16:47 To: Pete Rivett - Adaptive; Steve Cook; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, etc: I have one basic question . wwill users need and understand the fine distinctions being talked about on this thread? The entire concept of ownership of .ends. at any meta level seems beyond the level of detail most modelers will want or understand. The idea of this significant dot is, perhaps, indicating that there is more being put on a diagram than practical. A model management issue being intertwined with model subject issues seems confusing. Navigability: At the level of abstract information modeling these ideas of navigability and information ownership are not relevant . I am all in favvor of being able to model at this level. However when UML is being used to model an information system (of objects, tables or paper forms), such decisions are relevant. For many .technologies. for information management (including paper ones) the architectural decisions about the ability to traverse from one unit of information to another is very relevant. The idea that .somehow. you can always trace backwards is in theory only, once you transition from the abstract to a design it can matter quire a bit. In some technologies (like some repositories) it may not, but in many it does. For example . can you provide a list of all thhe instances of UML classifier . anywhere? What about JJava.Iterator? I think people understand and need some way to express navigability where it is relevant to the kind of design they are creating. People understand the idea that an .employee action. form has some way to reference the employee. They also understand that they may or may not be able to find all of the employee action forms for an employee? The difference is important and may be a reason for a system to be designed. Ownership: Once you are designing units of information or objects, how that information is managed also matters . so there is a real decision that has to be made with regard to an association; is it an independent unit of information or part of the information units at the ends? Once you have to deal with management of information such things matter. This, to me, is the only distinction that makes sense for ownership . anything finer grain seems impractical. In UMML this is probably best captured by the unpopular association Vs. association class distinction. That, for model management purposes, an association is not a unified and managed piece of information seems very counter intuitive, a poor way to work around more general model management issues of information ownership. I.m not discounting some of the use cases that have had us come to these conclusion, I am sure many of them are valid. I would just like to encourage a focus on good language design and practical concepts for the modeler. If this group is 10% confused the masses will be 90% confused. -Cory -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Wednesday, March 11, 2009 6:48 AM To: Steve Cook; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Ø If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? When you say .the association is deleted. I think this could mean two things: a) The user performs some action offered by a tool user interface (e.g. right click on the line representing the association and selecting .Delete. from pop-up menu, or selecting the association line and just pressing the Delete key, or right clicking on the association in a tree browser of the whole model). b) An action is performed against the model being managed by the tool: in this case the action would be CMOF::Element::delete() (interestingly EMOF has no such delete operation!). Case b) is more straightforward: I think the classifier would be left owning the association end Property with all meta-attributes (multiplicity, visibility, constraints etc) retained apart from Property::association which would be unset, and Property::/opposite which would implicitly be unset through its derivation. That includes Property::type being retained (I had to think a bit about this last). I don.t think the effect on this Property differs depending on whether the other end is owned by the Association (and so will be deleted) or the other classifier. ** This is a compliance matter but actually one of MOF compliance, since UML itself does not define such actions at the metamodel level. Case a) provides room for the tool to do something .smart. and possibly even to prompt the user for an option. For example, to check whether the association should be deleted from the current diagram only or the whole model (and hence any other diagrams). Or to check whether the association end properties should also be deleted, though it would not be wrong to automatically delete the ends without prompting (regardless of the ownership of the ends . which arguably is a subtlety many venddors would not want to expose to their users). This is not a compliance matter: user interface behavior of UML tools is out of scope. There is no necessity (only an expectation) that there is any connection at all with the .delete. at the user interface and the .delete(). operation on the model described in b). For example the .delete from diagram only. option does not touch the model at all in the sense of b). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 11 March 2009 03:20 To: Pete Rivett; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, very well said. A couple of questions for the group: If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 11 March 2009 08:18 To: BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves, As Steve said (attached) you.re not at the right meta-level. That the Association owns its ends only means that in the Model itself, deleting the Association will delete its Properties. i.e. to do with model management. It says nothing at all at the business level . that would be representeed by whether these Properties themselves have isComposite=true (i.e. whether the specific Association is drawn with a black diamond). You can have a black diamond regardless of whether those Properties/ends are owned by the Class or the Association. The only .application. that the UML metamodel governs the runtime behavior of is a UML tool: i.e. the UML metamodel is the (structural) business model specifying (some aspects of) a UML tool (which is why I.d argue that all Associations in the UML metamodel itself should be navigable . sinnce tools should be able to traverse models efficiently in both directions). Hope that helps Pete From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 23:53 To: Pete Rivett; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, So if we agree to say that the concept of ownership "is based on" the concept of composition it means that the semantic of composition applies. Then strictly speaking, when an association is deleted, the properties (=the "ends") that it owns should be deleted, right ? But nothing implies that the "ends" that are owned by the classifiers are also deleted. That is : depending on the association end ownership the, same action (e.g. DestroyLinkAction), which could also append at run time, will not have the same result on the system. That is why I believe we cannot say that the ownership has no business meaning. Yves -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 10 mars 2009 23:26 À : Jim Amsden; BERNARD, Yves Cc : Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Jim, That might be what you do but that does not seem to be using the information available in the UML model: you are in effect ignoring the fact that navigability and property ownership are now orthogonal and can be separately modeled. Though I.m not entirely clear what you mean by .translate. and .switching physical ownership in relational systems. (are you referring to the process of generating a relational PSM from a platform-agnostic PIM?). How for example would your approach cope with something like the association between a Stereotype instance and the instance of the metaclass to which it is applied? In this case there is no Property on the metaclass, but in any UML tool (which is the .runtime. application) it is clearly important to allow efficient access from a model element to its applied stereotypes. An example of such a pattern in a business model might be the association between a Person class and a PayrollRecord class . where theree is no property Person.payrollRecord (because this might represent an existing Directory structure) but efficient access is required to the PayrollRecord for a Person. To Yves. original question in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? The UML spec has almost nothing to say about the semantics of .ownership.. It has little enough to say about composition (on which it is based) beyond .An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.. And in addition ownership has a naming aspect: A namespace provides a container for named elements. It provides a means for resolving composite names, such as name1::name2::name3. The member association identifies all named elements in a namespace called N that can be referred to by a composite name of the form N::. Note that this is different from all of the names that can be referred to unqualified within N, because that set also includes all unhidden members of enclosing namespaces. Although naming is not really related to .semantics. . since the semantics are largely governed by the Actions in UML which reference elements directly not by name. Thus the decision as to ownership will be largely determined by considerations of model management rather than of business meaning. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 10 March 2009 11:17 To: BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 À : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reassonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just iingrained differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a biit worse than . the ambiguity of a binary association sshown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, theiir cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract synntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . butt, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. 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. __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com 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. __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com Subject: RE: FW: Association End Ownership and Navigability Date: Thu, 12 Mar 2009 06:49:19 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmjFbpE6w1CMP6BTlWgVObyOvvbHQAAZeIAAABuo5A= From: "Pete Rivett" To: "Hains, Ralph" , "Jim Amsden" , "BERNARD, Yves" Cc: "Bran Selic" , "Cory Casanave" , "Ed Seidewitz" , "Steve Cook" , Hmm I thought Cory was making the case that ownership and navigability were meaningful and useful to end users (at least those doing what he calls .information system modeling.) if explained in the right terms (which he made a good stab at, but the UML spec does not). Pete From: Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Sent: 12 March 2009 06:41 To: Jim Amsden; BERNARD, Yves Cc: Bran Selic; Cory Casanave; Ed Seidewitz; Pete Rivett; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Sorry, I did not mean this to start another debate (but thank you for both of your explanations anyway, which both have merit). All I meant to say is that if end users have an issue with this case (completely clear in my head) they will have a field day with ownership versus navigability. I was just agreeing with Cory on this. Next time I will just say .I agree!. From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 12 March 2009 13:23 To: BERNARD, Yves Cc: Bran Selic; Cory Casanave; Ed Seidewitz; Pete Rivett - Adaptive; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves, This diagram represents two completely different and unrelated concepts concerning instance and class. The one of the left indicates Class1 has an unnamed property of type Class2 by a composition association. That means deletion of an instance of Class1 implies a deletion of the instance of Class2 it contains. The diagram also indicates an instance of Class1 must have an instance of Class2, the property cannot be null. Deleting Class1 from the model has no effect on Class2. The second diagram says Class1 contains a nested class called Class2. This is a namespace concept. It does not imply that an instance of Class1 has any property defined by Class2. Nor does it have any implications about the deletion semantics of instances of Class2. It does mean that if you delete Class1 from the model, Class2 will be deleted also. It means that to reference Class2 (assuming it has public visibility) you have to use Class1::Class2 outside the context of Class1. From: "BERNARD, Yves" To: "Hains, Ralph" , "Cory Casanave" , "Pete Rivett - Adaptive" , "Steve Cook" , Jim Amsden/Raleigh/IBM@IBMUS Cc: "Bran Selic" , "Ed Seidewitz" , Date: 03/12/2009 09:07 AM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- I would do it like this: In the second diagram Class2 is defined "in the context of" Class1. Imagine we have a third Class named "Bridge" to model the object used to cross a river. If Class1 is "Network" we can define a local concept named "Bridge" (like the third Class) to model a means to connect two physical networks. The concept of "Bridge" as define by the nested class exits only in the context of Class1 ("Network") With this example, in the first diagram with the current value of the multiplicity we specify that: "a Network has one and only one Bridge". It would be clearer if the multiplicits is change for "0..*" => "A Network has 0 to n Bridge" In summary: the second diagram define the concept of Class2 in a specific context (Class1) but does not implies that Class1 have any part of that type. The first one define a part of Class1 whom the type can be specific to the Class1 or not. Cheers, Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : jeudi 12 mars 2009 13:15 À : Cory Casanave; Pete Rivett - Adaptive; Steve Cook; BERNARD, Yves; Jim Amsden Cc : Bran Selic; Ed Seidewitz; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Many of the newbies I train need to have the difference below explained 2, 3 or sometimes even more times before they get it. Possibly because I always try to do it (initially) without using a programming language metaphor. I usually give up (and use C++!). Yes I agree 90% that 90% end users will be confused (the 10% in me says 99% of end users will be confused!) Ralph From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: 11 March 2009 16:47 To: Pete Rivett - Adaptive; Steve Cook; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, etc: I have one basic question . willl users need and understand the fine distinctions being talked about on this thread? The entire concept of ownership of .ends. at any meta level seems beyond the level of detail most modelers will want or understand. The idea of this significant dot is, perhaps, indicating that there is more being put on a diagram than practical. A model management issue being intertwined with model subject issues seems confusing. Navigability: At the level of abstract information modeling these ideas of navigability and information ownership are not relevant . I am all in favor of being able to model at this level. However when UML is being used to model an information system (of objects, tables or paper forms), such decisions are relevant. For many .technologies. for information management (including paper ones) the architectural decisions about the ability to traverse from one unit of information to another is very relevant. The idea that .somehow. you can always trace backwards is in theory only, once you transition from the abstract to a design it can matter quire a bit. In some technologies (like some repositories) it may not, but in many it does. For example . can you provide a list of all the iinstances of UML classifier . anywhere? What about Javaa.Iterator? I think people understand and need some way to express navigability where it is relevant to the kind of design they are creating. People understand the idea that an .employee action. form has some way to reference the employee. They also understand that they may or may not be able to find all of the employee action forms for an employee? The difference is important and may be a reason for a system to be designed. Ownership: Once you are designing units of information or objects, how that information is managed also matters . so there is a real decision that has to be made with regard to an association; is it an independent unit of information or part of the information units at the ends? Once you have to deal with management of information such things matter. This, to me, is the only distinction that makes sense for ownership . anything finer grain seems impractical. In UML this is probably best captured by the unpopular association Vs. association class distinction. That, for model management purposes, an association is not a unified and managed piece of information seems very counter intuitive, a poor way to work around more general model management issues of information ownership. I.m not discounting some of the use cases that have had us come to these conclusion, I am sure many of them are valid. I would just like to encourage a focus on good language design and practical concepts for the modeler. If this group is 10% confused the masses will be 90% confused. -Cory -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Wednesday, March 11, 2009 6:48 AM To: Steve Cook; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Ø If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? When you say .the association is deleted. I think this could mean two things: a) The user performs some action offered by a tool user interface (e.g. right click on the line representing the association and selecting .Delete. from pop-up menu, or selecting the association line and just pressing the Delete key, or right clicking on the association in a tree browser of the whole model). b) An action is performed against the model being managed by the tool: in this case the action would be CMOF::Element::delete() (interestingly EMOF has no such delete operation!). Case b) is more straightforward: I think the classifier would be left owning the association end Property with all meta-attributes (multiplicity, visibility, constraints etc) retained apart from Property::association which would be unset, and Property::/opposite which would implicitly be unset through its derivation. That includes Property::type being retained (I had to think a bit about this last). I don.t think the effect on this Property differs depending on whether the other end is owned by the Association (and so will be deleted) or the other classifier. ** This is a compliance matter but actually one of MOF compliance, since UML itself does not define such actions at the metamodel level. Case a) provides room for the tool to do something .smart. and possibly even to prompt the user for an option. For example, to check whether the association should be deleted from the current diagram only or the whole model (and hence any other diagrams). Or to check whether the association end properties should also be deleted, though it would not be wrong to automatically delete the ends without prompting (regardless of the ownership of the ends . which arguably is a subtlety many vendorss would not want to expose to their users). This is not a compliance matter: user interface behavior of UML tools is out of scope. There is no necessity (only an expectation) that there is any connection at all with the .delete. at the user interface and the .delete(). operation on the model described in b). For example the .delete from diagram only. option does not touch the model at all in the sense of b). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 11 March 2009 03:20 To: Pete Rivett; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, very well said. A couple of questions for the group: If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 11 March 2009 08:18 To: BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves, As Steve said (attached) you.re not at the right meta-level. That the Association owns its ends only means that in the Model itself, deleting the Association will delete its Properties. i.e. to do with model management. It says nothing at all at the business level . that would be represented bby whether these Properties themselves have isComposite=true (i.e. whether the specific Association is drawn with a black diamond). You can have a black diamond regardless of whether those Properties/ends are owned by the Class or the Association. The only .application. that the UML metamodel governs the runtime behavior of is a UML tool: i.e. the UML metamodel is the (structural) business model specifying (some aspects of) a UML tool (which is why I.d argue that all Associations in the UML metamodel itself should be navigable . since tools should be able to traverse models efficiently in both directions). Hope that helps Pete From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 23:53 To: Pete Rivett; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, So if we agree to say that the concept of ownership "is based on" the concept of composition it means that the semantic of composition applies. Then strictly speaking, when an association is deleted, the properties (=the "ends") that it owns should be deleted, right ? But nothing implies that the "ends" that are owned by the classifiers are also deleted. That is : depending on the association end ownership the, same action (e.g. DestroyLinkAction), which could also append at run time, will not have the same result on the system. That is why I believe we cannot say that the ownership has no business meaning. Yves -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 10 mars 2009 23:26 À : Jim Amsden; BERNARD, Yves Cc : Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Jim, That might be what you do but that does not seem to be using the information available in the UML model: you are in effect ignoring the fact that navigability and property ownership are now orthogonal and can be separately modeled. Though I.m not entirely clear what you mean by .translate. and .switching physical ownership in relational systems. (are you referring to the process of generating a relational PSM from a platform-agnostic PIM?). How for example would your approach cope with something like the association between a Stereotype instance and the instance of the metaclass to which it is applied? In this case there is no Property on the metaclass, but in any UML tool (which is the .runtime. application) it is clearly important to allow efficient access from a model element to its applied stereotypes. An example of such a pattern in a business model might be the association between a Person class and a PayrollRecord class . where there iss no property Person.payrollRecord (because this might represent an existing Directory structure) but efficient access is required to the PayrollRecord for a Person. To Yves. original question in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? The UML spec has almost nothing to say about the semantics of .ownership.. It has little enough to say about composition (on which it is based) beyond .An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.. And in addition ownership has a naming aspect: A namespace provides a container for named elements. It provides a means for resolving composite names, such as name1::name2::name3. The member association identifies all named elements in a namespace called N that can be referred to by a composite name of the form N::. Note that this is different from all of the names that can be referred to unqualified within N, because that set also includes all unhidden members of enclosing namespaces. Although naming is not really related to .semantics. . since the semantics are largely governed by thee Actions in UML which reference elements directly not by name. Thus the decision as to ownership will be largely determined by considerations of model management rather than of business meaning. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 10 March 2009 11:17 To: BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 À : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonaable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrrained differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit wworse than . the ambiguity of a binary association showwn with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their caannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntaxx representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, aas I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. 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. __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com 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. __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com Subject: RE: FW: Association End Ownership and Navigability Date: Thu, 12 Mar 2009 10:33:56 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmjFbpE6w1CMP6BTlWgVObyOvvbHQAAZeIAAABuo5AAAUHNYA== From: "Cory Casanave" To: "Pete Rivett - Adaptive" , "Hains, Ralph" , "Jim Amsden" , "BERNARD, Yves" Cc: "Bran Selic" , "Ed Seidewitz" , "Steve Cook" , Pete, Yes . this is to confirm that I do think these are valid concepts for users at the information systems modeling level of abstraction. I don.t, however, think .ends. is the appropriate level of granularity for modeled information or model management ownership (the idea of one end being owned by the association and the other by the classifier makes my head hurt). Of course we have no way to separate or even identify these levels of abstraction, but that is another matter. You.re comments about the .personification. effect are very insightful. This is, of course, how OO has taught people to think. It brings up questions of open world, closed world and very closed world mindsets . we should really try and deal with these in the strategic discussions. -Cory -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, March 12, 2009 9:49 AM To: Hains, Ralph; Jim Amsden; BERNARD, Yves Cc: Bran Selic; Cory Casanave; Ed Seidewitz; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hmm I thought Cory was making the case that ownership and navigability were meaningful and useful to end users (at least those doing what he calls .information system modeling.) if explained in the right terms (which he made a good stab at, but the UML spec does not). Pete From: Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Sent: 12 March 2009 06:41 To: Jim Amsden; BERNARD, Yves Cc: Bran Selic; Cory Casanave; Ed Seidewitz; Pete Rivett; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Sorry, I did not mean this to start another debate (but thank you for both of your explanations anyway, which both have merit). All I meant to say is that if end users have an issue with this case (completely clear in my head) they will have a field day with ownership versus navigability. I was just agreeing with Cory on this. Next time I will just say .I agree!. From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 12 March 2009 13:23 To: BERNARD, Yves Cc: Bran Selic; Cory Casanave; Ed Seidewitz; Pete Rivett - Adaptive; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves, This diagram represents two completely different and unrelated concepts concerning instance and class. The one of the left indicates Class1 has an unnamed property of type Class2 by a composition association. That means deletion of an instance of Class1 implies a deletion of the instance of Class2 it contains. The diagram also indicates an instance of Class1 must have an instance of Class2, the property cannot be null. Deleting Class1 from the model has no effect on Class2. The second diagram says Class1 contains a nested class called Class2. This is a namespace concept. It does not imply that an instance of Class1 has any property defined by Class2. Nor does it have any implications about the deletion semantics of instances of Class2. It does mean that if you delete Class1 from the model, Class2 will be deleted also. It means that to reference Class2 (assuming it has public visibility) you have to use Class1::Class2 outside the context of Class1. From: "BERNARD, Yves" To: "Hains, Ralph" , "Cory Casanave" , "Pete Rivett - Adaptive" , "Steve Cook" , Jim Amsden/Raleigh/IBM@IBMUS Cc: "Bran Selic" , "Ed Seidewitz" , Date: 03/12/2009 09:07 AM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- I would do it like this: In the second diagram Class2 is defined "in the context of" Class1. Imagine we have a third Class named "Bridge" to model the object used to cross a river. If Class1 is "Network" we can define a local concept named "Bridge" (like the third Class) to model a means to connect two physical networks. The concept of "Bridge" as define by the nested class exits only in the context of Class1 ("Network") With this example, in the first diagram with the current value of the multiplicity we specify that: "a Network has one and only one Bridge". It would be clearer if the multiplicits is change for "0..*" => "A Network has 0 to n Bridge" In summary: the second diagram define the concept of Class2 in a specific context (Class1) but does not implies that Class1 have any part of that type. The first one define a part of Class1 whom the type can be specific to the Class1 or not. Cheers, Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : jeudi 12 mars 2009 13:15 À : Cory Casanave; Pete Rivett - Adaptive; Steve Cook; BERNARD, Yves; Jim Amsden Cc : Bran Selic; Ed Seidewitz; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Many of the newbies I train need to have the difference below explained 2, 3 or sometimes even more times before they get it. Possibly because I always try to do it (initially) without using a programming language metaphor. I usually give up (and use C++!). Yes I agree 90% that 90% end users will be confused (the 10% in me says 99% of end users will be confused!) Ralph From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: 11 March 2009 16:47 To: Pete Rivett - Adaptive; Steve Cook; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, etc: I have one basic question . will users need and understand the fine distinctions being talked about on this thread? The entire concept of ownership of .ends. at any meta level seems beyond the level of detail most modelers will want or understand. The idea of this significant dot is, perhaps, indicating that there is more being put on a diagram than practical. A model management issue being intertwined with model subject issues seems confusing. Navigability: At the level of abstract information modeling these ideas of navigability and information ownership are not relevant . I am all in favor of being able to model at this level. However when UML is being used to model an information system (of objects, tables or paper forms), such decisions are relevant. For many .technologies. for information management (including paper ones) the architectural decisions about the ability to traverse from one unit of information to another is very relevant. The idea that .somehow. you can always trace backwards is in theory only, once you transition from the abstract to a design it can matter quire a bit. In some technologies (like some repositories) it may not, but in many it does. For example . can you provide a list of all the instances of UML classifier . anywhere? What about Java.Iterator? I think people understand and need some way to express navigability where it is relevant to the kind of design they are creating. People understand the idea that an .employee action. form has some way to reference the employee. They also understand that they may or may not be able to find all of the employee action forms for an employee? The difference is important and may be a reason for a system to be designed. Ownership: Once you are designing units of information or objects, how that information is managed also matters . so there is a real decision that has to be made with regard to an association; is it an independent unit of information or part of the information units at the ends? Once you have to deal with management of information such things matter. This, to me, is the only distinction that makes sense for ownership . anything finer grain seems impractical. In UML this is probably best captured by the unpopular association Vs. association class distinction. That, for model management purposes, an association is not a unified and managed piece of information seems very counter intuitive, a poor way to work around more general model management issues of information ownership. I.m not discounting some of the use cases that have had us come to these conclusion, I am sure many of them are valid. I would just like to encourage a focus on good language design and practical concepts for the modeler. If this group is 10% confused the masses will be 90% confused. -Cory -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Wednesday, March 11, 2009 6:48 AM To: Steve Cook; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Ø If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? When you say .the association is deleted. I think this could mean two things: a) The user performs some action offered by a tool user interface (e.g. right click on the line representing the association and selecting .Delete. from pop-up menu, or selecting the association line and just pressing the Delete key, or right clicking on the association in a tree browser of the whole model). b) An action is performed against the model being managed by the tool: in this case the action would be CMOF::Element::delete() (interestingly EMOF has no such delete operation!). Case b) is more straightforward: I think the classifier would be left owning the association end Property with all meta-attributes (multiplicity, visibility, constraints etc) retained apart from Property::association which would be unset, and Property::/opposite which would implicitly be unset through its derivation. That includes Property::type being retained (I had to think a bit about this last). I don.t think the effect on this Property differs depending on whether the other end is owned by the Association (and so will be deleted) or the other classifier. ** This is a compliance matter but actually one of MOF compliance, since UML itself does not define such actions at the metamodel level. Case a) provides room for the tool to do something .smart. and possibly even to prompt the user for an option. For example, to check whether the association should be deleted from the current diagram only or the whole model (and hence any other diagrams). Or to check whether the association end properties should also be deleted, though it would not be wrong to automatically delete the ends without prompting (regardless of the ownership of the ends . which arguably is a subtlety many vendors would not want to expose to their users). This is not a compliance matter: user interface behavior of UML tools is out of scope. There is no necessity (only an expectation) that there is any connection at all with the .delete. at the user interface and the .delete(). operation on the model described in b). For example the .delete from diagram only. option does not touch the model at all in the sense of b). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 11 March 2009 03:20 To: Pete Rivett; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, very well said. A couple of questions for the group: If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 11 March 2009 08:18 To: BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves, As Steve said (attached) you.re not at the right meta-level. That the Association owns its ends only means that in the Model itself, deleting the Association will delete its Properties. i.e. to do with model management. It says nothing at all at the business level . that would be represented by whether these Properties themselves have isComposite=true (i.e. whether the specific Association is drawn with a black diamond). You can have a black diamond regardless of whether those Properties/ends are owned by the Class or the Association. The only .application. that the UML metamodel governs the runtime behavior of is a UML tool: i.e. the UML metamodel is the (structural) business model specifying (some aspects of) a UML tool (which is why I.d argue that all Associations in the UML metamodel itself should be navigable . since tools should be able to traverse models efficiently in both directions). Hope that helps Pete From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 23:53 To: Pete Rivett; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, So if we agree to say that the concept of ownership "is based on" the concept of composition it means that the semantic of composition applies. Then strictly speaking, when an association is deleted, the properties (=the "ends") that it owns should be deleted, right ? But nothing implies that the "ends" that are owned by the classifiers are also deleted. That is : depending on the association end ownership the, same action (e.g. DestroyLinkAction), which could also append at run time, will not have the same result on the system. That is why I believe we cannot say that the ownership has no business meaning. Yves -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 10 mars 2009 23:26 À : Jim Amsden; BERNARD, Yves Cc : Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Jim, That might be what you do but that does not seem to be using the information available in the UML model: you are in effect ignoring the fact that navigability and property ownership are now orthogonal and can be separately modeled. Though I.m not entirely clear what you mean by .translate. and .switching physical ownership in relational systems. (are you referring to the process of generating a relational PSM from a platform-agnostic PIM?). How for example would your approach cope with something like the association between a Stereotype instance and the instance of the metaclass to which it is applied? In this case there is no Property on the metaclass, but in any UML tool (which is the .runtime. application) it is clearly important to allow efficient access from a model element to its applied stereotypes. An example of such a pattern in a business model might be the association between a Person class and a PayrollRecord class . where there is no property Person.payrollRecord (because this might represent an existing Directory structure) but efficient access is required to the PayrollRecord for a Person. To Yves. original question in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? The UML spec has almost nothing to say about the semantics of .ownership.. It has little enough to say about composition (on which it is based) beyond .An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.. And in addition ownership has a naming aspect: A namespace provides a container for named elements. It provides a means for resolving composite names, such as name1::name2::name3. The member association identifies all named elements in a namespace called N that can be referred to by a composite name of the form N::. Note that this is different from all of the names that can be referred to unqualified within N, because that set also includes all unhidden members of enclosing namespaces. Although naming is not really related to .semantics. . since the semantics are largely governed by the Actions in UML which reference elements directly not by name. Thus the decision as to ownership will be largely determined by considerations of model management rather than of business meaning. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 10 March 2009 11:17 To: BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 À : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. 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. __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com 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. __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com Subject: RE: FW: Association End Ownership and Navigability Date: Thu, 12 Mar 2009 15:19:16 -0000 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmjFbpE6w1CMP6BTlWgVObyOvvbHQAAZeIAAABuo5AAAUHNYAABt/fg From: "Hains, Ralph" To: "Cory Casanave" , "Pete Rivett - Adaptive" , "Jim Amsden" , "BERNARD, Yves" Cc: "Bran Selic" , "Ed Seidewitz" , "Steve Cook" , I was simply agreeing that most end users will have problems with the concepts. And implicitly that it does matter (that most end users will have problems with the concepts). UML has always been a trade-off between being able to express every concept desired and being simple and compact enough to be usable rather than unwieldy. I tend to the .less is more. camp on this (as if you couldn.t tell!) . I think there is a good argument that there is too much already. Ralph From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: 12 March 2009 14:34 To: Pete Rivett - Adaptive; Hains, Ralph; Jim Amsden; BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, Yes . this is to confirm that I do think these are valid concepts for users at the information systems modeling level of abstraction. I don.t, however, think .ends. is the appropriate level of granularity for modeled information or model management ownership (the idea of one end being owned by the association and the other by the classifier makes my head hurt). Of course we have no way to separate or even identify these levels of abstraction, but that is another matter. You.re comments about the .personification. effect are very insightful. This is, of course, how OO has taught people to think. It brings up questions of open world, closed world and very closed world mindsets . we should really try and deal with these in the strategic discussions. -Cory -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, March 12, 2009 9:49 AM To: Hains, Ralph; Jim Amsden; BERNARD, Yves Cc: Bran Selic; Cory Casanave; Ed Seidewitz; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hmm I thought Cory was making the case that ownership and navigability were meaningful and useful to end users (at least those doing what he calls .information system modeling.) if explained in the right terms (which he made a good stab at, but the UML spec does not). Pete From: Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Sent: 12 March 2009 06:41 To: Jim Amsden; BERNARD, Yves Cc: Bran Selic; Cory Casanave; Ed Seidewitz; Pete Rivett; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Sorry, I did not mean this to start another debate (but thank you for both of your explanations anyway, which both have merit). All I meant to say is that if end users have an issue with this case (completely clear in my head) they will have a field day with ownership versus navigability. I was just agreeing with Cory on this. Next time I will just say .I agree!. From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 12 March 2009 13:23 To: BERNARD, Yves Cc: Bran Selic; Cory Casanave; Ed Seidewitz; Pete Rivett - Adaptive; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves, This diagram represents two completely different and unrelated concepts concerning instance and class. The one of the left indicates Class1 has an unnamed property of type Class2 by a composition association. That means deletion of an instance of Class1 implies a deletion of the instance of Class2 it contains. The diagram also indicates an instance of Class1 must have an instance of Class2, the property cannot be null. Deleting Class1 from the model has no effect on Class2. The second diagram says Class1 contains a nested class called Class2. This is a namespace concept. It does not imply that an instance of Class1 has any property defined by Class2. Nor does it have any implications about the deletion semantics of instances of Class2. It does mean that if you delete Class1 from the model, Class2 will be deleted also. It means that to reference Class2 (assuming it has public visibility) you have to use Class1::Class2 outside the context of Class1. From: "BERNARD, Yves" To: "Hains, Ralph" , "Cory Casanave" , "Pete Rivett - Adaptive" , "Steve Cook" , Jim Amsden/Raleigh/IBM@IBMUS Cc: "Bran Selic" , "Ed Seidewitz" , Date: 03/12/2009 09:07 AM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- I would do it like this: In the second diagram Class2 is defined "in the context of" Class1. Imagine we have a third Class named "Bridge" to model the object used to cross a river. If Class1 is "Network" we can define a local concept named "Bridge" (like the third Class) to model a means to connect two physical networks. The concept of "Bridge" as define by the nested class exits only in the context of Class1 ("Network") With this example, in the first diagram with the current value of the multiplicity we specify that: "a Network has one and only one Bridge". It would be clearer if the multiplicits is change for "0..*" => "A Network has 0 to n Bridge" In summary: the second diagram define the concept of Class2 in a specific context (Class1) but does not implies that Class1 have any part of that type. The first one define a part of Class1 whom the type can be specific to the Class1 or not. Cheers, Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : jeudi 12 mars 2009 13:15 À : Cory Casanave; Pete Rivett - Adaptive; Steve Cook; BERNARD, Yves; Jim Amsden Cc : Bran Selic; Ed Seidewitz; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Many of the newbies I train need to have the difference below explained 2, 3 or sometimes even more times before they get it. Possibly because I always try to do it (initially) without using a programming language metaphor. I usually give up (and use C++!). Yes I agree 90% that 90% end users will be confused (the 10% in me says 99% of end users will be confused!) Ralph From: Cory Casanave [mailto:cory-c@modeldriven.com] Sent: 11 March 2009 16:47 To: Pete Rivett - Adaptive; Steve Cook; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, etc: I have one basic question . will users need and understand the fine distinctions being talked about on this thread? The entire concept of ownership of .ends. at any meta level seems beyond the level of detail most modelers will want or understand. The idea of this significant dot is, perhaps, indicating that there is more being put on a diagram than practical. A model management issue being intertwined with model subject issues seems confusing. Navigability: At the level of abstract information modeling these ideas of navigability and information ownership are not relevant . I am all in favor of being able to model at this level. However when UML is being used to model an information system (of objects, tables or paper forms), such decisions are relevant. For many .technologies. for information management (including paper ones) the architectural decisions about the ability to traverse from one unit of information to another is very relevant. The idea that .somehow. you can always trace backwards is in theory only, once you transition from the abstract to a design it can matter quire a bit. In some technologies (like some repositories) it may not, but in many it does. For example . can you provide a list of all the instances of UML classifier . anywhere? What about Java.Iterator? I think people understand and need some way to express navigability where it is relevant to the kind of design they are creating. People understand the idea that an .employee action. form has some way to reference the employee. They also understand that they may or may not be able to find all of the employee action forms for an employee? The difference is important and may be a reason for a system to be designed. Ownership: Once you are designing units of information or objects, how that information is managed also matters . so there is a real decision that has to be made with regard to an association; is it an independent unit of information or part of the information units at the ends? Once you have to deal with management of information such things matter. This, to me, is the only distinction that makes sense for ownership . anything finer grain seems impractical. In UML this is probably best captured by the unpopular association Vs. association class distinction. That, for model management purposes, an association is not a unified and managed piece of information seems very counter intuitive, a poor way to work around more general model management issues of information ownership. I.m not discounting some of the use cases that have had us come to these conclusion, I am sure many of them are valid. I would just like to encourage a focus on good language design and practical concepts for the modeler. If this group is 10% confused the masses will be 90% confused. -Cory -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Wednesday, March 11, 2009 6:48 AM To: Steve Cook; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Ø If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? When you say .the association is deleted. I think this could mean two things: a) The user performs some action offered by a tool user interface (e.g. right click on the line representing the association and selecting .Delete. from pop-up menu, or selecting the association line and just pressing the Delete key, or right clicking on the association in a tree browser of the whole model). b) An action is performed against the model being managed by the tool: in this case the action would be CMOF::Element::delete() (interestingly EMOF has no such delete operation!). Case b) is more straightforward: I think the classifier would be left owning the association end Property with all meta-attributes (multiplicity, visibility, constraints etc) retained apart from Property::association which would be unset, and Property::/opposite which would implicitly be unset through its derivation. That includes Property::type being retained (I had to think a bit about this last). I don.t think the effect on this Property differs depending on whether the other end is owned by the Association (and so will be deleted) or the other classifier. ** This is a compliance matter but actually one of MOF compliance, since UML itself does not define such actions at the metamodel level. Case a) provides room for the tool to do something .smart. and possibly even to prompt the user for an option. For example, to check whether the association should be deleted from the current diagram only or the whole model (and hence any other diagrams). Or to check whether the association end properties should also be deleted, though it would not be wrong to automatically delete the ends without prompting (regardless of the ownership of the ends . which arguably is a subtlety many vendors would not want to expose to their users). This is not a compliance matter: user interface behavior of UML tools is out of scope. There is no necessity (only an expectation) that there is any connection at all with the .delete. at the user interface and the .delete(). operation on the model described in b). For example the .delete from diagram only. option does not touch the model at all in the sense of b). Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 11 March 2009 03:20 To: Pete Rivett; BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, very well said. A couple of questions for the group: If an association end is owned by the classifier, and the association is deleted, what do people expect to happen in a UML tool? Do people believe that the answer to this question is a compliance matter? -- Steve From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 11 March 2009 08:18 To: BERNARD, Yves; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves, As Steve said (attached) you.re not at the right meta-level. That the Association owns its ends only means that in the Model itself, deleting the Association will delete its Properties. i.e. to do with model management. It says nothing at all at the business level . that would be represented by whether these Properties themselves have isComposite=true (i.e. whether the specific Association is drawn with a black diamond). You can have a black diamond regardless of whether those Properties/ends are owned by the Class or the Association. The only .application. that the UML metamodel governs the runtime behavior of is a UML tool: i.e. the UML metamodel is the (structural) business model specifying (some aspects of) a UML tool (which is why I.d argue that all Associations in the UML metamodel itself should be navigable . since tools should be able to traverse models efficiently in both directions). Hope that helps Pete From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 23:53 To: Pete Rivett; Jim Amsden Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Pete, So if we agree to say that the concept of ownership "is based on" the concept of composition it means that the semantic of composition applies. Then strictly speaking, when an association is deleted, the properties (=the "ends") that it owns should be deleted, right ? But nothing implies that the "ends" that are owned by the classifiers are also deleted. That is : depending on the association end ownership the, same action (e.g. DestroyLinkAction), which could also append at run time, will not have the same result on the system. That is why I believe we cannot say that the ownership has no business meaning. Yves -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 10 mars 2009 23:26 À : Jim Amsden; BERNARD, Yves Cc : Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Jim, That might be what you do but that does not seem to be using the information available in the UML model: you are in effect ignoring the fact that navigability and property ownership are now orthogonal and can be separately modeled. Though I.m not entirely clear what you mean by .translate. and .switching physical ownership in relational systems. (are you referring to the process of generating a relational PSM from a platform-agnostic PIM?). How for example would your approach cope with something like the association between a Stereotype instance and the instance of the metaclass to which it is applied? In this case there is no Property on the metaclass, but in any UML tool (which is the .runtime. application) it is clearly important to allow efficient access from a model element to its applied stereotypes. An example of such a pattern in a business model might be the association between a Person class and a PayrollRecord class . where there is no property Person.payrollRecord (because this might represent an existing Directory structure) but efficient access is required to the PayrollRecord for a Person. To Yves. original question in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? The UML spec has almost nothing to say about the semantics of .ownership.. It has little enough to say about composition (on which it is based) beyond .An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.. And in addition ownership has a naming aspect: A namespace provides a container for named elements. It provides a means for resolving composite names, such as name1::name2::name3. The member association identifies all named elements in a namespace called N that can be referred to by a composite name of the form N::. Note that this is different from all of the names that can be referred to unqualified within N, because that set also includes all unhidden members of enclosing namespaces. Although naming is not really related to .semantics. . since the semantics are largely governed by the Actions in UML which reference elements directly not by name. Thus the decision as to ownership will be largely determined by considerations of model management rather than of business meaning. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 10 March 2009 11:17 To: BERNARD, Yves Cc: Bran Selic; Ed Seidewitz; Hains, Ralph; Steve Cook; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I simply use property ownership as the manifestation of navigation in the metamodel. I then translate that to whatever is needed to effect navigation in the target runtime. For example, this results in switching the physical ownership in relational systems, but the semantics of accessibility/navigation are still the same. That is can I say aStudent.professor.salary or not. If Student has a navigable association to Professor, then I can. This navigation could be quite meaningful and useful in an Action language integrated with UML activities. From: "BERNARD, Yves" To: "Steve Cook" , "Hains, Ralph" , Jim Amsden/Raleigh/IBM@IBMUS, "Ed Seidewitz" Cc: "Bran Selic" , Date: 03/10/2009 01:46 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Ok, let's try this way... My question was not about the relationship between the dot notation and the association end ownership, but about the semantic of that ownership. In other words, in which case will you give the ownership of an association end to the association and in which case will you give it to the classifier ? If you considere that the model is the specification of a system, what will be the consequencies of each choice on this system? Conrad, I had a look on the discussion about isse 6243 and I have a better understanding on the way me came to the current situation. Anyway from my point of view, and in addition to Ed comments, there is actually an ambiguity between "Aggregation type, navigability, and end ownership are orthogonal concepts" and "Non-navigable ends must be owned by the association"... We may consider than association end ownership is matter of implementation (it is more or less what the 6243 discussion suggests) if we can demonstrate that it has no semantic impact on the system. I guess it can be done from a behavioural point of view but it will be more difficult from a structural point of view. Cheers, Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 16:56 À : BERNARD, Yves; Hains, Ralph; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Yves, I can try to address your first question. I fear that you are mixing up metalevels. The ends of a Composition can be owned by the Composition itself or by the classifiers that it connects, depending on the use of the dot notation in the Composition. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 15:38 To: Hains, Ralph; Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability And the specification also states : "An association may represent a composite aggregation (i.e., a whole/part relationship).". So what could be a "whole/part relationship" if it is actually orthogonal to the concept of ownership ? Could we work on a clear, unambiguous and consistent set of definition of "ownership", "composition", "property" and (eventually) "navigability" before going further in that discussion ? Yves -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : mardi 10 mars 2009 13:31 À : Steve Cook; BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability And the specification explicitly states: Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation. The notational standard now provides for combining these notations as shown in Figure 7.20, Pretty clear that dot notation is not intended to be .strongly linked to the concept of composite aggregation. (even if the spec goes on to destroy the orthogonality between navigability and end ownership as Ed pointed out, the orthogonality between end ownership and aggregation type is not, as far as I know, in dispute) I am uncertain at this point if I agree most with Steve or Jim. They are saying similar (though not quite identical) things. Where I agree with them both is that the current situation is just not right (and I don.t just mean the clear contradiction about orthogonality of concepts with the constraints). I certainly consider the dot notation pretty absurd. Ralph From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 10 March 2009 11:04 To: BERNARD, Yves; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Yves My comment is specifically about the dot notation. If an association end is marked as owned by the association, then when you delete the association its end will get deleted along with it, and when you serialize the association its end will get serialized nested in it. If the end is marked as owned by the classifier, then deleting the association will leave the end sitting on the classifier (presumably it turns into a disassociated classifier-typed property), and the end is serialized nested in the classifier. The nesting is especially material in version-control scenarios. Thus changing the dot notation has the primary effect of altering how the model itself behaves. As Jim says, its relationship to foreign keys, tables, classes etc is wholly secondary and entirely in the mind of the modeller, or manifested by some translation technology. -- Steve From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 10 March 2009 10:22 To: Steve Cook; Jim Amsden; Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability I disagree. The concept of ownership is strongly linked to the concept of composite aggregation that implies a dependency bewteen the lifecycle of the owner and the one of the owned element, cf. the semantic of composite aggregation. Then, the ownership of a property have direct consequencies on the system beeing modeled. Yves -----Message d'origine----- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé : mardi 10 mars 2009 11:08 À : Jim Amsden; Ed Seidewitz Cc : Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Objet : RE: FW: Association End Ownership and Navigability Personally I think the dot notation is absurd. Ownership is a property of the model, not of the system being modelled. Ownership means that model serialization formats are nested and model element deletion is propagated. Why this should be pushed in the face of the modeller is beyond me. -- Steve From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 09 March 2009 23:41 To: Ed Seidewitz Cc: Bran Selic; uml2-rtf@omg.org; BERNARD, Yves Subject: RE: FW: Association End Ownership and Navigability I would recommend removing the dots and the changes relating to property ownership. Property ownership is a manifestation of navigability - indicated by the arrow. It means the property is visible and accessible from the owning class and can be obtained through a ReadLinkAction. That's all it means. It doesn't have anything to do with correlation tables, foreign keys, nor does it constrain any implementation in any way other than for accessibility through a ReadLinkAction without a search or accessing indirectly through the association somehow. Tools would be free to implement every owned property in a correlation table if that met their needs. From: "Ed Seidewitz" To: "BERNARD, Yves" , "Bran Selic" Cc: Date: 03/09/2009 07:23 PM Subject: RE: FW: Association End Ownership and Navigability -------------------------------------------------------------------------------- Yes, but do we eliminate arrowheads from the notation? I think a lot of people will complain about that. Or do we make arrowheads mean what dots mean now? Except that was pretty much the way it was before the introduction of the dot notation, and the dot notation was introduced because people complained about the way it was! I have found with UML there is almost always someone to complain about anything you try to do. (I, myself, am always completely reasonable, of course! ) -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, March 09, 2009 6:37 PM To: Ed Seidewitz; Bran Selic Cc: uml2-rtf@omg.org Subject: RE: FW: Association End Ownership and Navigability Hum... And we had one of that kind in August... So, it seems that in most people minds and in most tool implementations the "arrow" notation is actually linked to the (opposite) end ownership. Then I strongly support Bran's proposal to get rid of this "non-concept" of navigability and to restaure understandability and consistency to this part of the UML specification. Note that if the word of navigability simply disapears from the spec we won't have any problem of ascending compatibility: everyone will give "navigability" the meaning he/she wants... Just like today ! Cheers, Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé : lundi 9 mars 2009 22:29 À : Bran Selic Cc : uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Bran . Yeah, I remember those discussions. Myself, I don.t think we will ever get rid of navigability, any more than shared aggregation, because it is too ingrained in how too many people think about associations . just ingrained differently for different people! I remember Karl proposing the dot notation, and I think the reason we decided that no dot meant association ownership was because that was consistent with UML 1 (where ends where always .owned. by the association). Consistency with UML 1 was more of a consideration in the early days of UML 2 (though not always that much even then.). Note that there is at least one case in which you can.t actually .find the opposite end by doing a search., at least no with UML actions. That is the case when both ends of the association are non-navigable, in which case neither end is readable, even by read link action. This makes associations with no navigable ends pretty useless, since there isn.t even any way to check if a link exists. (Conrad talked about removing the navigability constraint from read link action, but I don.t think an issue was ever submitted.) -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Monday, March 09, 2009 5:09 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: FW: Association End Ownership and Navigability For the record: I am the author of the wishy-washy wording for navigability (although it was endorsed by the RTF). The real intent is to depracate the concept and eventually retire it. This was decided after all the various refinements to the concept of association ends were introduced in UML 2 -- the concept is redundant and vestigal. The other reason for its depracation is that was a vaguely defined notion to start with. It was pointed out many times that, even with no navigability, it was always possible in principle to find the opposite end by doing a search on all instances of the class in question. Also, for the record: the dot notaiton and the wording were proposed by Karl Frank. Cheers...Bran On Mon, Mar 9, 2009 at 4:22 PM, Ed Seidewitz wrote: A question came up in the Model Interchange group, about the use of the dot notation for association end ownership, as well as the relation to navigability. This led to my message below, which, I think, may also be of interest to the RTF. In addition to pointing out an inconsistency in the discussion of the dot notation in the spec, the second part of the message also relates to Issue 13656, filed by Steve C., which suggests (incorrectly, in my opinion) that it is necessary that a navigable association end by in the namespace of the opposite classifier, even if it isn.t owned by that classifier. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Monday, March 09, 2009 4:11 PM To: Hains, Ralph Cc: model-interchange@omg.org Subject: RE: Association End Ownership and Navigability Well, as often seems to be the case, the more you look into something like this, the cloudier it gets. In addition to the paragraph I read during the teleconference, which indicated that the old navigability/ownership convention is obsolete, the spec also contains the following paragraph: This standard does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected. The dot notation must be applied at the level of complete associations or higher, so that 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. In this way, in contexts where the notation is used, the absence of the dot on certain ends does not leave the ownership of those ends ambiguous. It is not entirely clear what .applied at the level of complete associations or higher. means, but I think it means that you are free to apply this notation association by association. That is, the meaning is unambiguous when you show a dot on just one end of the association (that end is owned by the opposite classifier, while the other end is owned by the association) or when you show dots on both ends of the association (both ends are owned by opposite classifiers). However, the case of no dots is ambiguous! It could either mean both ends are owned by the association, or it could mean the dot notation is not being applied, in which there is no graphical information on end ownership. Thus, I believe that it is allowable according to the standard to show a unidirectional association, with no dots, and have the navigable end owned by the opposite classifier, but the non-navigable end be owned by the association (per the old convention). Of course, it is equally allowable to have both ends owned by the association! I believe this ambiguity was permitted in the standard to provide upward compatibility for the common use of the old navigability convention. (It is somewhat similar to . though a bit worse than . the ambiguity of a binary association shown with no arrowheads, which can mean either an association navigable in both directions, or an association navigable in neither direction.) Now, if that wasn.t confusing enough, consider the definition of the isNavigable operation from Subclause 7.3.44, Property: The query isNavigable() indicates whether it is possible to navigate across the property. Property::isNavigable() : Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation.navigableOwnedEnd->includes(self) The .not classifier->isEmpty(). part of this means that any association end owned by a classifier is always navigable! It is not actually possible to specify a non-navigable end that is classifier-owned . if there is no arrow, their cannot be a dot. Note that it this does not actually imply the old convention: unlike that convention, it is possible to have a navigable end that is owned by the association. However, it does mean that Figure 7.20 in the spec is wrong: you can.t have dots on non-navigable ends. (I need to check if someone has already put in an issue about this.) So, to Steve.s Issue 13656, what does it mean to have navigable end that is not owned by the opposite classifier? The question, of course, boils down to what navigability means in UML. Unfortunately, there is, once again, no good answer! Navigability is one of those concepts in UML (like shared aggregation) that almost everyone agrees needs to be their, but cannot agree on exactly why! I have been through arguments about this since UML 1. And the only resolution has been (again, like shared aggregation) to not really give navigability any real semantics, so that different people can use it for different purposes, as they wish. Here is the description of the semantics of navigability from Subclause 7.3.3, Association: Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends. Wishy-washy enough? Note that there is no reference here to names and namespaces because, in general, you don.t need to use a name to reference something in UML . references are through links in the abstract syntax representation, and a tool can let you set those in any number of ways. The semantics of navigability doesn.t have to do with the ability to name an opposite end, but, rather, on whether one can navigable .efficiently. across a link of the association at runtime. Unfortunately, the meaning of .efficient access. is not further defined. The only place in the spec that there is any formal impact of navigability is on ReadLinkAction: the open end of a read link action must be a navigable end of the association being read (see Constraint [4] under Subclause 11.3.33). Note that a ReadStructuralFeatureAction can also be used to read an association end, if that end is owned as a structural feature of a classifier . but, as I noted above, in that case the end is, by definition, navigable. So, how do you read an association end that is navigable but not owned by the opposite classifier? You use a read link action, with the navigable end as the open end, and a value for the opposite end as the action input. Even if you are using a textual notation that depends on naming, it is only necessary to have visibility of the definition of the association itself, which is the namespace for its owned ends. Note that this capability is very intentional, because there is a significant community of users out their who really want to model associations, including navigability, as being structurally independent of the things they are associating. (This has been referred to as the .data base viewpoint., versus the .object oriented. viewpoint, in which navigable ends are assumed to be owned by classifiers.) -- Ed 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. 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. 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. 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. 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. __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com 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. __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 3930 (20090312) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com Subject: RE: FW: Association End Ownership and Navigability Date: Thu, 12 Mar 2009 23:08:39 +0100 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FW: Association End Ownership and Navigability Thread-Index: AcmjFbpE6w1CMP6BTlWgVObyOvvbHQAAZeIAABHwdUA= From: "BERNARD, Yves" To: "Hains, Ralph" , "Jim Amsden" Cc: "Bran Selic" , "Cory Casanave" , "Ed Seidewitz" , "Pete Rivett - Adaptive" , "Steve Cook" , X-OriginalArrivalTime: 12 Mar 2009 22:08:40.0678 (UTC) FILETIME=[19CBD860:01C9A35F] I think that no other debate is opened here. From my point of view we said the same thing : I never said that the concepts are related. I try to use an example and not Jim (I was bielieving your question was to find an illustration outside the context of programming language). More, my English is far from perfection and this doesn't help... ;o) -----Message d'origine----- De : Hains, Ralph [mailto:ralph.hains@artisansoftwaretools.com] Envoyé : jeudi 12 mars 2009 14:41 À : Jim Amsden; BERNARD, Yves Cc : Bran Selic; Cory Casanave; Ed Seidewitz; Pete Rivett - Adaptive; Steve Cook; uml2-rtf@omg.org Objet : RE: FW: Association End Ownership and Navigability Sorry, I did not mean this to start another debate (but thank you for both of your explanations anyway, which both have merit). All I meant to say is that if end users have an issue with this case (completely clear in my head) they will have a field day with ownership versus navigability. I was just agreeing with Cory on this. Next time I will just say .I agree!. From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 12 March 2009 13:23