Issue 6397: UML 2 Super / state machines / restriction on redefining transitions (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: On page 502, there is a constraint that says that if a transition has a non-unique par <source state, trigger> it cannot be redefined. This introduces what appears to be an unnecessary an inconsistency and should be removed. Resolution: see above Revised Text: Actions taken: October 31, 2003: received issue March 8, 2005: closed issue Discussion: The rationale for the limitation is to allow visual determination of the redefinition relationships without relying on tool specific Capabilities. However in these cases where such graphical ambiguity exist, it can be resolved by showing the conflicting transition(s) in the derived statemachine as well. Furthermore, several tools supporting statemachine redefinition always show all the “inherited” transitions so such disabiguity does not exist in the first place. Therefore the proposed resolution is to remove the constraint. That is, remove the last paragraph of the Transition redefinition subsection on page 502: Transitions are identified by the (source state, trigger) pair. Only transitions that can be uniquely defined by this pair can be redefined. This excludes transitions with the same source, same trigger but different guards from being redefined. End of Annotations:===== ubject: UML 2 Super / state machines / restriction on redefining transitions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 31 Oct 2003 20:10:17 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 10/31/2003 20:10:24, Serialize complete at 10/31/2003 20:10:24 On page 502, there is a constraint that says that if a transition has a non-unique par it cannot be redefined. This introduces what appears to be an unnecessary an inconsistency and 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 OMG Issue 6397 Title: restriction on redefining transitions Source: International Business Machines (Mr. Bran Selic, mailto:%20bselic@ca.ibm.com) Summary: On page 502, there is a constraint that says that if a transition has a non-unique source/trigger pair it cannot be redefined. This introduces what appears to be an unnecessary an inconsistency and should be removed. Discussion: The rationale for the limitation is to allow visual determination of the redefinition relationships without relying on tool specific Capabilities. However since the reason for this limitation is not based on semantics, the issue should be accepted. The statement asserting this in the redefinition shall be removed. Disposition: Resolved. e-mail: bselic@ca.ibm.com OMG Issue 6397 Title: restriction on redefining transitions Source: International Business Machines (Mr. Bran Selic, mailto:%20bselic@ca.ibm.com) Summary: On page 502, there is a constraint that says that if a transition has a non-unique source/trigger pair it cannot be redefined. This introduces what appears to be an unnecessary an inconsistency and should be removed. Discussion: The rationale for the limitation is to allow visual determination of the redefinition relationships without relying on tool specific Capabilities. However in these cases where such graphical ambiguity exist, it can be resolved by showing the conflicting transition(s) in the derived statemachine as well. Furthermore, several tools supporting statemachine redefinition always show all the .inherited. transitions so such disabiguity does not exist in the first place. Therefore the proposed resolution is to remove the constraint. Disposition: Resolved. OMG Issue 6397 Title: restriction on redefining transitions Source: International Business Machines (Mr. Bran Selic, mailto:%20bselic@ca.ibm.com) Summary: On page 502, there is a constraint that says that if a transition has a non-unique source/trigger pair it cannot be redefined. This introduces what appears to be an unnecessary an inconsistency and should be removed. Discussion: The rationale for the limitation is to allow visual determination of the redefinition relationships without relying on tool specific Capabilities. However in these cases where such graphical ambiguity exist, it can be resolved by showing the conflicting transition(s) in the derived statemachine as well. Furthermore, several tools supporting statemachine redefinition always show all the .inherited. transitions so such disabiguity does not exist in the first place. Therefore the proposed resolution is to remove the constraint. That is, remove the last paragraph of the Transition redefinition subsection on page 502: Transitions are identified by the (source state, trigger) pair. Only transitions that can be uniquely defined by this pair can be redefined. This excludes transitions with the same source, same trigger but different guards from being redefined. Disposition: Resolved. OMG Issue 6397 Title: restriction on redefining transitions Source: International Business Machines (Mr. Bran Selic, mailto:%20bselic@ca.ibm.com) Summary: On page 502, there is a constraint that says that if a transition has a non-unique source/trigger pair it cannot be redefined. This introduces what appears to be an unnecessary an inconsistency and should be removed. Discussion: The rationale for the limitation is to allow visual determination of the redefinition relationships without relying on tool specific Capabilities. However in these cases where such graphical ambiguity exist, it can be resolved by showing the conflicting transition(s) in the derived statemachine as well. Furthermore, several tools supporting statemachine redefinition always show all the .inherited. transitions so such disabiguity does not exist in the first place. Therefore the proposed resolution is to remove the constraint. That is, remove the last paragraph of the Transition redefinition subsection on page 502: Transitions are identified by the (source state, trigger) pair. Only transitions that can be uniquely defined by this pair can be redefined. This excludes transitions with the same source, same trigger but different guards from being redefined. Disposition: Resolved. OMG Issue 6397 Title: restriction on redefining transitions Source: International Business Machines (Mr. Bran Selic, mailto:%20bselic@ca.ibm.com) Summary: On page 502, there is a constraint that says that if a transition has a non-unique source/trigger pair it cannot be redefined. This introduces what appears to be an unnecessary an inconsistency and should be removed. Discussion: The rationale for the limitation is to allow visual determination of the redefinition relationships without relying on tool specific Capabilities. However in these cases where such graphical ambiguity exist, it can be resolved by showing the conflicting transition(s) in the derived statemachine as well. Furthermore, several tools supporting statemachine redefinition always show all the .inherited. transitions so such disabiguity does not exist in the first place. Therefore the proposed resolution is to remove the constraint. That is, remove the last paragraph of the Transition redefinition subsection on page 502: Transitions are identified by the (source state, trigger) pair. Only transitions that can be uniquely defined by this pair can be redefined. This excludes transitions with the same source, same trigger but different guards from being redefined. Disposition: Resolved.