Modélisation des systèmes temps-réel répartis embarqués pour la ...

Modélisation des systèmes temps-réel répartis embarqués
nœuds de l’application demeure en dehors du cadre d’AADL, et doit par exemple être réalisée à
l’aide d’un langage de programmation.
Nous avons retranscrit en AADL les paramètres de configuration reconnus par GLADE sous
la forme d’un ensemble de composants et de propriétés AADL ; nous nous appuyons sur un système
de configuration concret. En pouvant ainsi exprimer un fichier de configuration de GLADE
en AADL, nous montrons que notre approche est viable, puisqu’il est possible d’utiliser AADL
comme langage alternatif pour une application industrielle.
Dans la mesure où elles sont relativement concises, les descriptions architecturales que nous
pouvons faire peuvent également être exploitées à des fins de documentation pour décrire l’allure
générale des applications.
Néanmoins, nous n’exploitons en fait qu’une partie des possibilités offertes par le langage,
et nous ne décrivons que la répartition des applications. Cette approche permet une approche de
description très souple, mais sous-utilise donc AADL. Par ailleurs, nous ne spécifions pas la partie
applicative : nous n’indiquons que les communications possibles, sans pouvoir déterminer leur
fréquence ni la structure exacte des données échangées.
Grâce à la richesse de sa syntaxe et de sa sémantique, AADL peut être utilisé pour modéliser
les applications selon une approche beaucoup plus fine ; nous pouvons alors envisager de décrire
complètement les applications – et pas seulement leur déploiement sur les différents nœuds. L’utilisation
d’AADL pour décrire complètement les applications est décrite dans les sections suivantes.
IV-2 Vers un développement conjoint de l’application et de l’intergiciel
Dans la section précédente nous avons montré comment utiliser AADL pour décrire le déploiement
d’une application. Cela suppose l’utilisation d’un intergiciel configuré par ailleurs. Le
développement séparé de l’intergiciel implique que celui-ci est relativement indépendant de l’application
qu’il sous-tend. Dans ces hypothèses, l’adéquation de l’intergiciel avec l’application peut
être évaluée a posteriori, typiquement à l’aide de suites de tests. Cette approche pose deux problèmes
majeurs :
– le test d’un intergiciel est en général très difficile à réaliser, étant donné que ce genre de
logiciel présente beaucoup de cas d’utilisation ;
– le développement séparé de l’intergiciel implique une certaines décorrélation par rapport à
l’application, qui peut rendre difficile l’évaluation des caractéristiques de l’ensemble formé
par l’application et son intergiciel ; cela concerne par exemple l’évaluation des temps d’exécution
ou la taille totale en mémoire.
Une solution appropriée à ce problème serait de concevoir un intergiciel spécifiquement adapté
à l’application considérée. Cet intergiciel serait conçu en même temps que l’application, et constituerait
donc une sous-couche applicative à part entière. Une application extrême de ce principe
revient en fait à ne pas avoir d’intergiciel, en laissant au concepteur de l’application le soin de
gérer tous les mécanismes de communications ; cela engendrerait un coût de développement prohibitif.
Notre objectif est donc de maintenir l’existence de l’intergiciel en tant qu’assemblage d’éléments
logiciels réutilisables, tout en associant étroitement son élaboration au processus de création
de l’application. Une approche efficace pour la réalisation de l’intergiciel consiste donc à intégrer
la configuration de l’intergiciel dans le processus de conception de l’application.
58 c○ 2007 Thomas Vergnaud