[aadl]: Couple of Data Modeling Annex issues

[Jérôme Hugues]

Hi Denis,

Le 15 avr. 2015 à 17:57, Denis Buzdalov <buzdalov at ispras.ru> a écrit :

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

About this question, and your lengthy comment after. Let me recall that the initial purpose of this property was to allow the modeling of initial value of a data port, parameter (default value), etc
We discussed also the issue you mentioned. We decided at that point that defining such legality rule would be tricky, firstly because we would need to put a “real language” for the value.
Depending on the usage of this value, this would be problematic. For Ocarina, we pass it “as is” to the compiler, and it checks its validity.

Perhaps we should detail more precisely this design rationale to evacuate the question

If we enter into the business of defining legality rule, once again we take the risk of defining a complex expression language for data types. ASN.1 is better for that purpose

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

Exactly on purpose ! We did not have the resources and the consideration for this for the reasons I stated before. But perhaps we would want to do it not just because of initial value, but because of the behavioral annex. From your example, how would you do the same initialization in one statement ? If we do it, then we can simply “borrow” it for the data annex

For TASTE, we took a different approach: if we want to be really that precise, we use ASN.1 for data types, and leave the data modeling for basic situations like definition of buffers

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

I will put this on the list of things to be discussed for the next meeting
Thanks


—
Jerome HUGUES
Enseignant-Chercheur/Associate Professor 
Ingénierie des Systèmes Embarqués/Embedded Systems Engineering

ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l’Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr 
Tel (+33) 5 61 33 91 84 - Fax (+33) 5 61 33 83 30
Plan d'accès/Access map

-------------- next part --------------
HTML attachment scrubbed and removed