SYSML12 — Using composite association between activities

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.

Resolution:
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