![]() ![]() |
||||
|
||||
An
AADL property provides information about an element of an AADL specification. For
example, properties are used to provide the period of a thread, the latency of a connection, or
the size of data. A property has a name and a type; only values of the appropriate type can be
associated with a property. Properties are declared in named property sets. Property
associations in component declarations assign a particular property value to a particular
property for a particular component.
A
property set contains three kinds of declarations:
For
example, the following AADL specification
property set Example is
-- Unit Type declaration
English_Units: type units
(inch, foot => inch
* 12, yard => foot * 3);
-- Integer type declaration
Length: type aadlinteger units Example::English_Units;
-- Constant declaration
One_Foot: constant Example::Length
=> 1 foot;
-- Property declaration
Documentation_Thickness:
Example::Length =>
value(Example::One_Foot)
applies to (processor,
bus, system);
end Example;
declares
a property set named Example that contains two property
type declarations, one
property constant declaration, and a property declaration. Specifically, the property set first
declares the unit type English_Units, which contains three
elements inch, foot, and yard. The
second type, Length, is declared to be integers
labeled by units from English_Units. The
property constant One_Foot is of type Length, and has the value 1 foot. Finally, the property
Documentation_Thickness is declared. It
has values of type Length, and a default value of
One_Foot. Furthermore, only
processor, bus, and system components can associate values
with this property.
Here
we give an overview of AADL property types and property declarations intended to
assist the producers of analyses in understanding what kind of properties can be expressed for
use by analyses. We do not consider property constants any further except for how they
impact the meta model. The reader is referred to Chapter 10 of the AADL Specification for
more information. |
||||
Property
types constrain the values that can be associated with a property. There are nine
kinds of property types:
It
is easy to confuse classifierand referencetypes. The distinction is that the values of
classifiertypes are the names of
component types or implementations whereas the values of
referencestypes are specific subcomponents,
connections, or features in a system
specification. The difference is highlighted in the following example:
property set ps is
classifierType: type classifier (system);
referenceType: type reference (system);
classifierProp: ps::classifierType
applies to (all);
referenceProp: ps::referenceType
applies to (all);
end ps;
system Inner
end Inner;
system Outer
end Outer;
system implementation Outer.Impl
subcomponents
innerSubComponent: system
Inner;
properties
ps::classifierProp =>
system Inner;
ps::referenceProp =>
reference innerSubComponent;
end Outer.Impl;
Property
values can also be lists whose members are restricted to be values of a particular
property type. The AADL Specification considers “listness”to be an attribute of the
property
declaration, not of the property type. |
||||
AADL
property declarations are introduced above, although they deserve a more thorough
description. The following property set contains two property declarations that demonstrate
the major features of property declarations:
property set Example2 is
-- A single-valued property
Stack_Size:
inherit Size
applies to (system,
process, thread)
=> 1 KB;
-- A multi-valued property
Source_Files:
list of aadlstring
applies to (all);
end Example2;
A
property declaration gives a type for the property: the type may be given by referencing a
named type, or by giving the type specification in-line. The property declaration for
Stack_Size references the type AADL_Properties::Size while the property declaration
for
Source_Files uses the type aadlstring directly. The Source_Files property is a multi-valued
property, one whose values are a list of strings. For example the value ("file1.c", "file2.c")
can be assigned to the property Source_Files. In general, a property is made multi-valued by
writing list
of
before its type, and lists are denoted by comma-separated property value
expressions enclosed in parentheses.
The
property declaration for Stack_Size uses the optional inherit modifier, which
affects
how the property lookup algorithm looks for the values of this property. If a property is
inherit, and no property
association for that property is found in the current component, then
the containing component is searched for a property association. This is useful, for example,
to
allow all threads in a thread group to defer to the thread group if they are all supposed to have
the same property value.
All
property declarations in addition to giving a type, must also have an applies to clause.
This clause specifies those categories of components in the specification for which this property
may be associated with a value. In addition to the standard component categories, this list may
specify that the property applies to mode, port
group, flow, [event] [data] port, server
subprogram, parameter, and connections of various kinds.
The component categories may
also be qualified by classifier references. For example, a property that applies to (processor
Intel_x86)
may only be associated with processor components whose component classifier
the processor type Intel_x86 or one of its descendents.
The keyword all is used to indicate
that the property applies to all components.
Finally,
a property declaration may optionally associate a default value with the property. If the
property lookup algorithm is unable to find a value associated with the property for a particular
component then the default value is used. |
||||
A
particular element of an AADL specification is given a particular value for a particular
property via a property association. Property associations are made with the properties
clause of component declarations, and within subcomponent declarations. In general, property
associations apply to the declarative AADL specification, and thus all instances of a component
implementation will have the same property values. The declarative model can embody
property associations for specific subcomponent instances via contained property associations,
which provide a path to the particular subcomponent or feature to which the property applies.
The specification below exemplifies the use of property associations.
thread implementation MyThread.Impl
properties
Example2::Source_Files
=> ("MyThread.c", "Helper.c");
end MyThread.Impl;
process implementation MyProcess.Impl
subcomponents
t1: thread MyThread.Impl;
t2: thread MyThread.Impl;
properties
Example2::Stack_Size
=> 2 KB;
end MyProcess.Impl;
system implementation Main.Impl
subcomponents
p: process MyProcess.Impl
{
Example2::Stack_Size => 4 KB applies to t1; };
properties
Example2::Source_files
+=> ("Main.c");
end Main.Impl;
We
have three component implementation declarations. The properties clause of
MyThread.Impl associates via the => operator the value ("MyThread.c",
"Helper.c")
with the Source_Files property. The properties
clause of Main.Impl, however, appends via
the +=> operator the value ("Main.c") to the Source_Files property. The full
value of the
Source_Files property for Main.Impl is the value of Source_Files in the component type
Main (not shown) with the value ("Main.c") appended to it.
The
properties clause of MyProcess.Impl associates the value 2 KB with the Stack_Size
property. Because this property is declared with the inherit modifier, the two thread
subcomponents will also have this property value for Stack_Size.
The
contained property association on subcomponent p in Main.impl, however, changes the
value of the Stack_Size property for the specific
thread instance
t1
of the process instance p
when Main.Impl is instantiated.
If instead the property association on p were {
Example2::Stack_Size => 4 KB; }, then the property association would refer to the
declarative model instead, changing the value of Stack_Size for the process subcomponent
itself.
Property
associations can be more complicated when modes are used. Modal property
associations and other complicating issues are discussed in Section 5.7 Advanced Property
Associations. |
||||
Our
analysis relies on the assignment of security levels to components. There is no standard
property for specifying this, so we declare a new SecurityLevel property in a new SEI
property set:
property set SEI is
SecurityLevel:
aadlinteger
applies to (data, subprogram,
thread, thread group,
process, memory, processor, bus, device,
system);
end SEI;
For
our analysis, the security level of a component is an integer value. The property applies to
all categories of components that can make up a system, but not to connections or to other
model elements such as ports or modes.
Here
is an example AADL specification that makes use of the new property:
thread Peter
features
pe: in event port;
pd: out data port signal;
properties
SEI::SecurityLevel =>
4;
end Peter;
thread implementation Peter.Default
end Peter.Default;
thread Pierre
features
pd: in data port signal;
pe: out event port;
properties
SEI::SecurityLevel =>
7;
end Pierre;
thread implementation Pierre.Default
properties
-- implementation
overwrites the property value of the type
SEI::SecurityLevel =>
8;
end Pierre.Default;
process Proc
end Proc;
-- This component will have its SecurityLevel
property value
-- updated to be maximum of the subcomponent
T1 and T2 values: 8
process implementation Proc.Impl
subcomponents
T1: thread Peter.Default;
T2: thread Pierre.Default;
connections
-- Good connection:
flow from level 4 to level 8
good: data port T1.pd
-> T2.pd;
-- Bad connection:
flow from level 8 to level 4
bad: event port T2.pe
-> T1.pe;
properties
-- Bad: Security
Level isn't high enough
SEI::SecurityLevel =>
6;
end Proc.Impl;
system Main
end Main;
-- This component will receive a SecurityLevel
property value
-- to be the subcomponent value: 8
system implementation Main.Impl
subcomponents
p1: process Proc.Impl;
end Main.Impl;
Thread
types Peter and Pierre have SecurityLevel values of 4 and 7, respectively.
The
Thread implementations Peter.Default and Pierre.Default have SecurityLevel values of 4
and 8 respectively. The analysis will issue a warning that the security level of Proc.Impl is not
high enough and that it has been upgraded, in this case from 6 to 8. Analysis will also issue
a
warning that the security level of Main.Impl has been set to 8. Process Proc.Impl has two
connections between the two threads, one in each direction. The connection from T1 to T2 is
okay because subcomponent T1 has a security level of 4 which is less than T2s security level
of 8: data is traveling from a less secure to a more secure component. But the connection from
T2 to T1 will be flagged by the
analysis as allowing data to travel from a more secure to a less
secure component. Figure 21 shows the errors and warnings generated by the analysis plug-in
for this example.
![]() Figure 21: Results of applying security
level analysis to the sample specification. |
||||
Because
property values can be inherited from ancestor types and as well as along the
component containment hierarchy, the property values associated with a particular component
may not all be declared in the component itself. In fact, because of the append operator +=>
for list values, the value itself may be constructed from property associations declared in
multiple components. The AADL Specification specifies the algorithm used to determine the
property value associated with a particular property for a particular component. The gist of the
algorithm is as follows:
An
example lookup is illustrated in Figure 22. Instance4 is an element in the system instance
hierarchy. The value of one of its properties is determined by first looking for a property
associated with the instance itselfshown as step 1. This would be specified by a contained
property association. The contained property association for this instance declared in a
component implementation highest in the instance hierarchy determines that value. If no
instance value exists, the implementation (ImplA) of the instance is examined (step 2). If it
does not exist, ancestor implementations are examined (step 3). If the property value still has
not been determined, the component type is examined (step 4). If not found there, its ancestor
component types are examined (step 5). If not found and the property is inherited, for
subcomponents and features, the enclosing implementation is examined. Otherwise, the
containing component in the component instance hierarchy is examined (step 6). Finally, the
default value is considered.
![]() Figure 22: Example of the order
in which model components are search for property associations. The model on the left is
an AADL instance model; the model on the right is an AADL declarative model.
The
lookup process must also take into account modal properties, modal subcomponents,
property references, and the append operator. The interaction of modes with the property
lookup process together with the complexities of modal properties described above necessitate
the introduction of an additional level of abstraction in the property lookup API provided by
OSATE; see Section 5.8.4 Getting Property Values. |
||||