[aadl]: On data components modelling problems

[Denis Buzdalov]

Hi Jérôme,

> I defined an endianness property for my own needs, but it applies to
> processor, (it is actually, AFAICT, a configuration of the
> OS/processor for some family of processors), I do not see why it
> should be applied to data

Sometimes, data has endianess that does not depend on the processor/OS
which handles it. The very common examples are network and bus
protocols.

For example, data of TCP protocol is hold in big-endian (this is not
applied to the payload, only to protocol-related data); data of USB bus
protocol is hold in little-endian. That's why if we are going to model
such things, we need to specify endianness of both processors and some
peaces of data.

> - order of component relates to how you translate a data component
> into a programming language

I can't agree with you fully as this point. Of course, I'm aware on
the order when I translate a data component into a programming
language. But I wrote an example in which order is significant but we
are not aware of programming languages at all, we are just modelling
one part of a system in a precise way but another part remains
abstract yet.

Yes, it is an open question whether AADL can be used for modelling
on different preciseness level in the same model, but
- I can't see fundamental reasons why not,
- I know applications where it can be really useful.

> - about alignment, I fail too see how you can model alignement
> without considering it in association with “in binding”, that is also
> likely to be removed (if not already do). Similarly, does it belong
> to AADL ?

Again, some protocols define that this or that data structures have to
be aligned. When we are modelling these structures in AADL, we have to
consider alignment.

I'm not talking about hardware alignments that are actually not really
present in most of models (like padding bits in MAC-level of ethernet
network). I'm talking about higher-level protocols, which structures
can be present in AADL models explicitly.

--
Denis Buzdalov
Software Engineering Department, ISPRAS