Issue 10413: Constraint.context vs Constraint.constrainedElement (uml2-rtf) Source: No Magic, Inc. (Mr. Tomas Juknevicius, tomas.juknevicius(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: The situation is now more-or-less clear. We will use a variant specified OCL spec for evaluating OCL constraints. However in my humble opinion, UML spec could also benefit if the descriptions of context and constrainedElement were clarrified a bit on how one should use them. As Karl correctly notes, when 2 properties can be used to specify the same thing, this introduces ambiguities in the model. Even if "nothing prevents the context and constrainedElement from beeing the same object", on the other hand nothing prevents these 2 from beeing different objects. Hence if author produces some UML model with constraints where constrainedElement!=context, the readers of this model cannot interpret it unambiguously. And I can imagine many cases, where constrainedElement will not be equal to context. For example if constraints are placed in a separate package from their constrained elements (perhaps constrained elements are in a separate, read-only library and constraints can not be added there; or for other packaging reasons). In this case context of these constraints will be their owner package (per UML2.1 rules) and constrainedElement will be completely unrelated to it. PS And this applies not only in the narrow case of constraints, specified in OCL. Almost all other languages need contextual information. For the sake of argument, lets say the constraint is specified in English language. Well, it so happens, that English language also needs some context to interpret sentences. The pronouns, such as "this", "these" or "such", can play the same role in English as the "self" variable in OCL. E.g. Imagine the constraint with specification=OpaqueExpression{language=English; body="these must be yellow"} placed into the class Box, having property contents:Apple[*] and constrainedElement pointing to this property. Now there is an ambiguity. If the constraint.context field is used for interpretting the phrase "these must be yellow" then the boxes must be yellow. If the constraint.constrainedElement is used, then apples in the box must be yellow. > Karl Frank wrote: > > Agreed. But imo it is a defect for the same thing to be specified in two equivalent ways. EVen if the context is by definition the constrained element, in the case of a > constraint, it remains an opening for confusion and doubt to specify it using different terms even when equivalent. > > But context means something different in regard to a behavior, so I believe constrainedElement is the right term, which is the one used in the OCL spec. > > - Karl > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Thursday, May 18, 2006 5:21 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 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 Resolution: Revised Text: Actions taken: May 22, 2006: received issue Discussion: End of Annotations:===== te: Mon, 22 May 2006 11:25:30 +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: Re: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement X-Virus-Scanned: ClamAV 0.88.2/1475/Mon May 22 08:09:26 2006 on banginis X-Virus-Status: Clean Ok, The situation is now more-or-less clear. We will use a variant specified OCL spec for evaluating OCL constraints. However in my humble opinion, UML spec could also benefit if the descriptions of context and constrainedElement were clarrified a bit on how one should use them. As Karl correctly notes, when 2 properties can be used to specify the same thing, this introduces ambiguities in the model. Even if "nothing prevents the context and constrainedElement from beeing the same object", on the other hand nothing prevents these 2 from beeing different objects. Hence if author produces some UML model with constraints where constrainedElement!=context, the readers of this model cannot interpret it unambiguously. And I can imagine many cases, where constrainedElement will not be equal to context. For example if constraints are placed in a separate package from their constrained elements (perhaps constrained elements are in a separate, read-only library and constraints can not be added there; or for other packaging reasons). In this case context of these constraints will be their owner package (per UML2.1 rules) and constrainedElement will be completely unrelated to it. PS And this applies not only in the narrow case of constraints, specified in OCL. Almost all other languages need contextual information. For the sake of argument, lets say the constraint is specified in English language. Well, it so happens, that English language also needs some context to interpret sentences. The pronouns, such as "this", "these" or "such", can play the same role in English as the "self" variable in OCL. E.g. Imagine the constraint with specification=OpaqueExpression{language=English; body="these must be yellow"} placed into the class Box, having property contents:Apple[*] and constrainedElement pointing to this property. Now there is an ambiguity. If the constraint.context field is used for interpretting the phrase "these must be yellow" then the boxes must be yellow. If the constraint.constrainedElement is used, then apples in the box must be yellow. > Karl Frank wrote: > > Agreed. But imo it is a defect for the same thing to be specified in two equivalent ways. EVen if the context is by definition the constrained element, in the case of a > constraint, it remains an opening for confusion and doubt to specify it using different terms even when equivalent. > > But context means something different in regard to a behavior, so I believe constrainedElement is the right term, which is the one used in the OCL spec. > > - Karl > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Thursday, May 18, 2006 5:21 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 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 > -- 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 Subject: RE: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement Date: Thu, 18 May 2006 14:26:03 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement Thread-Index: AcZ6wPJ+bL8pxEibQLyEfaw13YHImgAAEMHQ From: "Karl Frank" To: "Branislav Selic" Cc: "Juergen Boldt" , , "Tomas Juknevicius" , X-OriginalArrivalTime: 18 May 2006 21:26:05.0520 (UTC) FILETIME=[ABBCED00:01C67AC1] Agreed. But imo it is a defect for the same thing to be specified in two equivalent ways. EVen if the context is by definition the constrained element, in the case of a constraint, it remains an opening for confusion and doubt to specify it using different terms even when equivalent. But context means something different in regard to a behavior, so I believe constrainedElement is the right term, which is the one used in the OCL spec. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, May 18, 2006 5:21 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 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 WWW: http://www.nomagic.com