- 
                            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