MARTE — the GCM chapter should define a causality model for flows

Subject: the GCM chapter should define a causality model for flows. Details: the GCM chapter introduces the notion of flow port as a structural feature of a structured class. However, the specification does not states what happens when a flow comes into / get out of a flow port. There should be a reference to behaviors owned by this structured class. Proposed resolution: enhance the GCM chapter.

This issue concerns the semantics of FlowPorts and indeed its underlying causality model.
Indeed, the issue 11840 is also clearly related to this issue. Issue 11840 summary is following:
“Subject: Support for flows in activities. Details: The current specification provides a limited
support for flow in activity diagrams. The GCM chapter introduces the FlowSendAction
stereotype. However, there is no way to indicate the pins used to define the data to send. At the
same time, there is no action (such as FlowReceiveAction) to indicate how to receive a flow. It
seems that activity parameters are an interesing alternative to specify incoming and outgoing
flows in activity diagrams (SysML follows this approach). Proposed resolution: Remove the
FlowSendAction stereotype and provide a support for BOTH incoming and outgoing flows through
activity parameters (maybe a stereotype would need to be defined here).” Both issues are treated
in this document."
As stated by Conrad Bock in [Conrad Bock: “UML 2 Activity and Action Models Part 4: Object
Nodes”, Journal of Object Technology, vol.3, no.1, pp.27-41], there are traditionally two ways for
considering dataflow communications:

• a “pull” semantics with the following characteristics:
  o Passive: the arrival of data in the data store does not trigger behaviors per se. It
  is indeed additional actions, for example time-triggered actions, that when
  needed pull the data from the data store. o Non-depleting: the use of data in the store does not remove it from the store
• a “push” form of data flow and storage, with the following characteristics:
  o Active: the arrival of data in the data store triggers execution of some behavior.
  o Depleting: the data arriving on the port is not store locally. Data is indeed
  conveyed to the triggered behavior.
  The objective of this resolution is to enable GCM's users to address both forms of data flow. For
  that purpose, we are making the following proposal:
• Data sending:
  o The «SendFlowAction» stereotype is removed (NOTE: in this case, one resolves
  in the same time the issue 12286. This latter was then set to Duplicate/Merged
  and refer this resolution). Indeed, the standard UML SendObjectAction is already
  well suited to express a data emission. The execution of a SendObjectAction
  results in the emission of a message encapsulating the sent object (which can be
  an instance of any classifier). Note that, SendObjectAction inherits from
  InvocationAction and as defined in the composite structure package, this action
  already enables to specify a target port for the action (see, UML2 spec., section
  9.3.9 on p. 182).
  o In addition to specify the flowProperty on which a SendObjectAction is applied (or
  more generally to specify the feature of a non-atomic FlowPort or
  ClientServerPort on which an InvocationAction is applied), one introduces the
  «GCMInvocationAction» stereotype which extends InvocationAction (from
  InvocationActions). In this case, the stereotyped invocation action targets a nonatomic
  flow FlowPort or a featureBased ClientServerPort (i.e. a ClientServerPort
  which have been specified using a ClientServerSpecification. Cf resolution 11820
  for a precise definition of these concepts), and one of its features. For example, if
  a non-atomic output flowport has two flow properties (i.e. it is typed by a
  FlowSpecification with two out flow properties), the ‘onPort’ property of
  SendObjectAction enables to specify that this flow port is used as a target of the
  send. In addition, the ‘onFeature’ property of «GCMInvocationAction» enables to
  specify which of the two flow properties the target of the send is.
• Data reception events: Once we have dealt with data sending, it is also required to be able to deal with
  data receipt. For that purpose, we introduce the «DataEvent» stereotype. This
  latter extends the UML's AnyReceiveEvent metaclass. This metaclass is the
  most generic kind of concrete MessageEvent. DataEvents are raised when data
  (which have been sent as a consequence of a SendObjectAction) are received
  on a behavioral FlowPort. In the case of a non-behavioral FlowPort, data are
  propagated along associated delegation connectors, and no event is raised at all
  (just as for standard UML Ports). DataEvents raised as a consequence of data
  receptions on behavioral ports are then stored in the event pool of the owning
  object just like any other kind of UML events would be. It implies that the UML
  semantic variation points related to event management also applies to
  «DataEvent» (and typically concerning the way events are ordered in and
  extracted from the event pool). This is however fully in line with the philosophy of
  the GCM which aims to be as generic as possible. Particular semantic
  interpretation on the way DataEvent are dispatched and consumed would thus
  require a specialization of the GCM, such as the one proposed in the HLAM subprofile
  of MARTE. The definition of «DataEvent» mimics the definition of the UML
  SignalEvent metaclass, in the sense that it is possible to attach a classifier to the
  event in order to characterize it (just as it is possible to attach a Signal to a
  SignalEvent). More precisely, the classifier that can be attached to the event
  must be a classifier that can be used to type flow ports or flow properties (i.e.,
  DataType and Class). In order to avoid confusion with SignalEvent, a constraint
  imposes that the classifier associated with the DataEvent cannot be a Signal.
  DataEvents can then be exploited by triggers of transitions within a
  StateMachine, or by triggers of AcceptEventActions within an Activity. Hence, it is
  possible to specify reactions to reception of data of a particular type (i.e., data
  which are typed by a classifier compatible with the classifier associated with the
  DataEvent). Note that such triggers can natively be related to particular ports i.e.,
  the ports from which the DataEvent have been raised.
  o UML Triggers can natively be related to a particular port. Additionally, in MARTE,
  we introduce the possibility to specify more precisely the origin of a trigger. The
  «GCMTrigger» stereotype is defined for that purpose. It extends the UML Trigger
  metaclass and it owns a property that enables to specify which feature of the
  FlowSpecification of a FlowPort or ClientServerSpecification of a
  ClientServerPort (cf. resolution 11820 for details on ClientServerPort) is the
  origin of the trigger. It is thus possible to specify reactions that are, for example,
  related to the occurrence of a given DataEvent on a non-atomic FlowPort, and for a particular FlowProperty. Of course this advanced mechanism is mainly
  interesting for non-atomic port, because in other cases, there are no possible
  ambiguities.
  The concepts denoted below were defined to support the “push” semantic of MARTE's ports
  (including flow and client-server ports), and they are well aligned with the standard event model.
  The “active” characteristic of the «push» semantics is covered because the reception of a data on
  a behavioral FlowPort raises a DataEvent, which can be used as a trigger in a behavior. The
  “depleting” characteristics of the "push" semantics is covered because, according to the standard
  UML semantics, once an event has been consumed by a behavior, it is no longer available in the
  event pool to trigger other behaviors.
  Concerning the “pull” semantics of MARTE's FlowPorts, no particular extensions are required. A
  simple modeling pattern (suggested by SysML and Conrad Bock’s article, respectively for the
  usage of delegation connectors and the usage of properties for persistent data storage and nondepleting
  data use) is indeed sufficient as explained next.
  According to the UML 2 superstructure, a non-behavioral port should have delegation connectors,
  so that incoming requests can be propagated along these connectors to parts of the composite
  structure owning the port (in other case as said previously and as it is defined in the UML2
  specification, messages are lost). Then there are two possibilities for the parts connected to the
  ports: either they delegate also the requests to some of their parts, or they deal directly with the
  request triggering the execution of one of their behaviors. This case fits also with the MARTE's
  client-server port and it is thus reasonable to have a similar mechanism for MARTE's flow ports.
  At the end of the delegation chain, a non-behavioral input atomic flow port should have at least
  one delegation connector targeting a part which is type-compatible with the port (if there is no
  delegation connector, the data is simply lost). When a data is received on such a port and then
  delegated through the connector, no DataEvent is raised (which is in line with the “passive”
  aspect of the “pull” form of data flow). In this case, the semantics says that the data is written in
  the part targeted by the delegation connector, replacing any existing value. The data stored on
  the targeted properti can then be used when needed by the behavior of the component, typically
  via a ReadStructuralFeatureAction (which has no depleting effect on the value of the property).
  For more complex storage policies, we propose to introduce the « DataPool » stereotype. Two
  default storage and selection policies are defined: LIFO and FIFO. « DataPool » can also be
  associated with user-defined policies, via its ‘insertion’ and ‘selection’ properties. These
  properties explicitly reference UML Behaviors, respectively describing how a data is to be
  inserted in the property, and how a set of data is to be selected from the property. When a data is
  received on a FlowPort with a delegation connector targeting a property stereotyped with
  «DataPool», the semantics says that the data is inserted in the pool following the description provided by ‘insertion’ behavior (Concerning the usage of the ‘selection’ behavior, see the
  following description concerning the usage of connectors between properties and behavior
  parameters).
  This rule can be extended for non-atomic flow ports, where each flow property should be
  associated with a delegation connector (by convention, when one of the flow properties is not
  associated with a delegation connector, the FlowPort should be behavioral, and data received on
  this FlowPort and related to this FlowProperty will raise a DataEvent).
  Finally, issue 11840 proposes the possibility of an explicit “binding” between flow ports of a
  component and parameters of the component behaviors. This additional proposition is an
  alternative solution to the mechanisms described below. Moreover, let's notice that SysML is
  relying on this mechanism, but SysML is lacking two points: firstly, SysML does not define indeed
  clearly how that works (i.e., either by name matching between ports and parameters, or
  (probably) by using a BindingConnector), and secondly SysML does define also it’s the clear
  meaning of this mechanism. Hence, we provide next a clear semantics for this mechanism
  aligned (i.e., compatible) with the “pull” and “push” semantics we have considered until now:
• “pull” semantics: A standard UML connector is expressed between a property (which
  used to be the target of a delegation connector, but does not need to be) of the
  component and an IN or INOUT parameter of a behavior or operation (which would
  typically belong to the owner of the port, but does not need to be). It means that the
  values passed to the parameters of the behavior (or operation) when the behavior is
  called are actually the values of the connected properties. The connectors just prevent
  from the usage of an explicit ReadStructuralFeatureAction to get the value associated
  with the properties. Note that this usage of connectors is compatible with the abstract
  syntax of UML, since both Property and Parameter are ConnectableElements. In the
  case where the connected property is stereotyped with « DataPool », its ‘selection’
  Behavior is used to compute the values to be selected (from the property) and to be
  passed to the parameter.
• “push” semantics: Connectors are directly expressed between input non-behavioral flow
  ports (respectively the output flow ports) and input parameters (respectively the output
  flow ports) of the classifierBehavior Activity of the composite structure owning the ports.
  The idea is that each incoming data received on a flow port will be propagated to a
  parameter of the classifier behavior. The data associated with the input message will be
  handled as a token on an ActivityParameterNode corresponding to the parameter. The
  token will then enter the chain of computation described by the set of object flows and
  actions of the activity (with respect to the token propagation semantics of UML activities). At the end of the computation chain, tokens will be propagated to
  ActivityParameterNodes corresponding to output parameters of the Activity. If a
  delegation connector is modeled between such a parameter and an output flow port of
  the composite structure, a message containing the produced data will be emitted through
  the flow port (just as if SendObjectAction with this value would have been applied on the
  flow port). The standard semantics of UML activities implies that tokens related to
  required input parameters must be available for the called activity to start, and that token
  corresponding to output parameters will be made available on corresponding output pins
  once the activity is finished. Note that if one wants the activity modeling the classifierbehavior
  to be able to accept inputs (on its input parameters) and produce outputs (on its
  output parameters) while it is executing, input and output parameters of the activity
  should typically be specified as streaming parameters. Examples are provided in the
  revised text.