OSATE

OSATE (Open Source AADL Tool Environment) est un environnement de développement open source autour du langage de modélisation AADL développé par le SEI (Software Engineering Institute). Il s’adresse aux concepteurs de SETRC et fournit des outils de conception et d’analyse. Son architecture est illustrée par la figure 6.1. OSATE est construit autour de l’environnement Eclipse et de son framework de méta-modélisation EMF (Eclipse Modeling Framework). Eclipse fournit un ensemble d’abstractions pour spécialiser l’environnement à une application particulière. EMF est une surcouche pour la définition de langages spécifiques et pour la transformation de modèles : EMF inclut notamment le méta-métamodèle Ecore et le support du format d’échange XMI. Pour supporter l’intégration de plug-ins, OSATE définit également des abstractions pour mettre en place des outils d’analyse de modèles AADL ainsi que des générateurs de code pour des plates-formes d’exécution spécifiques. OSATE est une spécialisation du framework Eclipse [2] pour AADL. Le code source d’OSATE s’organise en un ensemble conséquent de 46 projets Java qui s’insèrent au-dessus du framework Eclipse/EMF. Parmi ces 46 projets, 12 sont dédiés à l’analyse (e.g. analyse architecturale, latence, consommation d’énergie…). Les projets restants définissent l’architecture d’OSATE. Notamment : – org.osate.aadl2 définit le méta-modèle AADL au format Ecore [17]. Ce projet contient également l’ensemble des classes Java qui constituent les éléments du méta-modèle. Elles sont automatiquement générées à partir du méta-modèle Ecore. – org.osate.aadl2.instanciation implémente l’instanciation de modèles AADL, c’est-à-dire la sélection du composant AADL principal et la simplification du modèle (suppression des composants non utilisés, fusion des types hérités…). – org.osate.aadl2.modelsupport fournit des mécanismes pour faciliter la mise en place de plug-ins d’analyse et de génération : méthodes de parcours des éléments d’un modèle AADL, notifications d’erreurs, utilisation des ressources internes à l’environnement (éditeur textuel, explorateur de projets). – org.osate.annexsupport permet la définition et l’intégration d’annexes au langage AADL (i.e. extensions du langage). Il fournit les types génériques qu’il faut spécialiser pour assurer un support complet d’une annexe. La figure 6.2 donne un aperçu de l’environnement Eclipse dans lequel les développeurs créent leurs plug-ins OSATE (i.e. back-end)

Architecture de RAMSES 

Le framework RAMSES est un ensemble de modules pour l’environnement OSATE. La figure 6.4 donne une vue d’ensemble de l’architecture de RAMSES. Celle-ci est constituée de quatre branches : Lancement, Transformation, Analyse et Generation. Celles-ci sont décrites dans les paragraphes suivants Lancement Cette branche a pour rôle de piloter le processus de raffinement incrémental et de coordonner ses différentes étapes (e.g. transformation, analyse, génération). Il s’agit du cœur du framework. Elle implémente la logique d’exécution du processus et contient les ressources nécessaires à son fonctionnement : méta-modèle du processus, moteur de transformation. Les plugins Core et Support assurent respectivement l’initialisation du processus en ligne de commande et son exécution. L’initialisation est réalisée en ligne de commande par l’utilisateur qui spécifie : une liste de modèles AADL, le code source métier ainsi que le fichier décrivant le processus. Le lancement est détaillé en section 6.3. Transformation Cette branche réalise les étapes Transformation du processus en s’appuyant sur plusieurs bibliothèques : – Une bibliothèque de modules de transformation (Targets) : ceux-ci réalisent le raffinement de différents éléments AADL. Pour favoriser la réutilisation et l’adaptation de raffinements, ces modules sont classés par plate-forme d’exécution (e.g. common, arinc653, osek) et par objectif de raffinement (e.g. communications, architecture). Ils sont référencés par l’utilisateur dans la description du processus pour définir les étapes de transformation : chaque étape référence une liste de modules qui seront superimposés lors de l’exécution du processus. – Une bibliothèque de fonctions d’interrogation (Tools) : les fonctions d’interrogation sont des expressions OCL qui modélisent des contraintes plus ou moins complexes pour filtrer les éléments AADL sur lesquels les transformations sont appliquées. Ces interrogateurs améliorent ainsi la lisibilité des transformations.