Issue 6490: Protocol machines do not subset state invariant (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Minor Summary: Protocol machines subset guards, but not state invariant. What's the difference? Resolution: Revised Text: Actions taken: November 7, 2003: received issue March 9, 2005: closed issue Discussion: Guards are interpreted in the sense of pre and post conditions under protocol stat machine, which is a different meaning as a guard for a behavioural state. State invariant has the same interpretation for both kinds of state machines. So there is no reason to redefine or subset it. Historically, this feature has been created under protocol state machine, and be generalized for all SM, though it has been judged that it is of a general interest. Disposition: Closed, no change End of Annotations:===== me: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Minor Subject: Protocol machines do not subset state invariant. Protocol machines subset guards, but not state invariant. What's the difference? Issue 6490: Protocol machines do not subset state invariant (uml2-superstructure-ftf) Click here for this issue's archive. Source: NIST (Mr. Conrad Bock, mailto:%20conrad.bock@nist.gov) Nature: Revision Severity: Minor Summary: Protocol machines subset guards, but not state invariant. What's the difference? Discussion: Guards are interpreted in the sense of pre and post conditions under protocol stat machine, which is a different meaning as a guard for a behavioural state. State invariant has the same interpretation for both kinds of state machines. So there is no reason to redefine or subset it. Historically, this feature has been created under protocol state machine, and be generalized for all SM, though it has been judged that it is of a general interest. Disposition: Closed, no change To: Cc: "'UML Superstructure FTF'" Subject: RE: SM - Proposed resolution for PSM issues X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Sat, 31 Jan 2004 16:20:57 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/31/2004 16:21:01, Serialize complete at 01/31/2004 16:21:01 Sorry for the late input, I would like to mention the following: (1) it is very important to say that the state of the PSM is not necessarily related to the state of the entity implementing the interface (although, I am not sure that I would exclude that possibility altogether -- I have actually seen some special cases where it makes sense for the two to be the same) (2) I don't like the term PSM state, because it is meaningless and does not convey the intent very well. My suggestion is to call it the "protocol state" because that is what it is. Cheers, Bran "Conrad Bock" 01/25/2004 01:10 AM Please respond to conrad.bock To: "'UML Superstructure FTF'" cc: Subject: RE: SM - Proposed resolution for PSM issues Phillipe, Thanks for the proposals. The explanation in 6490 (Protocol machines do not subset state invariant) is fine with me. On Issue 6152 (Protocol state machines are not pre/postconditions), change 1 looks good to me. Change 2 is better than the existing text, but still refers to "states" without clarifying whether they are internal or external. Since it is a PSM, and change 1 says PSM states are not generally easy to map to internal states, I'd suggest putting "PSM" before state in the text, and delete "final" before state because it shouldn't imply Final State. Here is the edit: Semantics of a protocol transition A protocol transition can be semantically interpreted in terms of pre and post conditions on the associated operation. For example, the transition in Figure 365 can be interpreted in the following way : 1. the operation "m1" can be called on an instance when it is in the PSM state S1 under the condition C1, 2. when "m1" is called in the PSM state "S1" under the condition "C1", then the PSM state "S2" must be reached under the condition "C2". Conrad Reply-To: From: "DESFRAY Philippe" To: "'Branislav Selic'" , Cc: "'UML Superstructure FTF'" Subject: RE: SM - Proposed resolution for PSM issues Date: Mon, 2 Feb 2004 17:39:48 +0100 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal Here is an amendment to the proposed text : 1 Change PSM state to Protocol states (I agre, this is more consistent with the notion of "protocol transition"). 2 (the state of the PSM is not necessarily related to the state of the entity implementing ... although, I am not sure that I would exclude that possibility altogether ...) Yes both cases exist. I beleive it is reflected in the existing text, but I amended it to present a bit more that both possibilities do exist. If there is no objection to this text, I would like to insert it in ballot 7. -- Philippe -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : samedi 31 janvier 2004 22:21 À : conrad.bock@nist.gov Cc : 'UML Superstructure FTF' Objet : RE: SM - Proposed resolution for PSM issues Sorry for the late input, I would like to mention the following: (1) it is very important to say that the state of the PSM is not necessarily related to the state of the entity implementing the interface (although, I am not sure that I would exclude that possibility altogether -- I have actually seen some special cases where it makes sense for the two to be the same) (2) I don't like the term PSM state, because it is meaningless and does not convey the intent very well. My suggestion is to call it the "protocol state" because that is what it is. Cheers, Bran "Conrad Bock" 01/25/2004 01:10 AM Please respond to conrad.bock To: "'UML Superstructure FTF'" cc: Subject: RE: SM - Proposed resolution for PSM issues Phillipe, Thanks for the proposals. The explanation in 6490 (Protocol machines do not subset state invariant) is fine with me. On Issue 6152 (Protocol state machines are not pre/postconditions), change 1 looks good to me. Change 2 is better than the existing text, but still refers to "states" without clarifying whether they are internal or external. Since it is a PSM, and change 1 says PSM states are not generally easy to map to internal states, I'd suggest putting "PSM" before state in the text, and delete "final" before state because it shouldn't imply Final State. Here is the edit: Semantics of a protocol transition A protocol transition can be semantically interpreted in terms of pre and post conditions on the associated operation. For example, the transition in Figure 365 can be interpreted in the following way : 1. the operation "m1" can be called on an instance when it is in the PSM state S1 under the condition C1, 2. when "m1" is called in the PSM state "S1" under the condition "C1", then the PSM state "S2" must be reached under the condition "C2". Conrad Resolution for PSM issues.doc Issue 6490: Protocol machines do not subset state invariant (uml2-superstructure-ftf) Click here for this issue's archive. Source: NIST (Mr. Conrad Bock, mailto:%20conrad.bock@nist.gov) Nature: Revision Severity: Minor Summary: Protocol machines subset guards, but not state invariant. What's the difference? Discussion: Guards are interpreted in the sense of pre and post conditions under protocol stat machine, which is a different meaning as a guard for a behavioural state. State invariant has the same interpretation for both kinds of state machines. So there is no reason to redefine or subset it. Historically, this feature has been created under protocol state machine, and be generalized for all SM, though it has been judged that it is of a general interest. Disposition: Closed, no change