(1) A subprogram component represents sequentially executed source text that is called with parameters. A subprogram may not have any state that persists beyond the call (static data). Subprograms can have local variables that are represented by data subcomponents in the subprogram implementation. All parameters and required access to external data must be explicitly declared as part of the subprogram type declaration. In addition, any events raised within a subprogram must be specified as part of its type declaration.
(2) A subprogram call sequence is declared in a thread implementation or in a subprogram implementation. Subprogram call sequences may be mode-specific. Subprograms can be called from threads and from other subprograms that execute within a thread. These calls can be local calls, i.e., performed in the context of the caller thread, or they can be remote calls to subprograms that are executed in the context of another thread.
(3) Subprogram instances may be modeled explicitly through subprogram subcomponent declarations. In this case, components can be modeled as requiring and providing access to subprogram instances.
(4) Subprogram instances may be implied by a subprogram call reference to a subprogram type or implementation. In this case, a subprogram is implicitly instantiated within the containing process.
Syntax
subprogram_call_sequence ::=
defining_call_sequence_identifier :
{ { subprogram_call }+ }
[ { { call_sequence_property_association }+ } ] [ in_modes ] ;
subprogram_call ::=
defining_call_identifier : subprogram called_subprogram
[ { { subcomponent_call_property_association }+ } ] ;
called_subprogram ::=
-- identification by classifier
subprogram_unique_component_classifier_reference
| ( data_unique_component_type_reference
. data_provides_subprogram_access_identifier )
| ( subprogram_group_unique_component_type_reference
. provides_subprogram_access_identifier )
| ( abstract_unique_component_type_reference
. provides_subprogram_access_identifier )
| ( feature_group_identifier
. requires_subprogram_access_identifier )
-- identification by prototype
| component_prototype_identifier
-- identification by processor subprogram access feature
| ( processor . provides_subprogram_access_identifier )
-- identification by subprogram instance
| subprogram_subcomponent_identifier
| ( subprogram_group_subcomponent_identifier .
provides_subprogram_access_identifier )
| requires_subprogram_access_identifier
| ( requires_subprogram_group_access_identifier .
provides_subprogram_access_identifier )
NOTES:
Subprogram type and implementation declarations follow the syntax rules for component types and implementations. Subprogram instances may be implied by subprogram calls referring to subprogram classifiers, or subprogram instances may be declared explicitly as subprogram subcomponents and made accessible to calls through provides and requires subprogram access declarations.
Naming Rules
(N1) The defining identifier of a subprogram call sequence declaration must be unique within the local namespace of the component implementation that contains the subprogram call sequence.
(N2) The defining identifier of a subprogram call declaration must be unique within the local namespace of the component implementation that contains the subprogram call.
(N3) If the called subprogram name is a subprogram classifier reference, its component type identifier or component implementation name must exist in the package namespace.
(N4) The subprogram classifier reference of a subprogram call may be a subprogram type reference.
(N5) If the called subprogram name is a subprogram subcomponent reference, the subprogram subcomponent must exist in the component implementation containing the subprogram call declaration.
(N6) If the called subprogram name is a requires subprogram access reference, the requires subprogram access must exist in the component type of the component implementation containing the subprogram call declaration.
Legality Rules
Category |
Type |
Implementation |
subprogram |
Features: · out event port · out event data port · feature group · requires data access · requires subprogram access · requires subprogram group access · parameter · feature Flow specifications: yes Modes: yes Properties: yes |
Subcomponents: · data · abstract · subprogram Subprogram calls: yes Connections: yes Flows: yes Modes: yes Properties: yes |
(L1) A subprogram type declaration can contain parameter, out event port, out event data port, and feature group declarations as well as requires data, subprogram, and subprogram group access declarations. It can also contain a flow specification subclause, a modes subclause, and property associations.
(L2) A subprogram implementation can contain abstract, subprogram, and data subcomponents, a subprogram calls subclause, a connections subclause, a flows subclause, a modes subclause, and property associations.
(L3) Only one subprogram call sequence can apply to a given mode.
Consistency Rules
(C1)The reference to a provides subprogram access of a processor in a subprogram call (processor . provides_subprogram_access_identifier) must identify a provides subprogram access feature of the processor that the thread executing the call is bound to.
(C2)A subprogram call may reference a subprogram classifier. A project may enforce a consistency rule that this reference be to a subprogram subcomponent declaration or requires subprogram access declaration. This ensures that a modeler consistently models subprogram calss the same way.
Standard Properties
-- Properties related to source text
Source_Name: aadlstring
Source_Text: inherit list of aadlstring
Source_Language: inherit list of Supported_Source_Languages
Type_Source_Name: aadlstring
-- Properties specifying memory requirements of subprograms
Source_Code_Size: Size
Source_Data_Size: Size
Source_Stack_Size: Size
Source_Heap_Size: Size
Allowed_Memory_Binding_Class:
inherit list of classifier (memory, system, processor)
Allowed_Memory_Binding: inherit list of reference (memory, system, processor)
Actual_Memory_Binding: inherit list of reference (memory)
-- execution related properties
Compute_Execution_Time: Time_Range
Compute_Deadline: Time
Client_Subprogram_Execution_Time: Time_Range
Reference_Processor: inherit classifier ( processor )
-- remote subprogram call related properties
Urgency: aadlinteger 0 .. Max_Urgency
Actual_Subprogram_Call: reference (subprogram)
Allowed_Subprogram_Call: list of reference (subprogram)
Actual_Subprogram_Call_Binding: list of reference (bus, processor, memory, device)
Allowed_Subprogram_Call_Binding:
inherit list of reference (bus, processor, device)
Subprogram_Call_Type: enumeration (Synchronous, SemiSynchronous)
=> Synchronous
Semantics
(5) A subprogram component represents sequentially executable source text that is called with parameters. The results of a subprogram call must be available to the caller at the time those results are used. This allows for synchronous and semi-synchronous calls.
(6) A subprogram type declaration specifies all interactions of the subprogram with other parts of the application source text. Subprogram parameters are specified as features of a subprogram type (see Section 8.4). This includes in and in out parameters passed into a subprogram and out and in out parameters returned from a subprogram on a call, events being raised from within the subprogram through its out event port and out event data port, required access to static data by the subprogram are specified as part of the features subclause of a subprogram type declaration, and required access to subprograms that are contained in another component and are called by this subprogram.
(7) A subprogram implementation represents implementation details that are relevant to architecture modeling. It specifies calls to other subprograms and the mode in which the call sequence occurs. It also specifies any local data of the subprogram, i.e., data that does not persist beyond the call.
(8) All access to data that persists beyond the life of the subprogram execution, i.e., any state that is maintained by a subprogram, must be modeled through requires data access. If requires data access is declared for a subprogram type, access to the data subcomponent may be performed in a critical region to assure concurrency control for calls from different threads (for more on concurrency control see Sections 5.1 and 5.4).
(9) Subprogram source text can contain Send_Output service calls to cause the transmission of events and event data through its out event ports (see Section 8.3). The fact that events may emit from a subprogram call is documented by the declaration of out event ports and out event data ports as features of the subprogram.
(10) Subprogram implementations and thread implementations can contain subprogram calls. A thread or subprogram can contain multiple calls to the same subprogram - with the same parameter values or with different parameter values.
(11) Subprogram call sequences can be declared to apply to specific modes. In this case a call sequence is only executed if one of the specified modes is the current mode.
(12) Modeling of subprograms is not required and the level of detail is not prescribed by the standard. Instead it is determined by the level of detail necessary for performing architecture analyses or code generation.
(13) In an object-oriented application methods are called on an object instance and the object instance is available within the method by the name this. In AADL a subprogram call can identify the subprogram being called by the provides subprogram access feature of a data component. In AADL, the data component must be explicitly passed into a subprogram as parameter (by value) or as requires data access (by reference). Requires data access may require concurrency control to ensure mutual exclusion.
(14) Ordering of subprogram calls is by default determined by the order of the subprogram call declarations. Annex-specific notations, e.g., the Behavior Annex, can be introduced to allow for other call order specifications, such as conditional calls and iterations.
(15) The flow of parameter values between subprogram calls as well as to and from ports of enclosing threads is specified through parameter connection declarations (see Section 9.3).
(16) Subprogram instances may be modeled explicitly through subprogram subcomponent declarations, or they may be implied from the call references to subprogram classifiers. A subprogram instance means that the subprogram executable binaries exist in the load image of the containing process. For subprograms, whose source text implementation is reentrant, it is assumed that a single instance of the subprogram binaries exist in the process address space. In the case of remote subprogram calls a proxy may be loaded for the calling thread and the actual subprogram is part of the load image of the process with the thread servicing the remote subprogram call.
(17) A subprogram subcomponent declaration explicitly represents a subprogram instance that resides in the protected address space of the containing process. Subprogram calls refer to the subprogram subcomponent or to requires subprogram access declarations. In case of a requires subprogram access the call is local to a subprogram instance in the containing process, or is remote to a subprogram instance in another process. Subprogram access connection declarations identify the subprogram instance to be called.
(18) The standard permits modeling of subprograms and subprogram calls without requiring the declaration of subprogram instances. In this case, subprogram calls may refer to subprogram classifiers and the source language processing system will determine the subprogram instance to be called. In the case of remote subprogram calls the target subprogram is identified by subprogram call properties. An Allowed_Subprogram_Call property, if present, identifies the remote subprogram(s) that are allowed to be used in a call binding. An Actual_Subprogram_Call property records the actual binding to a subprogram or provides subprogram access feature. Constraints on the buses and processors over which such calls can be routed can be specified with the Allowed_Subprogram_Call_Bindings property.
(19) The following control flow semantics apply to subprogram calls, when the call refers to:
· Subprogram classifier: execution by the calling thread
· Provides subprogram access of data type: execution by the calling thread
· Subprogram subcomponent in calling thread: execution by the calling thread
· Provides subprogram access feature of a data component: execution by calling thread
· Subprogram access to subprogram component in enclosing thread group, process, or system: execution by calling thread
· Subprogram access to subprogram component in another thread group, process, or system: execution by calling thread
· Provides subprogram access of another thread: execution by called thread
· Provides subprogram access feature of a device: execution inside device
· Subprogram access of a processor: execution inside the processor (operating system)
· Subprogram classifier and the call has a subprogram call binding property that refers to provides subprogram access in other thread: execution by called thread
(20) The results of a subprogram call must be available to the caller at the time those results are used. In the case of a local call the results are available when the call returns, i.e., the call is performed as a synchronous call. In the case of remote call, the caller thread is by default suspended until the execution of the subprogram completes (synchronous call). The caller thread may issue multiple concurrently executing subprogram calls and wait for their result when needed (semi-synchronous call). The Subprogram_Call_Type property indicates whether synchronous or semi-synchronous calls are desired.
(21) In the case of a remote call, the thread servicing the subprogram call assures that only one call at a time is serviced. In other words, it acts as a critical region for all calls to provides subprogram access features of a thread.
(22) Provides subprogram access features may be declared for processors or devices. In the case of processors they represent operating system services provided by the processor. In the case of a device, they represent services on the device that can be invoked by the application software.
Processing Requirements and Permissions
(23) The subprogram call order defines a default execution order for the subprogram calls. Alternate call orders can be modeled in an annex subclause introduced for that purpose.
(24) The legality rules require that call declarations either refer only to subprogram classifiers or to subprogram instances (subcomponents and provides/requires subprogram access). This rule can be relaxed to allow a mix of both if this is appropriate for the development process.
(25) An implementation method may support synchronous calls only or also semi-synchronous calls.
Examples
data matrix
end matrix;
data weather_forecast
end weather_forecast;
data date
end date;
subprogram Matrix_delta
features
A: in parameter matrix;
B: in parameter matrix;
result: out parameter matrix;
end Matrix_delta;
subprogram Interpret_result
features
A: in parameter matrix;
result: out parameter weather_forecast;
end Interpret_result;
data weather_DB
features
getCurrent: provides subprogram access getCurrent;
getFuture: provides subprogram access getFuture;
end weather_DB;
subprogram getCurrent
features
result: out parameter Matrix;
end getCurrent;
subprogram getFuture
-- a subprogram whose source text sends an event
-- the subprogram also has access to shared data
features
date: in parameter date;
result: out parameter Matrix;
bad_date: out event port;
wdb: requires data access weather_DB;
end getFuture;
thread Predict_Weather
features
target_date: in event data port date;
prediction: out event data port weather_forecast;
past_date: out event port;
weather_database: requires data access weather_DB;
end Predict_Weather;
thread implementation Predict_Weather.others
calls main : {
-- subprogram call on a data component provides subprogram access feature
-- out parameter is not resolved, but will be identified by user of value
current: subprogram weather_DB.getCurrent;
-- subprogram call on a data component provides subprogram access feature with port value
-- as additional parameter. Event is mapped to thread event
future: subprogram weather_DB.getFuture;
-- in parameter actuals are out parameter values of previous calls
-- they are identified by the call name and the out parameter name
diff: subprogram Matrix_delta;
-- call with out parameter value resolved to be passed on through a port
interpret: subprogram Interpret_result;
};
connections
fdconn: parameter target_date -> future.date;
pdconn: port future.bad_date -> past_date;
daconn: parameter current.result -> diff.A;
dbconn: parameter future.result -> diff.B;
iaconn: parameter diff.result -> interpret.A;
pconn: parameter interpret.result -> prediction;
fwconn: data access weather_database <-> future.wdb;
end Predict_Weather.others;