Issue 15233: OCL 2.2 Correction to Issue 9796 for AssociationEndCall (ocl2-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: Issue 9796 responded to the merge of Attribute and AssociationEnd as Property in UML by merging AttributeCallExp and AssociationEndCallExp. This merge was not appropriate since UML made no change to the required OCL navigability. Without AssociationEndCallExp, it is not possible to express a qualified association navigation, since the 'replacement' PropertyCallExp does not allow for the qualifiers in: self.customer[123456] Resolution: Revised Text: Actions taken: April 29, 2010: received issue Discussion: End of Annotations:===== ronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoFAJxR2UtUXeby/2dsb2JhbACQcIwfcbwwhRAE Date: Thu, 29 Apr 2010 17:35:30 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: issues@omg.org Subject: OCL 2.2 Correction to Issue 9796 for AssociationEndCall X-Plusnet-Relay: 09aeb093fa02a7c8eceb2809e5e22d1d Hi Issue 9796 responded to the merge of Attribute and AssociationEnd as Property in UML by merging AttributeCallExp and AssociationEndCallExp. This merge was not appropriate since UML made no change to the required OCL navigability. Without AssociationEndCallExp, it is not possible to express a qualified association navigation, since the 'replacement' PropertyCallExp does not allow for the qualifiers in: self.customer[123456] Regards From: "Rouquette, Nicolas F (316A)" To: "ocl2-rtf@omg.org" Date: Thu, 29 Apr 2010 12:21:15 -0700 Subject: Re: issue 15233 -- OCL 2 RTF issue Thread-Topic: issue 15233 -- OCL 2 RTF issue Thread-Index: Acrn0SN2Cs+HX3SwReqMb++YNdSK5g== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized From the point of view of the UML 2.x RTF, the following statement is perplexing: This merge was not appropriate since UML made no change to the required OCL navigability. Have we (the UML RTF) missed something that should have been done as a consequence of resolving OCL issue 9796? Please clarify. - Nicolas. On Apr 29, 2010, at 12:04 PM, Juergen Boldt wrote: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoFAJxR2UtUXeby/2dsb2JhbACQcIwfcbwwhRAE Date: Thu, 29 Apr 2010 17:35:30 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: issues@omg.org Subject: OCL 2.2 Correction to Issue 9796 for AssociationEndCall X-Plusnet-Relay: 09aeb093fa02a7c8eceb2809e5e22d1d Hi Issue 9796 responded to the merge of Attribute and AssociationEnd as Property in UML by merging AttributeCallExp and AssociationEndCallExp. This merge was not appropriate since UML made no change to the required OCL navigability. Without AssociationEndCallExp, it is not possible to express a qualified association navigation, since the 'replacement' PropertyCallExp does not allow for the qualifiers in: self.customer[123456] Regards Ed Willink Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAFAC6B2UvUnw4U/2dsb2JhbACBP5p1YHG9W4JeFYIdBA Date: Thu, 29 Apr 2010 20:56:07 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: "Rouquette, Nicolas F (316A)" CC: "ocl2-rtf@omg.org" Subject: Re: issue 15233 -- OCL 2 RTF issue X-Plusnet-Relay: afba0a998e8a107217b8a3400596da78 Hi Nicolas No problem for UML. It made a sensible simplification of two classes that were the same. However the navigation scenarios in which these could be used didn't change, so OCL which is concerned with the navigation scenarios should only have changed to align terminology. OCL has never not been broken here. It has just become more so. While I have your attention, am I right in thinking that for pedantic completeness OCL should also support a.b[c][q] in which b is an Association class name c is a Property name to disambiguate when b.source and b.target are the same N to N Classifier q is a list of qualifiers this being the logical combination of the two a.b[c] a.b[q] syntaxes. Regards Ed Willink On 29/04/2010 20:21, Rouquette, Nicolas F (316A) wrote: From the point of view of the UML 2.x RTF, the following statement is perplexing: This merge was not appropriate since UML made no change to the required OCL navigability. Have we (the UML RTF) missed something that should have been done as a consequence of resolving OCL issue 9796? Please clarify. - Nicolas. On Apr 29, 2010, at 12:04 PM, Juergen Boldt wrote: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoFAJxR2UtUXeby/2dsb2JhbACQcIwfcbwwhRAE Date: Thu, 29 Apr 2010 17:35:30 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: issues@omg.org Subject: OCL 2.2 Correction to Issue 9796 for AssociationEndCall X-Plusnet-Relay: 09aeb093fa02a7c8eceb2809e5e22d1d Hi Issue 9796 responded to the merge of Attribute and AssociationEnd as Property in UML by merging AttributeCallExp and AssociationEndCallExp. This merge was not appropriate since UML made no change to the required OCL navigability. Without AssociationEndCallExp, it is not possible to express a qualified association navigation, since the 'replacement' PropertyCallExp does not allow for the qualifiers in: self.customer[123456] Regards Ed Willink Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.814 / Virus Database: 271.1.1/2842 - Release Date: 04/29/10 07:27:00 From: "Rouquette, Nicolas F (316A)" To: Ed Willink CC: "ocl2-rtf@omg.org" Date: Thu, 29 Apr 2010 14:27:49 -0700 Subject: Re: issue 15233 -- OCL 2 RTF issue Thread-Topic: issue 15233 -- OCL 2 RTF issue Thread-Index: Acrn4tHFp5OXCeRRQpSq9qDHqKdEoA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized On Apr 29, 2010, at 12:56 PM, Ed Willink wrote: Hi Nicolas No problem for UML. It made a sensible simplification of two classes that were the same. However the navigation scenarios in which these could be used didn't change, so OCL which is concerned with the navigation scenarios should only have changed to align terminology. OCL has never not been broken here. It has just become more so. While I have your attention, am I right in thinking that for pedantic completeness OCL should also support a.b[c][q] in which b is an Association class name If you are pedantic, then please be careful to use pedantic UML terminology where we have the concept of Association and AssociationClass. So, what you wrote above is, w.r.t. UML, pedantically confusing. I suppose you meant: b is the name of an Association c is a Property name to disambiguate when b.source and b.target are the same N to N Classifier I don't understand what you mean here. Are you referring to the support in OCL for disambiguating association ends by qualifying them? OCL 2.2 includes an example in clause 7.5.3 "Qualifying association ends with association names" If this is what you meant, then the OCL 2.2 syntax would be: a.b::c (assuming that 'c' is the name of an association end defined in the association 'b') q is a list of qualifiers If I have followed your line of reasoning, you are asking about combining the OCL syntax for qualifying association ends with association names with the OCL syntax for using association end qualifiers. Pedantically speaking, note that the two uses of "qualification" here are completely different. The first, i.e., qualifying association ends, refers to lexical disambiguation -- i.e., if "a.c" is ambiguous, then it can be disambiguated as "a.b::c" The second, i.e., association end qualifiers, refers to "navigation through qualified associations" (OCL 7.5.6), i.e., this refers to a qualifier defined on an association end. This qualifier can be used to partition the set of links of the association as described in UML 7.3.44 Property (see "Package AssociationClasses") In your example, this corresponds to a.c[q] (if "a.c" is unambiguous) or to a.b::c[q] (If "a.c" is ambiguous and requires lexical disambiguation by qualifying the association end 'c' with the name of the association, 'b'). Here, "[q]" refers to the sense of qualified associations in OCL 7.5.6 and the sense of property qualifier in 7.3.44. this being the logical combination of the two a.b[c] a.b[q] syntaxes. I doubt it because if 'b' is the name of an association, then "a.b[q]" is an ill-formed OCL expression. -- Nicolas. Regards Ed Willink On 29/04/2010 20:21, Rouquette, Nicolas F (316A) wrote: From the point of view of the UML 2.x RTF, the following statement is perplexing: This merge was not appropriate since UML made no change to the required OCL navigability. Have we (the UML RTF) missed something that should have been done as a consequence of resolving OCL issue 9796? Please clarify. - Nicolas. On Apr 29, 2010, at 12:04 PM, Juergen Boldt wrote: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoFAJxR2UtUXeby/2dsb2JhbACQcIwfcbwwhRAE Date: Thu, 29 Apr 2010 17:35:30 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: issues@omg.org Subject: OCL 2.2 Correction to Issue 9796 for AssociationEndCall X-Plusnet-Relay: 09aeb093fa02a7c8eceb2809e5e22d1d Hi Issue 9796 responded to the merge of Attribute and AssociationEnd as Property in UML by merging AttributeCallExp and AssociationEndCallExp. This merge was not appropriate since UML made no change to the required OCL navigability. Without AssociationEndCallExp, it is not possible to express a qualified association navigation, since the 'replacement' PropertyCallExp does not allow for the qualifiers in: self.customer[123456] Regards Ed Willink Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.814 / Virus Database: 271.1.1/2842 - Release Date: 04/29/10 07:27:00 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFADVt2kvUnw4R/2dsb2JhbACBPpsBYHG+EYJPBYI+BA Date: Fri, 30 Apr 2010 13:43:50 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: "Rouquette, Nicolas F (316A)" CC: "ocl2-rtf@omg.org" Subject: Re: issue 15233 -- OCL 2.2 Correction to Issue 9796 for AssociationEndCall X-Plusnet-Relay: b5b9a69d036420b80de10f4b24b96c81 Hi Nicolas [I tried commenting in line but it was unreadable.] Yes, Thanks. I'm trying hard to learn true UML terminology rather than the usages that appear in the OCL specification. It appears that as well as reviewing every usage of the words 'attribute', 'feature' and 'property', I must also review 'association' for UML alignment. Yes, not all my examples were well-formed because there is a disconnect that I'm trying to resolve between examples in Section 7 and syntaxes in Section 9.3. Yes, qualifi... is dangerously overloaded. I'll try to refer more clearly to: OCL 7.5.6 Qualified Association End Navigation e.g. self.customer[8764423] OclExpression . Name-of-Property [ Values-of-Qualifiers ] => Value-of-Property (NB. this is neither an AssociationClassCallExpCS nor IteratorExpCS[E] (an implicit collect), the only syntaxes that initialise the ast.qualifiers. Both require a Name-of-AssociationClass.) This was an AssociationEndCallExp prior to OCL 2.0 06-05-01. OCL 7.5.4 Explicit AssociationClass Navigation e.g. self.employeeRanking[bosses] OclExpression . Name-of-AssociationClass [ Name-of-Property ] => Value-of-AssociationClass (NB. this is not an AssociationClassCallExpCS since that has qualifier arguments) UML Infra 9.14.1 Qualified Names e.g. Namespace::element rather than OCL 7.5.7 PathName. ------ My query was whether it was valid, albeit obscure, UML for an N-N association in the style of OCL Fig 7.2 to be elaborated with qualifiers in the style of Bank.accountNumber in OCL 7.1 so that an Explicit AssociationClass Navigation might also require qualifiers. e.g. in Fig 7.1 could there be an Invitation AssociationClass with Properties 'when', 'where' and ends 'host' and 'guest' qualified by Person.name? Something like the following might then be needed to query all invitation locations for which Jill was jack's guest. jack.invitation[guest]['Jill'].where ------- Therefore to restore OCL 2.0 functionality for 7.5.6, it seems we must re-instate AssociationEndCallExpCS or add qualifiers to PropertyCallExpCS. (AssociationEndCallExpEval is still in OCL 2.2). If jack.invitation[guest]['Jill'] is indeed a reasonable OCL expression, then we add optional qualifiers to AssociationClassCallExpCS to support 7.5.4 and discuss whether it should be jack.invitation[guest]['Jill'] or the less gramatically challenging jack.invitation[guest|'Jill']. For jack.invitation[guest] and jack.invitation['Jill'] a semantic disambiguation is required to determine whether the explicit property or qualifiers are omitted. Regards Ed Willink On 29/04/2010 22:27, Rouquette, Nicolas F (316A) wrote: On Apr 29, 2010, at 12:56 PM, Ed Willink wrote: Hi Nicolas No problem for UML. It made a sensible simplification of two classes that were the same. However the navigation scenarios in which these could be used didn't change, so OCL which is concerned with the navigation scenarios should only have changed to align terminology. OCL has never not been broken here. It has just become more so. While I have your attention, am I right in thinking that for pedantic completeness OCL should also support a.b[c][q] in which b is an Association class name If you are pedantic, then please be careful to use pedantic UML terminology where we have the concept of Association and AssociationClass. So, what you wrote above is, w.r.t. UML, pedantically confusing. I suppose you meant: b is the name of an Association c is a Property name to disambiguate when b.source and b.target are the same N to N Classifier I don't understand what you mean here. Are you referring to the support in OCL for disambiguating association ends by qualifying them? OCL 2.2 includes an example in clause 7.5.3 "Qualifying association ends with association names" If this is what you meant, then the OCL 2.2 syntax would be: a.b::c (assuming that 'c' is the name of an association end defined in the association 'b') q is a list of qualifiers If I have followed your line of reasoning, you are asking about combining the OCL syntax for qualifying association ends with association names with the OCL syntax for using association end qualifiers. Pedantically speaking, note that the two uses of "qualification" here are completely different. The first, i.e., qualifying association ends, refers to lexical disambiguation -- i.e., if "a.c" is ambiguous, then it can be disambiguated as "a.b::c". The second, i.e., association end qualifiers, refers to "navigation through qualified associations" (OCL 7.5.6), i.e., this refers to a qualifier defined on an association end. This qualifier can be used to partition the set of links of the association as described in UML 7.3.44 Property (see "Package AssociationClasses") In your example, this corresponds to a.c[q] (if "a.c" is unambiguous) or to a.b::c[q] (If "a.c" is ambiguous and requires lexical disambiguation by qualifying the association end 'c' with the name of the association, 'b'). Here, "[q]" refers to the sense of qualified associations in OCL 7.5.6 and the sense of property qualifier in 7.3.44. this being the logical combination of the two a.b[c] a.b[q] syntaxes. I doubt it because if 'b' is the name of an association, then "a.b[q]" is an ill-formed OCL expression. -- Nicolas. Regards Ed Willink On 29/04/2010 20:21, Rouquette, Nicolas F (316A) wrote: From the point of view of the UML 2.x RTF, the following statement is perplexing: This merge was not appropriate since UML made no change to the required OCL navigability. Have we (the UML RTF) missed something that should have been done as a consequence of resolving OCL issue 9796? Please clarify. - Nicolas. On Apr 29, 2010, at 12:04 PM, Juergen Boldt wrote: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoFAJxR2UtUXeby/2dsb2JhbACQcIwfcbwwhRAE Date: Thu, 29 Apr 2010 17:35:30 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: issues@omg.org Subject: OCL 2.2 Correction to Issue 9796 for AssociationEndCall X-Plusnet-Relay: 09aeb093fa02a7c8eceb2809e5e22d1d Hi Issue 9796 responded to the merge of Attribute and AssociationEnd as Property in UML by merging AttributeCallExp and AssociationEndCallExp. This merge was not appropriate since UML made no change to the required OCL navigability. Without AssociationEndCallExp, it is not possible to express a qualified association navigation, since the 'replacement' PropertyCallExp does not allow for the qualifiers in: self.customer[123456] Regards Ed Willink From: "Rouquette, Nicolas F (316A)" To: Ed Willink CC: "ocl2-rtf@omg.org" Date: Fri, 30 Apr 2010 10:42:04 -0700 Subject: Re: issue 15233 -- OCL 2.2 Correction to Issue 9796 for AssociationEndCall Thread-Topic: issue 15233 -- OCL 2.2 Correction to Issue 9796 for AssociationEndCall Thread-Index: AcrojHMGIpwNeK5iQrSr4JFbagUkjA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Ed, Thanks for the clarification. There are multiple problems here; I'll address them separately. Now that I've clarified this mess for you, I hope you can clarify how to write constraints for profiles in OCL; this is not as simple as you say it is. 1) OCL2.2, clause 7.5.6 I noticed that the way the OCL2.2 document uses the UML concept of UML::Property::qualifier is incorrect. Precisely, OCL2.2 Fig 7.1 is wrong; look at UML2.3 Fig 7.72 for a correct version of the UML::Association between Bank and Person. In QVTo-like syntax, UML2.3 Fig 7.72 would be something like this: -- See UML7.3.44, Figure 7.72 package PersonBankExample { class Bank { references <> customer:Person[0..1] opposites bankAccount; } class Person { references bankAccount:Bank[*] opposites customer; } } Note: I tried this with the latest/greatest QVTo editor and it doesn't like this example... The problem with OCL 2.2, Fig 7.1 are: - give a name to the association end near Bank, e.g. 'bankAccount' - fix the multiplicity of: Person::bankAccount from 0..1 to * -- i.e., a person can have zero or more bank accounts! - fix the multiplicity of Bank::customer from 0..* to 0..1 -- i.e., there is zero or one customer for a given 'accountNumber' value. - give a name to the association itself, e.g., BankAccount, or, if you want to use the UML notation convention, A_customer_bankAccount Note that the example in OCL2.2, 7.5.6, is correct, i.e.: context Bank inv: self.customer[8764423] This should be read as 8764423 is the qualifying value for the 'accountNumber' qualifier. This qualifying value for a given instance of Bank (self) designates zero or one Person whose 'bankAccount' has this particular 'accountNumber' value, i.e., 8764423. From a parsing point of view, this expression uses the square brackets for specifying the value of a UML::Property::qualifier. This applies when the expression before the square brackets designates an entity that is a kind of Property and that this Property is an Association::memberEnd (i.e., an association end property in common UML speak). 2) OCL2.2, clause 7.5.4 The OCL examples for Figure 7.2, currently: context Person inv: self.employeeRanking[bosses]->sum() > 0 context Person inv: self.employeeRanking[employees]->sum() > 0 context Person inv: self.employeeRanking->sum() > 0 -- INVALID! context Person inv: self.job[employer] should be fixed to: context Person inv: self.EmployeeRanking[bosses]->sum() > 0 context Person inv: self.EmployeeRanking[employees]->sum() > 0 context Person inv: self.EmployeeRanking->sum() > 0 -- INVALID! context Person inv: self.Job[employer] That is, 'EmployeeRanking' is the name of the association shown in Fig 7.2 That figure does not have anything called 'employeeRanking' and it is misleading to suggest that in OCL the name of the association could be written with a lowercase initial letter when the name of the association itself has an initial capital letter. Since lexical names are case-sensitive in both UML and OCL, case-sensitivity should be respected to avoid creating confusion and potential ambiguity with other names that are lexically different only by their upper/lower case letter. From a parsing point view, this expression uses the square brackets for specifying an association end property by name. This applies when the expression before the square brackets designates an entity that is a kind of Association (i.e, it could be an AssociationClass as well). In particular, the text in clause 7.5.4 about using the name of an association class with a lowercase initial letter should be removed. That is, change the following, currently: To specify navigation to association classes (Job and Marriage in the example), OCL uses a dot and the name of the association class starting with a lowercase character: context Person inv: self.job The sub-expression self.job evaluates to a Set of all the jobs a person has with the companies that are his/her employer. In the case of an association class, there is no explicit rolename in the class diagram. The name job used in this navigation is the name of the association class starting with a lowercase character, similar to the way described in the sub clause .Missing AssociationEnd names. above. to: To specify navigation to association classes (Job and Marriage in the example), OCL uses a dot and the name of the association class: context Person inv: self.Job The sub-expression self.Job evaluates to a Set of all the jobs a person has with the companies that are his/her employer. In the case of an association class, there is no explicit rolename in the class diagram. The name Job used in this navigation is the name of the association class. 3) OCL 7.5.6 + 7.5.4 One could conceivably use the two syntaxes in a variant of the example shown for OCL 7.5.6: context Bank inv: self.BankAccount[customer][8764423] 4) Qualification in the sense of selection. In the style of QVT1.1, clause 8.2.2.7, one could also get confused with the QVT notation where square brackets are used as a shorthand for a select operation, e.g; list->propertyname[res | condition] // represents list->collectselect(i;res:=i.propertyname | condition) In the context of OCL2.2, Figure 7.1, one could think of doing something like this to retrieve all of the employees at a company who started their job after January 1, 2010. It would be misleading to expect the QVT-inspired shorthand notation to work: context Company def: employeesHiredIn2010: Set(Person) = self.Job[startDate > Date('January 1, 2010')] As far as OCL is concerned, this should be written with an explicit select statement, i.e.: context Company def: employeesHiredIn2010: Set(Person) = self.Job->select(startDate > Date('January 1, 2010')) - Nicolas. On Apr 30, 2010, at 5:43 AM, Ed Willink wrote: Hi Nicolas [I tried commenting in line but it was unreadable.] Yes, Thanks. I'm trying hard to learn true UML terminology rather than the usages that appear in the OCL specification. It appears that as well as reviewing every usage of the words 'attribute', 'feature' and 'property', I must also review 'association' for UML alignment. Yes, not all my examples were well-formed because there is a disconnect that I'm trying to resolve between examples in Section 7 and syntaxes in Section 9.3. Yes, qualifi... is dangerously overloaded. I'll try to refer more clearly to: OCL 7.5.6 Qualified Association End Navigation e.g. self.customer[8764423] OclExpression . Name-of-Property [ Values-of-Qualifiers ] => Value-of-Property (NB. this is neither an AssociationClassCallExpCS nor IteratorExpCS[E] (an implicit collect), the only syntaxes that initialise the ast.qualifiers. Both require a Name-of-AssociationClass.) This was an AssociationEndCallExp prior to OCL 2.0 06-05-01. OCL 7.5.4 Explicit AssociationClass Navigation e.g. self.employeeRanking[bosses] OclExpression . Name-of-AssociationClass [ Name-of-Property ] => Value-of-AssociationClass (NB. this is not an AssociationClassCallExpCS since that has qualifier arguments) UML Infra 9.14.1 Qualified Names e.g. Namespace::element rather than OCL 7.5.7 PathName. ------ My query was whether it was valid, albeit obscure, UML for an N-N association in the style of OCL Fig 7.2 to be elaborated with qualifiers in the style of Bank.accountNumber in OCL 7.1 so that an Explicit AssociationClass Navigation might also require qualifiers. e.g. in Fig 7.1 could there be an Invitation AssociationClass with Properties 'when', 'where' and ends 'host' and 'guest' qualified by Person.name? Something like the following might then be needed to query all invitation locations for which Jill was jack's guest. jack.invitation[guest]['Jill'].where ------- Therefore to restore OCL 2.0 functionality for 7.5.6, it seems we must re-instate AssociationEndCallExpCS or add qualifiers to PropertyCallExpCS. (AssociationEndCallExpEval is still in OCL 2.2). If jack.invitation[guest]['Jill'] is indeed a reasonable OCL expression, then we add optional qualifiers to AssociationClassCallExpCS to support 7.5.4 and discuss whether it should be jack.invitation[guest]['Jill'] or the less gramatically challenging jack.invitation[guest|'Jill']. For jack.invitation[guest] and jack.invitation['Jill'] a semantic disambiguation is required to determine whether the explicit property or qualifiers are omitted. Regards Ed Willink On 29/04/2010 22:27, Rouquette, Nicolas F (316A) wrote: On Apr 29, 2010, at 12:56 PM, Ed Willink wrote: Hi Nicolas No problem for UML. It made a sensible simplification of two classes that were the same. However the navigation scenarios in which these could be used didn't change, so OCL which is concerned with the navigation scenarios should only have changed to align terminology. OCL has never not been broken here. It has just become more so. While I have your attention, am I right in thinking that for pedantic completeness OCL should also support a.b[c][q] in which b is an Association class name If you are pedantic, then please be careful to use pedantic UML terminology where we have the concept of Association and AssociationClass. So, what you wrote above is, w.r.t. UML, pedantically confusing. I suppose you meant: b is the name of an Association c is a Property name to disambiguate when b.source and b.target are the same N to N Classifier I don't understand what you mean here. Are you referring to the support in OCL for disambiguating association ends by qualifying them? OCL 2.2 includes an example in clause 7.5.3 "Qualifying association ends with association names" If this is what you meant, then the OCL 2.2 syntax would be: a.b::c (assuming that 'c' is the name of an association end defined in the association 'b') q is a list of qualifiers If I have followed your line of reasoning, you are asking about combining the OCL syntax for qualifying association ends with association names with the OCL syntax for using association end qualifiers. Pedantically speaking, note that the two uses of "qualification" here are completely different. The first, i.e., qualifying association ends, refers to lexical disambiguation -- i.e., if "a.c" is ambiguous, then it can be disambiguated as "a.b::c". The second, i.e., association end qualifiers, refers to "navigation through qualified associations" (OCL 7.5.6), i.e., this refers to a qualifier defined on an association end. This qualifier can be used to partition the set of links of the association as described in UML 7.3.44 Property (see "Package AssociationClasses") In your example, this corresponds to a.c[q] (if "a.c" is unambiguous) or to a.b::c[q] (If "a.c" is ambiguous and requires lexical disambiguation by qualifying the association end 'c' with the name of the association, 'b'). Here, "[q]" refers to the sense of qualified associations in OCL 7.5.6 and the sense of property qualifier in 7.3.44. this being the logical combination of the two a.b[c] a.b[q] syntaxes. I doubt it because if 'b' is the name of an association, then "a.b[q]" is an ill-formed OCL expression. -- Nicolas. Regards Ed Willink On 29/04/2010 20:21, Rouquette, Nicolas F (316A) wrote: From the point of view of the UML 2.x RTF, the following statement is perplexing: This merge was not appropriate since UML made no change to the required OCL navigability. Have we (the UML RTF) missed something that should have been done as a consequence of resolving OCL issue 9796? Please clarify. - Nicolas. On Apr 29, 2010, at 12:04 PM, Juergen Boldt wrote: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoFAJxR2UtUXeby/2dsb2JhbACQcIwfcbwwhRAE Date: Thu, 29 Apr 2010 17:35:30 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: issues@omg.org Subject: OCL 2.2 Correction to Issue 9796 for AssociationEndCall X-Plusnet-Relay: 09aeb093fa02a7c8eceb2809e5e22d1d Hi Issue 9796 responded to the merge of Attribute and AssociationEnd as Property in UML by merging AttributeCallExp and AssociationEndCallExp. This merge was not appropriate since UML made no change to the required OCL navigability. Without AssociationEndCallExp, it is not possible to express a qualified association navigation, since the 'replacement' PropertyCallExp does not allow for the qualifiers in: self.customer[123456] Regards Ed Willink X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADfH2kvUnw4S/2dsb2JhbACdJXG+Y4JPBYI+BA Date: Fri, 30 Apr 2010 20:08:58 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: "Rouquette, Nicolas F (316A)" CC: "ocl2-rtf@omg.org" Subject: Re: issue 15233 -- OCL 2.2 Correction to Issue 9796 for AssociationEndCall X-Plusnet-Relay: 325e964550b77d191f71a1a9b0a0c477 Hi Nicolas Thanks for the clarification. There are multiple problems here; I'll address them separately. Likewise thanks. I've just pasted much of your text into a new OCL issue on UML alignment of association names. The problem with OCL 2.2, Fig 7.1 are: Unfortunately, since Section 7 has never been checked with a tool, there are at least 20 problems with Figure 7.1 and many more in the subsequent text. One could conceivably use the two syntaxes in a variant of the example shown for OCL 7.5.6: context Bank inv: self.BankAccount[customer][8764423] Thanks, that's what I suspected and so tells me how to fix it. In the style of QVT1.1, clause 8.2.2.7, one could also get confused with the QVT notation where square brackets are used as a shorthand for a select operation, e.g; list->propertyname[res | condition] // represents list->collectselect(i;res:=i.propertyname | condition) Ok. QVTo syntax is a bit of a hindrance. I'll propose the [][] syntax. Regards Ed Willink