Query Language for AADLv2, Jérôme Hugues, ISAE Serban Gheorghe, Edgewater

Query Language for AADLv2, Jérôme Hugues, ISAE Serban Gheorghe, Edgewater

Outline 1. Discussion from previous meetings 2. Defining elements for a DSL, inputs from the meta model 3. Defining elements for a DSL, inputs from user needs 4. Binding to model elements page 2

AADL A is for analysis Analysis of AADL models rely on a QVT-like approach Queries on the model, View (restriction) of model elements then Transform into analytic models Actually more than 50+ transformations towards analysis Yet, some very simple are also required Need a DSL to ease implementation of analysis plug-ins Rationale: reduce implementation code for new analysis, hide meta-model for nonexperts, adaptable to project-specific needs page 3

A few approaches Having something generic is not new to AADL, but done in different contexts REAL (O. Gilles PhD) : based on set theory One theorem = one constraint expressed on a model E.g. compatibility with Ravenscar, MILS, ARINC653 Tested by ESA, RC OAR (SEI, UIUC): DSL to query model elements Then delegation to Mathematica to compute/refine some properties E.g. allocate threads to processors OCL (D. Blouin): library of helper functions page 4

Roadmap proposal (from Paris meeting) Objectives: do not define a DSL, but bricks of a DSL for other annex languages From the AADLv2 meta-model and OAR, OCL, REAL Define mini-language for querying properties Similarly, should map meta-model, and be simple Reflect type and unit systems, Easy to take into account new property types (this.<property_name> too complex?) Define list of accessors on the declarative and instance models Name of accessors should map meta-model ones, But need to synchronize to reduce complexity of accessors page 5

Objectives and non-objectives Main objective: define a sublanguage to be integrated to other AADL annex languages Defining a full-fledged language is out of scope Use of query language depends on analysis, programming model, Some analysis are better expressed with.. An imperative language: e.g. Response Time Analysis A logic language (a-la Prolog): e.g. architectural patterns A set-based language (e.g. REAL): restrictions on patterns A query language is the root of all these prog. Models A sublanguage to fetch information from models elements of both the declarative model and the instance model Should enable navigation (introspection) of models page 6

High-Level Requirements (R1) The query language shall have the following properties (a) Easy integration to other language, e.g. Behavioral Annex E.g. compute() based on Compute_Execution_Time (b) Follow scope rules from AADLv2 Notion of local subcomponents, features, parent component, etc. Possibility to integrate in an annex language (c) Computations made by host language page 7

High-Level Requirements (R2) The Query Language shall support (a) Fetching information on property values (b) Building collections of AADL model entities Abstract collection: array, list, set depending on the host language From particular predicate (category, category + filter) (c) specifying the Query universe Instance model rooted at top system component Instance model rooted at this component The whole workspace (d) specifying both transitive and non transitive queries page 8

Syntax of the Query Language (R3) The Syntax of the Query Language shall be close to (a) The declarative language for manipulating property types: aadlinteger, aadlboolean, range, units, etc. Rationale: avoid syntactic sugar from meta-model (b) The meta-model for model entities: component type/implementation, subcomponents, features, etc. Rationale: take advantage of JMI code whenever possible (R4): The syntax shall be close to Java one Rationale: so are JMI, OCL, ATL, et al. Note: divergence to R3 might be necessary to accommodate incidental complexities from AADLv2 meta-model E.g. when manipulating property types that are range of units, e.g. Compute_Execution_Time page 9

Outline 1. Discussion from previous meetings 2. Defining elements for a DSL, inputs from the meta model 3. Defining elements for a DSL, inputs from user needs 4. Binding to model elements page 10

Package. Public decl... Private decl. AADL model elements Component type. Identifier. Extends. Prototypes. Features. Flows. Properties. Annex. Ports. Access. Subprogram. Parameter. Feature Category. Data. Subprogram. Thread (group). Process. Memory. Device. (virtual) processor. (virtual) bus. System. Abstract references Property sets. Units. Property type. Property definition. Constants Component implementation. Identifier. Extends. Subcomponents. Connections. Call sequences. Modes. Flows. Properties. Annex. Ports. Access. Parameter. Modes. transitions page 11

Strategy for designing accessors Idea pushed by Alain Plantec (UBO) Define a simplified version of the meta-model of AADLv2 Iterate on it, based on actual project requirements Rationale Resolve statically all elements: extends, prototypes, properties Note: it is the way Ocarina proceeds to generate code out of its decorated AST, robust and generic Implemented in Ocarina/TASTE as An XML schema An AADLv2 instance model to XML transformation Validation scripts page 12

Package. Public decl... Private decl. AADLv2 simplified Component type. Identifier. Extends. Prototypes. Features. Flows. Properties. Annex. Ports. Access. Subprogram. Parameter. Feature Category. Data. Subprogram. Thread (group). Process. Memory. Device. (virtual) processor. (virtual) bus. System. Abstract references Property sets. Units. Property type. Property definition. Constants Component implementation. Identifier. Extends. Subcomponents. Connections. Call sequences. Modes. Flows. Properties (resolved). Annex. Ports. Access. Parameter. Modes. transitions page 13

Accessors from XML Schema These are directly derived from the XSD definition Generic rules apply to map XSD to various programming languages, like Java or Python Use this to infer the query DSL List of accessors Relationships among entities page 14

Outline 1. Discussion from previous meetings 2. Defining elements for a DSL, inputs from the meta model 3. Defining elements for a DSL, inputs from user needs 4. Binding to model elements page 15

Set of Queries Need to reflect on the actual requirements from existing analysis and experiments Existing inputs Ocarina tests: Ravenscar, MILS, ARINC653, Data Model annex ESA tests: ARAM Other private experiments from LUTE page 16

Outline 1. Discussion from previous meetings 2. Defining elements for a DSL, inputs from the meta model 3. Defining elements for a DSL, inputs from user needs 4. Binding to model elements page 17

Query universe Defining scope or universe of the query is key issue a) Root of Query Universe a) whole workspace b) top system instance c) a reference to a component in the instance model from a previous query b) transitive vs non-transitive Query page 18

Binding queries to AADL models Using AADL annex subclause + Liskov principle -- This system models a Ravenscar-compliant system, see -- corresponding REAL theorems for more details. system Ravenscar_System extends AADL_System Inherit constraints annex real_specification {** theorem check_ravenscar foreach s in Local_Set do Attach constraint to requires (check_ravenscar_profile); a model entity, apply check (1 = 1); to all end check_ravenscar; **}; implementations end Ravenscar_System; Pro: incremental refinement of systems constraints, from generic rules (AADL, Ravenscar) to specific ones, bound to OSATE automatic builders Cons: could add many layers, if combined with annexes page 19

Binding queries to AADL models (cont d) Using tool specific mechanisms Ocarina command line parameters RDAL intrinsics OSATE plug-ins Pro: clean separation of concerns, the language uses its semantics to find the elements on which it applies, with a first initial query Con: when to trigger queries? page 20

Roadmap 1. Provide clear definition of Query universe List of accessors 2. Provide examples and case studies Interaction with PSL and RDAL(?) Study interactions with ASL effort by UBO Study outcome from Lute (Rockwell) page 21