SysML 1.2 RTF Avatar
  1. OMG Issue

SYSML12 — Using composite association between activities

  • Key: SYSML12-22
  • Legacy Issue Number: 13924
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Using composite association between activities. The actual nature of the properties corresponding to the association end is not clear. Either it is a CallBahaviorAction and then it is not an instance of associated activity, or it is an activity execution and then the association should be derived beacause it depends on the CallBehaviorActions owned by the activity. Proposed resolution: State that composite associations between activities are always derived from the CallBehaviorAction owned by the activity.

  • Reported: SysML 1.1 — Thu, 7 May 2009 04:00 GMT
  • Disposition: Closed; No Change — SysML 1.2
  • Disposition Summary:

    When an Activity property corresponds to a CallBehaviorAction of another
    Activity, the value at “runtime” is an instance of the called activity (it can’t be an
    instance of the CallBehaviorAction, since Actions are not Classifiers). This value
    is not derived from anything else, it’s a new instance of the activity, a new
    execution (associations themselves are not derived, only their instances/links).
    This information is in the section on CallBehaviorAction. At the time the section
    on CallBehaviorAction was written, it was decided not to require a one-to-one
    correspondence between property names and CallBehaviorActions, even though
    that would typically be true.
    Comment from filer:
    Except if i miss something, the only way to create an instance of an
    activity from another activity is to execute an invocation action. That is: an
    activity execution won't instanciate any other activity if it doesn't own the
    corresponding invocation action, and conversely any execution of an
    CallBehaviorAction will instantiate the corresponding behavior. Then, for a
    given Activity, owned invocation action (e.g. CallBehaviorAction) and
    activity instance owned by composition are actually not independent. If no
    constraint is defined between these two properties the activity definition
    can be inconsistent. That's why I suggest that composite associations
    between activities should be derived. The two composition associations
    you describe above are at different metalevels. The link between Activity
    and CallBehaviorAction is specified by an M2 (metamodel) association
    and the link itself exists at M1 (user model). The link between Activity and Activity (due to invocation) is specified at M1 and
    the link itself exists at M0 (runtime). The constraints between these two
    associations is semantics, in the mathmatical sense, and is described in
    UML/SysML in natural language (see Executable UML for a mathematical
    specification of semantics). The constraints in the UML/SysML spec in the
    Constraints sections are syntactic, that is, between M2 and M1.
    Disposition: ClosedNoChange

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