5.1      Data

(1)   A data component type represents a data type in source text.  The internal structure of a source text data type, e.g., the instance variables of a class or the fields of a record, can be represented by data subcomponents in a data component implementation. The provides subprogram access features of a data component type can model the concept of methods on a class or operations on an abstract data type.  A source text data type can be modeled by a data component type declaration with relevant properties without providing internal details in a data component implementation.

(2)   A data component classifier, i.e., a data component type name or a data component type and implementation name pair (separated by a dot “.”), is used as data type indicator in port declarations, subprogram parameter declarations, and data subcomponent declarations.

(3)   A data subcomponent represents static data in the source text. Components can have shared access to data subcomponents, which means that there are mutual exclusion requirements. Only those components that explicitly declare required data access can access such sharable data subcomponents using a concurrency control protocol as specified by property. Data subcomponents can be shared within the same process and, if supported by the runtime system, across processes.  When declared in a subprogram or a thread that data subcomponent represents a local variable.

(4)   References to data components are modeled through provides and requires data access.  Threads, processes, systems, and subprograms may access data by reference (see Section 8.6). 

NOTES:

Support for shared data is not intended to be a substitute for data flow communication through ports.  It is provided to support modeling of systems whose application logic requires them to manipulate data concurrently in a non-deterministic order that cannot be represented as data flow, such as database access.  It is also provided for modeling source text that does not use port-based communication.

AADL focuses on architecture modeling.  When used for data modeling, properties defined as part of the Data Modeling Annex (Annex Document B) can be used to further characterize data components. 

Legality Rules

Category

Type

Implementation

data

Features:

·         feature group

·         provides subprogram access

·         requires subprogram access

·         requires subprogram group access

·         feature

Flow specifications: no

Modes: no

Properties: yes

Subcomponents:

·         data

·         subprogram

·         abstract

Subprogram calls: no

Connections: yes (access)

Flows: no

Modes: no

Properties: yes

 

(L1)      A data type declaration can contain provides subprogram access declarations as well as property associations.

(L2)      A data type declaration must not contain a flow specification or modes subclause.

(L3)      A data implementation can contain abstract, data and subprogram subcomponents, access connections, and data property associations.  

(L4)      A data implementation must not contain a flow implementation, an end-to-end flow specification, or a modes subclause.

Standard Properties

Source_Data_Size: Size
Source_Code_Size: Size
Type_Source_Name: aadlstring
Source_Name: aadlstring
Source_Text: inherit list of aadlstring
-- hardware mapping
Base_Address: aadlinteger 0 .. Max_Base_Address
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)
-- Data sharing properties
Access_Right : Access_Rights => read_write  
Concurrency_Control_Protocol: Supported_Concurrency_Control_Protocols
 
 

(5)   The value of the Type_Source_Name property identifies the name of the data type declaration in the source text. The value of the Source_Name property identifies the name of the static or local data variable in the source text.

Semantics

(6)   The data component type represents a data type in the source text that defines a representation and interpretation for instances of data in the source text.  This includes data transferred through data and event data ports, and parameter values transferred to subprograms.  This data type (class) may have associated access functions (called methods in an Object-Oriented context) that are represented by provides subprogram access declarations in the features subclause of the data type declaration.  In this case, the data may be accessed through the subprograms.

(7)   A provides subprogram access declaration represents a callable subprogram. It represents implicitly declared subprogram subcomponent that is contained in the process of the subprogram call, i.e., a single subprogram instance exists within a process.  Modelers may also declare subprogram subcomponents explicitly.  A remotely callable access function of a data type is modeled by a provides subprogram access declaration that will be connected from a subprogram call or is named in the classifier reference of the call. 

(8)   Elements of a data component can be accessed and changed directly or via provides subprogram access features.  This corresponds to get and set methods of a class.  AADL does not impose visibility restrictions on elements of a data component.

(9)   A data component type can have zero data component implementations. This allows source text data types to be modeled without having to represent implementation details.

(10)  A data component implementation represents the internal structure of a data component type.  It can contain data subcomponents. This is used to model source language concepts such as fields in a record and instance variables in a class.  The data subcomponent represents actual data values.  AADL does not require the user to provide internal details of data representations if they are not relevant to the architecture model.  The user may choose to reflect relevant data modeling information in properties, e.g., the memory requirements, the measurement unit used for the data, acceptable data types for a union type, dimensionality of an array structure, the super types in a type hierarchy, or the data type of a reference.

(11)  Data component types can be extended through component type extension declarations.  This permits modeling of subclasses and type inheritance in source text.  However, it is recommended to use the capabilities of the Data Modeling Annex to represent data model characteristics in AADL (see Annex Document B).

(12)  A data subcomponent represents a data instance, i.e., data in the source text that is potentially sharable between threads and persists across thread dispatches.  A data subcomponent is considered to be static data with the exception of data subcomponents in subprograms, which represent local data.  Each declared data subcomponent represents a separate instance of source text data. 

(13)  A data subcomponent declared in a subprogram represents local data.  This data cannot be made accessible outside the subprogram through a provides data access declaration.

(14)  When declaring data subcomponents, it is sufficient for the component classifier reference of data subcomponent declarations to only refer to the data component type.  An implementation method can generate a system instance and perform memory usage analysis if a Source_Data_Size property value is specified in the data component type.

(15)  Data subcomponents that are not declared in subprograms can be shared between threads.  This is expressed by requires data access declarations in the component type declarations of subprograms, threads, thread groups, processes, and systems. The access is resolved to data subcomponents or provides data access declarations.  Each required reference to shared data may have its own Access_Right property value.  Its value must be consistent with the value of the Access_Right property of the data component or a provides data access.  The Access_Right property value of Read_Only on a data component indicates that the component contains a constant value that does not change.

(16)  Concurrent access to shared data is coordinated according to the concurrency control protocol specified by the Concurrency_Control_Protocol property value associated with the data component.  A thread is considered to be in a critical region when it is accessing a shared data component.  When a thread enters a critical region a Get_Resource operation is performed on the shared data component (see Runtime Support in Section 5.1.1).  Upon exit from a critical region a Release_Resource operation is performed (see Runtime Support in Section 5.1.1).  If multiple data components with concurrency control protocols are accessed by a thread, the AADL runtime system must ensure that the critical regions are nested, i.e., the Get_Resource and Release_Resource operations are pair-wise nested for each data component. 

(17)  Concurrent access to shared data may be coordinated through provides subprogram (group) access.  In this case, the concurrency control protocol specifies how the execution of subprograms on the data component is coordinated.

(18)  Data component classifier references are also used to specify the data type for data and event data ports as well as subprogram parameters. When ports are connected or when required data access and subprogram parameters are resolved, the data component classifier references representing the data types must be compatible.  This means that the data type of an out port must be compatible with the data type of an in port, the data type of a provided data access declaration or a declared data component must be compatible with the data type of a required data component, and the data type of an actual parameter must be compatible with that of the formal parameter of a subprogram.  Compatibility is determined by the Classifier_Matching_Rule property (see Section 9.2).

(19)  Data components can be declared as arrays of data subcomponents.  Same as for other subcomponent array declarations this is a short-hand for declaring several subcomponents of the same type through separate subcomponent declarations.  If the intent is to model a data component whose representation in the source text is an array data modeling properties should be used (see Appendix A.8).

5.1.1       Runtime Support For Shared Data Access

(20)  A standard set of runtime services is provided.  The application program interface for these services is defined in the code generation annex of this standard (see Annex Document A). They are callable from within the source text.

(21)  The following are subprograms that may be explicitly called by application source code, or they may be called by an AADL runtime system that is generated from an AADL model. 

(22)  The Get_Resource and Release_Resource  runtime services represent an abstract interface for functions that perform locking and unlocking of resources according to the specified concurrency control protocol.  The method may lock multiple resources simultaneously.

    subprogram  Get_Resource
    features
      resource: in parameter <implementation-specific representation of one or more resources>; 
    end Get_Resource;
    subprogram  Release_Resource 
    features
      resource: in parameter <implementation-specific representation of one or more resources>; 
    end Release_Resource;

Processing Requirements and Permissions

(23)  If any source text is associated with a data component type, then a corresponding source text data type declaration must be visible in the outermost scope of that source text, as defined by the scope and visibility rules of the applicable source language standard.  The name of the data component type determines the source name of the data type. Supported mappings of the identifier to a source type name for specific source languages are defined in the source language annex of this standard.  Such mapping can also be explicitly specified through the Type_Source_Name property.

(24)  The applicable source language standard may allow a data type to be declared using a type constructor or type modifier that references other source text data types.  A source text data type name defined by a source type constructor may, but is not required to, be modeled as a data component type with the referenced type features explicitly named in a corresponding data component implementation declaration. 

(25)  Data modeling properties allow for modeling data representations in the source text that include stored references (pointers).  A method of implementation may disallow storing of such data references as data values in order to assure safe execution of embedded applications. 

(26)  A method of implementation may use a provides subprogram access declaration to represent an implicit subprogram subcomponent.  In this case, the provides subprogram access feature does not have to be connected to a subprogram subcomponent or a requires subprogram access feature.

(27)  A method of implementation may disallow assignments that might result in a runtime error depending on the actual value being assigned.  If a method of implementation employs a runtime check to determine if a specific value may be legally assigned, then any runtime fault is associated with the thread that contains the source of the data assignment.

(28)  If two static data declarations refer to the same source text data, then that data must be replicated in binary images.  If this replication occurs within the same virtual address space, a method for resolving name conflicts must be in place.  Alternatively the processing method may require that each source text data be represented by only one data component declaration per process address space.

(29)  The concurrency control protocol can be implemented through a number of concurrency control mechanisms such as mutex, lock, semaphore, or priority ceiling protocol. Appropriate concurrency control state is associated with the shared data component to maintain concurrency control.  The protocol implementation must provide appropriate implementations of the Get_Resource and Release_Resource operations.

(30)  A method of implementation may choose to support only locking of one resource at a time, or locking of multiple resources simultaneously.  In the former case it is the responsibility of the caller of Get_Resource in such an order that deadlock and starvation is avoided.  In the latter case, the Get_Resource implementation must assure absence of deadlock and starvation.

(31)  A method of implementation may choose to generate the Get_Resource and Release_Resource calls as part of the AADL runtime system generation, or it may choose to require the application programmer to place those calls into the application code.  In the latter case, implementation methods may validate the sequencing of those calls to assure compliance with the AADL specification.

Examples

package personnel

public

with Base_Types, retep::relief;

data Person

end Person;

 

data Personnel_record

-- Methods are not required, but when provided act as access methods

features

   -- a method on the data type

   -- subprogram type for signature

   update_address: provides subprogram access update_address;

end Personnel_record;

 

data implementation Personnel_record.others

subcomponents

   -- here we declare the internal structure of the data type

   -- One field is defined in terms of another type;

   -- the type name is sufficient, it defaults to others.

   -- the package Base_Types is defined in the Data Model Annex document.

   -- It provides data component classifiers for common data types.

   Name : data Base_Types::String;

   Home_address : data retep::relief::Address;

end Personnel_record.others;

 

data Personnel_database

end Personnel_database;

 

data implementation Personnel_database.oracle

end Personnel_database.oracle;

 

subprogram update_address

features

   person: in out parameter Personnel_record;

   street :in parameter Base_Types::String;

   city: in parameter Base_Types::String;

end update_address;

-- use of a data type as port type.

thread SEI_Personnel_addition

features

   new_person: in event data port Personnel_record;

   SEI_personnel: requires data access Personnel_database.oracle;

properties

   Dispatch_Protocol => aperiodic;

end SEI_Personnel_addition;

end personnel;

 

package retep::relief

public

   data Address

   features

      -- a subprogram access feature without parameter detail

      getStreet : provides subprogram access;

      getCity : provides subprogram access;

   end Address;

   data implementation Address.others

   properties

      Source_Data_Size => 512 Bytes;

   end Address.others;

end retep::relief;

 

-- The implementation is shown as a private declaration

-- The public and the private part of a package are separate AADL specifications

package retep::relief

private

with Base_Types;

   data implementation Address.others

   subcomponents

      street : data Base_Types::String;

      streetnumber: data Base_Types::Integer;

      city: data Base_Types::String;

      zipcode: data Base_Types::Integer;

   end Address.others;

end retep::relief;