10.2    Flow Implementations

(1)   Component implementations must provide an implementation for each flow specification.  A flow implementation declaration identifies the flow through its subcomponents. In case of a flow source specification, it starts from the flow source of a subcomponent or from the component implementation itself and ends with the port named in the flow source specification.  In case of a flow sink specification, the flow implementation starts with the port named in the flow sink specification declaration and ends within the component implementation itself or with the flow sink of a subcomponent. In case of a flow path specification, the flow implementation starts with the in_flow port and ends with the out_flow port.  Flow characteristics modeled by properties on the flow implementation are constrained by the property values in the flow specification.  Flow implementations can be declared to be mode-specific.

Syntax

flow_implementation ::=
    ( flow_source_implementation
    | flow_sink_implementation
    | flow_path_implementation )
    [ { { property_association }+ } ]
    [ in_modes_and_transitions ] ;
 
flow_source_implementation ::=
    flow_identifier : flow source
      { subcomponent_flow_identifier -> connection_identifier -> }*
      out_flow_feature_identifier 
 
flow_sink_implementation ::=
    flow_identifier : flow sink
      in_flow_feature_identifier        
      { -> connection_identifier -> subcomponent_flow_identifier }*
 
flow_path_implementation ::= 
    flow_identifier : flow path
      in_flow_feature_identifier        
      [ { -> connection_identifier -> subcomponent_flow_identifier }+
         -> connection_identifier ]
      -> out_flow_feature_identifier 
 
 
subcomponent_flow_identifier ::= 
    ( subcomponent_identifier [ . flow_spec_identifier ] ) 
    | data_component_reference
 
data_component_reference ::=
    data_subcomponent_identifier | requires_data_access_identifier
    | provides_data_access_identifier

Naming Rules

(N1)     The flow identifier of a flow implementation must name a flow specification in the component type.  A flow implementation name may appear more than once in each component implementation, either as alternative flows under different modes or transitions (using in modes), or to represent multiple flows for the same flow specification such as replicated flows to support redundancy or different flows for different elements of feature groups.

(N2)     The in_flow and out_flow feature identifier in a flow implementation must refer to the same in_flow and out_flow feature as the flow specification it implements.

(N3)     The subcomponent flow identifier of a flow implementation must name a subcomponent and optionally a flow specification in the component type of the named subcomponent, or it must name a data component in the form of a data subcomponent, provides data access, or requires data access.

(N4)     In case of a flow source implementation the flow identifier of the first subcomponent must refer to a flow source or a data component.

(N5)     In case of a flow sink implementation the flow identifier of the last subcomponent must refer to a flow sink or a data component.

(N6)     In all other cases the subcomponent flow identifier must refer to a flow path or a data component.

(N7)     The connection identifier in a flow implementation must refer to a connection in the component implementation.

Legality Rules

(L1)      The source of a connection named in a flow implementation declaration must be the same as the in_flow feature of the flow implementation, or as the out flow feature of the directly preceding subcomponent flow specification, if present. 

(L2)      The destination of a connection named in a flow implementation declaration must be the same as the out flow feature of the flow implementation, or as the in_flow feature of the directly succeeding subcomponent flow specification, if present. 

(L3)      The in_flow feature of a flow implementation must be identical to the in_flow feature of the corresponding flow specification. The out_flow feature of a flow implementation must be identical to the out_flow feature of the corresponding flow specification.

(L4)      If the component implementation provides mode-specific flow implementations, as indicated by the in modes statement, then the set of modes in the in modes statement of all flow implementations for a given flow specification must include all the modes for which the flow specification is declared.

(L5)      In case of a mode-specific flow implementation, the connections and the subcomponents named in the flow implementation must be declared at least for the modes listed in the in modes statement of the flow implementation.

(L6)      Flow implementations may be declared from an in_flow feature directly to an out_flow feature.

(L7)      Component type extensions may refine flow specifications and component implementation extensions may refine subcomponents and connections with in modes statements. A flow implementation that is inherited by the extension must be consistent with the modes of the refined flow specifications, subcomponents, and connections if named in the flow implementation according to rules (L4) and (L5). Otherwise, the flow implementation has to be defined again in the component implementation extension and satisfy rules (L4) and (L5).

(L8)      Component implementation extensions may declare flow implementations for flow specifications that were already declared in the component implementation being extended.

Consistency Rules

(C1)If the component implementation has subcomponents, then a flow implementation declaration is required for each flow specification for a fully refined flow. 

Semantics

(2)   A flow implementation declaration represents the realization of a flow specification in the given component implementation.  Different mode-specific flow implementations may be declared for the same flow specification. 

(3)   A flow path implementation starts with the port or data access named in the corresponding flow specification, passes through zero or more subcomponents, and ends with the port or data access named in the corresponding flow specification (see Figure 20).  A flow source implementation ends with the port or data access named in the corresponding flow specification.  A flow sink implementation starts with the port or data access named in the corresponding flow specification. A flow path implementation may specify a flow that goes directly from an in_flow feature to an out_flow feature without any connections in between.

(4)   A flow implementation may refer to subcomponents without identifying a flow specification in the subcomponent.  In this case,  (a) an unnamed flow specification is assumed to exist from the destination port of the preceding connection to the source port of the succeeding connection if no flow specification is declared for the subcomponent, (b) it represents a separate flow for each of the flow specifications of the subcomponent.

(5)   A flow implementation within a thread may be modeled as flow through subprogram calls via their parameters.  If the call is to a subprogram via a subprogram access feature, the flow goes to the subprogram instance being called.  This may be a subprogram in a different thread that is called remotely.

(6)   A flow through a component may transform the input into a different form for output.  In case of data, event data port, or data access, the data type may change. Similarly the flow path may be between different port types, between ports and feature groups, and between data access and ports or feature groups. This permits end-to-end flows to be specified as logical information flows through a system despite the fact that the information is being manipulated and its representation changed.

(7)   The optional in_modes_and_transitions subclause specifies what modes the flow implementation is part of.  The detailed semantics of this subclause are defined in Section 12.

(8)   Flow specifications can have component implementation specific and mode specific property values.  The respective property associations can be declared in the properties subclause of the component implementation or as property association with the flow implementation declaration.

Examples

-- This is an AADL fragement

-- process foo is declared in the previous section

process implementation foo.basic

subcomponents

   A: thread bar.basic;

   -- bar has a flow path fs1 from port p1 to p2

   -- bar has a flow source fs2 to p3

   B: thread baz.basic;

   -- baz has a flow path fs1 from port p1 to p2

   -- baz has a flow sink fsink in port reset

connections

   conn1: port signal -> A.p1;

   conn2: port A.p2 -> B.p1;

   conn3: port B.p2 -> result2;

   conn4: port A.p2 -> result1;

   conn6: port A.p3 -> status;

   connToThread: port initcmd -> B.reset;

flows

   Flow1: flow path

            signal -> conn1 -> A.fs1 -> conn4 -> result1;

   Flow2: flow path

            signal -> conn1 -> A.fs1 -> conn2 ->

            B.fs1 -> conn3 -> result2;

   Flow3: flow sink initcmd -> connToThread -> C.fsink;

   -- a flow source may start in a subcomponent,

   -- i.e., the first named element is a flow source

   Flow4: flow source A.fs2 -> conn6 -> status;

end foo.basic;