Issue 9751: UML/OCL spec mismatch-Constraint.context vs Constraint.constrainedElement (uml2-rtf) Source: No Magic, Inc. (Mr. Tomas Juknevicius, tomas.juknevicius(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: There is an clash/mismatch between the UML2.0 and OCL2.0 specs on constraint semantics. The UML superstructure doc 05-07-04, chapter 7.3.10 states, that Constraint has context and constrainedElement associations(properties). The Semantic section of the paragraph states, that the context property of the constraint is used in OCL constraint evaluation as a "self". However the OCL2.0 specification doc 05-06-06, chapter 12 specifies different rules, how OCL expressions are evaluated in the UML models. In most cases it is mandated that the self (a.k.a. contextual classifier) should be derived from the constrainedElement property. In particular, for most common case - invariant constraints, 12.6, 12.6.1 paragraphs state, that the contextual classifier should be the classifier, specified by the constrainedElement property: contextualClassifier = self.constraint.constrainedElement->any(true).oclAsType(Classifier) The other conditions are irrelevant for the issue at hand: constraint should have <<invariant>> stereotype (self.constraint.stereotype.name = ?invariant?) constraint.constrainedElement should have a single element (self.constraint.constrainedElement->size() = 1) constraint.constrainedElement should be classifier (self.constraint.constrainedElement.any(true).oclIsKindOf(Classifier)) expression result should be boolean (self.bodyExpression.type.name = ?Boolean?) So we have a conflicting specs here. Which one of these is correct? I am inclined to believe, that the OCL spec, being more concrete, is correct - UML spec mentions the usage of "self" only casually, in one sentence. However if this true, what is the meaning of the context property of the constraint in the UML? It seams that this property is then unnecessary and not used (at least for OCL constraints) anywhere... Note that the upcoming UML2.1 superstructure spec, 06-04-02, introduces small changes to the context property of the constraint. Context is now changed to subset namespace. However the issue, described above, is not mitigated and is still present in 2.1. Resolution: Revised Text: Actions taken: May 18, 2006: received issue Discussion: End of Annotations:===== te: Thu, 18 May 2006 21:11:33 +0300 From: Tomas Juknevicius X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: ocl2-rtf@omg.org, uml2-rtf@omg.org Subject: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement X-Virus-Scanned: ClamAV 0.88.2/1468/Thu May 18 17:48:03 2006 on banginis X-Virus-Status: Clean Hello, I am not sure if I am mailing this issue to the correct mailing lists. If not, please let me know where it should be directed. We are trying to implement the OCL constraint evaluator for UML models. In the process of reading specs, I found the issue described below and am stuck. There is an clash/mismatch between the UML2.0 and OCL2.0 specs on constraint semantics. The UML superstructure doc 05-07-04, chapter 7.3.10 states, that Constraint has context and constrainedElement associations(properties). The Semantic section of the paragraph states, that the context property of the constraint is used in OCL constraint evaluation as a "self". However the OCL2.0 specification doc 05-06-06, chapter 12 specifies different rules, how OCL expressions are evaluated in the UML models. In most cases it is mandated that the self (a.k.a. contextual classifier) should be derived from the constrainedElement property. In particular, for most common case - invariant constraints, 12.6, 12.6.1 paragraphs state, that the contextual classifier should be the classifier, specified by the constrainedElement property: contextualClassifier = self.constraint.constrainedElement->any(true).oclAsType(Classifier) The other conditions are irrelevant for the issue at hand: constraint should have <> stereotype (self.constraint.stereotype.name = ?invariant?) constraint.constrainedElement should have a single element (self.constraint.constrainedElement->size() = 1) constraint.constrainedElement should be classifier (self.constraint.constrainedElement.any(true).oclIsKindOf(Classifier)) expression result should be boolean (self.bodyExpression.type.name = ?Boolean?) So we have a conflicting specs here. Which one of these is correct? I am inclined to believe, that the OCL spec, being more concrete, is correct - UML spec mentions the usage of "self" only casually, in one sentence. However if this true, what is the meaning of the context property of the constraint in the UML? It seams that this property is then unnecessary and not used (at least for OCL constraints) anywhere... Note that the upcoming UML2.1 superstructure spec, 06-04-02, introduces small changes to the context property of the constraint. Context is now changed to subset namespace. However the issue, described above, is not mitigated and is still present in 2.1. -- Tomas Juknevicius Senior Programmer No Magic Lithuanian Development Center Savanoriu 363-IVa., LT-49425, Kaunas Phone: +370-37-324032; Fax: +370-37-320670 e-mail: Tomas_dot_Juknevicius_at_nomagic_dot_com WWW: http://www.nomagic.com Subject: RE: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement Date: Thu, 18 May 2006 12:37:30 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement Thread-Index: AcZ6p36ZlX50iwl1RIKx9sn9mhUlrAACrZqw From: "Karl Frank" To: "Tomas Juknevicius" , , X-OriginalArrivalTime: 18 May 2006 19:37:32.0478 (UTC) FILETIME=[81A995E0:01C67AB2] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k4IJQlYv020788 imo, For OCL, the OCL spec trumps any other spec. It is a defect in the UML spec to try to specify OCL and this should be an issue for the next UML revision. - Karl Frank -----Original Message----- From: Tomas Juknevicius [mailto:TomasJkn@nomagic.com] Sent: Thursday, May 18, 2006 2:12 PM To: ocl2-rtf@omg.org; uml2-rtf@omg.org Subject: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement Hello, I am not sure if I am mailing this issue to the correct mailing lists. If not, please let me know where it should be directed. We are trying to implement the OCL constraint evaluator for UML models. In the process of reading specs, I found the issue described below and am stuck. There is an clash/mismatch between the UML2.0 and OCL2.0 specs on constraint semantics. The UML superstructure doc 05-07-04, chapter 7.3.10 states, that Constraint has context and constrainedElement associations(properties). The Semantic section of the paragraph states, that the context property of the constraint is used in OCL constraint evaluation as a "self". However the OCL2.0 specification doc 05-06-06, chapter 12 specifies different rules, how OCL expressions are evaluated in the UML models. In most cases it is mandated that the self (a.k.a. contextual classifier) should be derived from the constrainedElement property. In particular, for most common case - invariant constraints, 12.6, 12.6.1 paragraphs state, that the contextual classifier should be the classifier, specified by the constrainedElement property: contextualClassifier = self.constraint.constrainedElement->any(true).oclAsType(Classifier) The other conditions are irrelevant for the issue at hand: constraint should have <> stereotype (self.constraint.stereotype.name = ?invariant?) constraint.constrainedElement should have a single element (self.constraint.constrainedElement->size() = 1) constraint.constrainedElement should be classifier (self.constraint.constrainedElement.any(true).oclIsKindOf(Classifier)) expression result should be boolean (self.bodyExpression.type.name = ?Boolean?) So we have a conflicting specs here. Which one of these is correct? I am inclined to believe, that the OCL spec, being more concrete, is correct - UML spec mentions the usage of "self" only casually, in one sentence. However if this true, what is the meaning of the context property of the constraint in the UML? It seams that this property is then unnecessary and not used (at least for OCL constraints) anywhere... Note that the upcoming UML2.1 superstructure spec, 06-04-02, introduces small changes to the context property of the constraint. Context is now changed to subset namespace. However the issue, described above, is not mitigated and is still present in 2.1. -- Tomas Juknevicius Senior Programmer No Magic Lithuanian Development Center Savanoriu 363-IVa., LT-49425, Kaunas Phone: +370-37-324032; Fax: +370-37-320670 e-mail: Tomas_dot_Juknevicius_at_nomagic_dot_com WWW: http://www.nomagic.com X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 18 May 2006 16:58:20 -0400 To: Tomas Juknevicius , ocl2-rtf@omg.org, uml2-rtf@omg.org From: Juergen Boldt Subject: Re: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement FOlks, where should I log this issue? -Juergen At 02:11 PM 5/18/2006, Tomas Juknevicius wrote: Hello, I am not sure if I am mailing this issue to the correct mailing lists. If not, please let me know where it should be directed. We are trying to implement the OCL constraint evaluator for UML models. In the process of reading specs, I found the issue described below and am stuck. There is an clash/mismatch between the UML2.0 and OCL2.0 specs on constraint semantics. The UML superstructure doc 05-07-04, chapter 7.3.10 states, that Constraint has context and constrainedElement associations(properties). The Semantic section of the paragraph states, that the context property of the constraint is used in OCL constraint evaluation as a "self". However the OCL2.0 specification doc 05-06-06, chapter 12 specifies different rules, how OCL expressions are evaluated in the UML models. In most cases it is mandated that the self (a.k.a. contextual classifier) should be derived from the constrainedElement property. In particular, for most common case - invariant constraints, 12.6, 12.6.1 paragraphs state, that the contextual classifier should be the classifier, specified by the constrainedElement property: contextualClassifier = self.constraint.constrainedElement->any(true).oclAsType(Classifier) The other conditions are irrelevant for the issue at hand: constraint should have <> stereotype (self.constraint.stereotype.name = ?invariant?) constraint.constrainedElement should have a single element (self.constraint.constrainedElement->size() = 1) constraint.constrainedElement should be classifier (self.constraint.constrainedElement.any(true).oclIsKindOf(Classifier)) expression result should be boolean (self.bodyExpression.type.name = ?Boolean?) So we have a conflicting specs here. Which one of these is correct? I am inclined to believe, that the OCL spec, being more concrete, is correct - UML spec mentions the usage of "self" only casually, in one sentence. However if this true, what is the meaning of the context property of the constraint in the UML? It seams that this property is then unnecessary and not used (at least for OCL constraints) anywhere... Note that the upcoming UML2.1 superstructure spec, 06-04-02, introduces small changes to the context property of the constraint. Context is now changed to subset namespace. However the issue, described above, is not mitigated and is still present in 2.1. -- Tomas Juknevicius Senior Programmer No Magic Lithuanian Development Center Savanoriu 363-IVa., LT-49425, Kaunas Phone: .37-324032; Fax: .37-320670 e-mail: Tomas_dot_Juknevicius_at_nomagic_dot_com WWW: http://www.nomagic.com Juergen Boldt Director, Member Services 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: 781 444 0404 x 132 fax: 781 444 0320 email: juergen@omg.org www.omg.org Subject: RE: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement Date: Thu, 18 May 2006 14:01:13 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement Thread-Index: AcZ6vdh+fyAvcAPCQVGojayLEx2eMwAABx+w From: "Karl Frank" To: "Juergen Boldt" , "Tomas Juknevicius" , , X-OriginalArrivalTime: 18 May 2006 21:01:14.0948 (UTC) FILETIME=[3349B040:01C67ABE] imo the OCL spec is clear and consistent. The problem is with the UML 2 spec. - Karl -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, May 18, 2006 4:58 PM To: Tomas Juknevicius; ocl2-rtf@omg.org; uml2-rtf@omg.org Subject: Re: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement FOlks, where should I log this issue? -Juergen At 02:11 PM 5/18/2006, Tomas Juknevicius wrote: Hello, I am not sure if I am mailing this issue to the correct mailing lists. If not, please let me know where it should be directed. We are trying to implement the OCL constraint evaluator for UML models. In the process of reading specs, I found the issue described below and am stuck. There is an clash/mismatch between the UML2.0 and OCL2.0 specs on constraint semantics. The UML superstructure doc 05-07-04, chapter 7.3.10 states, that Constraint has context and constrainedElement associations(properties). The Semantic section of the paragraph states, that the context property of the constraint is used in OCL constraint evaluation as a "self". However the OCL2.0 specification doc 05-06-06, chapter 12 specifies different rules, how OCL expressions are evaluated in the UML models. In most cases it is mandated that the self (a.k.a. contextual classifier) should be derived from the constrainedElement property. In particular, for most common case - invariant constraints, 12.6, 12.6.1 paragraphs state, that the contextual classifier should be the classifier, specified by the constrainedElement property: contextualClassifier = self.constraint.constrainedElement->any(true).oclAsType(Classifier) The other conditions are irrelevant for the issue at hand: constraint should have <> stereotype (self.constraint.stereotype.name = ?invariant?) constraint.constrainedElement should have a single element (self.constraint.constrainedElement->size() = 1) constraint.constrainedElement should be classifier (self.constraint.constrainedElement.any(true).oclIsKindOf(Classifier)) expression result should be boolean (self.bodyExpression.type.name = ?Boolean?) So we have a conflicting specs here. Which one of these is correct? I am inclined to believe, that the OCL spec, being more concrete, is correct - UML spec mentions the usage of "self" only casually, in one sentence. However if this true, what is the meaning of the context property of the constraint in the UML? It seams that this property is then unnecessary and not used (at least for OCL constraints) anywhere... Note that the upcoming UML2.1 superstructure spec, 06-04-02, introduces small changes to the context property of the constraint. Context is now changed to subset namespace. However the issue, described above, is not mitigated and is still present in 2.1. -- Tomas Juknevicius Senior Programmer No Magic Lithuanian Development Center Savanoriu 363-IVa., LT-49425, Kaunas Phone: +370-37-324032; Fax: +370-37-320670 e-mail: Tomas_dot_Juknevicius_at_nomagic_dot_com WWW: http://www.nomagic.com Juergen Boldt Director, Member Services 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 To: "Karl Frank" Cc: "Juergen Boldt" , ocl2-rtf@omg.org, "Tomas Juknevicius" , uml2-rtf@omg.org Subject: RE: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 18 May 2006 17:12:19 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 05/18/2006 17:12:20, Serialize complete at 05/18/2006 17:12:20 I am not so sure, Karl. The UML 2 spec only mentions OCL as an example of a constraint language and how it might be used -- there is nothing normative here. OTOH, following a quick review of the OCL spec, there is some stuff here that I just noticed for the first time: it talks about constraints having stereotypes, which implies some kind of profile -- which is not defined anywhere as far as I can tell. Or, it might be the old confusion between keywords and stereotype labels. This looks like a pretty serious bug in the definition of OCL. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Karl Frank" 05/18/2006 05:01 PM To "Juergen Boldt" , "Tomas Juknevicius" , , cc Subject RE: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement imo the OCL spec is clear and consistent. The problem is with the UML 2 spec. - Karl -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, May 18, 2006 4:58 PM To: Tomas Juknevicius; ocl2-rtf@omg.org; uml2-rtf@omg.org Subject: Re: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement FOlks, where should I log this issue? -Juergen At 02:11 PM 5/18/2006, Tomas Juknevicius wrote: Hello, I am not sure if I am mailing this issue to the correct mailing lists. If not, please let me know where it should be directed. We are trying to implement the OCL constraint evaluator for UML models. In the process of reading specs, I found the issue described below and am stuck. There is an clash/mismatch between the UML2.0 and OCL2.0 specs on constraint semantics. The UML superstructure doc 05-07-04, chapter 7.3.10 states, that Constraint has context and constrainedElement associations(properties). The Semantic section of the paragraph states, that the context property of the constraint is used in OCL constraint evaluation as a "self". However the OCL2.0 specification doc 05-06-06, chapter 12 specifies different rules, how OCL expressions are evaluated in the UML models. In most cases it is mandated that the self (a.k.a. contextual classifier) should be derived from the constrainedElement property. In particular, for most common case - invariant constraints, 12.6, 12.6.1 paragraphs state, that the contextual classifier should be the classifier, specified by the constrainedElement property: contextualClassifier = self.constraint.constrainedElement->any(true).oclAsType(Classifier) The other conditions are irrelevant for the issue at hand: constraint should have <> stereotype (self.constraint.stereotype.name = ?invariant?) constraint.constrainedElement should have a single element (self.constraint.constrainedElement->size() = 1) constraint.constrainedElement should be classifier (self.constraint.constrainedElement.any(true).oclIsKindOf(Classifier)) expression result should be boolean (self.bodyExpression.type.name = ?Boolean?) So we have a conflicting specs here. Which one of these is correct? I am inclined to believe, that the OCL spec, being more concrete, is correct - UML spec mentions the usage of "self" only casually, in one sentence. However if this true, what is the meaning of the context property of the constraint in the UML? It seams that this property is then unnecessary and not used (at least for OCL constraints) anywhere... Note that the upcoming UML2.1 superstructure spec, 06-04-02, introduces small changes to the context property of the constraint. Context is now changed to subset namespace. However the issue, described above, is not mitigated and is still present in 2.1. -- Tomas Juknevicius Senior Programmer No Magic Lithuanian Development Center Savanoriu 363-IVa., LT-49425, Kaunas Phone: +370-37-324032; Fax: +370-37-320670 e-mail: Tomas_dot_Juknevicius_at_nomagic_dot_com WWW: http://www.nomagic.com Juergen Boldt Director, Member Services 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 Subject: RE: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement Date: Thu, 18 May 2006 14:15:38 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement Thread-Index: AcZ6v8GX9o/BP5SJQzKQR0t5skhFrAAABdow From: "Karl Frank" To: "Branislav Selic" Cc: "Juergen Boldt" , , "Tomas Juknevicius" , X-OriginalArrivalTime: 18 May 2006 21:15:39.0405 (UTC) FILETIME=[368B5BD0:01C67AC0] I have no objection to filing Tomas' issue with both specs. But aren't you (BRan) now raising a new issue of your own wirt stereotypes? I wasn't saying the OCL spec had no bugs, just that it seems clear in respect of Tomas' point. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, May 18, 2006 5:12 PM To: Karl Frank Cc: Juergen Boldt; ocl2-rtf@omg.org; Tomas Juknevicius; uml2-rtf@omg.org Subject: RE: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement I am not so sure, Karl. The UML 2 spec only mentions OCL as an example of a constraint language and how it might be used -- there is nothing normative here. OTOH, following a quick review of the OCL spec, there is some stuff here that I just noticed for the first time: it talks about constraints having stereotypes, which implies some kind of profile -- which is not defined anywhere as far as I can tell. Or, it might be the old confusion between keywords and stereotype labels. This looks like a pretty serious bug in the definition of OCL. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Karl Frank" 05/18/2006 05:01 PM To "Juergen Boldt" , "Tomas Juknevicius" , , cc Subject RE: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement imo the OCL spec is clear and consistent. The problem is with the UML 2 spec. - Karl -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, May 18, 2006 4:58 PM To: Tomas Juknevicius; ocl2-rtf@omg.org; uml2-rtf@omg.org Subject: Re: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement FOlks, where should I log this issue? -Juergen At 02:11 PM 5/18/2006, Tomas Juknevicius wrote: Hello, I am not sure if I am mailing this issue to the correct mailing lists. If not, please let me know where it should be directed. We are trying to implement the OCL constraint evaluator for UML models. In the process of reading specs, I found the issue described below and am stuck. There is an clash/mismatch between the UML2.0 and OCL2.0 specs on constraint semantics. The UML superstructure doc 05-07-04, chapter 7.3.10 states, that Constraint has context and constrainedElement associations(properties). The Semantic section of the paragraph states, that the context property of the constraint is used in OCL constraint evaluation as a "self". However the OCL2.0 specification doc 05-06-06, chapter 12 specifies different rules, how OCL expressions are evaluated in the UML models. In most cases it is mandated that the self (a.k.a. contextual classifier) should be derived from the constrainedElement property. In particular, for most common case - invariant constraints, 12.6, 12.6.1 paragraphs state, that the contextual classifier should be the classifier, specified by the constrainedElement property: contextualClassifier = self.constraint.constrainedElement->any(true).oclAsType(Classifier) The other conditions are irrelevant for the issue at hand: constraint should have <> stereotype (self.constraint.stereotype.name = ?invariant?) constraint.constrainedElement should have a single element (self.constraint.constrainedElement->size() = 1) constraint.constrainedElement should be classifier (self.constraint.constrainedElement.any(true).oclIsKindOf(Classifier)) expression result should be boolean (self.bodyExpression.type.name = ?Boolean?) So we have a conflicting specs here. Which one of these is correct? I am inclined to believe, that the OCL spec, being more concrete, is correct - UML spec mentions the usage of "self" only casually, in one sentence. However if this true, what is the meaning of the context property of the constraint in the UML? It seams that this property is then unnecessary and not used (at least for OCL constraints) anywhere... Note that the upcoming UML2.1 superstructure spec, 06-04-02, introduces small changes to the context property of the constraint. Context is now changed to subset namespace. However the issue, described above, is not mitigated and is still present in 2.1. -- Tomas Juknevicius Senior Programmer No Magic Lithuanian Development Center Savanoriu 363-IVa., LT-49425, Kaunas Phone: +370-37-324032; Fax: +370-37-320670 e-mail: Tomas_dot_Juknevicius_at_nomagic_dot_com WWW: http://www.nomagic.com Juergen Boldt Director, Member Services 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 www.omg.org To: "Karl Frank" Cc: "Juergen Boldt" , ocl2-rtf@omg.org, "Tomas Juknevicius" , uml2-rtf@omg.org Subject: RE: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 18 May 2006 17:20:51 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 05/18/2006 17:20:52, Serialize complete at 05/18/2006 17:20:52 I was indeed raising a separate OCL issue (a major one, I believe), but I was also saying that there is no real issue with the UML 2 spec. In fact, if you think about it, there is nothing to prevent constrainedElement and context from being the same object. There is no real contradiction here. Bran "Karl Frank" 05/18/2006 05:15 PM To Branislav Selic/Ottawa/IBM@IBMCA cc "Juergen Boldt" , , "Tomas Juknevicius" , Subject RE: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement I have no objection to filing Tomas' issue with both specs. But aren't you (BRan) now raising a new issue of your own wirt stereotypes? I wasn't saying the OCL spec had no bugs, just that it seems clear in respect of Tomas' point. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, May 18, 2006 5:12 PM To: Karl Frank Cc: Juergen Boldt; ocl2-rtf@omg.org; Tomas Juknevicius; uml2-rtf@omg.org Subject: RE: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement I am not so sure, Karl. The UML 2 spec only mentions OCL as an example of a constraint language and how it might be used -- there is nothing normative here. OTOH, following a quick review of the OCL spec, there is some stuff here that I just noticed for the first time: it talks about constraints having stereotypes, which implies some kind of profile -- which is not defined anywhere as far as I can tell. Or, it might be the old confusion between keywords and stereotype labels. This looks like a pretty serious bug in the definition of OCL. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Karl Frank" 05/18/2006 05:01 PM To "Juergen Boldt" , "Tomas Juknevicius" , , cc Subject RE: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement imo the OCL spec is clear and consistent. The problem is with the UML 2 spec. - Karl -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, May 18, 2006 4:58 PM To: Tomas Juknevicius; ocl2-rtf@omg.org; uml2-rtf@omg.org Subject: Re: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement FOlks, where should I log this issue? -Juergen At 02:11 PM 5/18/2006, Tomas Juknevicius wrote: Hello, I am not sure if I am mailing this issue to the correct mailing lists. If not, please let me know where it should be directed. We are trying to implement the OCL constraint evaluator for UML models. In the process of reading specs, I found the issue described below and am stuck. There is an clash/mismatch between the UML2.0 and OCL2.0 specs on constraint semantics. The UML superstructure doc 05-07-04, chapter 7.3.10 states, that Constraint has context and constrainedElement associations(properties). The Semantic section of the paragraph states, that the context property of the constraint is used in OCL constraint evaluation as a "self". However the OCL2.0 specification doc 05-06-06, chapter 12 specifies different rules, how OCL expressions are evaluated in the UML models. In most cases it is mandated that the self (a.k.a. contextual classifier) should be derived from the constrainedElement property. In particular, for most common case - invariant constraints, 12.6, 12.6.1 paragraphs state, that the contextual classifier should be the classifier, specified by the constrainedElement property: contextualClassifier = self.constraint.constrainedElement->any(true).oclAsType(Classifier) The other conditions are irrelevant for the issue at hand: constraint should have <> stereotype (self.constraint.stereotype.name = ?invariant?) constraint.constrainedElement should have a single element (self.constraint.constrainedElement->size() = 1) constraint.constrainedElement should be classifier (self.constraint.constrainedElement.any(true).oclIsKindOf(Classifier)) expression result should be boolean (self.bodyExpression.type.name = ?Boolean?) So we have a conflicting specs here. Which one of these is correct? I am inclined to believe, that the OCL spec, being more concrete, is correct - UML spec mentions the usage of "self" only casually, in one sentence. However if this true, what is the meaning of the context property of the constraint in the UML? It seams that this property is then unnecessary and not used (at least for OCL constraints) anywhere... Note that the upcoming UML2.1 superstructure spec, 06-04-02, introduces small changes to the context property of the constraint. Context is now changed to subset namespace. However the issue, described above, is not mitigated and is still present in 2.1. -- Tomas Juknevicius Senior Programmer No Magic Lithuanian Development Center Savanoriu 363-IVa., LT-49425, Kaunas Phone: +370-37-324032; Fax: +370-37-320670 e-mail: Tomas_dot_Juknevicius_at_nomagic_dot_com WWW: http://www.nomagic.com Juergen Boldt Director, Member Services 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