[aadl]: Couple of Data Modeling Annex issues

[Denis Buzdalov]

Hi, Jérôme and all interested in Data Modeling Annex!

Some questions are raised during implementation of partial support of
data_modeling property set in our simulator.

1) Initial_Value property is a list of strings. Meaning of each string
in case of non-string simple values is pretty clear. But what is meant
when we have some simple data component (e.g. Base_Types::Integer) with
Initial_Value property association to list of different correct strings
(e.g. => ("0", "1")? Is this situation legal?
If it is, what is its meaning?
If it is not, why don't we add a legality rule for it?
Probably, we should consider leaving a single string for a value of
Initial_Value property?

2) Let's consider also initial values for complex data structures.
Consider an example

data St
end St;

data implementation St.impl
subcomponents
  a: data Base_Types::Integer;
  b: data Base_Types::Integer;
end St.impl;

process p
end p;

process implementation p.impl
subcomponents
  st: data St.impl;
end p.impl;

What is meant to do if we want some initial values for p.impl.st data
component instance? Data Modeling Annex at the moment doesn't say about
string representation for data structures.

Of course, we can define an extension of p.impl with appropriate
property associations for subcomponents, but I think this approach is
too dirty to think about because we'll need as much additional
components as we have different initial values and other difficulties
during refactoring and changes in a model with such components.

I can imagine at least three variants to assign initial value to a
structure using existing property association.
One of them uses the fact that Initial_Value is a list:
st: data St.impl {Data_Model::Initial_Value => ("a => 0", "b => 1")}

This approach can be called `imperative' since it looks like multiple
assignment. The pro of such approach is that partial initialization
looks natively, i.e.
{Data_Model::Initial_Value => ("b => 1")}
looks usable, at my mind.

It is also usable when we don't need to override initial value of the
subcomponent `a' (if is already exists).

Another variant is to introduce some syntax for data structures, like
{Data_Model::Initial_Value => ("{ a => 0, b => 1 }")}

At this example we are using curly braces to mark that there's a
structure, not a simple value.

Yet another variant (the worst at my mind) the same as the previous
except using curly braces, i.e. simply
{Data_Model::Initial_Value => ("a => 0, b => 1")}
This approach works badly for nested structures (probably, dots can be
used to access second-level data components).

Last two variants require only a single string as the property value.
So they are applicable in case if it would be considered to leave a
single string instead of list of strings for the `Initial_Value'
property.

3) Actually, the last point is not really a question but a suggestion.
I think we need a legality rule saying that Initial_Value property can
be set only for those data components that have Data_Representation
property set and only for those ports and parameters which corresponding
data components have Data_Representation property set.

This legality rule allows at least to distinguish, for instance, string
and integers with `Data_Model::Initial_Value => ("0")' association. In
general, this requirement allows to interpret initial value string
adequately.

--
Denis Buzdalov
Software Engineering Department, ISPRAS