Issue 6395: UML 2 Super / State machines / Transition triggers cannot be redefined (uml2-rtf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: Transition triggers do not appear to be redefinable in the current metamodel. There does not seem to be any reason for this restriction and it should be removed Resolution: Revised Text: Actions taken: October 31, 2003: received issue Discussion: Disposition: Deferred to UML 2.4 RTF End of Annotations:===== ubject: UML 2 Super / State machines / Transition triggers cannot be redefined X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 31 Oct 2003 20:06:35 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 10/31/2003 20:06:37, Serialize complete at 10/31/2003 20:06:37 Transition triggers do not appear to be redefinable in the current metamodel. There does not seem to be any reason for this restriction and it should be removed. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 Reply-To: Joaquin Miller X-Sender: jm-acm.no@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 19 Jan 2004 09:35:17 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: ,sm, issue 6395 OMG Issue 6395 Title: Transition triggers cannot be redefined ... Discussion: The rationale for not replacing the triggers is similar to that of redefinition rules for operations on a classifier. The set of triggers form a contract for the states specifying the signals it responds to. Modifying a trigger is practically similar to allowing deletion of a feature through a redefinition, which is not consistent with other redefinition contexts in UML. Eran, i feel the last sentence needs some work; maybe expansion, too. It's not clear to me why modifying is similar to deleting in this case. I don't deny it, not at all; i just don't see it. I wonder if there are other practical reasons for not redefining transition triggers. I would not be surprised. ....................................... (Also, a bit of copy editing: would it be useful to replace 'it' in the second sentence with the name of whatever it refers to? Might be either of these, or some third: The set of triggers form a contract for a classifier specifying the signals that classifier responds to. The set of triggers form a contract for a state, specifying the signals that state responds to. If the latter, then: The set of triggers form a contract for a classifier, specifying the signals that classifier responds to when in a particular state.) 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: Mon, 19 Jan 2004 09:35:17 -0800 To: UML Superstructure FTF From: Joaquin Miller Subject: ,sm, issue 6395 OMG Issue 6395 Title: Transition triggers cannot be redefined ... Discussion: The rationale for not replacing the triggers is similar to that of redefinition rules for operations on a classifier. The set of triggers form a contract for the states specifying the signals it responds to. Modifying a trigger is practically similar to allowing deletion of a feature through a redefinition, which is not consistent with other redefinition contexts in UML. Eran, i feel the last sentence needs some work; maybe expansion, too. It's not clear to me why modifying is similar to deleting in this case. I don't deny it, not at all; i just don't see it. I wonder if there are other practical reasons for not redefining transition triggers. I would not be surprised. ....................................... (Also, a bit of copy editing: would it be useful to replace 'it' in the second sentence with the name of whatever it refers to? Might be either of these, or some third: The set of triggers form a contract for a classifier specifying the signals that classifier responds to. The set of triggers form a contract for a state, specifying the signals that state responds to. If the latter, then: The set of triggers form a contract for a classifier, specifying the signals that classifier responds to when in a particular state.) PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 From: Eran Gery To: Joaquin Miller Cc: UML Superstructure FTF , Thomas Weigert Subject: RE: ,sm, issue 6395 Date: Mon, 19 Jan 2004 20:13:26 +0200 X-Mailer: Internet Mail Service (5.5.2656.59) This is another practical reason not to allow this... In the SM team we have discussed both. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Mon, January 19, 2004 8:00 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: ,sm, issue 6395 The reason for not redefining triggers is that the combination of trigger and state identifies the transition. Redefining the trigger would mean introducing a new transition, not changing an existing one (i.e., this is like changing the name of an operation). You can redefine the actions and final states of a transition, however. The redefinition semantics for statemachines has been carefully worked out over the course of more than a year by the SM team. All the best, Th. -----Original Message----- From: Joaquin Miller [mailto:joaquin.no.spam@acm.org] Sent: Monday, January 19, 2004 11:35 AM To: UML Superstructure FTF Subject: ,sm, issue 6395 OMG Issue 6395 Title: Transition triggers cannot be redefined ... Discussion: The rationale for not replacing the triggers is similar to that of redefinition rules for operations on a classifier. The set of triggers form a contract for the states specifying the signals it responds to. Modifying a trigger is practically similar to allowing deletion of a feature through a redefinition, which is not consistent with other redefinition contexts in UML. Eran, i feel the last sentence needs some work; maybe expansion, too. It's not clear to me why modifying is similar to deleting in this case. I don't deny it, not at all; i just don't see it. I wonder if there are other practical reasons for not redefining transition triggers. I would not be surprised. ....................................... (Also, a bit of copy editing: would it be useful to replace 'it' in the second sentence with the name of whatever it refers to? Might be either of these, or some third: The set of triggers form a contract for a classifier specifying the signals that classifier responds to. The set of triggers form a contract for a state, specifying the signals that state responds to. If the latter, then: The set of triggers form a contract for a classifier, specifying the signals that classifier responds to when in a particular state.) PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 To: "Thomas Weigert" Cc: "Joaquin Miller" , "UML Superstructure FTF" Subject: RE: ,sm, issue 6395 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 19 Jan 2004 15:18:47 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/19/2004 15:19:11, Serialize complete at 01/19/2004 15:19:11 Well, I was on that SM (S&M?) team and in my opinion we never closed on it (instead, the time ran out and we defaulted). I disagree with the conclusion that the combination of trigger and state identifies a transition. (In particular, I disagree with it because it creates backward compatibility problems for our product -- and, I will remind everyone that, as a matter of principle, we always tried to support backward compatibility of products in the submission). In this case, I see no reason to treat transitions differently from other features in a state machine, which are identified by their (model element) identity. Cheers, Bran "Thomas Weigert" 01/19/2004 01:00 PM To: "Joaquin Miller" , "UML Superstructure FTF" cc: Subject: RE: ,sm, issue 6395 The reason for not redefining triggers is that the combination of trigger and state identifies the transition. Redefining the trigger would mean introducing a new transition, not changing an existing one (i.e., this is like changing the name of an operation). You can redefine the actions and final states of a transition, however. The redefinition semantics for statemachines has been carefully worked out over the course of more than a year by the SM team. All the best, Th. -----Original Message----- From: Joaquin Miller [mailto:joaquin.no.spam@acm.org] Sent: Monday, January 19, 2004 11:35 AM To: UML Superstructure FTF Subject: ,sm, issue 6395 OMG Issue 6395 Title: Transition triggers cannot be redefined ... Discussion: The rationale for not replacing the triggers is similar to that of redefinition rules for operations on a classifier. The set of triggers form a contract for the states specifying the signals it responds to. Modifying a trigger is practically similar to allowing deletion of a feature through a redefinition, which is not consistent with other redefinition contexts in UML. Eran, i feel the last sentence needs some work; maybe expansion, too. It's not clear to me why modifying is similar to deleting in this case. I don't deny it, not at all; i just don't see it. I wonder if there are other practical reasons for not redefining transition triggers. I would not be surprised. ....................................... (Also, a bit of copy editing: would it be useful to replace 'it' in the second sentence with the name of whatever it refers to? Might be either of these, or some third: The set of triggers form a contract for a classifier specifying the signals that classifier responds to. The set of triggers form a contract for a state, specifying the signals that state responds to. If the latter, then: The set of triggers form a contract for a classifier, specifying the signals that classifier responds to when in a particular state.) PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 From: "Thomas Weigert" To: "Branislav Selic" , "Thomas Weigert" Cc: "Joaquin Miller" , "UML Superstructure FTF" Subject: RE: ,sm, issue 6395 Date: Tue, 20 Jan 2004 10:24:30 -0600 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Bran, first, I don't understand your statement about backwards compatibility. There was much discussion in the SM group regarding the semantics of inheritance (remember the questions of redefinition vs. replacement vs. deletion). As the UML 1.4 had nothing bindingly defined any more detailed definition would be a change. Knowing this, the SM team selected the current definitions. Specifically, for example, this rules out deletion semantics. This was a known change that was deemed to be for the better. You also supported this, at least in the Paris meeting where this issue was decided by the group. This was definitely not a situation where time ran out, but instead the result of a very focused discussion and analysis. Further, though, I think there is some confusion here with respect to the term "identity" which I probably chose unwisely. This was not a discussion on what model element is identical to what other model element. Instead, the question was as to what constitutes a conceptual unit in the specification. In this context, we had decided (in the SM team) that a transition is characterized by its source state and its trigger. Redefinition was worked out with respect to that. Similarly to the other parts of the spec where redefinitions are discussed. All the best, Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, January 19, 2004 2:19 PM To: Thomas Weigert Cc: Joaquin Miller; UML Superstructure FTF Subject: RE: ,sm, issue 6395 Well, I was on that SM (S&M?) team and in my opinion we never closed on it (instead, the time ran out and we defaulted). I disagree with the conclusion that the combination of trigger and state identifies a transition. (In particular, I disagree with it because it creates backward compatibility problems for our product -- and, I will remind everyone that, as a matter of principle, we always tried to support backward compatibility of products in the submission). In this case, I see no reason to treat transitions differently from other features in a state machine, which are identified by their (model element) identity. Cheers, Bran "Thomas Weigert" 01/19/2004 01:00 PM To: "Joaquin Miller" , "UML Superstructure FTF" cc: Subject: RE: ,sm, issue 6395 The reason for not redefining triggers is that the combination of trigger and state identifies the transition. Redefining the trigger would mean introducing a new transition, not changing an existing one (i.e., this is like changing the name of an operation). You can redefine the actions and final states of a transition, however. The redefinition semantics for statemachines has been carefully worked out over the course of more than a year by the SM team. All the best, Th. -----Original Message----- From: Joaquin Miller [mailto:joaquin.no.spam@acm.org] Sent: Monday, January 19, 2004 11:35 AM To: UML Superstructure FTF Subject: ,sm, issue 6395 OMG Issue 6395 Title: Transition triggers cannot be redefined ... Discussion: The rationale for not replacing the triggers is similar to that of redefinition rules for operations on a classifier. The set of triggers form a contract for the states specifying the signals it responds to. Modifying a trigger is practically similar to allowing deletion of a feature through a redefinition, which is not consistent with other redefinition contexts in UML. Eran, i feel the last sentence needs some work; maybe expansion, too. It's not clear to me why modifying is similar to deleting in this case. I don't deny it, not at all; i just don't see it. I wonder if there are other practical reasons for not redefining transition triggers. I would not be surprised. ....................................... (Also, a bit of copy editing: would it be useful to replace 'it' in the second sentence with the name of whatever it refers to? Might be either of these, or some third: The set of triggers form a contract for a classifier specifying the signals that classifier responds to. The set of triggers form a contract for a state, specifying the signals that state responds to. If the latter, then: The set of triggers form a contract for a classifier, specifying the signals that classifier responds to when in a particular state.) PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 To: "Thomas Weigert" Cc: "Joaquin Miller" , "Thomas Weigert" , "UML Superstructure FTF" Subject: RE: ,sm, issue 6395 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 20 Jan 2004 12:29:12 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/20/2004 12:13:32, Serialize complete at 01/20/2004 12:13:32 No, I never agreed to this. However, I do have to correct my previous statement: I now recall that I was not officially part of the U2P SM team because of a silly restriction that we had instituted that one could only be a member of at most two work groups. So, I missed out on the "conclusions" reached by the state machine group, although I do recall raising objections to this in some meeting when it was discussed (probably a plenary session). Of course, we never voted on resolutions in the U2P, so this one snuck through -- as did a few others, I am sure. It is quite a serious issue for IBM. Fortunately, I do not see any real problems with making triggers redefinable elements. Why it is necessary to identify a transition by its source state and trigger -- it should be identified like every other feature of a classifier. Thanks, Bran "Thomas Weigert" 01/20/2004 11:24 AM To: Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc: "Joaquin Miller" , "UML Superstructure FTF" Subject: RE: ,sm, issue 6395 Bran, first, I don't understand your statement about backwards compatibility. There was much discussion in the SM group regarding the semantics of inheritance (remember the questions of redefinition vs. replacement vs. deletion). As the UML 1.4 had nothing bindingly defined any more detailed definition would be a change. Knowing this, the SM team selected the current definitions. Specifically, for example, this rules out deletion semantics. This was a known change that was deemed to be for the better. You also supported this, at least in the Paris meeting where this issue was decided by the group. This was definitely not a situation where time ran out, but instead the result of a very focused discussion and analysis. Further, though, I think there is some confusion here with respect to the term "identity" which I probably chose unwisely. This was not a discussion on what model element is identical to what other model element. Instead, the question was as to what constitutes a conceptual unit in the specification. In this context, we had decided (in the SM team) that a transition is characterized by its source state and its trigger. Redefinition was worked out with respect to that. Similarly to the other parts of the spec where redefinitions are discussed. All the best, Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, January 19, 2004 2:19 PM To: Thomas Weigert Cc: Joaquin Miller; UML Superstructure FTF Subject: RE: ,sm, issue 6395 Well, I was on that SM (S&M?) team and in my opinion we never closed on it (instead, the time ran out and we defaulted). I disagree with the conclusion that the combination of trigger and state identifies a transition. (In particular, I disagree with it because it creates backward compatibility problems for our product -- and, I will remind everyone that, as a matter of principle, we always tried to support backward compatibility of products in the submission). In this case, I see no reason to treat transitions differently from other features in a state machine, which are identified by their (model element) identity. Cheers, Bran "Thomas Weigert" 01/19/2004 01:00 PM To: "Joaquin Miller" , "UML Superstructure FTF" cc: Subject: RE: ,sm, issue 6395 The reason for not redefining triggers is that the combination of trigger and state identifies the transition. Redefining the trigger would mean introducing a new transition, not changing an existing one (i.e., this is like changing the name of an operation). You can redefine the actions and final states of a transition, however. The redefinition semantics for statemachines has been carefully worked out over the course of more than a year by the SM team. All the best, Th. -----Original Message----- From: Joaquin Miller [mailto:joaquin.no.spam@acm.org] Sent: Monday, January 19, 2004 11:35 AM To: UML Superstructure FTF Subject: ,sm, issue 6395 OMG Issue 6395 Title: Transition triggers cannot be redefined ... Discussion: The rationale for not replacing the triggers is similar to that of redefinition rules for operations on a classifier. The set of triggers form a contract for the states specifying the signals it responds to. Modifying a trigger is practically similar to allowing deletion of a feature through a redefinition, which is not consistent with other redefinition contexts in UML. Eran, i feel the last sentence needs some work; maybe expansion, too. It's not clear to me why modifying is similar to deleting in this case. I don't deny it, not at all; i just don't see it. I wonder if there are other practical reasons for not redefining transition triggers. I would not be surprised. ....................................... (Also, a bit of copy editing: would it be useful to replace 'it' in the second sentence with the name of whatever it refers to? Might be either of these, or some third: The set of triggers form a contract for a classifier specifying the signals that classifier responds to. The set of triggers form a contract for a state, specifying the signals that state responds to. If the latter, then: The set of triggers form a contract for a classifier, specifying the signals that classifier responds to when in a particular state.) PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 OMG Issue 6395 Title: Transition triggers cannot be redefined Source: International Business Machines (Mr. Bran Selic, mailto:%20bselic@ca.ibm.com) Summary: Transition triggers do not appear to be redefinable in the current metamodel. There does not seem to be any reason for this restriction and it should be removed Discussion: The rationale for not replacing the triggers is similar to that of redefinition rules for operations on a classifier. The set of triggers form a contract for the states specifying the signals it responds to. Modifying a trigger is practically similar to allowing deletion of a feature through a redefinition, which is not consistent with other redefinition contexts in UML. Resolution: Closed, No change. From: Eran Gery To: Branislav Selic Cc: Guus Ramackers , UML Superstructure FTF Subject: RE: SM resolutions for ballot 5 Date: Mon, 19 Jan 2004 11:28:02 +0200 X-Mailer: Internet Mail Service (5.5.2656.59) Bran See inline. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Sun, January 18, 2004 9:11 PM To: Eran Gery Cc: Guus Ramackers; UML Superstructure FTF Subject: Re: SM resolutions for ballot 5 Thanks, Eran. (BTW, please use my new e-mail address and get rid of the old Rational one: it is no longer valid. The new one is in this e-mail.) I have some feedback now, but may have some more later as I review the proposed resolutions in more detail later: Issue 6229: Can you please provide the proposed diagram in your resolution text. I am really sorry to be so fussy, but, according to the formal OMG rules, we vote on the EXACT text (and graphics) and not a description of it -- the same goes for graphics. I may make an exception of metamodel changes in some cases, but even those should, in principle, be explicit. [EG] I will fix that for the ballot. The question I have is whether in order to get feedback we can send out drafts that outline the resolutions, and the have the final thing in the ballot. Also in terms of process it is more efficient, as if the FTF pushes back on a resolution outline there's no point to spend the time and do all this fine tuning. Issue 6256: I guess this has to be completed with the activities changes. So, until Conrad provides the appropriate changes, I do not think this is closed. Also, are there not text changes accompanying this: in the description of the associations of the corresponding metaclasses. Those too should be included in the resolution text. Until those changes are in there, I cannot consider this solution adequate. [EG] OK - So I will remoe it from the ballot. Issue 6381: It would be nice if we had agreement from Alan Moore (who raised the issue) before we submitted this one for a vote. [EG] I believe I have well addressed Alan's request for clarification. Also, I do not see anything controvercial here. Nevertheless I will solicit his feedback on the proposal. Issue 6395: The problem with this resolution is that (a) it creates backward compatibility problems (at least for Rose RT users) and (b) I do not agree that changing the trigger is tantamount to changing a feature definition. In most cases, it changes the way that an event is handled in a given state -- it does not remove the operation. I would like more discussion on this resolution. [EG] I will remove it from ballot5 then. By definition it can't be a backward compatibility issue as inheritance was not specified in UML 1. So compatibility should not be part of the debate. To repeat, I apologize for being such a stickler to precise formats, but I think that this is the only way that we can ensure that there are no misunderstandings about what goes into the final text of the revised submission. I plan to enforce this discipline consistently throughout the process. Thanks, 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 Eran Gery 01/18/2004 01:25 PM To: UML Superstructure FTF cc: Guus Ramackers , "Bran Selic (E-mail)" Subject: SM resolutions for ballot 5 Attached 11 proposed resolution for Statemachines. Most are trivial, few less... Thanks, Eran #### SM-proposals-ballot5.doc has been removed from this note on January 18, 2004 by Branislav Selic To: Eran Gery Cc: Guus Ramackers , UML Superstructure FTF Subject: RE: SM resolutions for ballot 5 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 19 Jan 2004 15:10:00 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/19/2004 15:10:01, Serialize complete at 01/19/2004 15:10:01 Hi Eran, It is quite OK to pass the outline of a resolution for comment. I had mistakenly assumed that you were submitting these issues to the ballot. Regarding issue 6395: It is precisely because state machine inheritance was not specified in UML 1.x that we have a compatibility problem. In principle, anything that was not specified in 1.x was an unbound semantic variation point. With the new stuff in 2.0, we are tightening things up and, hence, creating backward compatibility problems. In this case it does not matter anyway, since there are other reasons to object to the proposed resolution. However, I wanted to point out that this line of argument is, in my view, inappropriate. Thanks, Bran Eran Gery 01/19/2004 04:28 AM To: Branislav Selic/Ottawa/IBM@IBMCA cc: Guus Ramackers , UML Superstructure FTF Subject: RE: SM resolutions for ballot 5 Bran See inline. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Sun, January 18, 2004 9:11 PM To: Eran Gery Cc: Guus Ramackers; UML Superstructure FTF Subject: Re: SM resolutions for ballot 5 Thanks, Eran. (BTW, please use my new e-mail address and get rid of the old Rational one: it is no longer valid. The new one is in this e-mail.) I have some feedback now, but may have some more later as I review the proposed resolutions in more detail later: Issue 6229: Can you please provide the proposed diagram in your resolution text. I am really sorry to be so fussy, but, according to the formal OMG rules, we vote on the EXACT text (and graphics) and not a description of it -- the same goes for graphics. I may make an exception of metamodel changes in some cases, but even those should, in principle, be explicit. [EG] I will fix that for the ballot. The question I have is whether in order to get feedback we can send out drafts that outline the resolutions, and the have the final thing in the ballot. Also in terms of process it is more efficient, as if the FTF pushes back on a resolution outline there's no point to spend the time and do all this fine tuning. Issue 6256: I guess this has to be completed with the activities changes. So, until Conrad provides the appropriate changes, I do not think this is closed. Also, are there not text changes accompanying this: in the description of the associations of the corresponding metaclasses. Those too should be included in the resolution text. Until those changes are in there, I cannot consider this solution adequate. [EG] OK - So I will remoe it from the ballot. Issue 6381: It would be nice if we had agreement from Alan Moore (who raised the issue) before we submitted this one for a vote. [EG] I believe I have well addressed Alan's request for clarification. Also, I do not see anything controvercial here. Nevertheless I will solicit his feedback on the proposal. Issue 6395: The problem with this resolution is that (a) it creates backward compatibility problems (at least for Rose RT users) and (b) I do not agree that changing the trigger is tantamount to changing a feature definition. In most cases, it changes the way that an event is handled in a given state -- it does not remove the operation. I would like more discussion on this resolution. [EG] I will remove it from ballot5 then. By definition it can't be a backward compatibility issue as inheritance was not specified in UML 1. So compatibility should not be part of the debate. To repeat, I apologize for being such a stickler to precise formats, but I think that this is the only way that we can ensure that there are no misunderstandings about what goes into the final text of the revised submission. I plan to enforce this discipline consistently throughout the process. Thanks, 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 Eran Gery 01/18/2004 01:25 PM To: UML Superstructure FTF cc: Guus Ramackers , "Bran Selic (E-mail)" Subject: SM resolutions for ballot 5 Attached 11 proposed resolution for Statemachines. Most are trivial, few less... Thanks, Eran #### SM-proposals-ballot5.doc has been removed from this note on January 18, 2004 by Branislav Selic To: Eran Gery Cc: Guus Ramackers , UML Superstructure FTF Subject: RE: SM resolutions for ballot 5 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 19 Jan 2004 15:10:00 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/19/2004 15:10:01, Serialize complete at 01/19/2004 15:10:01 Hi Eran, It is quite OK to pass the outline of a resolution for comment. I had mistakenly assumed that you were submitting these issues to the ballot. Regarding issue 6395: It is precisely because state machine inheritance was not specified in UML 1.x that we have a compatibility problem. In principle, anything that was not specified in 1.x was an unbound semantic variation point. With the new stuff in 2.0, we are tightening things up and, hence, creating backward compatibility problems. In this case it does not matter anyway, since there are other reasons to object to the proposed resolution. However, I wanted to point out that this line of argument is, in my view, inappropriate. Thanks, Bran Eran Gery 01/19/2004 04:28 AM To: Branislav Selic/Ottawa/IBM@IBMCA cc: Guus Ramackers , UML Superstructure FTF Subject: RE: SM resolutions for ballot 5 Bran See inline. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Sun, January 18, 2004 9:11 PM To: Eran Gery Cc: Guus Ramackers; UML Superstructure FTF Subject: Re: SM resolutions for ballot 5 Thanks, Eran. (BTW, please use my new e-mail address and get rid of the old Rational one: it is no longer valid. The new one is in this e-mail.) I have some feedback now, but may have some more later as I review the proposed resolutions in more detail later: Issue 6229: Can you please provide the proposed diagram in your resolution text. I am really sorry to be so fussy, but, according to the formal OMG rules, we vote on the EXACT text (and graphics) and not a description of it -- the same goes for graphics. I may make an exception of metamodel changes in some cases, but even those should, in principle, be explicit. [EG] I will fix that for the ballot. The question I have is whether in order to get feedback we can send out drafts that outline the resolutions, and the have the final thing in the ballot. Also in terms of process it is more efficient, as if the FTF pushes back on a resolution outline there's no point to spend the time and do all this fine tuning. Issue 6256: I guess this has to be completed with the activities changes. So, until Conrad provides the appropriate changes, I do not think this is closed. Also, are there not text changes accompanying this: in the description of the associations of the corresponding metaclasses. Those too should be included in the resolution text. Until those changes are in there, I cannot consider this solution adequate. [EG] OK - So I will remoe it from the ballot. Issue 6381: It would be nice if we had agreement from Alan Moore (who raised the issue) before we submitted this one for a vote. [EG] I believe I have well addressed Alan's request for clarification. Also, I do not see anything controvercial here. Nevertheless I will solicit his feedback on the proposal. Issue 6395: The problem with this resolution is that (a) it creates backward compatibility problems (at least for Rose RT users) and (b) I do not agree that changing the trigger is tantamount to changing a feature definition. In most cases, it changes the way that an event is handled in a given state -- it does not remove the operation. I would like more discussion on this resolution. [EG] I will remove it from ballot5 then. By definition it can't be a backward compatibility issue as inheritance was not specified in UML 1. So compatibility should not be part of the debate. To repeat, I apologize for being such a stickler to precise formats, but I think that this is the only way that we can ensure that there are no misunderstandings about what goes into the final text of the revised submission. I plan to enforce this discipline consistently throughout the process. Thanks, 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 Eran Gery 01/18/2004 01:25 PM To: UML Superstructure FTF cc: Guus Ramackers , "Bran Selic (E-mail)" Subject: SM resolutions for ballot 5 Attached 11 proposed resolution for Statemachines. Most are trivial, few less... Thanks, Eran #### SM-proposals-ballot5.doc has been removed from this note on January 18, 2004 by Branislav Selic Subject: RE: Super FTF telecon on Wed. Aug. 18 - issue 6437 Date: Wed, 18 Aug 2004 05:43:50 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Super FTF telecon on Wed. Aug. 18 - issue 6437 Thread-Index: AcSEj3arftLItj3ySduRIgtMeO5IrQAA0g4wAA20qkAAFVPbIA== From: "Karl Frank" To: "Pete Rivett" , "Branislav Selic" , , X-OriginalArrivalTime: 18 Aug 2004 12:43:50.0414 (UTC) FILETIME=[0302B2E0:01C48521] Pete: The issue in 6437 is merely asking for reinstatement of targetScope (or at least having it be a standard tag). The proposed resolution makes it clear that isStatic serves as the UML 2 substitute for targetScope , so there is no need to reinstate targetScope or have a tag to express it. The resolution _does_ distinguish targetScope and ownerScope, it mentions them both and adds a "change from UML 1" section that documents the disappearance of both. isStatic in UML 2 relates to targetScope in so far as the enumerated datatype of targetScope was in UML 1 defined as providing two values (corresponding to isStatic = true and isStatic = false) saying whether a feature was to characterize instances or characterize classifications. End of story. -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Tuesday, August 17, 2004 10:39 PM To: Karl Frank; Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Super FTF telecon on Wed. Aug. 18 - issue 6437 With respect to the resolution for 6437 this does not distinguish between targetScope (the subject of the issue) and ownerScope - two separate metaattributes on Feature at UML 1.x. As I understand it isStatic at UML 2 relates to ownerScope not targetScope. I must admit I do not understand well how the latter was intended to be used in UML 1.x (there are no examples): it's defined (on Structuralfeature) as follows: targetScope Specifies whether the targets are ordinary Instances or are Classifiers. Possibilities are: . instance - Each value contains a reference to an Instance of the target Classifier. This is the setting for a normal Attribute. . classifier - Each value contains a reference to the target Classifier itself. This represents a way to store meta-information. With MOF now sharing the UML metamodel I see no reason for a separate indicator for "meta-information": rather than targetScope=classifier one would define the association to the appropriate metaclass - as we have in fact already done for Profiles. So I agree the resolution should be Closed no change, but not in the way explained which relates to ownerScope only. I am interested if anyone has any examples of the real use of targetScope at UML 1.x and whether I have the right end of the stick: we should get confirmation (e.g. from Guus who raised the issue) before proceeding with this new closure. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Tuesday, August 17, 2004 8:54 PM To: Branislav Selic; uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: RE: Super FTF telecon on Wed. Aug. 18 Eight proposals are attached. One, 6630, met with counterarguments in an earlier circulation. I am still convinced my proposal is in the best interest of UML modeling, so I am sending it out again with a little more argument to back it up. The obvious easy resolution is self-evident, just x-out the navigability from Supplier, but before I fall back to that easy answer, I want to try out my preferred solution first. Guus, one of your issues is in this batch, so you should look for it. 6616, humorously but accurately named "isRoot disappeared". Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 3:20 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Super FTF telecon on Wed. Aug. 18 DATE: Wed. Aug. 18 TIME: 11 am EDT (usual time) DURATION: 35 minutes NUMBER: 866 842-3549 (toll free North America) 1+613 787-5018 (International) PASSCODE: 8455752# Please plan to attend this one, it is very important. Thanks...Bran From: "Eran Gery" To: "Branislav Selic \(E-mail\)" Cc: Subject: RE: Ballot 24 resolutions from Bran - 6395 - Redefining triggers Date: Fri, 20 Aug 2004 11:30:42 +0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Bran - 6395 is controvercial. Many of us stick to the constraint that triggers shall not be changed Instead of going to infinite debates, lets change this into an SVP. Appologize for the late feedback, but in any case its less than 48 hours since you posted it... Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 5:54 AM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 resolutions from Bran Attached, please find proposals for 24 issue resolutions for ballot 24 (rhymes nicely, doesn't it?) Many of them are deferrals, but some of them are real resolutions. They cover a range of areas including classes, state machines, components, interactions, and "general" stuff. Since some of them were originally assigned to other FTF members, please have a look at them, just in case you are working on a resolution to the same issue. Regards, Bran To: "Eran Gery" Cc: uml2-superstructure-ftf@omg.org Subject: RE: Ballot 24 resolutions from Bran - 6395 - Redefining triggers X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 20 Aug 2004 08:17:53 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/20/2004 08:17:55, Serialize complete at 08/20/2004 08:17:55 I will pull it from the ballot. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 08/20/2004 04:30 AM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Ballot 24 resolutions from Bran - 6395 - Redefining triggers Bran - 6395 is controvercial. Many of us stick to the constraint that triggers shall not be changed Instead of going to infinite debates, lets change this into an SVP. Appologize for the late feedback, but in any case its less than 48 hours since you posted it... Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 5:54 AM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 resolutions from Bran Attached, please find proposals for 24 issue resolutions for ballot 24 (rhymes nicely, doesn't it?) Many of them are deferrals, but some of them are real resolutions. They cover a range of areas including classes, state machines, components, interactions, and "general" stuff. Since some of them were originally assigned to other FTF members, please have a look at them, just in case you are working on a resolution to the same issue. Regards, Bran From: "Thomas Weigert" To: "Branislav Selic" , , Subject: RE: Ballot 24 resolutions from Bran Date: Wed, 18 Aug 2004 22:29:33 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, comments so far.... 6395: This solution is not complete. If you want something to be redefinable, you also need to establish the redefinition context as well as add an association that redefines "redefinedElement". However, the resolution itself is inappropriate, I believe. There is a reason why Trigger is not redefinable: The souce state/trigger tuple uniquely identifies a transition. So redefining the Trigger would mean to redefine the transition. Thus you should just redefine the transition directly, by changing the Trigger, for example. There would be no point in redefining the Trigger itself. 6440: I personally think that the issuer raises a legitimate concern that many users will struggle with. The additions afforded by Component should just be available to StructuredClasses::Classes. This duplication of capability is more than confusing. 6902: In 6.3.3, there is a paragraph in black saying something about the causality model. The phrasing needs to clarified to make sure that the passing of information between behaviors in this manner is through the arguments passed by the invocation. As it stands now it reads as if two behaviors could wantonly exchange information during execution without sending messages. Any such information exchange that does not rely on the message exchange discussed in the basic causality model can only be through the parameters (or global variables). 6988: The use of "We may also represent..." is inappropriate wording for the specification. Use something like "An execution occurrence may also be represented by ...." instead. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, August 18, 2004 9:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 resolutions from Bran Attached, please find proposals for 24 issue resolutions for ballot 24 (rhymes nicely, doesn't it?) Many of them are deferrals, but some of them are real resolutions. They cover a range of areas including classes, state machines, components, interactions, and "general" stuff. Since some of them were originally assigned to other FTF members, please have a look at them, just in case you are working on a resolution to the same issue. Regards, Bran To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Ballot 24 resolutions from Bran X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 18 Aug 2004 23:50:05 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/18/2004 23:50:07, Serialize complete at 08/18/2004 23:50:07 Thanks, Thomas. Feedback embedded below: > 6395: This solution is not complete. If you want something to be > redefinable, you also need to establish the redefinition context as > well as add an association that redefines "redefinedElement". > > However, the resolution itself is inappropriate, I believe. There is > a reason why Trigger is not redefinable: The souce state/trigger > tuple uniquely identifies a transition. So redefining the Trigger > would mean to redefine the transition. Thus you should just redefine > the transition directly, by changing the Trigger, for example. There > would be no point in redefining the Trigger itself. There seems something wrong with the reasoning here: a transition is a model element that has identity. Redefining one of its "features" in a subclass does not change its identity. The purpose of redefinition is to maximize reuse. (Anyways, I'll think about this one a bit more -- I'm not thinking straight any more.) > 6440: I personally think that the issuer raises a legitimate concern > that many users will struggle with. The additions afforded by > Component should just be available to StructuredClasses::Classes. > This duplication of capability is more than confusing. Personally, I agree with you -- I do not see much value in the extra capabilities that components add. However, this is an argument that was prolonged and rather bitter and not one we will ever resolve by ourselves (the market will). I also believe that the folks who raised the issue, were not aware of the inheritance relationship between these two. What would you suggest? > 6902: In 6.3.3, there is a paragraph in black saying something about > the causality model. The phrasing needs to clarified to make sure > that the passing of information between behaviors in this manner is > through the arguments passed by the invocation. As it stands now it > reads as if two behaviors could wantonly exchange information during > execution without sending messages. Any such information exchange > that does not rely on the message exchange discussed in the basic > causality model can only be through the parameters (or global variables). What you have there is Cornad's last revision. I have no more energy or time to work on this, so I just put it out for comment. If people feel that it is busted, I will pull it and defer it until kingdom come. I am quite disappointed with how this one turned out. > 6988: The use of "We may also represent..." is inappropriate wording > for the specification. Use something like "An execution occurrence > may also be represented by ...." instead. Actually I agree with you. However, the colloquial "we" is used throughout this chapter and fixing it in this one place only makes it inconsistent. The problem of idiosyncratic writing and formatting styles is endemic throughout the spec. Thanks...Bran From: "Thomas Weigert" To: "Branislav Selic" , "Thomas Weigert" Cc: , Subject: RE: Ballot 24 resolutions from Bran Date: Wed, 18 Aug 2004 23:11:58 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, please see below... -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, August 18, 2004 10:50 PM To: Thomas Weigert Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Ballot 24 resolutions from Bran Thanks, Thomas. Feedback embedded below: > 6395: This solution is not complete. If you want something to be > redefinable, you also need to establish the redefinition context as > well as add an association that redefines "redefinedElement". > > However, the resolution itself is inappropriate, I believe. There is > a reason why Trigger is not redefinable: The souce state/trigger > tuple uniquely identifies a transition. So redefining the Trigger > would mean to redefine the transition. Thus you should just redefine > the transition directly, by changing the Trigger, for example. There > would be no point in redefining the Trigger itself. There seems something wrong with the reasoning here: a transition is a model element that has identity. Redefining one of its "features" in a subclass does not change its identity. The purpose of redefinition is to maximize reuse. (Anyways, I'll think about this one a bit more -- I'm not thinking straight any more.) Probably no great harm is done in making this redefinable, albeit I cannot quite see the application. However, if you decide to, you will have to add the associations described in the first paragraph, otherwise it does not work. > 6440: I personally think that the issuer raises a legitimate concern > that many users will struggle with. The additions afforded by > Component should just be available to StructuredClasses::Classes. > This duplication of capability is more than confusing. Personally, I agree with you -- I do not see much value in the extra capabilities that components add. However, this is an argument that was prolonged and rather bitter and not one we will ever resolve by ourselves (the market will). I also believe that the folks who raised the issue, were not aware of the inheritance relationship between these two. What would you suggest? Yes, this is a difficult question. I noticed that at least one of the popular UML text books got this all confused, so I worry about the user. Maybe a "Defer"? Your call. > 6902: In 6.3.3, there is a paragraph in black saying something about > the causality model. The phrasing needs to clarified to make sure > that the passing of information between behaviors in this manner is > through the arguments passed by the invocation. As it stands now it > reads as if two behaviors could wantonly exchange information during > execution without sending messages. Any such information exchange > that does not rely on the message exchange discussed in the basic > causality model can only be through the parameters (or global variables). What you have there is Cornad's last revision. I have no more energy or time to work on this, so I just put it out for comment. If people feel that it is busted, I will pull it and defer it until kingdom come. I am quite disappointed with how this one turned out. I understand your frustration. How about changing the first sentence following Fig. 2 to "The causality model also subsumes behaviors invoking each other and passing information to each other through arguments to parameters of the invoked behavior, as enabled by CallBehaviorAction (see page XXX)." > 6988: The use of "We may also represent..." is inappropriate wording > for the specification. Use something like "An execution occurrence > may also be represented by ...." instead. Actually I agree with you. However, the colloquial "we" is used throughout this chapter and fixing it in this one place only makes it inconsistent. The problem of idiosyncratic writing and formatting styles is endemic throughout the spec. I see. You are right. Making this one change is just a drop in the bucket... Thanks...Bran e-mail: bselic@ca.ibm.com