MARTE 1.0b2 FTF Avatar
  1. OMG Issue

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

  • Key: MARTE-86
  • Legacy Issue Number: 11839
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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.

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    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
      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
      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.
  • Updated: Fri, 6 Mar 2015 20:58 GMT