Issue 5977: saying {nonunique} on one end of a binary association is meaningless (uml2-rtf) Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com) Nature: Uncategorized Issue Severity: Summary: Also, saying {nonunique} on one end of a binary association is meaningless by the current rules, because the other end remains {unique} by default, so no duplicate links would be allowed Resolution: Also, saying {nonunique} on one end of a binary association is meaningless by the current rules, because the other end remains {unique} by default, so no duplicate links would be allowed Disposition: Merged with 6464 Revised Text: Actions taken: June 19, 2003: received issue February 20, 2015: closed issue Discussion: Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification. End of Annotations:===== From: "Baisley, Donald E" To: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Cc: James Odell Subject: UML 2 Issues Date: Thu, 19 Jun 2003 19:48:10 -0500 X-Mailer: Internet Mail Service (5.5.2656.59) While reviewing certification questions, I found the following issues in the UML 2 specification. 2. Also, saying {nonunique} on one end of a binary association is meaningless by the current rules, because the other end remains {unique} by default, so no duplicate links would be allowed. Subject: RE: UML 2 Issues Date: Fri, 20 Jun 2003 07:55:30 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2 Issues Thread-Index: AcM2xbqXDEvyKJRiQsqdgHhDxSOrOAAKPHWg From: "Pete Rivett" To: "Baisley, Donald E" Cc: "James Odell" , , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h5K6tZkM011189 Hi Don, > 2. Also, saying {nonunique} on one end of a binary association is > meaningless by the current rules, because the other end > remains {unique} by default, so no duplicate links would be allowed. The (nonunique) refers to the values from the perspective of that Property (association end) for an instance not from the perspective of the links in the Association. So if the association links Route with City then it makes perfect sense for Route.city to be (nonunique) - to allow a route to revisit the same city (this would also need to be an ordered property). However this does not prevent City.route from being unique: one could want to enforce the rule that the same city cannot be included on different Routes. Pete Pete Rivett (pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] > Sent: 20 June 2003 01:48 > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Cc: James Odell > Subject: UML 2 Issues > > > While reviewing certification questions, I found the > following issues in the UML 2 specification. > > 1. UML's use of the word "unique" for multiplicity is > ambiguous. It means "distinct", but it could be mistaken to > mean "unique across all instances". For example, if someone > says that the employee-number attribute of employee is > unique, it would likely be understood to mean that each > employee has an employee-number that is different from every > other employee. But that's not what UML defines "unique" to > mean. I recommend that the FTF change "{unique}" to > "{distinct}" or "{set}". > > 2. Also, saying {nonunique} on one end of a binary association is > meaningless by the current rules, because the other end > remains {unique} by default, so no duplicate links would be allowed. > > 3. The notation for shared aggregation appears to be missing > from the association notation section. > > 4. The description of DataType is plainly wrong in the > specification. A data type is a classification of data > values. The identity of a data value is based on the value > itself. And the identity definitely exists. Otherwise you > would not be able to know when you had two occurrences of the > same value. If a value has no identity, it would not be > possible to distinguish different values of the same data > type. Someone has confused the concept of having identity > with the concept of having a memory address. Note also that > an instance specification is capable, according to the > specification, of identifying a data value, so it is a > contradiction to say a data value has no identity. Perhaps > the specification is using the word "identity" in a way that > is completely different from anything in my dictionary. The > key point to make is that a data value is not to be confused > with a data variable or a slot in an object that can hold a > data value. > > 5. The description of GeneralizationSet uses the words > "general" and "specific" to mean "specific" and "general" > respectively. The description also uses unclear terms like > "maps to classifier" without identifying which association. > Also, the semantics has: "All of the Generalization links > that share a given general Classifier are divided into > disjoint sets (that is, > partitions) using the generalizationSet association." This > statement is nonsense. First, the metamodel does not require > all generalizations to be put into partitions using "the > generalizationSet association". Second, partitions are not > required by the metamodel to be disjoint - the same > generalization can be in multiple generalization sets (as > should be the case). > > Regards, > Don Baisley > Unisys > > The information contained in this email and any attached files is confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. From: "Baisley, Donald E" To: Pete Rivett Cc: James Odell , uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Subject: RE: UML 2 Issues Date: Mon, 23 Jun 2003 14:04:20 -0500 X-Mailer: Internet Mail Service (5.5.2656.59) > The (nonunique) refers to the values from the perspective of > that Property (association end) for an instance.... I understand that. But since we are talking about ends of an association, the cardinality of a property for an object is tied to the number of links connected to that object. A route visits the same city twice only if there are two links connecting the route and the city, which means that it must be allowed that the city can be visited by the same route twice. In UML 2 speak this means that city.route must be {nonunique}. If that is not the desired semantics, then route.city and city.route should not be opposite ends of the same association. > However this does not prevent City.route from being unique: one > could want to enforce the rule that the same city cannot be > included on different Routes. Your final remark shows the confusion that comes from abusing the terms "unique" and "nonunique" in UML 2. According to UML 2, saying {unique} on city.route means that a city can have no single route more than once, which is not the same as saying it cannot be included on different routes. Your mistake demonstrates my first issue below. Note that the rule you mention is nicely stated using the word "unique" by its normal English definition, a definition that also fits common database usage. If I say that person.socialSecurityNumber is "unique", then I expect that no two persons have the same socialSecurityNumber. I don't mean that all of a person's social security numbers are different. Let's just fix UML 2 to use words in the way they are commonly understood. Let's have "unique" mean unique. We can use "distinct" or "set" for what "unique" was supposed to mean, and use "nondistinct" for what "nonunique" was supposed to mean. Regards, Don -----Original Message----- From: Pete Rivett [mailto:Pete.Rivett@adaptive.com] Sent: Thursday, June 19, 2003 11:56 PM To: Baisley, Donald E Cc: James Odell; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: UML 2 Issues Hi Don, > 2. Also, saying {nonunique} on one end of a binary association is > meaningless by the current rules, because the other end > remains {unique} by default, so no duplicate links would be allowed. The (nonunique) refers to the values from the perspective of that Property (association end) for an instance not from the perspective of the links in the Association. So if the association links Route with City then it makes perfect sense for Route.city to be (nonunique) - to allow a route to revisit the same city (this would also need to be an ordered property). However this does not prevent City.route from being unique: one could want to enforce the rule that the same city cannot be included on different Routes. Pete Pete Rivett (pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] > Sent: 20 June 2003 01:48 > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Cc: James Odell > Subject: UML 2 Issues > > > While reviewing certification questions, I found the > following issues in the UML 2 specification. > > 1. UML's use of the word "unique" for multiplicity is > ambiguous. It means "distinct", but it could be mistaken to > mean "unique across all instances". For example, if someone > says that the employee-number attribute of employee is > unique, it would likely be understood to mean that each > employee has an employee-number that is different from every > other employee. But that's not what UML defines "unique" to > mean. I recommend that the FTF change "{unique}" to > "{distinct}" or "{set}". > > 2. Also, saying {nonunique} on one end of a binary association is > meaningless by the current rules, because the other end > remains {unique} by default, so no duplicate links would be allowed. > > 3. The notation for shared aggregation appears to be missing > from the association notation section. > > 4. The description of DataType is plainly wrong in the > specification. A data type is a classification of data > values. The identity of a data value is based on the value > itself. And the identity definitely exists. Otherwise you > would not be able to know when you had two occurrences of the > same value. If a value has no identity, it would not be > possible to distinguish different values of the same data > type. Someone has confused the concept of having identity > with the concept of having a memory address. Note also that > an instance specification is capable, according to the > specification, of identifying a data value, so it is a > contradiction to say a data value has no identity. Perhaps > the specification is using the word "identity" in a way that > is completely different from anything in my dictionary. The > key point to make is that a data value is not to be confused > with a data variable or a slot in an object that can hold a > data value. > > 5. The description of GeneralizationSet uses the words > "general" and "specific" to mean "specific" and "general" > respectively. The description also uses unclear terms like > "maps to classifier" without identifying which association. > Also, the semantics has: "All of the Generalization links > that share a given general Classifier are divided into > disjoint sets (that is, > partitions) using the generalizationSet association." This > statement is nonsense. First, the metamodel does not require > all generalizations to be put into partitions using "the > generalizationSet association". Second, partitions are not > required by the metamodel to be disjoint - the same > generalization can be in multiple generalization sets (as > should be the case). > > Regards, > Don Baisley > Unisys > > The information contained in this email and any attached files is confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. Subject: RE: UML 2 Issues Date: Tue, 24 Jun 2003 03:53:28 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2 Issues Thread-Index: AcM5un8OxcMmphB7QOKemFtXtUZqeQAPYCIA From: "Pete Rivett" To: "Baisley, Donald E" Cc: "James Odell" , , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h5O2qqkM012904 Hi again Don, See [PJR] below. > -----Original Message----- > From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] > Sent: 23 June 2003 20:04 > To: Pete Rivett > Cc: James Odell; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: UML 2 Issues > > > > The (nonunique) refers to the values from the perspective of that > > Property (association end) for an instance.... > > I understand that. But since we are talking about ends of an > association, the cardinality of a property for an object is > tied to the number of links connected to that object. A > route visits the same city twice only if there are two links > connecting the route and the city, which means that it must > be allowed that the city can be visited by the same route > twice. In UML 2 speak this means that city.route must be > {nonunique}. If that is not the desired semantics, then > route.city and city.route should not be opposite ends of the > same association. > > > However this does not prevent City.route from being unique: > one could > > want to enforce the rule that the same city cannot be included on > > different Routes. [PJR] I must have written that too late at night: to enforce that rule one would constrain City.route->asSet()->size() to be less than 1. > > Your final remark shows the confusion that comes from abusing > the terms "unique" and "nonunique" in UML 2. According to > UML 2, saying {unique} on city.route means that a city can > have no single route more than once, which is not the same as > saying it cannot be included on different routes. Your > mistake demonstrates my first issue below. Note that the > rule you mention is nicely stated using the word "unique" by > its normal English definition, a definition that also fits > common database usage. [PJR] It was not my understanding of 'unique' that was at fault - just my general powers of reasoning! > > If I say that person.socialSecurityNumber is "unique", then I > expect that no two persons have the same > socialSecurityNumber. I don't mean that all of a person's > social security numbers are different. > > Let's just fix UML 2 to use words in the way they are > commonly understood. Let's have "unique" mean unique. We > can use "distinct" or "set" for what "unique" was supposed to > mean, and use "nondistinct" for what "nonunique" was supposed to mean. [PJR] The problem with your proposed use of 'unique' is in defining the scope over which the uniqueness is supposed to apply. In general there are lots of UML terms that are at odds with normal English, but they have aquired a life of their own (including 'unique') and to change them at this stage may cause more problems than it's worth. As I said earlier it was not my understanding of 'unique' that was the problem - indeed I found the concept very easy to pick up. Cheers Pete Pete Rivett (pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > > Regards, > Don > > -----Original Message----- > From: Pete Rivett [mailto:Pete.Rivett@adaptive.com] > Sent: Thursday, June 19, 2003 11:56 PM > To: Baisley, Donald E > Cc: James Odell; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: UML 2 Issues > > > Hi Don, > > 2. Also, saying {nonunique} on one end of a binary association is > > meaningless by the current rules, because the other end > > remains {unique} by default, so no duplicate links would be allowed. > > The (nonunique) refers to the values from the perspective of > that Property (association end) for an instance not from the > perspective of the links in the Association. So if the > association links Route with City then it makes perfect sense > for Route.city to be (nonunique) - to allow a route to > revisit the same city (this would also need to be an ordered > property). However this does not prevent City.route from being > unique: one could want to enforce the rule that the same city > cannot be included on different Routes. > > Pete > > Pete Rivett (pete.rivett@adaptive.com) > Consulting Architect, Adaptive Inc. > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > http://www.adaptive.com > > > > > > -----Original Message----- > > From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] > > Sent: 20 June 2003 01:48 > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > > Cc: James Odell > > Subject: UML 2 Issues > > > > > > While reviewing certification questions, I found the > > following issues in the UML 2 specification. > > > > 1. UML's use of the word "unique" for multiplicity is > > ambiguous. It means "distinct", but it could be mistaken to > > mean "unique across all instances". For example, if someone > > says that the employee-number attribute of employee is > > unique, it would likely be understood to mean that each > > employee has an employee-number that is different from every > > other employee. But that's not what UML defines "unique" to > > mean. I recommend that the FTF change "{unique}" to > > "{distinct}" or "{set}". > > > > 2. Also, saying {nonunique} on one end of a binary association is > > meaningless by the current rules, because the other end > > remains {unique} by default, so no duplicate links would be allowed. > > > > 3. The notation for shared aggregation appears to be missing > > from the association notation section. > > > > 4. The description of DataType is plainly wrong in the > > specification. A data type is a classification of data > > values. The identity of a data value is based on the value > > itself. And the identity definitely exists. Otherwise you > > would not be able to know when you had two occurrences of the > > same value. If a value has no identity, it would not be > > possible to distinguish different values of the same data > > type. Someone has confused the concept of having identity > > with the concept of having a memory address. Note also that > > an instance specification is capable, according to the > > specification, of identifying a data value, so it is a > > contradiction to say a data value has no identity. Perhaps > > the specification is using the word "identity" in a way that > > is completely different from anything in my dictionary. The > > key point to make is that a data value is not to be confused > > with a data variable or a slot in an object that can hold a > > data value. > > > > 5. The description of GeneralizationSet uses the words > > "general" and "specific" to mean "specific" and "general" > > respectively. The description also uses unclear terms like > > "maps to classifier" without identifying which association. > > Also, the semantics has: "All of the Generalization links > > that share a given general Classifier are divided into > > disjoint sets (that is, > > partitions) using the generalizationSet association." This > > statement is nonsense. First, the metamodel does not require > > all generalizations to be put into partitions using "the > > generalizationSet association". Second, partitions are not > > required by the metamodel to be disjoint - the same > > generalization can be in multiple generalization sets (as > > should be the case). > > > > Regards, > > Don Baisley > > Unisys > > > > > > The information contained in this email and any attached > files is confidential and intended solely for the > addressee(s). The e-mail may be legally privileged or > prohibited from disclosure and unauthorised use. > > If you are not the named addressee you may not use, copy or > disclose this information to any other person. If you > received this message in error please notify the sender immediately. > > Any views or opinions presented here may be solely those of > the originator and do not necessarily reflect those of the Company. > The information contained in this email and any attached files is confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. From: "Baisley, Donald E" To: Pete Rivett Cc: James Odell , uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Subject: RE: UML 2 Issues Date: Mon, 23 Jun 2003 22:29:42 -0500 X-Mailer: Internet Mail Service (5.5.2656.59) Hi Pete, Did isUnique come from UML 1? I don't think so. I think it came from MOF 1. So replacing {unique} with {distinct} or {set} and replacing {nonunique} with {duplicates allowed} or {bag} should have no significant impact and will likely be a better match to current usage. > ... one would constrain City.route->asSet()->size() to be less than 1. I think you mean "less than or equal to 1". In any case, the constraint implies city.route is a bag ({nonunique} in current UML 2 speak), which goes right along with what I said in issue 2 below. Regards, Don -----Original Message----- From: Pete Rivett [mailto:Pete.Rivett@adaptive.com] Sent: Monday, June 23, 2003 7:53 PM To: Baisley, Donald E Cc: James Odell; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: UML 2 Issues Hi again Don, See [PJR] below. > -----Original Message----- > From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] > Sent: 23 June 2003 20:04 > To: Pete Rivett > Cc: James Odell; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: UML 2 Issues > > > > The (nonunique) refers to the values from the perspective of that > > Property (association end) for an instance.... > > I understand that. But since we are talking about ends of an > association, the cardinality of a property for an object is > tied to the number of links connected to that object. A > route visits the same city twice only if there are two links > connecting the route and the city, which means that it must > be allowed that the city can be visited by the same route > twice. In UML 2 speak this means that city.route must be > {nonunique}. If that is not the desired semantics, then > route.city and city.route should not be opposite ends of the > same association. > > > However this does not prevent City.route from being unique: > one could > > want to enforce the rule that the same city cannot be included on > > different Routes. [PJR] I must have written that too late at night: to enforce that rule one would constrain City.route->asSet()->size() to be less than 1. > > Your final remark shows the confusion that comes from abusing > the terms "unique" and "nonunique" in UML 2. According to > UML 2, saying {unique} on city.route means that a city can > have no single route more than once, which is not the same as > saying it cannot be included on different routes. Your > mistake demonstrates my first issue below. Note that the > rule you mention is nicely stated using the word "unique" by > its normal English definition, a definition that also fits > common database usage. [PJR] It was not my understanding of 'unique' that was at fault - just my general powers of reasoning! > > If I say that person.socialSecurityNumber is "unique", then I > expect that no two persons have the same > socialSecurityNumber. I don't mean that all of a person's > social security numbers are different. > > Let's just fix UML 2 to use words in the way they are > commonly understood. Let's have "unique" mean unique. We > can use "distinct" or "set" for what "unique" was supposed to > mean, and use "nondistinct" for what "nonunique" was supposed to mean. [PJR] The problem with your proposed use of 'unique' is in defining the scope over which the uniqueness is supposed to apply. In general there are lots of UML terms that are at odds with normal English, but they have aquired a life of their own (including 'unique') and to change them at this stage may cause more problems than it's worth. As I said earlier it was not my understanding of 'unique' that was the problem - indeed I found the concept very easy to pick up. Cheers Pete Pete Rivett (pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > > Regards, > Don > > -----Original Message----- > From: Pete Rivett [mailto:Pete.Rivett@adaptive.com] > Sent: Thursday, June 19, 2003 11:56 PM > To: Baisley, Donald E > Cc: James Odell; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: UML 2 Issues > > > Hi Don, > > 2. Also, saying {nonunique} on one end of a binary association is > > meaningless by the current rules, because the other end > > remains {unique} by default, so no duplicate links would be allowed. > > The (nonunique) refers to the values from the perspective of > that Property (association end) for an instance not from the > perspective of the links in the Association. So if the > association links Route with City then it makes perfect sense > for Route.city to be (nonunique) - to allow a route to > revisit the same city (this would also need to be an ordered > property). However this does not prevent City.route from being > unique: one could want to enforce the rule that the same city > cannot be included on different Routes. > > Pete > > Pete Rivett (pete.rivett@adaptive.com) > Consulting Architect, Adaptive Inc. > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > http://www.adaptive.com > > > > > > -----Original Message----- > > From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] > > Sent: 20 June 2003 01:48 > > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > > Cc: James Odell > > Subject: UML 2 Issues > > > > > > While reviewing certification questions, I found the > > following issues in the UML 2 specification. > > > > 1. UML's use of the word "unique" for multiplicity is > > ambiguous. It means "distinct", but it could be mistaken to > > mean "unique across all instances". For example, if someone > > says that the employee-number attribute of employee is > > unique, it would likely be understood to mean that each > > employee has an employee-number that is different from every > > other employee. But that's not what UML defines "unique" to > > mean. I recommend that the FTF change "{unique}" to > > "{distinct}" or "{set}". > > > > 2. Also, saying {nonunique} on one end of a binary association is > > meaningless by the current rules, because the other end > > remains {unique} by default, so no duplicate links would be allowed. > > > > 3. The notation for shared aggregation appears to be missing > > from the association notation section. > > > > 4. The description of DataType is plainly wrong in the > > specification. A data type is a classification of data > > values. The identity of a data value is based on the value > > itself. And the identity definitely exists. Otherwise you > > would not be able to know when you had two occurrences of the > > same value. If a value has no identity, it would not be > > possible to distinguish different values of the same data > > type. Someone has confused the concept of having identity > > with the concept of having a memory address. Note also that > > an instance specification is capable, according to the > > specification, of identifying a data value, so it is a > > contradiction to say a data value has no identity. Perhaps > > the specification is using the word "identity" in a way that > > is completely different from anything in my dictionary. The > > key point to make is that a data value is not to be confused > > with a data variable or a slot in an object that can hold a > > data value. > > > > 5. The description of GeneralizationSet uses the words > > "general" and "specific" to mean "specific" and "general" > > respectively. The description also uses unclear terms like > > "maps to classifier" without identifying which association. > > Also, the semantics has: "All of the Generalization links > > that share a given general Classifier are divided into > > disjoint sets (that is, > > partitions) using the generalizationSet association." This > > statement is nonsense. First, the metamodel does not require > > all generalizations to be put into partitions using "the > > generalizationSet association". Second, partitions are not > > required by the metamodel to be disjoint - the same > > generalization can be in multiple generalization sets (as > > should be the case). > > > > Regards, > > Don Baisley > > Unisys > > > > > > The information contained in this email and any attached > files is confidential and intended solely for the > addressee(s). The e-mail may be legally privileged or > prohibited from disclosure and unauthorised use. > > If you are not the named addressee you may not use, copy or > disclose this information to any other person. If you > received this message in error please notify the sender immediately. > > Any views or opinions presented here may be solely those of > the originator and do not necessarily reflect those of the Company. > The information contained in this email and any attached files is confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 02:22:18 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 24 draft Thread-Index: AcSGUaOOvWEvXmwvTEeA2cPkA+ZL9gAHR9rg Priority: Urgent From: "Pete Rivett" To: "Branislav Selic" , , X-Virus-Scanned: by amavisd-new at sentraliant.com 3391: I don't really like the idea of 2 separate sequences (one for body one for language) which must be kept in sync. It seems to me each (body+language) pair should be a structure/tuple: was this considered? I don't think the resolution should be pulled just on my objection but do think that at the very minimum the language property should be unique; and there should be a constraint that the size of the 2 sequences must be equal. 3398: the discussion (and hence the disposition) do not address the issue raised which is that the XMI spec specifies a number of tags that may be attached to metamodel elements in order to tailor the XMI Schema or Documents. While most of these have sensible defaults, there are others that do not. Prime examples are the XML namespace URI (e.g. http://schema.omg.org/spec/UML/2.0) and the namespace prefix (e.g. UML). Such values should certainly be included in the XMI for the metamodel and also in the specification document (a good place would be Appendix F). 5977: two problems are raised by the resolution: a) isUnique=true is the default for MultiplicityElement so we have a problem in that AFAIK (looking at resolution to 7575 in this set of issues) there is no notation to specify non-default multiplicity: the of {unique} is pointless since that's the default anyway! b) whether or not {nonunique} has an explicit notation the point raised by the issue still stands at the metamodel level: there should be a constraint to say that if one end of an association has isUnique=false then the other end must also have isUnique=false. 5979: also requires an Infra change 6171: In the last sentence, rather than saying 'Such rules are beyond the scope of UML' could they not be made a semantic variation point? A precedent is in 7.8.3 where there is a SVP related to compatibility of redefinitions. (I don't feel strongly about this) 6409, 6430, 6452: The discussion gives the reason for deferral as the OCL 2.0 spec not having been adopted; in fact it was adopted at the same time as Super. The declared intention of the submission teams on adoption was for the FTFs to perform a reconciliation between the largely stable adopted specs: OCL in particular has had virtually no changes. In any case the differences in OCL 2.0 are not great and it is not the case AFAIK that 'the vast majority of constraints are likely have to be rewritten'. If we've run out of time let's say that rather than raise unwarranted concerns (e.g. to AB) that major reconciliation work is still required with OCL. 6616: (minor typo) the discussion states: "and provides yet another way to introduce inconsistencies into a model, declaring a node a root when it in fact has children." In fact the inconsistency would be if the node had parent(s) 6630: I'm not very happy with the resolution since it continues to ignore the point I've been trying to make about the distinction between navigability and ownership (you can have navigability without an owned property): and I did not see any objection to my proposal of using the new dot notation to show non-ownership. It would be nice to have a response to that though I will not continue to object on this point. However I do strongly object to removing the name of association end supplierDependency on the basis that " by naming the supplierDependency end, the metamodel would invite constraints to be written involving it, etc". (this from an email between those word-smithing the issue) My objections are: a) the issue did not cite any problem with this being named b) I think it's acknowledged that some tools at least would like to do 'where used' navigations - and recent discussions on MDA have stressed the need for traceability: removing the association end name is actively hostile to such tools c) the only people who will be writing constraints on this association end would be ourselves or a successor RTF d) taking this rule as a precedent would involve deleting large numbers of other association end names from the metamodel. e) the resolution does not even make explicit that this name is being removed 7400: Misses the point of the issue: I wrote an email to explain the issue and the change needed (which is to have AssociationClass::ownedEnd subsetting AssociationClass::ownedAttribute). Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 7:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 draft Attached, please find the draft of ballot 24. There are 66 resolutions in this one -- good work! Reminder: voting on this ballot will commence on Friday at 6 pm EDT. If you have any complaints or suggestions, please submit them by tomorrow noon EDT. Regards, Bran To: uml2-rtf@omg.org Subject: Link semantics X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 29 Aug 2005 17:03:26 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/29/2005 17:03:26, Serialize complete at 08/29/2005 17:03:26 It may seem that link semantics should be fully clear by now, but, following a series of recent discussions with several individuals, I think that the spec still leaves too much room for interpretation. Part of this discussion is prompted by Pete's recent reply to one of my e-mails, where he stated that it should not be possible for an association to have one of its ends marked "unique" while the other is marked "non-unique". (In fact, as Pete pointed out, someone raised an issue about that (5977).) At first glance, this may seen patently obvious, but, as I argue below, it does not necessarily follow. I will use the following simple example of a binary association L to illustrate my arguments: An association, as we all agree is a collection of links. What do the members of this collection look like and what do they represent? First, I had always assumed that the members of L would be pairs of object identifier values (e.g., , ,...). However, in a recent discussion I was presented with a different interpretation in which members of L were viewed as consisting of pairs OF COLLECTIONS of object identifier values (e.g., <{a1, a2}, {b1}>, <{a1,a3}, {b2, b5, b52}>, ...). I haven't checked the text in detail, but, based on this discussion, it seemed that the spec is not clear on this. If so, it needs to be fixed. (I am curious, though, if anyone in the RTF feels that the second interpretation is the proper one.) This is one issue, but not my main point. Back to the original issue: How can it be that one end of an association can be unique while the other is non-unique? For example, what could the diagram below mean? Consider the following interpretation of an association end: An association end represents a correspondence (or "mapping" if you like) of instances of the classifier at that end to instances of the classifier at the opposite end. In the general case, each instance at one end maps to a collection of instances at the opposite end. For example, Let's assume that, for element b3 of class B at time t, this collection consists of two elements of class A: {a1, a7}. This means that there exist two links at that instant: and From the other side, assume that for element a4 of class A, the corresponding collection is {b17, b52, b52} implying the existence of three links: , [1], and [2]. (I am using indices here to distinguish between two links anchored in the same two elements.) Because end A::b is marked as nonunique, we CAN have the same element appearing more than once in the "correspondence" set. OTOH, because end B::a is marked as unique, it CANNOT have duplicates in its collections. So, we see that with this interpretation of the meaning of association ends, it is quite possible to have different uniqueness designators at the two ends. Note that this is independent of whether an association end is owned by the class or by the association. One of the nice features of this "mapping" interpretation of association ends is that it is more general and provides for a richer modeling capability. It is also better aligned with the extended definition of association ends that was introduced in UML 2.0. Finally, it seems to match the actions model better, because link actions actually manipulate link ends rather than links. [ACKNOWLEDGEMENT: this "mapping" interpretation of association ends was brought to my attention by Prof. Dragan Milicev of the U. of Belgrade who first noted it.] Whichever side you take on these issues, it is a fact that the current spec is ambiguous on these points. We definitely need to be clear on this. Cheers...Bran To: Branislav Selic Cc: uml2-rtf@omg.org Subject: Re: Link semantics X-Mailer: Lotus Notes Release 6.5 September 18, 2003 From: "Richard Vermillion" Date: Mon, 29 Aug 2005 21:14:00 -0400 X-MIMETrack: Serialize by Router on notes.ny.cyberdialogue.com/CyberDialogue(Release 5.0.12 |February 13, 2003) at 08/29/2005 09:14:12 PM, Serialize complete at 08/29/2005 09:14:12 PM Apologies for the long response and poor quality artwork, but here's some more grist for the mill. I agree that the current spec is a bit too fuzzy on the questions that Bran raises, and presumably, the same issues would exist when one end is single-valued and the other is multi-valued and non-unique. For instance: {nonunique} ------- +a +b ------- | A |-------------------| B | | | 1 * | | ------- ------- If we have: a1.b = {b1, b2, b1} then the links are: [1] [2] using Bran's convention for link notation. And the values of B::a are: b1.a = {a1} b2.a = {a2} At least I think this is right. But it just feels a bit funny because the two links are "collapsing" into one single-valued property. But if we agree that this is the way this should work, then we're not far from Bran's test case: {unique} {nonunique} ------- +a +b ------- | A |-------------------| B | | | 2 * | | ------- ------- If we have: a1.b = {b1, b2, b1} a2.b = {b1, b2, b3, b2} a3.b = {b3} then the links are: [1] [2] [1] [2] And they would have the equivalent B::a values: b1.a = {a1, a2} b2.a = {a1, a2} b3.a = {a2, a3} This would satisfy all of the constraints on the association ends (as far as I know) but has even more "collapsing" of link ends going on. And, finally, what happens if we have the exact same scenario above, except B::a is also non-unique. Is the same set of links then illegal? When looked at from B's perspective, we would have: b1.a = {a1, a1, a2} x -- illegal because of B::a.upper b2.a = {a1, a2, a2} x -- illegal because of B::a.upper b3.a = {a2, a3} Is this invalid as soon as you add b1 to the a2.b collection? And presumably this would all be fine if B::a had multiplicity [0..*]. -rv Richard Vermillion Fulcrum Analytics, Inc. Branislav Selic 08/29/05 05:03 PM To: uml2-rtf@omg.org cc: Subject: Link semantics ----------------------------------------- (on mx01.fulcrumanalytics.com) email-body was scanned and no virus found email-body was scanned and no virus found --------------------------------------------------------- It may seem that link semantics should be fully clear by now, but, following a series of recent discussions with several individuals, I think that the spec still leaves too much room for interpretation. Part of this discussion is prompted by Pete's recent reply to one of my e-mails, where he stated that it should not be possible for an association to have one of its ends marked "unique" while the other is marked "non-unique". (In fact, as Pete pointed out, someone raised an issue about that (5977).) At first glance, this may seen patently obvious, but, as I argue below, it does not necessarily follow. I will use the following simple example of a binary association L to illustrate my arguments: An association, as we all agree is a collection of links. What do the members of this collection look like and what do they represent? First, I had always assumed that the members of L would be pairs of object identifier values (e.g., , ,...). However, in a recent discussion I was presented with a different interpretation in which members of L were viewed as consisting of pairs OF COLLECTIONS of object identifier values (e.g., <{a1, a2}, {b1}>, <{a1,a3}, {b2, b5, b52}>, ...). I haven't checked the text in detail, but, based on this discussion, it seemed that the spec is not clear on this. If so, it needs to be fixed. (I am curious, though, if anyone in the RTF feels that the second interpretation is the proper one.) This is one issue, but not my main point. Back to the original issue: How can it be that one end of an association can be unique while the other is non-unique? For example, what could the diagram below mean? Consider the following interpretation of an association end: An association end represents a correspondence (or "mapping" if you like) of instances of the classifier at that end to instances of the classifier at the opposite end. In the general case, each instance at one end maps to a collection of instances at the opposite end. For example, Let's assume that, for element b3 of class B at time t, this collection consists of two elements of class A: {a1, a7}. This means that there exist two links at that instant: and >From the other side, assume that for element a4 of class A, the corresponding collection is {b17, b52, b52} implying the existence of three links: , [1], and [2]. (I am using indices here to distinguish between two links anchored in the same two elements.) Because end A::b is marked as nonunique, we CAN have the same element appearing more than once in the "correspondence" set. OTOH, because end B::a is marked as unique, it CANNOT have duplicates in its collections. So, we see that with this interpretation of the meaning of association ends, it is quite possible to have different uniqueness designators at the two ends. Note that this is independent of whether an association end is owned by the class or by the association. One of the nice features of this "mapping" interpretation of association ends is that it is more general and provides for a richer modeling capability. It is also better aligned with the extended definition of association ends that was introduced in UML 2.0. Finally, it seems to match the actions model better, because link actions actually manipulate link ends rather than links. [ACKNOWLEDGEMENT: this "mapping" interpretation of association ends was brought to my attention by Prof. Dragan Milicev of the U. of Belgrade who first noted it.] Whichever side you take on these issues, it is a fact that the current spec is ambiguous on these points. We definitely need to be clear on this. Cheers...Bran