5.1 Data
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, is represented by data subcomponents in a data component implementation. Subprogram features of a data component type can model the concept of methods on a class or operations on an abstract data type.  If subprogram features are declared, the data component may only be accessed through the subprograms.  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.
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.
A data subcomponent represents static data in the source text. Components can have shared access to data subcomponents. Only those components that explicitly declare required data access can access such sharable data subcomponents according to a specified concurrency control protocol property.  Concurrency control is assured either through the subprogram features of the data component type or by the component requiring access.  Data subcomponents can be shared within the same process and, if supported by the runtime system, across processes. 
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.
Legality Rules
Category
Type
Implementation
Data
Features:
    • subprogram
    • provides data access
Flow specifications: no
Properties: yes
Subcomponents:
    • data
Subprogram calls: no
Connections: access
Flows: no
Modes: yes
Properties: yes

A data type declaration can contain subprogram declarations, provides data access declarations as well as property associations.
A data type declaration must not contain a flow specification.
A data implementation can contain data subcomponents, a modes subclause, access connections, and data property associations.  
A data implementation must not contain a flow implementation or an end-to-end flow specification.
Each requires data access reference may have its own Required_Access property value.  This property value must not conflict with the Provided_Access property value associated with the data component or the corresponding provides access declaration.
The data classifier references of two data ports, event data ports, data access, or parameters to be identical.  When a data type has zero or one implementation, then the referenced data types must match.  When a data type has more than one implementation, both the data type and the appropriate implementation must be present in the data classifier reference of a data port, event data port, data access, or parameter declaration.
Standard Properties
Source_Data_Size: Size
Type_Source_Name: aadlstring
Source_Name: aadlstring
Source_Text: inherit list of aadlstring
-- Data sharing properties
Concurrency_Control_Protocol: Supported_Concurrency_Control_Protocols =>                
NoneSpecified
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 data variable in the source text.
Semantics
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 subprogram declarations in the features subclause of the data type declaration.  In this case, the data may be accessed through the subprograms.
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. 
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.
A data component type declaration can provide access to its data subcomponents. This allows other components to directly access specific parts of the data component represented by the data subcomponent for which access is provided. This can be used to model source language concepts such as direct access to fields of a record or public access to instance variables in a class.
A data component type declaration can require access to data components external to the data component type and its implementations. This can be used to model references to other data in the source language.
Data component types can be extended through component type extension declarations.  This permits modeling of subclasses and type inheritance in source text.
A data subcomponent represents a data instance, i.e., static data in the source text that is potentially sharable between threads and persists across thread dispatches.  Each declared data subcomponent represents a separate instance of source text data.
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 even generate a system instance and perform memory usage analysis if a Source_Data_Size property value is specified in the data component type.
Static data is sharable 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 Required_Access property value.  Its value must be consistent with the value of the Provided_Access property. 
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.  Upon exit from a critical region a Release_Resource operation is performed.  If multiple data components with concurrency control protocols are accessed by a thread, the critical regions may be nested, i.e., the Get_Resource and Release_Resource operations are pair-wise nested for each data component.  Furthermore, deadlock avoidance among threads accessing the same set of shared data components is assured by proper nesting of the critical regions across all of the threads.
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.  Data component classifier references are considered to be compatible if they are identical, and if the represented source text data types are compatible according to source language rules. 
Data implementation property associations allow mode-specific property values to be associated with the data component.
NOTES:
The property types aadlboolean, aadlstring, aadlinteger, and aadlreal cannot be used as predeclared component data types.  Instead data component types with the names Boolean, string, integer, and real can be declared in a package and used throughout AADL specifications.
Processing Requirements and Permissions
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.
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. 
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.
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.
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.
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
data Person
end Person;

data Personnel_record
-- Methods are not required, but when provided act as access methods
features
   -- a subprogram feature with reference to a
   -- subprogram type for signature
   update_address: subprogram 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.
   Name : data basic::string;
   Home_address : data sei::aadl::relief::Address;
end Personnel_record.others;

subprogram update_address
features
   person: in out parameter Personnel_record;
   street :in parameter basic::string;
   city: in parameter basic::string;
end update_address;

package basic
public
   -- string as type
   data string
   end string;

   -- int as type
   data int
   properties
      Source_Data_Size => 64 bits;
   end int;
end basic;

-- 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;

package sei::aadl::relief
public
   data Address
   features
      -- a subprogram feature without parameter detail
      getStreet : subprogram;
      getCity : subprogram;
   end Address;
end sei::aadl::relief;

-- The implementation is shown as a private declaration
-- The public and the private part of a package are separate AADL spec’s
package sei::aadl::relief
private
   data implementation Address.others
   subcomponents
      street : data basic::string;
      streetnumber: data basic::int;
      city: data basic::string;
      zipcode: data basic::int;
   end Address.others;
end sei::aadl::relief;