Issue 6488: Conditions for parameter sets (02) (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: Parameter sets need conditions for pre/postconditions Resolution: see above Revised Text: Actions taken: November 7, 2003: received issue March 8, 2005: closed issue Discussion: updated figure below (includes resolution of 6109): In ParameterSet, in Associations section, add this entry in alphabetical order with the others: “condition : Constraint [*] Constraint that should be satisified for the owner of the parameters in an input parameter set to start execution using the values provided for those parameters, or the owner of the parameters in an output parameter set to end execution providing the values for those parameters, if all preconditions and conditions on input parameter sets were satisfied.” in Semantics section, in the first paragraph, at the end add the sentence: "The semantics of conditions of input and output parameter sets is the same as Behavior preconditions and postconditions, respectively, but apply only to the set of parameters specified.” End of Annotations:===== me: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Significant Subject: Conditions for parameter sets Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 29 Feb 2004 09:25:56 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: ,av, Issue 6488 This is the proposed resolution for issue 6488: In ParameterSet, in Associations section, add this entry in alphabetical order with the others: "condition : Constraint [*] Conditions required for the owner of the parameters in an input parameter set to start execution using the values provided for those parameters, or the owner of the parameters in an output parameter set to end execution providing the values for those parameters, if all preconditions were satisfied." in Semantics section, in the first paragraph, at the end add the sentence: "The semantics of conditions of input and output parameter sets is the same as Behavior preconditions and postconditions, respectively." ................................................... I trust we all agree that 'precondition' is used on the shop floor with two quite different meanings. One meaning, in contract based specification, is a condition that is the x in 'if you satisfy x i will satisfy y.' I'll call that a 'contract condition.' The other meaning is a condition that is the x in in ' i won't do anything unless x.' I'll call that a 'guard.' The famous, but non-normative, Glossary seems to pick one, contract condition, by focusing on the invocation: "precondition: a constraint [that] expresses a condition that must be true when an operation is invoked." [Part IV - Appendices Glossary ptc/03-07-06] The specification tells us that "a constraint is an assertion that indicates a restriction that must be satisfied by a correct design of the system." [7.6.1 Semantics] As applied to an operation, a precondition is "an optional set of Constraints on the state of the system when the Operation is invoked." This again focuses on the invocation. [7.10.1 Associations] "The preconditions for an operation define conditions that must be true when the operation is invoked. These preconditions may be assumed by an implementation of this operation." [7.10.1 Semantics] This fits perfectly with contract condition. And that interpretation is clinched by "The postconditions for an operation define conditions that will be true when the invocation of the operation is completes successfully, assuming the preconditions were satisfied." [7.10.1 Semantics] It is certainly the case that an operation may be executed, even if its precondition is not satisfied: "The behavior of an invocation of an operation when a precondition is not satisfied is a semantic variation point." [7.10.1 Semantics] The same applies to actions. "localPrecondition: constraint that must be satisfied when execution is started." [12.3.1 Associations] "Local preconditions ... are constraints that must hold when the execution starts." [12.3.1 Semantics] The precondition of an activity is defined at Behavior. [mentioned in passing at 12.3.2 Notation] The precondition of Behavior fits with the others discussed so far. "precondition: an optional set of Constraints specifying what must be fulfilled when the behavior is invoked." "postcondition: an optional set of Constraints specifying what is fulfilled after the execution of the behavior is completed, if its precondition was fulfilled before its invocation." [13.3.3 Associations] This is all good. The precondition of ProtocolStateMachine seems to fit. "preCondition: specifies the precondition of the transition." [15.3.7 Associations] The use of 'precondition' to specify 'preCondition' suggests that the meaning is that already specified for Operation, Action, Activity, and Behavior. "It specifies the condition that should be verified before triggering the transition." [15.3.7 Associations] Although the use of 'should' in a specification is problematical at best, its use here fits with the meaning, contract condition. We also have: "A protocol state machine specifies all the legal transitions for each operation refered by its transitions. This means that for any operation refered [to] by a protocol state machine, the part of its precondition relative to legal initial or final state is completely specified by the protocol stat[e] machine." [15.3.7 Semantics] I'm not sure what that means, but i assume it is consistent with the other uses of 'precondition' in the preceding text of the Superstructure specification and consistent with the specification of 'precondition' for protocol state machines. "The description of the locations of the extension point [of a use case] ... can also be given ... as ... a precondition ..." [16.3.6 Notation] That is neutral as to the intended meaning of 'precondition.' ................................................... So, much of the specification text is perfectly clear that a precondition is a contract condition. The rest of the text is certainly consistent with that usage. On the other hand, the proposed resolution to 6488 fits with the other usage of 'precondition,' as guard. "Conditions required ... to start execution ..." [Proposed resolution 6488] ....... Perhaps we can avoid arguing about what 'precondition' "really" means. I hope we can all agree that, given the specification of the association, ParameterSet.condition, the proposed resolution to 6488, it is not the case that "The semantics of conditions of input ... parameter sets is the same as Behavior preconditions ..." I see two options: -- change the specification text proposed for ParameterSet.condition to fit with contract condition -- or not add the sentence quoted at the end of the previous paragraph. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 29 Feb 2004 09:38:08 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: ,av, Issue 6488 This is the proposed resolution for issue 6488: In ParameterSet, in Associations section, add this entry in alphabetical order with the others: "condition : Constraint [*] Conditions required for the owner of the parameters in an input parameter set to start execution using the values provided for those parameters, or the owner of the parameters in an output parameter set to end execution providing the values for those parameters, if all preconditions were satisfied." in Semantics section, in the first paragraph, at the end add the sentence: "The semantics of conditions of input and output parameter sets is the same as Behavior preconditions and postconditions, respectively." ................................................... I trust we all agree that 'precondition' is used on the shop floor with two quite different meanings. One meaning, in contract based specification, is a condition that is the x in 'if you satisfy x i will satisfy y.' I'll call that a 'contract condition.' The other meaning is a condition that is the x in in ' i won't do anything unless x.' I'll call that a 'guard.' The famous, but non-normative, Glossary seems to pick one, contract condition, by focusing on the invocation: "precondition: a constraint [that] expresses a condition that must be true when an operation is invoked." [Part IV - Appendices Glossary ptc/03-07-06] The specification tells us that "a constraint is an assertion that indicates a restriction that must be satisfied by a correct design of the system." [7.6.1 Semantics] As applied to an operation, a precondition is "an optional set of Constraints on the state of the system when the Operation is invoked." This again focuses on the invocation. [7.10.1 Associations] "The preconditions for an operation define conditions that must be true when the operation is invoked. These preconditions may be assumed by an implementation of this operation." [7.10.1 Semantics] This fits perfectly with contract condition. And that interpretation is clinched by "The postconditions for an operation define conditions that will be true when the invocation of the operation is completes successfully, assuming the preconditions were satisfied." [7.10.1 Semantics] It is certainly the case that an operation may be executed, even if its precondition is not satisfied: "The behavior of an invocation of an operation when a precondition is not satisfied is a semantic variation point." [7.10.1 Semantics] The same applies to actions. "localPrecondition: constraint that must be satisfied when execution is started." [12.3.1 Associations] "Local preconditions ... are constraints that must hold when the execution starts." [12.3.1 Semantics] The precondition of an activity is defined at Behavior. [mentioned in passing at 12.3.2 Notation] The precondition of Behavior fits with the others discussed so far. "precondition: an optional set of Constraints specifying what must be fulfilled when the behavior is invoked." "postcondition: an optional set of Constraints specifying what is fulfilled after the execution of the behavior is completed, if its precondition was fulfilled before its invocation." [13.3.3 Associations] This is all good. The precondition of ProtocolStateMachine seems to fit. "preCondition: specifies the precondition of the transition." [15.3.7 Associations] The use of 'precondition' to specify 'preCondition' suggests that the meaning is that already specified for Operation, Action, Activity, and Behavior. "It specifies the condition that should be verified before triggering the transition." [15.3.7 Associations] Although the use of 'should' in a specification is problematical at best, its use here fits with the meaning, contract condition. We also have: "A protocol state machine specifies all the legal transitions for each operation refered by its transitions. This means that for any operation refered [to] by a protocol state machine, the part of its precondition relative to legal initial or final state is completely specified by the protocol stat[e] machine." [15.3.7 Semantics] I'm not sure what that means, but i assume it is consistent with the other uses of 'precondition' in the preceding text of the Superstructure specification and consistent with the specification of 'precondition' for protocol state machines. "The description of the locations of the extension point [of a use case] ... can also be given ... as ... a precondition ..." [16.3.6 Notation] That is neutral as to the intended meaning of 'precondition.' ................................................... So, much of the specification text is perfectly clear that a precondition is a contract condition. The rest of the text is certainly consistent with that usage. On the other hand, the proposed resolution to 6488 fits with the other usage of 'precondition,' as guard. "Conditions required ... to start execution ..." [Proposed resolution 6488] ....... Perhaps we can avoid arguing about what 'precondition' "really" means. I hope we can all agree that, given the specification of the association, ParameterSet.condition, the proposed resolution to 6488, it is not the case that "The semantics of conditions of input ... parameter sets is the same as Behavior preconditions ..." I see two options: -- change the specification text proposed for ParameterSet.condition to fit with contract condition -- or not add the sentence quoted at the end of the previous paragraph. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Reply-To: From: "Conrad Bock" To: "UML Superstructure FTF" Subject: RE: ,av, Issue 6488 Date: Mon, 1 Mar 2004 11:04:18 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Hi Joaquin, Thanks for catching this. I didn't agree with your reading of the existing spec, but that is another matter, see discussion after my sig. It affects this issue, however, because I'm not sure what wording has the right connotation. There are at least two parts to it: - contract: postcondition is satisifed if precondition is. The existing issue resolution text says this, but I clarified. - enforcement of constraints is a semantic variation, as you quoted: "a constraint is an assertion that indicates a restriction that must be satisfied by a correct design of the system." [7.6.1 Semantics] I assume behavior pre/postconditions adhere to both of these, and I wanted the parameter set conditions to also. Changed the text to: In ParameterSet, in Associations section, add this entry in alphabetical order with the others: "condition : Constraint [*] Constraint that should be satisified for the owner of the parameters in an input parameter set to start execution using the values provided for those parameters, or the owner of the parameters in an output parameter set to end execution providing the values for those parameters, if all preconditions and conditions on input parameter sets were satisfied." in Semantics section, in the first paragraph, at the end add the sentence: "The semantics of conditions of input and output parameter sets is the same as Behavior preconditions and postconditions, respectively, but apply only to the set of parameters specified." This way, the definition falls back on the definition of constraint, which does not restrict enforcement. Let me know if there is a better way to put it. Conrad > One meaning, in contract based specification, is a condition that is > the x in 'if you satisfy x i will satisfy y.' I'll call that a > 'contract condition.' > > The other meaning is a condition that is the x in in ' i won't do > anything unless x.' I'll call that a 'guard.' > > The famous, but non-normative, Glossary seems to pick one, contract > condition, by focusing on the invocation: "precondition: a constraint > [that] expresses a condition that must be true when an operation is > invoked." [Part IV - Appendices Glossary ptc/03-07-06] The glossary wording sounds like a guard to me, but I've always assumed it is requirement that should be met, but the execution effect is a semantic variation. > The specification tells us that "a constraint is an assertion that > indicates a restriction that must be satisfied by a correct design of > the system." [7.6.1 Semantics] This is what I meant by condition on parameter sets, emphasis on "correct design". The system can be incorrectly designed, so it is up to the system when constraints as enforced. > As applied to an operation, a precondition is "an optional set of > Constraints on the state of the system when the Operation is > invoked." This again focuses on the invocation. [7.10.1 > Associations] Sounds agnostic to me, but since it refers to constraint, so presumably carries that semantic. > "The preconditions for an operation define conditions that must be > true when the operation is invoked. These preconditions may be > assumed by an implementation of this operation." [7.10.1 Semantics] > This fits perfectly with contract condition. > The same applies to actions. "localPrecondition: constraint that > must be satisfied when execution is started." [12.3.1 Associations] > "Local preconditions ... are constraints that must hold when the > execution starts." [12.3.1 Semantics] > The precondition of Behavior fits with the others discussed so far. > "precondition: an optional set of Constraints specifying what must be > fulfilled when the behavior is invoked." "postcondition: an optional > set of Constraints specifying what is fulfilled after the execution > of the behavior is completed, if its precondition was fulfilled > before its invocation." [13.3.3 Associations] Using "must", "what is fulfilled" sounds like a guard again, which isn't the intention. I used the word "required" for parameter sets, which as the same incorrecet connotation. > And that interpretation is clinched by "The postconditions for an > operation define conditions that will be true when the invocation of > the operation is completes successfully, assuming the preconditions > were satisfied." [7.10.1 Semantics] Alot better, but "will be" is again ambiguous about when the constraint is enforced. > It is certainly the case that an operation may be executed, even if its > precondition is not satisfied: "The behavior of an invocation of an > operation when a precondition is not satisfied is a semantic variation > point." [7.10.1 Semantics] This is inline with the definition of "constraint", but not the other usages of constraint above. OMG Issue No: 6488 Title: Conditions for parameter sets (02) Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Parameter sets need conditions for pre/postconditions Discussion: In Figure 189, add the association from ParameterSet to Constraint shown in the updated figure below (includes resolution of 6109): In ParameterSet, in Associations section, add this entry in alphabetical order with the others: .condition : Constraint [*] Conditions required for the owner of the parameters in an input parameter set to start execution using the values provided for those parameters, or the owner of the parameters in an output parameter set to end execution providing the values for those parameters, if all preconditions were satisfied.. in Semantics section, in the first paragraph, at the end add the sentence: "The semantics of conditions of input and output parameter sets is the same as Behavior preconditions and postconditions, respectively.. Disposition: Resolved Parameter sets need conditions for pre/postconditions Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: ,av, Proposed issue resolutions Date: Wed, 25 Feb 2004 13:31:27 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Ken, > The diagram for issue 6488 is incorrect. The association should > be between ParameterSet and Constraint, not Parameter and > Constraint (based on the proposed resolution). Thanks, see update attached. Conrad Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 12 Mar 2004 13:22:10 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: Ballot 9 No vote X-Change Technologies votes yes on all issues on Ballot 9 except for Issue 6488. We vote no on Issue 6488. We will change our vote to yes if -- the word 'should' in the first text to be added is replaced with another word or that text is rewritten to make it clear whether the condition (a) must be satisfied in order for execution to execution (that is, execution does not start until the condition is satisfied), or (b) is, along with the condition for the end of execution, a part of a contract (but execution will start whether or not the condition is satisfied). -- and, if the case is (a), then the second text is not added. PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Subject: RE: Reminder to vote on Ballot 9 Date: Tue, 16 Mar 2004 07:36:17 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Reminder to vote on Ballot 9 Thread-Index: AcQKnDKAi3+k4MUuSAaKHFNBcOm0xgAtfWIq From: "Karl Frank" To: "Branislav Selic" , X-OriginalArrivalTime: 16 Mar 2004 12:36:18.0806 (UTC) FILETIME=[47CD8960:01C40B53] The substance of 6488 is marred by being written as a description of what "should" be, if something "were" the case. Specifications are not advice. The problematic phrase in 6488 resolution is: Constraint that should be satisified for the owner of the parameters in an input parameter set to start execution using the values provided for those parameters, or the owner of the parameters in an output parameter set to end execution providing the values for those parameters, if all preconditions and conditions on input parameter sets were satisfied.ā.¯ Karl Frank -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Mon 3/15/2004 9:44 AM To: uml2-superstructure-ftf@omg.org Cc: Subject: Reminder to vote on Ballot 9 Ballot 9 closes this Wednesday (March 17) at 6 PM EST. The following companies have yet to vote on Ballot 9: * 88solutions * Adaptive * Artisan * ATC enterprises * Borland * CEA-LIST * Compuware * Gentleware * INRIA * Orcle * Popkin * Telelogic If your company name is not on this list then your vote has been registered. BTW, we already have quorum on ballot 9, so it will be a valid ballot. Bran Selic 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 Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 16 Mar 2004 09:07:25 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: Reminder to vote on Ballot 9 The substance of 6488 is marred by being written as a description of what "should" be, if something "were" the case. Specifications are not advice. That's right. Let's try to clean up the should-typically-etc. in future issue resolutions. PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Subject: RE: Ballot 9 -- vote starts today at 6 pm EST Date: Tue, 16 Mar 2004 23:50:12 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 9 -- vote starts today at 6 pm EST Thread-Index: AcQBenP8xLMBqwp9Q+S3r2Yt6ykixQKXvIiw From: "Pete Rivett" To: "Branislav Selic" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i2H4frre007110 Adaptive votes YES to all the proposed resolutions. And brings the editor's attention to the following typo in the resolution to issue 6965: "[1] The query allIncludedUseCases() returns the transitive closer " And in 6488: "condition : Constraint [*] Constraint that should be satisified for the " Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, March 03, 2004 11:45 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Ballot 9 -- vote starts today at 6 pm EST You have two weeks to vote (and re-vote, if you want) on these proposed resolutions. Bran issueresolution-cb-31.doc