FUML12 — ReadSelfAction is not compliant with UML 2.4.1 Superstructure Specification (formal/11-08-06)

ReadSelfAction issue - in a scenario where an activity with a context (classifier) calls (CallBehaviorAction) an activity owned by other classifier, the ReadSelfAction (from fUML execution model) violates the constraint defined in UML superstructure 2.4.1 because it returns the context from the caller activity (not necessary the same classifier).

8.6.3.2.10 ReadSelfActionActivation
Reference context = new Reference();
context.referent = his.getExecutionContext();

11.3.36 ReadSelfAction (from IntermediateActions), pg. 280 - UML 2.4.1
[3] The type of the result output pin is the host classifier.
self.result.type = self.context

fUML constrains calls to behaviors with contexts

The semantics of ReadSelfAction is exactly as called for by the UML standard: it retrieves the context object for an execution. The issue raised is really a question about the propagation of the dynamic context object specified as part of the semantics of CallBehaviorAction.

But note that, in 7.5.2.2.3 CallBehaviorAction, the following constraint is included on the fUML subset of the UML abstract syntax:

[3] proper_context
If the behavior has a context, it must be the same as the context of the enclosing activity or a (direct or indirect) superclass of it.

self.behavior.context->notEmpty() implies
  union(self.context.allParents())->includes(self.behavior.context)

[Actually, the OCL here has an error. The call to {{union}} should be {{self.context->union}}. This will be submitted as a separate issue.]

If this constraint is satisfied, then the propagation of the context object in 8.6.2.2.3 CallBehaviorActionActivation is consistent, as noted in the following comment on the doAction operation: [Note that this requires the behavior context to be compatible with the type of the current contect object.]. If the above constraint is violated, then the model is outside the fUML subset, and fUML does not provide semantics for it.

This constraint was added to the abstract syntax in order to be able to provide reasonable semantics at all for making a call to a behavior with a context. Unless one can propagate the caller's context, it is not clear what context object one would give to the new execution of the called behavior. Unlike the case of an operation call, in which the target object of the call becomes the context for the execution of the operation method, no target object is specified for a behavior call. However, if the above constraint holds, then the called behavior's context is guaranteed to be consistent with the caller's context, and it is then valid to propagate the dynamic context object at runtime. (This might be useful, e.g., for doing a functional decomposition of a behavior that is the method of an operation.)

And, in this case, the current semantics for ReadSelfAction is then completely consistent. While a called behavior may have a different context classifier than the calling behavior, the constraint ensures that it will at least be a generalization of the context classifier of the calling behavior, so the runtime context object from the calling execution will conform to the caller's context classifier. On the other hand, if the called behavior does not have a context classifier, then an execution of the called behavior will have itself as its context object, which will then be (correctly) what is returned by a ReadSelfAction.