Description Architecturale et Comportementale à l’aide du langage AADLv2

Dans les chapitres précédents, nous avons présenté l’utilisation du langage AADL pour la modélisation, la configuration et le déploiement des composants architecturaux des systèmes TRAADLv2 et de ses annexes qui introduisent de nombreux éléments et améliorations permettant une description plus fine des composants architecturaux et de leur comportement.développé pour les systèmes avioniques et spatiaux. Destiné lui aussi à l’avionique, la richesse d’expression et les nom- breuses extensions du langage AADL ont étendu son activité au domaine des systèmes TR), dont un sous-ensemble d’élé- ments constitue notre épine dorsale pour la description logicielle architecturale et compor- tementale d’une application répartie avec une sémantique très proche de son implantation physique.Ce chapitre s’organise de la manière suivante. La section 4.2 présente les éléments du lan- gage cœur (composants matériels, logiciels, connecteurs, propriétés, etc). La section 4.3 est une introduction aux différents langages définis par l’annexe comportementale et présente nos contributions pour le développement et l’écriture de ce standard. La section 4.4 présente les avantages et les restrictions pour la modélisation des systèmes critiques. Enfin, la section 4.6 conclut ce chapitre.E par un assemblage de composants ma- tériels et logiciels connectés. Les propriétés AADL complètent la modélisation du système en autorisant l’attachement d’exigences fonctionnelles (fonction de calcul…) ou non fonction- nelles (contraintes temporelles, informations de déploiement…). Les annexes étendent le pou- voir d’expression du langage en définissant des règles, des recommandations, des patrons de modélisation ou des langages différents (ou externes) pour couvrir différents aspects du système que ce soit à des fins de représentation, d’analyse, d’implantation, etc.

Le langage AADLv2 apporte différentes améliorations (un méta-modèle, représentation gra- phique standardisée, profils, extensions…) caractéristiques des langages de modélisation spé- cifique à un domaine. AADLv2 définit des composants matériels et logiciels du système spécifiés par une inter-face (component_type) décrivant les éléments d’interface pour la connexion inter-composants et une implantation (component_implementation) spécifiant la structure interne du compo- sant. Un agrégat (ou composition) de composants peut décrire un composant établissant ainsi une hiérarchie composant → sous-composants structurant la description architecturale. AADLpropose deux catégories principales de composants : les composants matériels et logiciels et des composants spécifiques pour la composition du système (system) ou pour les premières étapes de la modélisation (abstract, voir 4.2.7).Le standard AADL autorise l’agrégation de composants et la définition de sous-composants selon des règles sémantiques précises. Le tableau 4.1 présente les relations légales entre composants et sous-composants découlant de la logique de composition de l’application. Par exemple, un composant de donnée ne peut pas contenir un processus ou un processeur ; cela ne correspond à aucun assemblage réel.

Eléments d’interfaces et connexions

Les éléments d’interfaces des composants (spécifiés au sein d’un component_type) mo- délisent les flôts de contrôles ou de données. Ils décrivent les mécanismes d’interaction pour l’échange et/ou la synchronisation de données entre les éléments de l’architecture. La com- munication est alors établie à l’aide des connexions reliant deux éléments d’interfaces. AADLLe listing 4.1 illustre l’utilisation des éléments d’interfaces et des connexions. Le proces- sus Transmitter.Impl contient un thread Transmitter_Thread.Impl qui exécute le sous- programme Transmit. Le port en entrée du processus est connecté à celui du thread, lui- même connecté au paramètre d’entrée du sous-programme. Le paramètre de sortie du sous- programme est connecté au port en sortie du thread, lui-même connecté au port en sortie du processus.Les accesseurs de composants (provides ou requires access) permettent de spécifier les accès aux sous-composants ou les relations entre les composants de données parta- gées et les sous-programmes pour leur manipulation. Le listing 4.2 décrit le patron de mo- délisation d’une variable partagée et les sous-programmes pour sa manipulation. Le thread Producer qui exécute le sous-programme Update déclare requérir l’accès à la donnée parta- gée Shared_Data. Le composant processus spécifiant le thread Producer effectue la connexion entre la donnée partagée et le thread.