Issue 19007: ReadSelfAction is not compliant with UML 2.4.1 Superstructure Specification (formal/11-08-06) (fuml-rtf) Source: (, ) Nature: Revision Severity: Minor Summary: 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 Resolution: 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. Revised Text: Actions taken: October 11, 2013: received issue October 8, 2015: Closed; No Change December 22, 2015: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 11 Oct 2013 11:54:09 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Alessandro Gerlinger Romero Employer: mailFrom: romgerale@yahoo.com.br Terms_Agreement: I agree Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) Section: 8.6.3.2.10 FormalNumber: ptc/2012-10-18 Version: 1.1 RTF Beta Doc_Year: 2012 Doc_Month: October Doc_Day: 18 Page: 306 Title: ReadSelfAction is not compliant with UML 2.4.1 Superstructure Specification (formal/11-08-06) Nature: Revision Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: 131.246.160.228 Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36 Time: 11:54 AM Description: 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