9.3      Parameter Connections

(1)   Parameter connections represent flow of data between the parameters of a sequence of subprogram calls in a thread.  Parameter connections may be declared from an incoming data or event data port  of the containing thread to an incoming parameter of a subprogram call. Parameter connections also specify connections from an incoming parameter of the containing subprogram to an incoming parameter of a subprogram call, from an outgoing parameter of a subprogram call to an outgoing parameter of the containing subprogram, and from an outgoing parameter of a subprogram call to an incoming parameter of a subprogram call or to an outgoing data or event data port of the containing thread.  In addition, parameters may be connected to data components (either to data subcomponents or data access features) to represent data flowing to and from static and local variables.  In summary, the parameter connections follow the containment hierarchy of subprogram calls nested in other subprograms.  This is illustrated in Figure 18.  The call order is from left to right.

figure13

Figure 18 Parameter Connections

(2)   For parameter connections, data transfer occurs at the time of the subprogram call and call return.  In the  case of subprogram calls to remote subprograms, the data is first transferred to a local proxy and from there passed to the remote subprogram.

Syntax

parameter_connection ::=
    parameter source_parameter_reference
        directional_connection_symbol destination_parameter_reference
 
parameter_connection_refinement ::=
    parameter         
 
parameter_reference ::= 
        -- parameter in the thread or subprogram type 
      component_type_parameter_identifier [ . data_subcomponent_identifier ]
    |   
        -- parameter in another subprogram call 
      subprogram_call_identifier . parameter_identifier
    |   
        -- data or event data port in the thread type 
        -- or an element of that port’s data
      component_type_port_identifier [ . data_subcomponent_identifier ]
    |   
        -- data subcomponent in the thread or subprogram
      data_subcomponent_identifier
    |   
        -- requires data access in the thread or subprogram type
      requires_data_access_identifier
    |
        -- data access element in a feature group of the component type
     component_type_feature_group_identifier . element_data_access_identifier
    |   
        -- port or parameter element in a feature group of the component type
      component_type_feature_group_identifier  . element_port_or_parameter_identifier 

Naming Rules

(N1)     The connection identifier in a parameter connection refinement declaration must refer to a named parameter or feature connection declared in an ancestor component implementation.

(N2)     A source (destination) reference in a parameter connection declaration must reference a parameter of a preceding (succeeding) subprogram call, a parameter declared in the component type of the containing subprogram, a data port or event data port declared in the component type of the enclosing thread, a data port or event data port that is an element of a feature group in the component type of the enclosing thread, a data subcomponent, or a requires data access to a data component.

Legality Rules

(L1)      The source of a parameter connection must be an incoming data or event data port of the containing thread, an incoming parameter of the containing subprogram, or a data subcomponent or requires data access with read-only or read-write access rights, or an outgoing parameter of a previous subprogram call.

(L2)      The following source/destination pairs are acceptable for parameter connection declarations: 

threadport -> call.parameter

requiresdataaccess -> call.parameter

threadfeaturegroup.port -> call.parameter

featuregroup.requiresdataaccess -> call.parameter

call.parameter -> threadport

call.parameter -> requiresdataaccess

call.parameter -> threadfeaturegroup.port

call.parameter -> featuregroup.requiresdataaccess

call.parameter -> threadincompletefeaturegroup

call.parameter -> datasubcomponent

containedcall.parameter -> parameter

datasubcomponent -> call.parameter

parameter -> containedcall.parameter

call.parameter -> call.parameter

 

(L3)      A parameter cannot be the destination feature reference of more than one parameter connection declaration unless the source feature reference of each parameter connection declaration is contained in a different mode.  In this case, the restriction applies for each mode.

(L4)      The data classifier of the source and destination must match. The matching rules as specified by the Classifier_Matching_Rule property apply (see Section 9.2 (L13)).  By default the data classifiers must be match.

Semantics

(3)   Parameter connections represent sequential flow of data through subprogram parameters in a sequence of subprogram calls being executed by a thread. 

(4)   Parameter connections are restricted to 1-n connectivity, i.e., a data port or parameter can have multiple outgoing connections, but only one incoming connection. 

(5)   If a subprogram has an in out parameter, this parameter may be the destination of an incoming parameter connection and the source of outgoing parameter connections.

(6)   Parameter connections follow the call sequence order of subprogram calls.  In other words, parameter connection sources must be preceding subprogram calls, and parameter connection destinations must be successor subprogram calls.

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

Examples

NOTE: An example of parameter connections can be found in Section 5.2.