Source: Model Driven Solutions ( Ed Seidewitz)
The fUML subset currently specifically excludes streaming parameters (see constraint fuml_parameter_not_exception_not_streaming in subclause 184.108.40.206 of the fUML 1.4 specification). While the use of streaming parameters is not critical for the modeling of software behavior, it is very commonly used in SysML activity models. Indeed, there is currently work ongoing to specify precise execution semantics for SysML 1.7, which will need to include the semantics of streaming. But the semantics of streaming are not really specific to SysML, and would also be useful for modeling the equivalent of "lazy evaluation" of lists, even in software models. Therefore, the fUML subset should be updated to include streaming parameters and the semantics of streaming in the execution of activities.
Reported: FUML 1.4b1 — Sat, 1 Dec 2018 21:19 GMT
Disposition: Resolved — FUML 1.5
Add semantics for streaming
Including semantics for streaming parameters in fUML was of interest from the time the standard was first developed. While it was decided not to include originally, the lack of streaming semantics has been increasingly detrimental to the use of fUML in the core area of model simulation. Further, much of the functionality need for streaming actually already exists in the current fUML execution model.
During the execution of an activity, the primary effect of using streaming parameters is on the semantics of call actions. When calling a behavior without streaming parameters, values on the input pins of the calling action are made available to the executing behavior, then the behavior executes to completion, after which any output parameter values are placed on the output pins of the calling action. On the other hand, if a behavior with input streaming parameters is called, then the behavior may continue executing even after all non-streaming inputs have been processed, in order to handle additional inputs that may be received through the streaming parameters. Further, if the behavior has streaming output parameters, then values posted to those parameters will be immediately offered from the output pins of the calling action, even while the behavior is still executing.
There is a close similarity between the semantics of calling an activity and the semantics of a structured activity node with a similar body to the activity. To a certain extent, the semantics of such a call can be thought of as being much like doing a “macro insertion” of the body of the called activity as a structured activity node at the point of the call. The semantic model for a structured activity node gives it an associated activity node activation group, similar to the activation group associated with a called activity. The activity node activation group for the structured activity node activation is created when the structured activity node activation fires.
In this semantic analog, the pins for non-streaming parameters on the call action are analogous to pins on the structured activity node. This means that the normal rules for firing and completing the structured activity node as an action apply to these pins. Extending this analogy to streaming, the pins for streaming parameters on the call action do not correspond to pins on the structured activity node, but, rather, the incoming object flows for streaming input parameter values pass directly into the interior of the structured activity node, and the outgoing object flows for output parameter values pass directly out. This reflects the semantics that, once the structured activity node has fired, tokens can pass freely in and out on these flows. The semantics of a call action with streaming parameters is analogous. Once the call action has fired, tokens can continue to pass in and out on the flows attached to pins corresponding to streaming parameters, during the execution of the called activity.
In the current semantic model for structured activity nodes, when a structured activity node activation fires, activity edge instances are also created at this time for the object flows that cross the structured activity node boundary. These edge instances directly connect pin activations outside the nested activity node activation group to those inside, allowing the flow of tokens regardless of the presence of the surrounding structured activity node. In order to allow such streaming semantics for call actions, it is necessary to create similar connections across the activity node activation group for containing the call action activation and the group for the called activity, in order to allow values to stream in and out of the called activity during its execution. The proposal here is to provide the necessary connections by allowing a streaming parameter value to have a registered listener. With this approach when values are posted to the streaming parameter, they are distributed to the registered listener.
- In the case of an input parameter, the corresponding activity parameter node creates a listener for itself and registers it with the appropriate parameter value. The call action input pin activation then continues to post values to the streaming parameter value as it receives them at any time during the execution of the call action, and these are then forwarded via the listener to the activity parameter node to be offered within the called activity.
- For an output parameter, the call behavior action creates a listener for its corresponding output pin activation. The activity parameter node activation for the output parameter within the called activity execution then posts values to the streaming parameter value as it receives them at any time during the activity execution, and these are then forwarded via the listener to the output pin activation to be offered within the calling activity. Note that there is no direct connection between the activity parameter node activation for an output parameter and the streaming parameter value object for that parameter. Instead, the activity parameter node activation obtains the appropriate parameter value from its activity execution when necessary to post new values.
In addition to new execution model class related to the listeners, this mechanism requires some significant changes to the specification of, particularly, the classes ActivityParameterNodeActivation, ActionActivation and CallActionActivation. However, the proposed streaming semantics are a clear extension of those currently specified for execution within an activity, and the adding this capability is entirely backwards compatible with previous fUML-conformant models that do not use streaming.
Updated: Fri, 18 Sep 2020 17:03 GMT