Open sprocter opened 10 years ago
At some point, we are going to have to assess the entire AADL / DML data type system. My personal opinion is that we should use the CORBA IDL type system embedded into AADL and DML.
A couple of questions:
On May 13, 2014, at 3:31 PM, Sam Procter notifications@github.com wrote:
A couple of questions:
• Should this issue block on that discussion? That is, should I avoid implementing aggregate types until we perform this assessment?
You should go ahead with aggregate types if that will be a relative minor effort.
• Would it be better to embed the CORBA IDL in DML and then translate that to standard AADL? Since we'll have to map down to standard types at some level (either DML -> AADL, or AADL -> Java) it seems like we could perform that mapping during either translation step.
This is something that we should start a discussion on for this summer. And perhaps bring it up at the next meeting to get it on the radar screen (list of possible things to address for the summer).
So after playing with record types in the high-assurance software course, it looks like simple aggregate types are not very hard to model, and may not be super hard to translate. Obviously it's not the full CORBA IDL, but depending on how big of a win this is, it may be worth the implementation effort.
Though sort of verbose, modeling aggregate types in AADL isn't particularly complex:
data SpO2Value
properties
Data_Model::Data_Representation => Integer;
end SpO2Value;
data SpO2Timestamp
properties
Data_Model::Data_Representation => Float;
end SpO2Timestamp;
data SpO2Aggregate
properties
Data_Model::Data_Representation => Struct;
end SpO2Aggregate;
data implementation SpO2Aggregate.imp
subcomponents
val : data PCA_Shutoff_Types::SpO2Value;
time : data PCA_Shutoff_Types::SpO2Timestamp;
end SpO2Aggregate.imp;
Then this could be translated to app-specific classes, as long as all types used in the aggregate are (eventually) mapped to the standard Integer / Float / Boolean etc.
package mdcf.app.example.types
public class SpO2Aggregate {
java.lang.Integer val;
java.lang.Float time;
}
After some more digging, it looks like another way (and perhaps the "intended" way) to model aggregate types in AADL is something more like the example below, but as you can see we lose all type information (everything is encoded as Strings) which I'm pretty unhappy with.
data SpO2Aggregate
properties
Data_Model::Data_Representation => Struct;
Data_Model::Enumerators => ("val", "time");
Data_Model::Representation => ("Integer", "Float");
end SpO2Aggregate;
If "Integer" and "Float" representations are distinct and are associated with "val" and "time" fields, then how is the type information lost? May be, I'm missing something.
If the type information is indeed lost, then this kinda raises an important (the elephant in the room) question "Is AADL the right technology/tool for your purpose?"
If "Integer" and "Float" representations are distinct and are associated with "val" and "time" fields, then how is the type information lost? May be, I'm missing something.
Lost may be poor wording on my part -- the translator could still run / generate typed code. It would cause the following problems, though:
Here's another take using property sets and the record
keyword.
First the property set in data_props.aadl
:
Enum: type enumeration (
enum1, enum2, enum3
);
SystemRecord: record (
a_string: aadlstring;
lower_int: aadlinteger; -- Integer as a primitive
upper_int: classifier (Integer); -- Integer as a Data Model type
an_enum: data_props::Enum;
) applies to (system); -- Aggregate can be applied to any system type or object
Now the model:
system subsys
properties -- Can assign record defaults in type or implementation, or...
data_props::SystemRecord => [
a_string => "string1";
an_enum => enum1;
lower_int => 6;
-- upper_int => 12; -- Not legal, as type has no primitive behind it.
];
end subsys;
system sys
end sys;
system implementation sys.imp
subcomponents
a_sub: system subsys { -- ...can assign record in property of instantiated component.
data_props::SystemRecord => [
a_string => "string1";
an_enum => enum1;
lower_int => 6;
-- upper_int => 12; -- Not legal, as type has no primitive behind it.
];
};
end sys.imp;
It would be nice if app developers could use aggregate types that would bundle together multiple pieces of information. This would allow for things like bundling physiological values with the confidence (or error-state) associated with the value's reading.