[fr] [en]
Dans les années 90, des initiatives de recherches ont été lancées dans le domaine de l'architecture logicielle avec pour objectif de combler le fossé séparant les lignes de codes des éléments gros-grains et la structure de leurs interactions. Les bénéfices attendus étaient une amélioration de l'évolutivité et de la compréhension du logiciel et du système, le support de développements basés sur l'architecture (lignes de produits, réutilisabilité), et de fournir une approche plus flexible pour l'intégration système. Un langage de description d'architectures (ADL) est une manière semi-formelle de spécifier les architectures logicielles et systèmes. Un ADL est un langage informatique utilisé pour décrire les composants logiciels, ou les composants logiciels et matériels, d'un système et les interactions entre ces composants. Le langage est utilisé pour décrire la structure d'un tel système comme un assemblage de composants logiciels et matériels. Le langage peut décrire les interfaces fonctionnelles des composants (flots de contrôle et de données) et les aspects non fonctionnels (aspects temporels, sûreté, fiabilité). À un plus haut niveau, la spécification d'une architecture décrit comment ces composants sont combinés en sous-systèmes, comment ils interagissent (structure des flots de données et de contrôles), et comment ils sont alloués sur les composants matériels.
MetaH est un ADL dédié aux systèmes avioniques qui a été développé par Honeywell depuis 1991 pour le DARPA et l'US Army. Un ensemble conséquent d'outils (éditeurs graphiques, analyseurs temporels, d'ordonnancement, de charge, générateurs de code...) ont déjà été prototypés et utilisés dans le contexte de plusieurs projets expérimentaux qui ont montré des bénéfices durant le développement compris entre 50 % (nouveau projet) et 90 % (modification de projet existant).
En 2001, MetaH a été pris comme base pour un effort de standardisation visant à définir AADL, un langage de description d'architectures avioniques, sous l'autorité du SAE. Cet AADL émergeant est un ADL développé pour répondre aux besoins spéciaux des systèmes embarqués temps-réel tels que les systèmes avioniques. En particulier, le langage peut décrire les mécanismes standard de flots de contrôles et de données utilisés dans les systèmes avioniques, et des aspects non-fonctionnels importants tels que les exigences temporelles, les fautes et erreurs, le partitionnement temporel et spatial et les propriétés de sûreté et de certification.
Le nom d'AADL signifie Architecture Analysis & Design Language (langage d'analyse et de conception d'architectures). Initialement, pour des raisons historiques, l'acronyme signifiait Avionics Architecture Description Language (Langage de description d'architectures avioniques). En pratique AADL s'adresse à tous les systèmes embarqués temps-réel, et pas seulement aux systèmes avioniques.
AADL est d'abord un langage textuel. Une annexe au standard définit une notation graphique associée. Une autre annexe définira un profil UML pour AADL.
La description d'une architecture en AADL consiste donc en la description de ses composants et leur composition sous forme d'une arborescence. Cette description pouvant être contenue dans des fichiers, une base de données, etc.
Les exemples données par la suite se réfèrent à la version 1.0 du standard.
Chaque composant est décrit en AADL en deux phases. La première, le type, correspond à l'interface fonctionnelle du composant, ce qui est visible des autres composants. La seconde, l'implémentation, décrit le contenu du composant (sous-composants, propriétés, connexions, etc.).
L'intérêt de scinder une description de composant en type et implémentation est de séparer deux points de vue. Décrire le type revient à spécifier l'interface du composant, exprimer à quoi il doit ressembler vu de l'extérieur. En revanche l'implémentation représente l'intérieur. Dans la pratique la description du type et de l'implémentation pourront être faites par des personnes différentes, chacune ayant en charge une étape dans le raffinement de la description de l'architecture, du plus haut niveau jusqu'aux moindres détails.
Chaque composant appartient à une catégorie. Ces catégories sont prédéfinie et se décomposent en catégories matérielles, catégories logicielles ou catégories composites :
Chaque implémentation est associée à un type de la même catégorie. À chaque type peuvent être associés zéro, une ou plusieurs implémentations. Le schéma ci-dessous montre deux types de composants (component types) dont le premier est associé à deux implémentations de composants (component implementations). L'extrait donnée ensuite montre un exemple de description de composants systèmes correspondant au schéma.
 |
system type1 end type1; system type2 end type2; system implementation type1.impl1 end type1.impl1; system implementation type1.impl2 end type1.impl2; |
Un mécanisme d'héritage existe pour décrire les composants. Il peut être appliqué tant aux types qu'aux implémentations. Ce mécanisme est d'une grande utilisé lorsque l'on veut raffiner une description en surchargeant un composant déjà décrit.
Certaines restrictions doivent être respectées. Ainsi, un type de composant peut hériter d'un autre type de même catégorie. De même une implémentation de composant peut hértier d'une autre implémentation de même catégorie.
Les relations type/implémentation se combinent avec les relations d'héritage. Ceci peut conduire à des schémas assez complexes, comme l'illustre la figure ci-dessous.
 |
system type1 end type1; system type2 extends type1 end type2; system implementation type1.impl1 end type1.impl1; system implementation type1.impl2 extends type1.impl1 end type1.impl2; system implementation type2.impl1 end type2.impl1; system implementation type2.impl2 extends type1.impl2 end type2.impl2; |
À chaque composant on peut associer des propriétés et leur donner des valeurs. Celles-ci permettent de caractériser le composant.
Certaines propriétés sont prédéfinies, c'est-à-dire qu'elles sont identifiées par un nom, un type et la liste des catégories de composants sur lesquelles elles s'appliquent. Par exemple les tâches (thread) disposent de propriétés temps-réel telles que la période, l'échéance ou la durée d'exécution.
De nouvelles propriétés, et de nouveaux types de propriétés, peuvent aussi être définis par l'utilisateur et associés à tout ou partie des catégories de composants. Ce mécanisme de propriétés est un point fort d'AADL en matière d'extensibilité. Grâce à lui, toute notion spécifique au besoin de l'utilisateur peut être prise en compte dans sa description.
thread thread1
properties
Period => 15 ms;
Deadline => 10 ms;
end thread1;
|
La description des flots de données et de contrôles entre composants se fait par le moyen de ports et de connexions. Un port est un point d'entrée et/ou de sortie d'un composant, par où peuvent transiter des données, des événements ou même des événements associés à des données. Une connexion permet de relier deux ports, soit les ports de deux sous-composants, soit le port d'un sous-composant avec le port du composant le contenant. Une vérification est faite qu'il y a bien conformité de type et de sens entre les ports connectés.
Le schéma suivant montre un système contenant deux process, eux-même contenant chacun un thread. Une succession de ports, représentés par les triangles, et de connexions, représentées par les lignes, établit une liaison entre les deux threads.
 |
system system1
end system1;
system implementation system1.impl
subcomponents
p1: process process1.impl;
p2: process process2.impl;
connections
cn: data port p1.outport -> p2.inport;
end system1.impl;
process process1
features
outport: out data port;
end process1;
process implementation process1.impl
subcomponents
t1: thread thread1.impl;
connections
cn: data port t1.outport -> outport;
end process1.impl;
process process2
features
inport: in data port;
end process2;
|
process implementation process2.impl
subcomponents
t2: thread thread2.impl;
connections
cn: data port inport -> t2.inport;
end process2.impl;
thread thread1
features
outport: out data port;
end thread1;
thread implementation thread1.impl
end thread1.impl;
thread thread2
features
inport: in data port;
end thread2;
thread implementation thread2.impl
end thread2.impl;
|
Le standard AADL fournit encore bien d'autres caractéristiques non décrites dans cette page. Citons cependant rapidement quelques uns de ces mécanismes :
Pour avoir plus d'informations, pour poser des questions, n'hésitez-pas à nous contacter.
Axlog et sa filiale Adalog proposent des cours complets AADL (description du cours, renseignements pratiques et contacts ici).