Checking syntactic constraints on models using ATL model

Checking syntactic constraints on models using ATL model transformations Skander TURKI, Eric SENN, Dominique BLOUIN Workshop mt. ATL 08 -09 july 2009 AIRBUS BARCO Avionics THALES Communications CEA-List CETIC FéRIA Lab-STICC / UBS SQS TCP K. U Leuven Universidad de Cantabria Axlog Verimag Support for Predictable Integration of mission Critical Embedded Systems ITEA 2 European Project

Context § AADL (Architecture and Analysis Design Language) : high-level analysis of the specification, the verification of functional and NFP of the system, code generation for the targeted hardware platform. § CAT (Consumption Analysis Toolbox) : SPICES sub-project that provides a method to estimate power consumption at an early stage of the design process § Integrated with OSATE (on top of Topcased and eclipse) § Marte Standard (Modeling and Analysis of Real-Time Embedded systems ) also integrated with Topcased throw Copyright Airbus -Papyrus. Image Graphique © I 3 M Skander TURKI, Eric SENN, Dominique BLOUIN Lab-STICC Nantes, 08/07/2009

Objectives § Provide UML/Marte users with AADL analysis tools : CAT § Allow AADL users to work with well established commercial case tools. § Accelerate AADL dissemination. Copyright Airbus - Image Graphique © I 3 M Skander TURKI, Eric SENN, Dominique BLOUIN Lab-STICC Nantes, 08/07/2009

Marte. To. Aadl Model Transformation § Use UML/MARTE as an AADL profile : § Marte specification Annex A : Guidance Example for Use of MARTE § allow MARTE users to stand upon precise semantics that are those of AADL : OMG MARTE consortium working with the AADL standardization committee to align MARTE with AADL semantics Skander TURKI, Eric SENN, Dominique BLOUIN Lab-STICC Nantes, 08/07/2009

Use Case : simple embedded system declaration model Structure Mapping rules : - Generalisation between two concrete (or two astract) classes is an AADL extension. - A Generalization from a concrete to an abstract class is an AADL implementation, the opposite is forbidden. Skander TURKI, Eric SENN, Dominique BLOUIN Lab-STICC Nantes, 08/07/2009

Use Case : simple embedded system model transformation CPU 2 is a processor implementaton of CPU processor type that extends CPU 1 Skander TURKI, Eric SENN, Dominique BLOUIN Lab-STICC Nantes, 08/07/2009

Problem : Syntactic gaps Problem : Too much design possibilities with {UML + Marte} Need to : bridge the syntactic gaps between these different languages § Design space reduction: Provide guidelines to MARTE users : Check constraints on transformation time. We decided not to add any extension to MARTE as this would break the standard aspect of MARTE. Skander TURKI, Eric SENN, Dominique BLOUIN Lab-STICC Nantes, 08/07/2009

The Marte. To. Aadl process Skander TURKI, Eric SENN, Dominique BLOUIN Lab-STICC Nantes, 08/07/2009

Design guidelines : Constraints Checking Generation of the Diagnosis Report § These 4 possibilities can be drawn using generalizations. Each possibility corresponds to a different AADL construct: §The first one is mapped to the AADL implementation §The second has no meaningful mapping in AADL, we can ignore it or generate an error message. §The third and forth situations correspond to the AADL extension construct : extend Marte User guidelines: Skander TURKI, Eric SENN, Dominique BLOUIN Lab-STICC Nantes, 08/07/2009

Diagnosis Report Meta Model Skander TURKI, Eric SENN, Dominique BLOUIN Lab-STICC Nantes, 08/07/2009

Design guidelines : Constraints Checking Generation of the Diagnosis Report (2) Skander TURKI, Eric SENN, Dominique BLOUIN Lab-STICC Nantes, 08/07/2009

Using the diagnosis report from the Marte. To. Aadl transformation § get. Higher. Severity. Notification() (if the result is > 2 it cannot continue): Skander TURKI, Eric SENN, Dominique BLOUIN Lab-STICC Nantes, 08/07/2009

Using the diagnosis report from the Marte. To. Aadl transformation (2) … Skander TURKI, Eric SENN, Dominique BLOUIN Lab-STICC Nantes, 08/07/2009

Conclusion § We presented a part of a MARTE to AADL model transformation that is used to solve the syntactic gaps between the two languages by constraints checking. § We also demonstrated how we can use a model transformation to check constraints on models. § We also detailed the presentation of the ecore VERIF metamodel. § We presented the structure of the ATL modules § For some syntactic gaps, we chose not to create a constraint. For implementation reasons, some “bad designs” can just be ignored like allocations between abstract classes. Skander TURKI, Eric SENN, Dominique BLOUIN Lab-STICC Nantes, 08/07/2009

Perspectives §Check constraints in design time? §Externalize the definition of constraints : easily extendable (like we externalized the mappings in an ATL library) Skander TURKI, Eric SENN, Dominique BLOUIN Lab-STICC Nantes, 08/07/2009

UMR 3192 Thank You