• Aucun résultat trouvé

TASM X ATL Consommation de Ressources, Synchronisation Toolset TASM UPPAAL &

4.3 ABAReL : Une Annexe Comportementale pour AADL

4.3.1 Les annexes AADL

Les annexes permettent d’incorporer des éléments rédigés dans une syntaxe différente de celle d’AADL. Elles permettent d’étendre la syntaxe AADL tout en utilisant des

outils existants. Plusieurs annexes du noyau AADL, utilisant différents formalismes, ont été approuvées et publiées par le standard. Nous résumons dans ce qui suit les annexes les plus connues. Nous accordons une attention particulière à la présentation de l’annexe comportementale [DBF+06], pour montrer les apports de notre annexe comportementale qui semble avoir des motivations similaires.

Annexe des notations graphiques : elle définit un ensemble de symboles graphiques pouvant être utilisés pour exprimer des relations entre composants, dispositifs, et connexions dans un modèle AADL. Les diagrammes graphiques d'AADL apportent plus de clarté et de compréhension au plan architectural d’un système embarqué. Ils permettent une présentation visuelle claire de la hiérarchie structurelle d'un système et de sa topologie de communication. Ces diagrammes sont parfaitement légaux selon la norme de noyau AADL si les symboles graphiques (voir chapitre 2, section 4.1.1) sont utilisés correctement dans le modèle graphique AADL.

Annexe des formats d’échange XMI : elle contient la définition du méta modèle AADL et les formats d'échange basés-XML pour les modèles AADL [SAE06]. Le méta modèle AADL décrit la structure des modèles AADL, c’est-à-dire, une représentation objet des spécifications AADL qui correspond sémantiquement à un arbre syntaxique abstrait. Il a été développé en utilisant la notation Ecore de l’environnement de modélisation Eclipse (EMF). Ce méta modèle est représenté comme ensemble de diagrammes de classes UML avec des propriétés additionnelles spécifiques-EMF qui supportent la génération automatique de méthodes pour la manipulation des modèles objet AADL et pour le stockage persistant et la récupération de tels modèles dans un ou plusieurs documents XML. En effet, cet environnement EMF produit également un schéma XML et un méta modèle XMI du méta modèle AADL. Ceci permet aux différents outils de l’environnement EMF, qui supportent le schéma AADL XML ou les spécifications XMI du méta modèle, d'interopérer sur des modèles AADL.

Annexe d’Interface de Programme d’Application : définit des règles pour que le texte source d’un langage de programmation spécifique soit conforme avec des spécifications d'architecture écrites en AADL. Cette annexe fournit des directives aux utilisateurs permettant d’assurer la transition entre les modèles AADL et le texte source d’un langage de programmation tels que ADA ou C. Elle préconise l'utilisation d'une API (Application Program Interface) entre le logiciel d'application et l'environnement d'exécution pour faciliter l'utilisation des modules contenant le code source d’application du langage dans un environnement d'exécution de l’architecture AADL.

Annexe du modèle d’erreur : définit des dispositifs pour permettre les spécifications de la gestion de redondance et des méthodes de mitigation de risque dans une architecture. Elle permet également des évaluations qualitatives et quantitatives des propriétés du système telles que la sûreté, la fiabilité, l'intégrité, la disponibilité, et la maintenabilité. Cette annexe définit un sous-langage qui peut être utilisé pour déclarer des modèles d'erreur dans une bibliothèque d'annexe d'erreur pour les associer aux composants dans des spécifications d'architecture. Elle définit également un sous-langage qui peut être utilisé dans une clause de l'annexe d'erreur d’une déclaration de l’implantation du noyau AADL standard.

L’annexe de comportement : permet d'exprimer les concepts de composition haute niveau, tels que les modes de synchronisation HRT-HOOD dans les modèles AADL par des annotations comportementales [DBF+06]. Ces annotations préservent la sémantique et les règles d'utilisation du langage AADL définies par le standard. Les extensions sont introduites par l'intermédiaire de nouvelles propriétés déclarées dans une clause « Property Set » ou via le mécanisme d'annexes. Les comportements décrits dans cette annexe sont vus comme des spécifications de comportements réels: ils peuvent donc être non déterministes. Ils sont basés sur les variables d'état dont l'évolution est spécifiée par les transitions exprimées dans l’annexe comportementale. Généralement, une spécification de cette annexe se présente comme suit :

annex behavior_specification {** <state variables> ? <initialization> ? <states> ? <transistions> ? <connections> ? **} ;

Exemple 1 : Pour expliquer les fonctionnalités de cette annexe, nous présentons un exemple de description AADL d’un thread nommé test contenant la déclaration d’une annexe comportementale décrivant l’envoi et la réception de messages.

thread test

features

p_in : in event data port Behaviour ::integer ; p_out: out event data port Behaviour ::integer ;

end test;

thread implementation test.default subcomponents

x: data Behaviour:: integer;

annex Behaviour_behavior {** states s0: initial state; s1: state; transitions s0 –[p_in?(x)] -> s1; s1 –[p_out!(x+1)] -> s0; **} end test.default;

Figure 4.1 – Exemple d’une annexe de comportement dans la description d’un thread

Le thread test reçoit un message à travers son port d’entrée p_in. La réception de ce message est spécifiée, dans cette annexe de comportement, par la première transition. Celle-ci fait passer le thread de l’état s0 à l’état s1 en défilant une donnée de la variable x au niveau de la garde [p_in ?(x)]. La deuxième transition spécifie l’envoie de message à travers le port de sortie p_out où la

variable x de la garde [p_out!(x+1)] est incrémentée par 1 et l’état du thread transite vers s0.

Notons que cette annexe ne change pas la sémantique existante du noyau du langage, elle offre juste des extensions optionnelles. Elle est basée sur le modèle d’exécution AADL dont la sémantique doit être formalisée. Des tentatives de formalisation de ce modèle d’exécution ont été abordées dans les travaux de [YHM+09] en utilisant comme formalisme la machine d’état abstraite temporisée (TASM). Néanmoins, cette contribution et plusieurs autres (voir section 4.2) se limitent uniquement à la formalisation de certains concepts AADL et le comportement complexe d’un thread n’est pas formellement défini. Nous présentons dans la section suivante une définition alternative d’une annexe comportementale basée sur la logique de réécriture permettant de compléter les insuffisances constatées lors de l’utilisation de l’annexe existante.