This chapter is from the book
This chapter is from the book
This chapter is from the book
3.2. Representing Code Artifacts
Within a comprehensive AADL architectural specification, source code files and related information needed for specifying and developing the software within a system are documented using standard properties. These properties capture information for documenting architectural views such as code views [Hofmeister 00] and implementation views of allocation view types [Clements 10].
In this section, we document information relating to the PBA application software contained within the process control.speed. This excludes software that may be resident in the sensors, actuators, and interface devices as well as the operating system within the processor. First, we assume the application software has been written in a programming language, such as C or Java or in a modeling language, such as Simulink. We also assume that the software has been organized using the capabilities of the source language (e.g., by organizing Java classes and methods into packages with public and private elements). In this case, we can focus on specifying a mapping of the source files into the processes and threads of the application runtime architecture. Section 3.2.1 illustrates this mapping, which can be used to generate build scripts from the AADL model. Section 3.2.2 discusses how you can map identifier names used in AADL to identifier names that are acceptable in the source language. For larger systems, we may want to reflect not only the application runtime architecture in AADL, but also the modular source code structure. Section 3.2.3 illustrates how we utilize AADL packages for that purpose.
3.2.1. Documenting Source Code and Binary Files
A modified excerpt of the PBA specification is shown in Listing 3-9. This includes a properties section within the implementation control.speed, where the property association for the property Source_Language declares that the source code language for the implementation is C. This property is of type Supported_Source_Languages, which is defined in the property set AADL_Project and has the enumeration values (Ada95, C, Simulink_6_5 are some examples). Property types and constants in the AADL_Project property set can be tailored for specific projects. For example, languages such as Java can be added to the Supported_Source_Languages property type.
Using a property association for the newly defined property Source_Language, the C language is declared as the programming language for all of the source code involved in the process control.speed. Two contained property associations for the property Source_Text identify the source and object code files for the threads speed_control_laws and scale_speed_data. Two other contained property associations for the property Source_Code_Size define the size of the compiled, linked, bound, and loaded code used in the final system.
In Listing 3-9, the data type sampled_speed_data is declared with a property association for the property Source_Data_Size. This property specifies the maximum size required for an instance of the data type. This data type is the classifier for the ports associated with the data that originates at the speed sensor.
Listing 3-9. PBA Specification with Code Properties
process implementation control.speed
subcomponents
scale_speed_data: thread read_data.speed;
speed_control_laws: thread control_laws.speed;
connections
DC1: port sensor_data -> scale_speed_data.sensor_data;
DC2: port scale_speed_data.proc_data ->
speed_control_laws.proc_data;
DC3: port speed_control_laws.cmd -> command_data;
EC1: port disengage -> speed_control_laws.disengage;
DC4: port set_speed -> speed_control_laws.set_speed;
properties
Source_Language => (C);
Source_Text => ("ControlLaws.cc", "ControlLaws.obj")
applies to speed_control_laws;
Source_Text => ("ScaleData.cc", "ScaleData.obj")
applies to scale_speed_data;
Source_Code_Size => 4 KByte applies to scale_speed_data;
Source_Code_Size => 10 KByte applies to speed_control_laws;
end control.speed;
3.2.2. Documenting Variable Names
A data port maps to a single variable in the application code. For example, the variable name for a data port can be specified using the Source_Name property. This is shown in Listing 3-10, for the in data port set_speed whose data classifier is the data type set_speed_value. The variable name for this port in the source code is SetValue.
We can use this mechanism to map data type and other component identifiers in an AADL model into the corresponding name in the source code. This is useful if the syntax of the source language allows characters in identifiers that are not allowed in AADL. We may also use this if we want to introduce more meaningful names in the AADL model for cryptic source code names.
Listing 3-10. Example of Documenting Variable Names
thread control_laws
features
proc_data: in data port;
cmd: out data port;
disengage: in event port;
set_speed: in data port set_speed_value
{Source_Name => "SetValue";};
properties
Dispatch_Protocol => Periodic;
Period => 50 ms;
end control_laws;
data set_speed_value
end set_speed_value;
3.2.3. Modeling the Source Code Structure
Source code expressed in programming languages typically consists of data types and functions. They may take the form of subprograms and functions, classes and methods, or operations on objects. These source code elements are typically organized into libraries and modular packages. Some of the library or package content is considered public (i.e., it can be used by others), whereas other parts are considered private (i.e., can only be used locally). In the case of modeling languages such as Simulink, block libraries play a similar role.
Sometimes it is desirable to represent this modular source code structure in the AADL model. We can do so by making use of the AADL package concept. For example, we can model the functions making up a Math library by placing the subprogram type declarations representing the function signatures into an AADL package together with the subprogram group declaration representing the library itself, as shown in Listing 3-11.
We can place data component types that represent classes within the same source code package, into one AADL package. We can place the data component type and the subprogram types representing the operations on the source code data type in the same package. The methods of classes can be recorded as subprogram access features of the data component type (see Section 4.2.5). Any module hierarchy in the source code can be reflected in the AADL package naming hierarchy. For more on the use of AADL packages to organize component declarations into packages, see Section 4.4.1.
Listing 3-11. Example of Modular Structure
package MathLib
public
with Base_Types;
subprogram group Math_Library
features
sqrt: provides subprogram access SquareRoot;
log: provides subprogram access;
pow: provides subprogram access;
end Math_Library;
subprogram SquareRoot
features
input: in parameter Base_Types::float;
result: out parameter Base_Types::float;
end SquareRoot;
end MathLib;