[aadl]: LUTE/REAL - referencing annex elements

[Julien Delange]

Dear Jerome,

Do you have an example of what the syntax would look like and how you will implement that ? One design guideline I would like to keep is to make the access to annex elements language-agnostic and avoid any annex-specific elements in the constraint language. Then, having some examples (in case you already have some) would be useful as well.


From: Jérôme Hugues [mailto:Jerome.HUGUES at isae.fr]
Sent: Friday, November 15, 2013 5:30 PM
To: Serban Gheorghe
Cc: Julien Delange; Pierre Dissaux; sae-aadl-users at lists.sei.cmu.edu
Subject: Re: [aadl]: LUTE/REAL - referencing annex elements

Hi,

Le 15 nov. 2013 à 17:08, Serban Gheorghe <serbang at edgewater.ca<mailto:serbang at edgewater.ca>> a écrit :

> Thanks for the clarification; I do not see off hand any technical reason why BA subcomponents can’t be referenced in constraint theorems, however I think that it is important to keep separate assertions about the structural sanity of a model (i.e. assertions on presence/absence of features, subcomponents and property fields, assertions on property expressions) from assertions on behaviour (i.e. state history dependent assertions). It would be great if you can send me a few examples of the type of constraint theorems you would want to express using mixed AALL core and BA references.

Referencing separate elements of a BA model could be made in a way similar to real: define accessors per concept.
Then, there is the issue of a not-so-complicated abstraction to represent the automata, and associated API to iterate on it, get guard, get successors, etc

Following Alexey suggestion to use Python, you could imagine getting the automata as a graph, and use Python API for that. Defining one specific to REAL (or its successors) could be painful. It is something I wanted to avoid in REAL, but we needed some elements for lists and sets, yet we lack a lot of features from traditional container libraries.

I'm currently investigating using Python and REAL accessors. It looks quite promising. The benefits is that we only need to standardize accessors, and let tool vendors propose API for manipulating entities. Drawback is that constraints are not portable ..

On the other hand, you have a graph for AADL core (or multiple actually), a timed/guarded automata  for BA, a stochastic/guarded for EMV2.Properties are lists, subcomponents (and features and etc.) are sets. Either we define an API to manipulate those concerns, and reinvent the wheel, but allow for constraints portability. Or we standardize abstract accessors, and then let tool vendors provide optimized solutions (Prolog, Python, LUTE/REAL, etc)

I'm not (yet) convinced about which one is the best, and should be followed. I'd certainly propose to be conservative: define accessors first in the document, then let multiple implementations coexist, and then decide about API

Finally, don't forget also OCL exists and provide for free a constraint language. If memory serves me, Dominique used it.

--
Jérôme Hugues, ISAE/DMIA
Jerome.HUGUES at isae.fr<mailto:Jerome.HUGUES at isae.fr> - (+33) 5 61 33 91 84

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