![]() ![]() |
||||||||||
|
||||||||||
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
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
specs
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; |
||||||||||