UML 2.2 RTF Avatar
  1. OMG Issue

UML22 — UML 2 Super/Interactions/Need constraints that cover multiple Lifelines

  • Key: UML22-34
  • Legacy Issue Number: 7161
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Consider an Interaction that describes collaboration of several parts of a classifier that owns some attributes.
    None of the parts own this attribute. I need to be able to describe a constraint, involving these attributes.

    Or when the overall classifier has a State Machine describing its overall behavior, and we want to refer to these states in an Interaction.

    In order to achieve this, it would be desirable to use:
    1. A guard that covers more than one lifeline (represents a guard involving the attributes, "global" to the set of Lifelines)
    2. A state symbol that covers more than one lifeline (represents a state invariant refering to the state of some state machine "global" to the set of Lifelines)
    3. A state invariant covering more than one lifeline (represents an invariant involving the attributes, "global" to the set of Lifelines)

  • Reported: UML 1.5 — Mon, 15 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion:
    Although this is a reasonable feature to request, it is an enhancement that exceeds the scope of the RTF. One of the main issues with it is that the semantics of defining such constraints in a distributed environment are not simple and require some serious consideration. The issue here is that Interactions consider all lifelines as potentially concurrent, and the restrictions on guards reflect this to prevent specifying distributed decisions that would imply implicit synchronization. The fact is, however, that many systems are such that it is known that the lifelines are not concurrent and checking remotely or on enclosing objects is not really hazardous. The problem is that we do not have a good way to define this in the specification. This is of course not dependent upon Interactions, but is a feature of all of UML. There seems to be a need to define object groups that share the same "thread" and are only pseudo-concurrent. If we had had such a construct, the guard could cover any subset of such a "same-thread-set-of-objects".
    Disposition: Closed Out Of Scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT