[aadl]: Examples for BA D.6-10 and D.7-07 errata

[Denis Buzdalov]

Hi, all.

I have several examples showing a need of making expression language
(in particular, in the `computation' action) a little bit more complex.
This need is expressed in errata D.6-10 and D.7-07, so this explanation
actually touches them.

Proposed additions can be divided to few types:
1) operations over timed values;
2) usage of data state in expressions;
3) addition of time unit to numbers;
4) making existing operations a little bit wider.

Let me go though the list.

-----------------

1) The simplest example, when we have pretty rough model with several
time values modelled, is:

computation(initialization_time + action_time);

where both initialization_time and action_time are property values.

This can be modelled by two consequent computations but I think this
looks (both semantically and in code) better.

We can have a little bit more complex example:

computation(initialization_time +
            known_constant_property * action_time);

Again, this can be modelled by a loop with the only computation action
in it, but it is harder to analyze and harder to understand.

The more complicated example is when we can't know the constant value
of repetition times and when we have only bounds:

computation(initialization_time +
            known_constant_bounds * action_time);

where known_constant_bounds is a property value of number range type.

-----------------

2) If we want to model e.g. a device with a property similar to
`transmission_time' for buses, we can have a need of writing
computations like

computation(initialization_time +
            variable_for_modeling_amount_of_work * action_item_time)

-----------------

3) Some numeric calculations may be needed to get a numeric value of
timed value. For example, consider we need to express some calculations
of time using numeric operations (like `max')

computation(max(1 / rate_value.upper, 1) sec + (5 ms .. 6 ms));

Sometimes, we probably would need this operation of adding time unit to
the numeric value applied to numeric range:

computation(range_value sec);

What we probably would need it is explained further.

-----------------

4.1) Ranges might be used in a pretty complex context:

computation(time_range_property * 5);

or

computation(time_range_property * dynamic_coefficient);

where `dynamic_coefficient' is a variable.

Ranges need to be shifted sometimes:

computation(standard_time_range_property + offset ms);

-----------------

4.2) One more example that touches operations on ranges is the
following.

Consider a model of a device having one port `data_port' with defined
`output_rate' property and sending data through this port according to
the rate. At the moment (considering resolved positively errata) we can
write something like:

states
  s : initial complete final state;
transitions
  s-[]->s {
    data_port ! (<data-to-send>);
    computation((1 / data_port#Output_Rate.Value_Range.upper) sec ..
                (1 / data_port#Output_Rate.Value_Range.lower) sec);
  };

Having an operation of addition of time unit to expression and having
one more nice operation of division using ranges, we can rewrite the
`computation' call by

    computation((1 / data_port#Output_Rate.Value_Range) sec);

which looks better and more understandable.

I understand possible troubles with division of a constant to
zero-containing range (because of getting two non-interlapping
semiunbound ranges) but I think this situation is manageable: e.g. as a
simple solution, division by zero-containing range can be prohibited.
This prohibition doesn't frighten me on its hardness to check in static
since we have prohibitions in the standard that are much harder to be
checked.

--
Denis Buzdalov
Software Engineering Department, ISPRAS