Add support for aggregate types

[sprocter]

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.

[John-Hatcliff]

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.

[sprocter]

A couple of questions:

1. Should this issue block on that discussion? That is, should I avoid implementing aggregate types until we perform this assessment?
2. 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.

[John-Hatcliff]

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).

[sprocter]

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.

Examples

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

[sprocter]

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;

[rvprasad]

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?"

[sprocter]

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:

1. The types are now opaque to AADL -- instead of AADL knowing we have an integer, it just knows we have something described by a string.
2. We're forced to choose between:
   1. Asking modelers to refer to base-types in their aggregations (eg, val is an integer) instead of custom types (eg, val is SpO2, which has its own type), or
   2. Asking modelers to type in custom type names (eg val is "SpO2"). OSATE can't offer any syntax assistance, and the translator would have to do more legwork. If we had aggregate types that were several-levels deep (eg val is itself an aggregate type), this could get sort of gross.

[scbarrett]

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;