MARTE 1.1 RTF Avatar
  1. OMG Issue

MARTE11 — FLOW : MARTE and AADL alignment

  • Key: MARTE11-60
  • Legacy Issue Number: 14865
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The AADL flow path implementation semantics is not in line with MARTE mapping proposition.
    The AADL flow path declaration and implementation mapping need to be rethink

  • Reported: MARTE 1.0 — Tue, 15 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    AADL flow semantics has been introduced to specify information transmission
    (data/event) over connection and subcomponent, covering the whole component
    and subcomponent hierarchy. This aspect is complementary to the structural
    one.
    Declaration flow paths links flow sources to flow sinks of components in a black
    boxes approach.
    Implementation flow paths specify the way this information is convey over
    connections and flow paths.
    End-to-end flows represent a logical flow of data and control from a source to a
    destination through the system instance, meaning a sequence of threads that
    process and possibly transform the data. The corresponding end-to-end flow
    instance is determined by expanding the flow specifications through their flow
    implementations.
    As UML/MARTE concepts makes a full distinction between logical and structural
    aspects, and while AADL manipulates them jointly, different and not full satisfying
    solutions can be provided to represent AADL flows and end-to-end-flows.
    • UML sequence diagrams, using message exchanges between instances
    and associated ports
    • UML activity diagrams, more focusing on actions and their associated
    control flow. Flow path declaration representation will stay unmodified, using the UML
    “InformationFlow” concept.
    Flow path implementation will be represented in a sequence diagram, using UML
    “GeneralOrdering” elements to keep order preservation between messages
    received and sent over the ports, UML “Messages” will be used to represent
    communication between instances. The Name of the GeneralOrdering element
    will make reference to the FlowPath declaration; the name of the message will
    make reference to the connection conveying it.
    To provide a representative distinction and to avoid code generation ambiguity
    between end-to-end flow and flow implementation representations, both
    represented as sequence diagrams, the first one will be stereotyped “end-to-end
    flow”, the second one, will have the suffix: Flowname_flow_impl.
    AADL flow sinks and flow sources can’t be represented in UML/MARTE.

  • Updated: Fri, 6 Mar 2015 23:15 GMT