Issue 6362: Side effects of value specifications (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Summary: Clarify whether guards and other value specification can have side effects Resolution: Revised Text: Actions taken: October 20, 2003: received issue March 9, 2005: closed issue Discussion: Whether ValueSpecifications might have side effects varies depending upon which of its concrete subclasses one is examining. If a particular ValueSpecification is any of the subclasses LiteralBoolean, LiteralInteger, LiteralString, LiteralUnlimitedNatural, LiteralNull or InstanceValue, the answer seems that they obviously are incapable, by definition, of having side effects. In contrast, it seems plausible that the Expression and OpaqueExpression subclasses of ValueSpecification might very well have side effects. However, other considerations argue against explicitly saying so. Interpretation of the contents of an OpaqueExpression’s body attribute is delegated to an external “linguistic analyzer” (page 47) and therefore, by definition, outside the scope of UML. Consequently, one cannot determine whether an OpaqueExpression’s body has sideeffects. Even though their tree structure is non-opaque and captured in UML, similar logic applies to evaluating whether Expressions can have side effects. An Expression is a “structured tree of symbols” where symbol interpretation “depends on the context of the expression” (page 46). Since the required “context” is not defined, the definition of the semantics of an expression is again outside the scope of UML. Since explicitly stating whether side-effects are allowed would be either irrelevant (for OpaqueExpression and Expression) or belaboring the obvious (fo r the Literal subclasses and InstanceValue), it seems unreasonable to suggest making any changes to the texts in section 7.5 of the UML2 Superstructure FAS (ptc/03-08-02) or in section 9.7 of the UML2 Infrastructure FAS (ptc/03-09-15). Note, also, that only the Expression and OpaqueExpression subclasses of ValueSpecfication are included in the Infrastructure FAS, so conclusions regarding the Literal subclasses and InstanceValue do not apply to the Infrastructure. The situation for guards is also somewhat more complex than one might expect since there are three different types of guards defined in the SuperFAS specification: ActivityEdge (section 12.3.3, page 293) defines a guard as a ValueSpecification. The semantics of these guards are further discussed under DecisionNodes on page 320. Consequently, the considerations outlined above for the subclasses of ValueSpecification are relevant here as well. The discussion of Interaction diagrams in section 14.4 (page 447) says that a guard “is a Message” and “is meant to be expressed in pseudocode or an actual programming language; UML does not prescribe its format”. Again, definition of guards is out of UML’s scope, so their potential for side effects cannot be determined, and arguably, should not be inhibited. The Transition class of State Machines (section 15.3.14, page 498) defines a guard to be a Constraint that “should be pure expressions without side effects. Guard expressions with side effects are ill formed.” And on page 501 of the same section, “Guards should not include expressions causing side effects. Models that violate this are considered ill formed.” Hence, the SuperFAS is already explicit about preventing side effects for Transition guards. Note that because guards are Constraints, they have a specification attribute that references a ValueSpecification describing the constraint’s definition. To prevent side effects on this ValueSpecification, Transition defines to local constraints that (1) require the value specification to evaluate to a boolean which does not, by definition, have side effects, and (2) explicitly prevent side effects. So, situation already handled. The Infrastructure FAS does not contain the word “guard” outside of the glossary, which has been excluded by another issue resolution. So no changes to it are required. Disposition: Closed, no change. End of Annotations:===== me: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Clarification Subject: Side effects of value specifications Clarify whether guards and other value specification can have side Subject: Issue 6362 opinions? Date: Mon, 7 Jun 2004 13:47:52 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 6362 Thread-Index: AcRLLJOTP1lYWHSJSBSasczM8mkFcgBosd7g From: "Tolbert, Doug M" To: , X-OriginalArrivalTime: 07 Jun 2004 20:47:52.0537 (UTC) FILETIME=[B3B8FC90:01C44CD0] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i57KqNun014012 Folks, I find myself sufficiently short of context on the subject issue (appearing below) to deal with it directly, so I'd like to solicit opinions before proposing a resolution. I'm sure some or all of you will know more of the history on this one than I, so please chime in. My personal feeling is that in absence of good and sufficient reason to the contrary, guards and value specifications should NOT have side effects, but this is more of a general conclusion on my part about expressions rather than something based on specifics of the situation in UML. Are you aware of any "good and sufficient reasons" why these things might want to have side-effects? If so, please enlighten us all. Thanks, Doug ---------- OMG Issue No: 6362 Title: Side effects of value specifications Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov ) Summary: Clarify whether guards and other value specification can have side effects Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Subject: ,cl, Proposed resolution for shared issue 6362 -- guard & expression side effects. Date: Thu, 17 Jun 2004 16:38:25 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: ,cl, Proposed resolution for shared issue 6362 -- guard & expression side effects. Thread-Index: AcRUxC7ARChPur98TbCYLKAuC7RpLA== From: "Tolbert, Doug M" To: , X-OriginalArrivalTime: 17 Jun 2004 23:38:26.0432 (UTC) FILETIME=[2FBAF000:01C454C4] The attached closure is, due to some additonal research, a bit different than discussed at Wednesday's Super telecon. The end result is "Closed, no change". Read the text for a more in depth analysis. Doug <> ------------------------------------------------------------------------------------ THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. Issue 6362 Resolution.doc OMG Issue No: 6362 Title: Side effects of value specifications Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Clarify whether guards and other value specification can have side effects Discussion: Whether ValueSpecifications might have side effects varies depending upon which of its concrete subclasses one is examining. If a particular ValueSpecification is any of the subclasses LiteralBoolean, LiteralInteger, LiteralString, LiteralUnlimitedNatural, LiteralNull or InstanceValue, the answer seems that they obviously are incapable, by definition, of having side effects. In contrast, it seems plausible that the Expression and OpaqueExpression subclasses of ValueSpecification might very well have side effects. However, other considerations argue against explicitly saying so. Interpretation of the contents of an OpaqueExpression.s body attribute is delegated to an external .linguistic analyzer. (page 47) and therefore, by definition, outside the scope of UML. Consequently, one cannot determine whether an OpaqueExpression.s body has side-effects. Even though their tree structure is non-opaque and captured in UML, similar logic applies to evaluating whether Expressions can have side effects. An Expression is a .structured tree of symbols. where symbol interpretation .depends on the context of the expression. (page 46). Since the required .context. is not defined, the definition of the semantics of an expression is again outside the scope of UML. Since explicitly stating whether side-effects are allowed would be either irrelevant (for OpaqueExpression and Expression) or belaboring the obvious (for the Literal subclasses and InstanceValue), it seems unreasonable to suggest making any changes to the texts in section 7.5 of the UML2 Superstructure FAS (ptc/03-08-02) or in section 9.7 of the UML2 Infrastructure FAS (ptc/03-09-15). Note, also, that only the Expression and OpaqueExpression subclasses of ValueSpecfication are included in the Infrastructure FAS, so conclusions regarding the Literal subclasses and InstanceValue do not apply to the Infrastructure. The situation for guards is also somewhat more complex than one might expect since there are three different types of guards defined in the SuperFAS specification: ActivityEdge (section 12.3.3, page 293) defines a guard as a ValueSpecification. The semantics of these guards are further discussed under DecisionNodes on page 320. Consequently, the considerations outlined above for the subclasses of ValueSpecification are relevant here as well. The discussion of Interaction diagrams in section 14.4 (page 447) says that a guard .is a Message. and .is meant to be expressed in pseudocode or an actual programming language; UML does not prescribe its format.. Again, definition of guards is out of UML.s scope, so their potential for side effects cannot be determined, and arguably, should not be inhibited. The Transition class of State Machines (section 15.3.14, page 498) defines a guard to be a Constraint that .should be pure expressions without side effects. Guard expressions with side effects are ill formed.. And on page 501 of the same section, .Guards should not include expressions causing side effects. Models that violate this are considered ill formed.. Hence, the SuperFAS is already explicit about preventing side effects for Transition guards. Note that because guards are Constraints, they have a specification attribute that references a ValueSpecification describing the constraint.s definition. To prevent side effects on this ValueSpecification, Transition defines to local constraints that (1) require the value specification to evaluate to a boolean which does not, by definition, have side effects, and (2) explicitly prevent side effects. So, situation already handled. The Infrastructure FAS does not contain the word .guard. outside of the glossary, which has been excluded by another issue resolution. So no changes to it are required. Disposition: Closed, no change. To: "Tolbert, Doug M" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: ,cl, Proposed resolution for shared issue 6362 -- guard & expression side effects. X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 18 Jun 2004 08:50:02 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 06/18/2004 08:50:03, Serialize complete at 06/18/2004 08:50:03 I like your resolution, Doug. Whether expressions have side effects or not is a semantic variation point in my opinion. We should be careful not to be too righteous. Besides, as the Heisenberg principle tells us, it is impossible not to have side effects (if nothing else, evaluating a guard takes up time, which can lead to race conditions). Therefore, the less said on this point, the better. If people want stricter rules, they should define them in profiles. Bran "Tolbert, Doug M" 06/17/2004 07:38 PM To , cc Subject ,cl, Proposed resolution for shared issue 6362 -- guard & expression side effects. The attached closure is, due to some additonal research, a bit different than discussed at Wednesday's Super telecon. The end result is "Closed, no change". Read the text for a more in depth analysis. Doug <> ------------------------------------------------------------------------------------ THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. [attachment "Issue 6362 Resolution.doc" deleted by Branislav Selic/Ottawa/IBM] Subject: FW: ,cl, Proposed resolution for shared issue 6362 -- guard & expression side effects. Date: Tue, 13 Jul 2004 09:15:34 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: ,cl, Proposed resolution for shared issue 6362 -- guard & expression side effects. Thread-Index: AcRUxC7ARChPur98TbCYLKAuC7RpLAUMF0TA From: "Tolbert, Doug M" To: , X-OriginalArrivalTime: 13 Jul 2004 16:15:34.0856 (UTC) FILETIME=[A093B480:01C468F4] This is a resending of the proposed resolution to issue 6362 requested by Bran. Doug -----Original Message----- From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] Sent: Thursday, June 17, 2004 4:38 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: ,cl, Proposed resolution for shared issue 6362 -- guard & expression side effects. The attached closure is, due to some additonal research, a bit different than discussed at Wednesday's Super telecon. The end result is "Closed, no change". Read the text for a more in depth analysis. Doug <> ------------------------------------------------------------------------------------ THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. Issue 6362 Resolution1.doc OMG Issue No: 6362 Title: Side effects of value specifications Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Clarify whether guards and other value specification can have side effects Discussion: Whether ValueSpecifications might have side effects varies depending upon which of its concrete subclasses one is examining. If a particular ValueSpecification is any of the subclasses LiteralBoolean, LiteralInteger, LiteralString, LiteralUnlimitedNatural, LiteralNull or InstanceValue, the answer seems that they obviously are incapable, by definition, of having side effects. In contrast, it seems plausible that the Expression and OpaqueExpression subclasses of ValueSpecification might very well have side effects. However, other considerations argue against explicitly saying so. Interpretation of the contents of an OpaqueExpression.s body attribute is delegated to an external .linguistic analyzer. (page 47) and therefore, by definition, outside the scope of UML. Consequently, one cannot determine whether an OpaqueExpression.s body has side-effects. Even though their tree structure is non-opaque and captured in UML, similar logic applies to evaluating whether Expressions can have side effects. An Expression is a .structured tree of symbols. where symbol interpretation .depends on the context of the expression. (page 46). Since the required .context. is not defined, the definition of the semantics of an expression is again outside the scope of UML. Since explicitly stating whether side-effects are allowed would be either irrelevant (for OpaqueExpression and Expression) or belaboring the obvious (for the Literal subclasses and InstanceValue), it seems unreasonable to suggest making any changes to the texts in section 7.5 of the UML2 Superstructure FAS (ptc/03-08-02) or in section 9.7 of the UML2 Infrastructure FAS (ptc/03-09-15). Note, also, that only the Expression and OpaqueExpression subclasses of ValueSpecfication are included in the Infrastructure FAS, so conclusions regarding the Literal subclasses and InstanceValue do not apply to the Infrastructure. The situation for guards is also somewhat more complex than one might expect since there are three different types of guards defined in the SuperFAS specification: ActivityEdge (section 12.3.3, page 293) defines a guard as a ValueSpecification. The semantics of these guards are further discussed under DecisionNodes on page 320. Consequently, the considerations outlined above for the subclasses of ValueSpecification are relevant here as well. The discussion of Interaction diagrams in section 14.4 (page 447) says that a guard .is a Message. and .is meant to be expressed in pseudocode or an actual programming language; UML does not prescribe its format.. Again, definition of guards is out of UML.s scope, so their potential for side effects cannot be determined, and arguably, should not be inhibited. The Transition class of State Machines (section 15.3.14, page 498) defines a guard to be a Constraint that .should be pure expressions without side effects. Guard expressions with side effects are ill formed.. And on page 501 of the same section, .Guards should not include expressions causing side effects. Models that violate this are considered ill formed.. Hence, the SuperFAS is already explicit about preventing side effects for Transition guards. Note that because guards are Constraints, they have a specification attribute that references a ValueSpecification describing the constraint.s definition. To prevent side effects on this ValueSpecification, Transition defines to local constraints that (1) require the value specification to evaluate to a boolean which does not, by definition, have side effects, and (2) explicitly prevent side effects. So, situation already handled. The Infrastructure FAS does not contain the word .guard. outside of the glossary, which has been excluded by another issue resolution. So no changes to it are required. Disposition: Closed, no change. effects.