Issue 15768: Wrong constraint on Operation::bodyCondition (uml2-rtf) Source: (Dr. Maged Elaasar, melaasar(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: The spec says: bodyCondition: Constraint[0..1] An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule couple this with: The bodyCondition for an operation constrains the return result. The bodyCondition differs from postconditions in that the bodyCondition may be overridden when an operation is redefined, whereas postconditions can only be added during redefinition. Also, in the current MM, the defined operations logic is implemented as a body Condition. Therefore, the bodyCondition is not an invariant, but rather a condition that describes the return result. of an operation Since a non-query operation can also have a return result, I see no reason to prevent a body condition on it. Resolution: Revised Text: Actions taken: October 15, 2010: received issue Discussion: End of Annotations:===== ubject: Non query operation with body condition To: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Fri, 15 Oct 2010 14:50:43 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/15/2010 14:50:44 Hi All, Can some body explain why this constraint in 7.3.37 Operation makes sense? [7]A bodyCondition can only be specified for a query operation. bodyCondition->notEmpty() implies isQuery Why cannot I define an non-query operation, i.e. one with side effects, that has a return type and specify a condition on the result of this operation? Maged Subject: Re: Non query operation with body condition To: Maged Elaasar Cc: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Tue, 19 Oct 2010 14:29:36 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/19/2010 14:29:37 Any opinions on this one? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 10/15/2010 02:50 PM To uml2-rtf@omg.org cc Subject Non query operation with body condition Hi All, Can some body explain why this constraint in 7.3.37 Operation makes sense? [7]A bodyCondition can only be specified for a query operation. bodyCondition->notEmpty() implies isQuery Why cannot I define an non-query operation, i.e. one with side effects, that has a return type and specify a condition on the result of this operation? Maged pic05705.gif From: Steve Cook To: Maged Elaasar CC: "uml2-rtf@omg.org" Subject: RE: Non query operation with body condition Thread-Topic: Non query operation with body condition Thread-Index: AQHLbJpGZJzSnNJF/karASScTtZINZNIjTEAgAAWVpA= Date: Tue, 19 Oct 2010 18:53:08 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.166.20.234] I cannot explain it. Maybe one of the UML archeologists might remember? The only difference between a bodyCondition and a postCondition is that a bodyCondition can be redefined. So you might say that the body defines how to achieve the postcondition. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 19 October 2010 19:30 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: Non query operation with body condition Any opinions on this one? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 10/15/2010 02:50 PM To uml2-rtf@omg.org cc Subject Non query operation with body condition Hi All, Can some body explain why this constraint in 7.3.37 Operation makes sense? [7]A bodyCondition can only be specified for a query operation. bodyCondition->notEmpty() implies isQuery Why cannot I define an non-query operation, i.e. one with side effects, that has a return type and specify a condition on the result of this operation? Maged From: "Rouquette, Nicolas F (316A)" To: Steve Cook CC: Maged Elaasar , "uml2-rtf@omg.org" Date: Wed, 20 Oct 2010 09:39:00 -0700 Subject: Re: Non query operation with body condition Thread-Topic: Non query operation with body condition Thread-Index: ActwdU1FmN0jhipXQDu4sWeN4vhgLg== 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 Whether this constraint makes sense or not depends on how you interpret the language in clause 6.4.2 about the use of OCL in the UML specification: . .Additional Operations. contains a numerical list of operations that are applicable to the concept. These may be queries or utility operations that are used to define constraints or other operations. Where possible, operations are specified using OCL. If you follow current (undocumented) practices, then the constraint makes sense because an operation body constraint is an OCL expression that, by definition, must be side-effects free. However, if the UML specification were to embrace the OCL specification, then we'd specify a operation in UML using the full capabilities OCL provides: - operation context (OCL clause 12.12) - invariants (OCL clause 12.6) - pre/post condition (OCL clause 12.7) - invariant (OCL clause 12.10) So, to answer your question: - if you follow UML 6.4.2, then 7.3.37 [7] makes sense. - if you specify the operation in OCL instead of UML, then 7.3.37[7] is irrelevant and you're free to include pre/post/invariant conditions. - Nicolas. On Oct 19, 2010, at 11:53 AM, Steve Cook wrote: I cannot explain it. Maybe one of the UML archeologists might remember? The only difference between a bodyCondition and a postCondition is that a bodyCondition can be redefined. So you might say that the body defines how to achieve the postcondition. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 19 October 2010 19:30 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: Non query operation with body condition Any opinions on this one? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 10/15/2010 02:50 PM To uml2-rtf@omg.org cc Subject Non query operation with body condition Hi All, Can some body explain why this constraint in 7.3.37 Operation makes sense? [7]A bodyCondition can only be specified for a query operation. bodyCondition->notEmpty() implies isQuery Why cannot I define an non-query operation, i.e. one with side effects, that has a return type and specify a condition on the result of this operation? Maged Subject: Re: Non query operation with body condition To: "Rouquette, Nicolas F (316A)" Cc: Steve Cook , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 20 Oct 2010 13:00:55 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/20/2010 13:01:05 Nic, the constraints included in the class descriptions of UML is meant to be general, not specific to the UML MM, i.e not documenting a convention. My point is that the body condition is a condition on the result of the operation; most widely intrepreted as the way to calculate the result. However, nothing says that the operation could have side effects from other logic and still return a result, described by that body condition. In light of this, I don't see why I cannot specify a body condition on a non-query operation. "Rouquette, Nicolas F (316A)" "Rouquette, Nicolas F (316A)" 10/20/2010 12:39 PM To Steve Cook cc Maged Elaasar/Ottawa/IBM@IBMCA, "uml2-rtf@omg.org" Subject Re: Non query operation with body condition Whether this constraint makes sense or not depends on how you interpret the language in clause 6.4.2 about the use of OCL in the UML specification: . .Additional Operations. contains a numerical list of operations that are applicable to the concept. These may be queries or utility operations that are used to define constraints or other operations. Where possible, operations are specified using OCL. If you follow current (undocumented) practices, then the constraint makes sense because an operation body constraint is an OCL expression that, by definition, must be side-effects free. However, if the UML specification were to embrace the OCL specification, then we'd specify a operation in UML using the full capabilities OCL provides: - operation context (OCL clause 12.12) - invariants (OCL clause 12.6) - pre/post condition (OCL clause 12.7) - invariant (OCL clause 12.10) So, to answer your question: - if you follow UML 6.4.2, then 7.3.37 [7] makes sense. - if you specify the operation in OCL instead of UML, then 7.3.37[7] is irrelevant and you're free to include pre/post/invariant conditions. - Nicolas. On Oct 19, 2010, at 11:53 AM, Steve Cook wrote: I cannot explain it. Maybe one of the UML archeologists might remember? The only difference between a bodyCondition and a postCondition is that a bodyCondition can be redefined. So you might say that the body defines how to achieve the postcondition. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 19 October 2010 19:30 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: Non query operation with body condition Any opinions on this one? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 10/15/2010 02:50 PM To uml2-rtf@omg.org cc Subject Non query operation with body condition Hi All, Can some body explain why this constraint in 7.3.37 Operation makes sense? [7]A bodyCondition can only be specified for a query operation. bodyCondition->notEmpty() implies isQuery Why cannot I define an non-query operation, i.e. one with side effects, that has a return type and specify a condition on the result of this operation? Maged pic31436.gif Subject: Re: Non query operation with body condition To: Maged Elaasar Cc: "Rouquette, Nicolas F (316A)" , Steve Cook , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 20 Oct 2010 13:08:24 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/20/2010 13:08:34 correction... "...However, nothing says that the operation cannot have side effects from other logic and still return a result.." Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 10/20/2010 01:00 PM To "Rouquette, Nicolas F (316A)" cc Steve Cook , "uml2-rtf@omg.org" Subject Re: Non query operation with body condition Nic, the constraints included in the class descriptions of UML is meant to be general, not specific to the UML MM, i.e not documenting a convention. My point is that the body condition is a condition on the result of the operation; most widely intrepreted as the way to calculate the result. However, nothing says that the operation could have side effects from other logic and still return a result, described by that body condition. In light of this, I don't see why I cannot specify a body condition on a non-query operation. "Rouquette, Nicolas F (316A)" "Rouquette, Nicolas F (316A)" 10/20/2010 12:39 PM To Steve Cook cc Maged Elaasar/Ottawa/IBM@IBMCA, "uml2-rtf@omg.org" Subject Re: Non query operation with body condition Whether this constraint makes sense or not depends on how you interpret the language in clause 6.4.2 about the use of OCL in the UML specification: . .Additional Operations. contains a numerical list of operations that are applicable to the concept. These may be queries or utility operations that are used to define constraints or other operations. Where possible, operations are specified using OCL. If you follow current (undocumented) practices, then the constraint makes sense because an operation body constraint is an OCL expression that, by definition, must be side-effects free. However, if the UML specification were to embrace the OCL specification, then we'd specify a operation in UML using the full capabilities OCL provides: - operation context (OCL clause 12.12) - invariants (OCL clause 12.6) - pre/post condition (OCL clause 12.7) - invariant (OCL clause 12.10) So, to answer your question: - if you follow UML 6.4.2, then 7.3.37 [7] makes sense. - if you specify the operation in OCL instead of UML, then 7.3.37[7] is irrelevant and you're free to include pre/post/invariant conditions. - Nicolas. On Oct 19, 2010, at 11:53 AM, Steve Cook wrote: I cannot explain it. Maybe one of the UML archeologists might remember? The only difference between a bodyCondition and a postCondition is that a bodyCondition can be redefined. So you might say that the body defines how to achieve the postcondition. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 19 October 2010 19:30 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: Non query operation with body condition Any opinions on this one? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 10/15/2010 02:50 PM To uml2-rtf@omg.org cc Subject Non query operation with body condition Hi All, Can some body explain why this constraint in 7.3.37 Operation makes sense? [7]A bodyCondition can only be specified for a query operation. bodyCondition->notEmpty() implies isQuery Why cannot I define an non-query operation, i.e. one with side effects, that has a return type and specify a condition on the result of this operation? Maged pic08693.gif Date: Wed, 20 Oct 2010 13:57:26 -0400 From: "Chonoles, Michael J" Subject: RE: Ex: Re: Non query operation with body condition To: Maged Elaasar Cc: "Rouquette, Nicolas F (316A)" , Steve Cook , "uml2-rtf@omg.org" Thread-Topic: Ex: Re: Non query operation with body condition Thread-Index: ActweeQhWDMNjWSQQeW5EvisPJwT2gABSKFg Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-20_08:2010-10-20,2010-10-20,1970-01-01 signatures=0 I don.t believe that a body condition is a condition on the result of the operation, that.s what a post condition is for. A body condition is usually a condition that says: .while this operation is being executed/performed, this condition cannot be violated. Of course this could be, in effect, a condition on the result. Here.s a related and illuminating question about the meaning of query in the realm of concurrent behavior. While a query is being executed, can any property of the owner be modified, even if it is reset to the original value when the result is returned. My assumption is that a query does not allow any property to change, even temporarily. If so, then there is no need for Body Conditions on Queries, as such body conditions would be irrelevant (i.e.., because nothing can change or violate any such condition). I believe that is the logic that prevents Body Conditions on queries. I believe the logic in the spec needs to be reversed. [7]A bodyCondition can only be specified for a non-query operation. bodyCondition->notEmpty() implies not(isQuery) Michael Chonoles LM From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, October 20, 2010 1:08 PM To: Maged Elaasar Cc: Rouquette, Nicolas F (316A); Steve Cook; uml2-rtf@omg.org Subject: Ex: Re: Non query operation with body condition correction... "...However, nothing says that the operation cannot have side effects from other logic and still return a result.." Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 10/20/2010 01:00 PM To "Rouquette, Nicolas F (316A)" cc Steve Cook , "uml2-rtf@omg.org" Subject Re: Non query operation with body condition Nic, the constraints included in the class descriptions of UML is meant to be general, not specific to the UML MM, i.e not documenting a convention. My point is that the body condition is a condition on the result of the operation; most widely intrepreted as the way to calculate the result. However, nothing says that the operation could have side effects from other logic and still return a result, described by that body condition. In light of this, I don't see why I cannot specify a body condition on a non-query operation. "Rouquette, Nicolas F (316A)" "Rouquette, Nicolas F (316A)" 10/20/2010 12:39 PM To Steve Cook cc Maged Elaasar/Ottawa/IBM@IBMCA, "uml2-rtf@omg.org" Subject Re: Non query operation with body condition Whether this constraint makes sense or not depends on how you interpret the language in clause 6.4.2 about the use of OCL in the UML specification: . .Additional Operations. contains a numerical list of operations that are applicable to the concept. These may be queries or utility operations that are used to define constraints or other operations. Where possible, operations are specified using OCL. If you follow current (undocumented) practices, then the constraint makes sense because an operation body constraint is an OCL expression that, by definition, must be side-effects free. However, if the UML specification were to embrace the OCL specification, then we'd specify a operation in UML using the full capabilities OCL provides: - operation context (OCL clause 12.12) - invariants (OCL clause 12.6) - pre/post condition (OCL clause 12.7) - invariant (OCL clause 12.10) So, to answer your question: - if you follow UML 6.4.2, then 7.3.37 [7] makes sense. - if you specify the operation in OCL instead of UML, then 7.3.37[7] is irrelevant and you're free to include pre/post/invariant conditions. - Nicolas. On Oct 19, 2010, at 11:53 AM, Steve Cook wrote: I cannot explain it. Maybe one of the UML archeologists might remember? The only difference between a bodyCondition and a postCondition is that a bodyCondition can be redefined. So you might say that the body defines how to achieve the postcondition. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 19 October 2010 19:30 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: Non query operation with body condition Any opinions on this one? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 10/15/2010 02:50 PM To uml2-rtf@omg.org cc Subject Non query operation with body condition Hi All, Can some body explain why this constraint in 7.3.37 Operation makes sense? [7]A bodyCondition can only be specified for a query operation. bodyCondition->notEmpty() implies isQuery Why cannot I define an non-query operation, i.e. one with side effects, that has a return type and specify a condition on the result of this operation? Maged Subject: RE: Ex: Re: Non query operation with body condition To: "Chonoles, Michael J" Cc: "Rouquette, Nicolas F (316A)" , Steve Cook , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 20 Oct 2010 14:05:05 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/20/2010 14:05:06 Michael, That is not what I understand the bodyCondition to mean. The spec says: bodyCondition: Constraint[0..1] An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule couple this with: The bodyCondition for an operation constrains the return result. The bodyCondition differs from postconditions in that the bodyCondition may be overridden when an operation is redefined, whereas postconditions can only be added during redefinition. Also, in the current MM, the defined operations logic is implemented as a body Condition. Therefore, the bodyCondition is not an invariant, but rather a condition that describes the return result. of an operation Since a non-query operation can also have a return result, I see no reason to prevent a body condition on it. Maged "Chonoles, Michael J" "Chonoles, Michael J" 10/20/2010 01:57 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "Rouquette, Nicolas F (316A)" , Steve Cook , "uml2-rtf@omg.org" Subject RE: Ex: Re: Non query operation with body condition I don.t believe that a body condition is a condition on the result of the operation, that.s what a post condition is for. A body condition is usually a condition that says: .while this operation is being executed/performed, this condition cannot be violated. Of course this could be, in effect, a condition on the result. Here.s a related and illuminating question about the meaning of query in the realm of concurrent behavior. While a query is being executed, can any property of the owner be modified, even if it is reset to the original value when the result is returned. My assumption is that a query does not allow any property to change, even temporarily. If so, then there is no need for Body Conditions on Queries, as such body conditions would be irrelevant (i.e.., because nothing can change or violate any such condition). I believe that is the logic that prevents Body Conditions on queries. I believe the logic in the spec needs to be reversed. [7]A bodyCondition can only be specified for a non-query operation. bodyCondition->notEmpty() implies not(isQuery) Michael Chonoles LM From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, October 20, 2010 1:08 PM To: Maged Elaasar Cc: Rouquette, Nicolas F (316A); Steve Cook; uml2-rtf@omg.org Subject: Ex: Re: Non query operation with body condition correction... "...However, nothing says that the operation cannot have side effects from other logic and still return a result.." Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 10/20/2010 01:00 PM To "Rouquette, Nicolas F (316A)" cc Steve Cook , "uml2-rtf@omg.org" Subject Re: Non query operation with body condition Nic, the constraints included in the class descriptions of UML is meant to be general, not specific to the UML MM, i.e not documenting a convention. My point is that the body condition is a condition on the result of the operation; most widely intrepreted as the way to calculate the result. However, nothing says that the operation could have side effects from other logic and still return a result, described by that body condition. In light of this, I don't see why I cannot specify a body condition on a non-query operation. "Rouquette, Nicolas F (316A)" "Rouquette, Nicolas F (316A)" 10/20/2010 12:39 PM To Steve Cook cc Maged Elaasar/Ottawa/IBM@IBMCA, "uml2-rtf@omg.org" Subject Re: Non query operation with body condition Whether this constraint makes sense or not depends on how you interpret the language in clause 6.4.2 about the use of OCL in the UML specification: . .Additional Operations. contains a numerical list of operations that are applicable to the concept. These may be queries or utility operations that are used to define constraints or other operations. Where possible, operations are specified using OCL. If you follow current (undocumented) practices, then the constraint makes sense because an operation body constraint is an OCL expression that, by definition, must be side-effects free. However, if the UML specification were to embrace the OCL specification, then we'd specify a operation in UML using the full capabilities OCL provides: - operation context (OCL clause 12.12) - invariants (OCL clause 12.6) - pre/post condition (OCL clause 12.7) - invariant (OCL clause 12.10) So, to answer your question: - if you follow UML 6.4.2, then 7.3.37 [7] makes sense. - if you specify the operation in OCL instead of UML, then 7.3.37[7] is irrelevant and you're free to include pre/post/invariant conditions. - Nicolas. On Oct 19, 2010, at 11:53 AM, Steve Cook wrote: I cannot explain it. Maybe one of the UML archeologists might remember? The only difference between a bodyCondition and a postCondition is that a bodyCondition can be redefined. So you might say that the body defines how to achieve the postcondition. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 19 October 2010 19:30 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: Non query operation with body condition Any opinions on this one? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 10/15/2010 02:50 PM To uml2-rtf@omg.org cc Subject Non query operation with body condition Hi All, Can some body explain why this constraint in 7.3.37 Operation makes sense? [7]A bodyCondition can only be specified for a query operation. bodyCondition->notEmpty() implies isQuery Why cannot I define an non-query operation, i.e. one with side effects, that has a return type and specify a condition on the result of this operation? Maged pic22965.gif Subject: RE: Ex: Re: Non query operation with body condition To: Maged Elaasar Cc: "Chonoles, Michael J" , "Rouquette, Nicolas F (316A)" , Steve Cook , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 20 Oct 2010 14:06:53 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/20/2010 14:06:55 oh well, another correction: "Therefore, the bodyCondition is not an invariant, but rather a condition that constrains the return result. of an operation" Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 10/20/2010 02:05 PM To "Chonoles, Michael J" cc "Rouquette, Nicolas F (316A)" , Steve Cook , "uml2-rtf@omg.org" Subject RE: Ex: Re: Non query operation with body condition Michael, That is not what I understand the bodyCondition to mean. The spec says: bodyCondition: Constraint[0..1] An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule couple this with: The bodyCondition for an operation constrains the return result. The bodyCondition differs from postconditions in that the bodyCondition may be overridden when an operation is redefined, whereas postconditions can only be added during redefinition. Also, in the current MM, the defined operations logic is implemented as a body Condition. Therefore, the bodyCondition is not an invariant, but rather a condition that describes the return result. of an operation Since a non-query operation can also have a return result, I see no reason to prevent a body condition on it. Maged "Chonoles, Michael J" "Chonoles, Michael J" 10/20/2010 01:57 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "Rouquette, Nicolas F (316A)" , Steve Cook , "uml2-rtf@omg.org" Subject RE: Ex: Re: Non query operation with body condition I don.t believe that a body condition is a condition on the result of the operation, that.s what a post condition is for. A body condition is usually a condition that says: .while this operation is being executed/performed, this condition cannot be violated. Of course this could be, in effect, a condition on the result. Here.s a related and illuminating question about the meaning of query in the realm of concurrent behavior. While a query is being executed, can any property of the owner be modified, even if it is reset to the original value when the result is returned. My assumption is that a query does not allow any property to change, even temporarily. If so, then there is no need for Body Conditions on Queries, as such body conditions would be irrelevant (i.e.., because nothing can change or violate any such condition). I believe that is the logic that prevents Body Conditions on queries. I believe the logic in the spec needs to be reversed. [7]A bodyCondition can only be specified for a non-query operation. bodyCondition->notEmpty() implies not(isQuery) Michael Chonoles LM From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, October 20, 2010 1:08 PM To: Maged Elaasar Cc: Rouquette, Nicolas F (316A); Steve Cook; uml2-rtf@omg.org Subject: Ex: Re: Non query operation with body condition correction... "...However, nothing says that the operation cannot have side effects from other logic and still return a result.." Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 10/20/2010 01:00 PM To "Rouquette, Nicolas F (316A)" cc Steve Cook , "uml2-rtf@omg.org" Subject Re: Non query operation with body condition Nic, the constraints included in the class descriptions of UML is meant to be general, not specific to the UML MM, i.e not documenting a convention. My point is that the body condition is a condition on the result of the operation; most widely intrepreted as the way to calculate the result. However, nothing says that the operation could have side effects from other logic and still return a result, described by that body condition. In light of this, I don't see why I cannot specify a body condition on a non-query operation. "Rouquette, Nicolas F (316A)" "Rouquette, Nicolas F (316A)" 10/20/2010 12:39 PM To Steve Cook cc Maged Elaasar/Ottawa/IBM@IBMCA, "uml2-rtf@omg.org" Subject Re: Non query operation with body condition Whether this constraint makes sense or not depends on how you interpret the language in clause 6.4.2 about the use of OCL in the UML specification: . .Additional Operations. contains a numerical list of operations that are applicable to the concept. These may be queries or utility operations that are used to define constraints or other operations. Where possible, operations are specified using OCL. If you follow current (undocumented) practices, then the constraint makes sense because an operation body constraint is an OCL expression that, by definition, must be side-effects free. However, if the UML specification were to embrace the OCL specification, then we'd specify a operation in UML using the full capabilities OCL provides: - operation context (OCL clause 12.12) - invariants (OCL clause 12.6) - pre/post condition (OCL clause 12.7) - invariant (OCL clause 12.10) So, to answer your question: - if you follow UML 6.4.2, then 7.3.37 [7] makes sense. - if you specify the operation in OCL instead of UML, then 7.3.37[7] is irrelevant and you're free to include pre/post/invariant conditions. - Nicolas. On Oct 19, 2010, at 11:53 AM, Steve Cook wrote: I cannot explain it. Maybe one of the UML archeologists might remember? The only difference between a bodyCondition and a postCondition is that a bodyCondition can be redefined. So you might say that the body defines how to achieve the postcondition. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 19 October 2010 19:30 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: Non query operation with body condition Any opinions on this one? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 10/15/2010 02:50 PM To uml2-rtf@omg.org cc Subject Non query operation with body condition Hi All, Can some body explain why this constraint in 7.3.37 Operation makes sense? [7]A bodyCondition can only be specified for a query operation. bodyCondition->notEmpty() implies isQuery Why cannot I define an non-query operation, i.e. one with side effects, that has a return type and specify a condition on the result of this operation? Maged pic23477.gif pic18746.gif Date: Wed, 20 Oct 2010 14:23:46 -0400 From: "Chonoles, Michael J" Subject: RE: RE: Ex: Re: Non query operation with body condition To: Maged Elaasar Cc: "Rouquette, Nicolas F (316A)" , Steve Cook , "uml2-rtf@omg.org" Thread-Topic: RE: Ex: Re: Non query operation with body condition Thread-Index: ActwgWcFQ2QIL1LsRMaccBR9bxBM6QAAkxVA Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-20_08:2010-10-20,2010-10-20,1970-01-01 signatures=0 Thanks for the clarification. Then, I.m not sure why it.s really needed at all. Sorry Michael From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, October 20, 2010 2:05 PM To: Chonoles, Michael J Cc: Rouquette, Nicolas F (316A); Steve Cook; uml2-rtf@omg.org Subject: RE: Ex: Re: Non query operation with body condition Michael, That is not what I understand the bodyCondition to mean. The spec says: bodyCondition: Constraint[0..1] An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule couple this with: The bodyCondition for an operation constrains the return result. The bodyCondition differs from postconditions in that the bodyCondition may be overridden when an operation is redefined, whereas postconditions can only be added during redefinition. Also, in the current MM, the defined operations logic is implemented as a body Condition. Therefore, the bodyCondition is not an invariant, but rather a condition that describes the return result. of an operation Since a non-query operation can also have a return result, I see no reason to prevent a body condition on it. Maged "Chonoles, Michael J" "Chonoles, Michael J" 10/20/2010 01:57 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "Rouquette, Nicolas F (316A)" , Steve Cook , "uml2-rtf@omg.org" Subject RE: Ex: Re: Non query operation with body condition I don.t believe that a body condition is a condition on the result of the operation, that.s what a post condition is for. A body condition is usually a condition that says: .while this operation is being executed/performed, this condition cannot be violated. Of course this could be, in effect, a condition on the result. Here.s a related and illuminating question about the meaning of query in the realm of concurrent behavior. While a query is being executed, can any property of the owner be modified, even if it is reset to the original value when the result is returned. My assumption is that a query does not allow any property to change, even temporarily. If so, then there is no need for Body Conditions on Queries, as such body conditions would be irrelevant (i.e.., because nothing can change or violate any such condition). I believe that is the logic that prevents Body Conditions on queries. I believe the logic in the spec needs to be reversed. [7]A bodyCondition can only be specified for a non-query operation. bodyCondition->notEmpty() implies not(isQuery) Michael Chonoles LM From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, October 20, 2010 1:08 PM To: Maged Elaasar Cc: Rouquette, Nicolas F (316A); Steve Cook; uml2-rtf@omg.org Subject: Ex: Re: Non query operation with body condition correction... "...However, nothing says that the operation cannot have side effects from other logic and still return a result.." Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 10/20/2010 01:00 PM To "Rouquette, Nicolas F (316A)" cc Steve Cook , "uml2-rtf@omg.org" Subject Re: Non query operation with body condition Nic, the constraints included in the class descriptions of UML is meant to be general, not specific to the UML MM, i.e not documenting a convention. My point is that the body condition is a condition on the result of the operation; most widely intrepreted as the way to calculate the result. However, nothing says that the operation could have side effects from other logic and still return a result, described by that body condition. In light of this, I don't see why I cannot specify a body condition on a non-query operation. "Rouquette, Nicolas F (316A)" "Rouquette, Nicolas F (316A)" 10/20/2010 12:39 PM To Steve Cook cc Maged Elaasar/Ottawa/IBM@IBMCA, "uml2-rtf@omg.org" Subject Re: Non query operation with body condition Whether this constraint makes sense or not depends on how you interpret the language in clause 6.4.2 about the use of OCL in the UML specification: . .Additional Operations. contains a numerical list of operations that are applicable to the concept. These may be queries or utility operations that are used to define constraints or other operations. Where possible, operations are specified using OCL. If you follow current (undocumented) practices, then the constraint makes sense because an operation body constraint is an OCL expression that, by definition, must be side-effects free. However, if the UML specification were to embrace the OCL specification, then we'd specify a operation in UML using the full capabilities OCL provides: - operation context (OCL clause 12.12) - invariants (OCL clause 12.6) - pre/post condition (OCL clause 12.7) - invariant (OCL clause 12.10) So, to answer your question: - if you follow UML 6.4.2, then 7.3.37 [7] makes sense. - if you specify the operation in OCL instead of UML, then 7.3.37[7] is irrelevant and you're free to include pre/post/invariant conditions. - Nicolas. On Oct 19, 2010, at 11:53 AM, Steve Cook wrote: I cannot explain it. Maybe one of the UML archeologists might remember? The only difference between a bodyCondition and a postCondition is that a bodyCondition can be redefined. So you might say that the body defines how to achieve the postcondition. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 19 October 2010 19:30 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: Non query operation with body condition Any opinions on this one? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 10/15/2010 02:50 PM To uml2-rtf@omg.org cc Subject Non query operation with body condition Hi All, Can some body explain why this constraint in 7.3.37 Operation makes sense? [7]A bodyCondition can only be specified for a query operation. bodyCondition->notEmpty() implies isQuery Why cannot I define an non-query operation, i.e. one with side effects, that has a return type and specify a condition on the result of this operation? Maged From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Wed, 20 Oct 2010 14:53:04 -0400 Subject: Re: Non query operation with body condition Thread-Topic: Non query operation with body condition Thread-Index: ActwgWcFQ2QIL1LsRMaccBR9bxBM6QAAkxVAAADZxwA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: elly needed at all. For some reason, it's a variant of post condition that can be redefined in a noncovariant way, as Steve and Maged said. This isn't substitutable for either read or write, so doesn't sound like a good idea. >From the name "body", I'd say Michael is right that it constrains the entire execution of the operation (OCL can constrain messages sent, etc), but the text is fairly explicit about focusing on the result. In either interpretation, Maged is right that limiting it to queries is unnecesssary. Conrad From: Steve Cook To: "Bock, Conrad" , "uml2-rtf@omg.org" Subject: RE: Non query operation with body condition Thread-Topic: Non query operation with body condition Thread-Index: AQHLcIhfBgAcWzy6fEmei9yvGUi+xJNKOB3w Date: Wed, 20 Oct 2010 19:33:39 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.20.234] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o9KJFfUt026137 >noncovariant way, as Steve and Maged said. Well, I said nothing about "noncovariant", because I don't know what it means. Contravariant? Invariant? Completely random? What is varying? I understand these terms when they apply to the types of parameters, but not here. >This isn't substitutable for either read or write, so doesn't sound like a good idea. I don't understand this comment. If an operation's body is redefined in a way that is logically consistent with its pre- and post-conditions, then it is substitutable for clients of the superclass. If it is redefined in a way that is not consistent with its pre- and post-conditions then it is semantically unsound. I have no idea what "substitutable for write" means in these circumstances. >Maged is right that limiting it to queries is unnecesssary. I agree. -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 20 October 2010 19:53 To: uml2-rtf@omg.org Subject: Re: Non query operation with body condition Michael, really needed at all. For some reason, it's a variant of post condition that can be redefined in a noncovariant way, as Steve and Maged said. This isn't substitutable for either read or write, so doesn't sound like a good idea. >From the name "body", I'd say Michael is right that it constrains the entire execution of the operation (OCL can constrain messages sent, etc), but the text is fairly explicit about focusing on the result. In either interpretation, Maged is right that limiting it to queries is unnecesssary. Conrad Date: Wed, 20 Oct 2010 16:05:08 -0400 From: "Chonoles, Michael J" Subject: RE: RE: Non query operation with body condition To: Steve Cook , "Bock, Conrad" , "uml2-rtf@omg.org" Thread-Topic: RE: Non query operation with body condition Thread-Index: AQHLcIhfBgAcWzy6fEmei9yvGUi+xJNKOB3wgAAKSiA= Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-20_08:2010-10-20,2010-10-20,1970-01-01 signatures=0 I suggest we redefine body condition to mean what I thought it meant, and eliminate the restriction, or assuming that query means nothing changes, even while it is running, reverse it, that is prohibit a body condition on a query as being redundant and a potential source of error. Michael -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Wednesday, October 20, 2010 3:34 PM To: Bock, Conrad; uml2-rtf@omg.org Subject: Ex: RE: Non query operation with body condition >noncovariant way, as Steve and Maged said. Well, I said nothing about "noncovariant", because I don't know what it means. Contravariant? Invariant? Completely random? What is varying? I understand these terms when they apply to the types of parameters, but not here. >This isn't substitutable for either read or write, so doesn't sound like a good idea. I don't understand this comment. If an operation's body is redefined in a way that is logically consistent with its pre- and post-conditions, then it is substitutable for clients of the superclass. If it is redefined in a way that is not consistent with its pre- and post-conditions then it is semantically unsound. I have no idea what "substitutable for write" means in these circumstances. >Maged is right that limiting it to queries is unnecesssary. I agree. -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 20 October 2010 19:53 To: uml2-rtf@omg.org Subject: Re: Non query operation with body condition Michael, really needed at all. For some reason, it's a variant of post condition that can be redefined in a noncovariant way, as Steve and Maged said. This isn't substitutable for either read or write, so doesn't sound like a good idea. >From the name "body", I'd say Michael is right that it constrains the entire execution of the operation (OCL can constrain messages sent, etc), but the text is fairly explicit about focusing on the result. In either interpretation, Maged is right that limiting it to queries is unnecesssary. Conrad From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Thu, 21 Oct 2010 14:17:41 -0400 Subject: RE: Non query operation with body condition Thread-Topic: Non query operation with body condition Thread-Index: AQHLcIhfBgAcWzy6fEmei9yvGUi+xJNKOB3wgAF81wA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov Steve, > >noncovariant way, as Steve and Maged said. > Well, I said nothing about "noncovariant", because I don't > know what it means. Contravariant? Invariant? Completely > random? What is varying? I understand these terms when > they apply to the types of parameters, but not here. I meant you pointed out the part of the spec that distinguishes body conditions from post conditions by saying post conditions constraints are only added under redefinition, which is covariant if you take return type as just one kind of constraint on output. > >This isn't substitutable for either read or write, so > doesn't sound like a good idea. > I don't understand this comment. If an operation's body is > redefined in a way that is logically consistent with its pre- and > post-conditions, then it is substitutable for clients of the > superclass. If it is redefined in a way that is not consistent with > its pre- and post-conditions then it is semantically unsound. bodyConstraint is about the return result rather than the body (so either it's named badly or defined badly). > I have no idea what "substitutable for write" means in these > circumstances. Neither do I. :) Return results are "read" by their callers, which expect the value to be of a certain type, so only read substitution applies here. If the purpose of bodyCondition over postCondition is to enable breaking this, I'm not sure it's a good idea. Conrad Subject: RE: Ex: Re: Non query operation with body condition To: Juergen Boldt X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 21 Oct 2010 14:29:31 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/21/2010 14:29:32 Yes please..include this title: Wrong constraint on Operation::bodyCondition description: The spec says: bodyCondition: Constraint[0..1] An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule couple this with: The bodyCondition for an operation constrains the return result. The bodyCondition differs from postconditions in that the bodyCondition may be overridden when an operation is redefined, whereas postconditions can only be added during redefinition. Also, in the current MM, the defined operations logic is implemented as a body Condition. Therefore, the bodyCondition is not an invariant, but rather a condition that describes the return result. of an operation Since a non-query operation can also have a return result, I see no reason to prevent a body condition on it. Juergen Boldt Juergen Boldt 10/20/2010 02:13 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Ex: Re: Non query operation with body condition Maged, should I assign an issue number to this email thread? -Juergen At 02:06 PM 10/20/2010, you wrote: oh well, another correction: "Therefore, the bodyCondition is not an invariant, but rather a condition that constrains the return result. of an operation" Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 10/20/2010 02:05 PM To "Chonoles, Michael J" cc "Rouquette, Nicolas F (316A)" , Steve Cook , "uml2-rtf@omg.org" Subject RE: Ex: Re: Non query operation with body condition Michael, That is not what I understand the bodyCondition to mean. The spec says: bodyCondition: Constraint[0..1] An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule couple this with: The bodyCondition for an operation constrains the return result. The bodyCondition differs from postconditions in that the bodyCondition may be overridden when an operation is redefined, whereas postconditions can only be added during redefinition. Also, in the current MM, the defined operations logic is implemented as a body Condition. Therefore, the bodyCondition is not an invariant, but rather a condition that describes the return result. of an operation Since a non-query operation can also have a return result, I see no reason to prevent a body condition on it. Maged "Chonoles, Michael J" "Chonoles, Michael J" 10/20/2010 01:57 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc "Rouquette, Nicolas F (316A)" , Steve Cook , "uml2-rtf@omg.org" Subject RE: Ex: Re: Non query operation with body condition I don.t believe that a body condition is a condition on the result of the operation, that.s what a post condition is for. A body condition is usually a condition that says: .while this operation is being executed/performed, this condition cannot be violated. Of course this could be, in effect, a condition on the result. Here.s a related and illuminating question about the meaning of query in the realm of concurrent behavior. While a query is being executed, can any property of the owner be modified, even if it is reset to the original value when the result is returned. My assumption is that a query does not allow any property to change, even temporarily. If so, then there is no need for Body Conditions on Queries, as such body conditions would be irrelevant (i.e.., because nothing can change or violate any such condition). I believe that is the logic that prevents Body Conditions on queries. I believe the logic in the spec needs to be reversed. [7]A bodyCondition can only be specified for a non-query operation. bodyCondition->notEmpty() implies not(isQuery) Michael Chonoles LM From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, October 20, 2010 1:08 PM To: Maged Elaasar Cc: Rouquette, Nicolas F (316A); Steve Cook; uml2-rtf@omg.org Subject: Ex: Re: Non query operation with body condition correction... "...However, nothing says that the operation cannot have side effects from other logic and still return a result.." Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 10/20/2010 01:00 PM To "Rouquette, Nicolas F (316A)" cc Steve Cook , "uml2-rtf@omg.org" Subject Re: Non query operation with body condition Nic, the constraints included in the class descriptions of UML is meant to be general, not specific to the UML MM, i.e not documenting a convention. My point is that the body condition is a condition on the result of the operation; most widely intrepreted as the way to calculate the result. However, nothing says that the operation could have side effects from other logic and still return a result, described by that body condition. In light of this, I don't see why I cannot specify a body condition on a non-query operation. "Rouquette, Nicolas F (316A)" "Rouquette, Nicolas F (316A)" 10/20/2010 12:39 PM To Steve Cook cc Maged Elaasar/Ottawa/IBM@IBMCA, "uml2-rtf@omg.org" Subject Re: Non query operation with body condition Whether this constraint makes sense or not depends on how you interpret the language in clause 6.4.2 about the use of OCL in the UML specification: . .Additional Operations. contains a numerical list of operations that are applicable to the concept. These may be queries or utility operations that are used to define constraints or other operations. Where possible, operations are specified using OCL. If you follow current (undocumented) practices, then the constraint makes sense because an operation body constraint is an OCL expression that, by definition, must be side-effects free. However, if the UML specification were to embrace the OCL specification, then we'd specify a operation in UML using the full capabilities OCL provides: - operation context (OCL clause 12.12) - invariants (OCL clause 12.6) - pre/post condition (OCL clause 12.7) - invariant (OCL clause 12.10) So, to answer your question: - if you follow UML 6.4.2, then 7.3.37 [7] makes sense. - if you specify the operation in OCL instead of UML, then 7.3.37[7] is irrelevant and you're free to include pre/post/invariant conditions. - Nicolas. On Oct 19, 2010, at 11:53 AM, Steve Cook wrote: I cannot explain it. Maybe one of the UML archeologists might remember? The only difference between a bodyCondition and a postCondition is that a bodyCondition can be redefined. So you might say that the body defines how to achieve the postcondition. From: Maged Elaasar [ mailto:melaasar@ca.ibm.com] Sent: 19 October 2010 19:30 To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: Re: Non query operation with body condition Any opinions on this one? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 10/15/2010 02:50 PM To uml2-rtf@omg.org cc Subject Non query operation with body condition Hi All, Can some body explain why this constraint in 7.3.37 Operation makes sense? [7]A bodyCondition can only be specified for a query operation. bodyCondition->notEmpty() implies isQuery Why cannot I define an non-query operation, i.e. one with side effects, that has a return type and specify a condition on the result of this operation? Maged 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 pic02256.gif t sure why it > Then, I t sure why it > Then, Ionrad.bock@nist.gov t sure why it Michael, > Then, I