8.7 Vérification formelle
9.1.5 Evaluation expérimentale de nos contributions
9.2 CONCLUSION. . . 148
9.3 LIMITES ET PERSPECTIVES. . . 148
9.3.1 Limites . . . 148
9.3.2 Perspectives . . . 149
Pour conclure cette étude, nous allons commencer par résumer l’ensemble des contribu- tions que nous venons de présenter. Nous prendrons alors un peu de recul pour évaluer la qualité et la complétude de notre travail. Enfin, nous discuterons les perspectives qu’offre le travail recherche que nous avons réalisé.
9.1
Rappel des contributions et résultats
Nous avons présenté dans ce mémoire trois contributions logicielles, qui s’articulent toutes autour d’une quatrième contribution : une méthode de conception.
9.1.1
Méthode de conception
Contribution centrale de notre étude, la méthode de conception que nous proposons dans ce mémoire permet d’améliorer l’efficacité des équipes de développement logiciel, en termes
de qualité et de productivité. En effet, cette méthodologie automatise l’analyse et la production des systèmes TR2E critiques et adaptatifs en proposant de :
– modéliser l’ensemble des mécanismes d’adaptation du système ;
– générer les modèles formels représentatifs de ces mécanismes d’adaptation ; – générer le code de mise en œuvre de ces mécanismes.
La mise en œuvre de cette spécification s’appuie sur des techniques de modélisation qui ont nécessité la proposition d’un nouveau langage de description d’architecture.
9.1.2
Langage de description d’architecture des systèmes TR
2E critiques et
adaptatifs
Notre méthodologie s’appuie sur un langage de description d’architecture (COAL) qui per- met de modéliser le comportement adaptatif d’un système. De plus, COAL permet de repré- senter conjointement l’architecture logicielle à base de composants génériques, ainsi que les propriétés spécifiques au domaine des systèmes TR2E.
COAL permet ainsi de capturer les caractéristiques non-fonctionnelles de l’application, et plus particulièrement les caractéristiques temporelles, tout en facilitant la décomposition fonc- tionnelle par le biais de composants logiciels génériques.
Avec ce langage, les différents comportements possibles du système sont représentés par le biais de modes de fonctionnement, encapsulés dans des automates de mode dont le com- portement est analysable. Nous avons montré au chapitre 7une technique de modélisation formelle grâce à laquelle nous vérifions que le comportement du système adaptatif respecte les propriétés de sûreté identifiées lors de sa spécification. De plus, COAL permet de spécifier l’ensemble des fonctionnalités actives dans un mode donné en associant une configuration logicielle à chacun de ces modes. Enfin, ce langage permet de paramétrer le compromis nécessaire entre les différents enjeux de la mise en œuvre de mécanismes d’adaptation : l’analysabilité, la rapidité, et la cohérence des flux de données.
Pour automatiser l’exploitation de cette spécification, nous avons créé un framework à composants, appelé MyCCM-HI, qui automatise la production et l’analyse des applications logicielles d’un système TR2E critique et adaptatif.
9.1.3
MyCCM-HI, framework à composants pour les systèmes TR2E critiques
et adaptatifs
Notre contribution autour du framework à composants MyCCM-HI se décompose en deux parties. Une partie dédiée à la production automatique du code de l’application, et une partie dédiée à la validation du comportement du système.
Production automatique de code
Une première partie, relativement mature, consiste en un générateur de code qui auto- matise la production de mécanismes d’adaptation “corrects par construction”. En effet, les mécanismes d’adaptation que nous utilisons garantissent que l’ensemble des tâches qui ont commencé leur exécution dans un mode donné finit leur exécution dans ce mode. En fonction de l’urgence de l’adaptation et de la nécessité de conserver des flux de données cohérents,
9.1. Rappel des contributions et résultats nous utilisons la politique de reconfiguration adéquate. Nous avons montré au chapitres 7
et 7que la sémantique de reconfiguration utilisée est analysable y compris concernant ses caractéristiques temporelles. De plus, le code généré par MyCCM-HI respecte les règles de réalisation des systèmes critiques que nous avons présenté au chapitre 3, ce qui facilite l’analyse des caractéristiques temporelles de l’application ainsi que l’analyse statique du code produit. Enfin, les résultats expérimentaux obtenus sur un cas d’étude industriel montre que le code obtenu est optimisé, alors que le facteur de génération est important : A partir de 836 lignes de spécification COAL, nous obtenons 20248 lignes de code C générées, pour une occupation mémoire à l’exécution inférieure à 860 Ko ; Le gain estimé en terme d’empreinte mémoire par rapport à MyCCM est d’un facteur 500 environ. Ce gain est en grande partie imputable à l’utilisation de l’intergiciel PolyORB-HI et du générateur de code associé, Ocarina.
Ce générateur de code est le fruit d’un travail collaboratif impliquant à la fois des ingénieurs Thales et des chercheurs de TelecomParisTech. Le fruit de ce travail, qui représente (en dehors du code d’Ocarina) plus de 130 000 lignes de code Java, a été suffisamment mature pour constituer une livraison “open source” d’une part, et la réalisation d’un démonstrateur lors d’un stage de Master d’autre part.
Vérification formelle du système et de ses applications
La seconde partie de notre contribution consiste en un ensemble de règles de transfor- mation qui permettent de générer automatiquement un modèle formel équivalent à la spé- cification système et/ou logicielle fournie. Ces modèles représentent à la fois la logique des changements de mode, ainsi que le comportement de l’ensemble de l’application en cours d’adaptation.
Nous avons formalisé ces règles de transformation au chapitre 7. Les expérimentations que nous avons réalisé autour du cas d’étude industriel nous ont permis de vérifier la validité de ces règles, et de vérifier le type de propriété de sûreté de fonctionnement spécifiées ci- dessous :
– un mode donné est accessible ;
– la spécification n’induit pas de blocage dans un mode donné ;
– deux modes fortement incohérents entre eux ne sont jamais simultanément actifs ; – le passage d’un mode à un autre n’excède pas un certain intervalle de temps ;
– deux modes faiblement incohérents ne sont pas simultanément actifs plus d’une certaine période de temps ;
– le système reconfigurable est ordonnançable.
Ces propriétés correspondent par ailleurs aux propriétés de sûreté que nous avions identifiés en précisant notre problématique, au chapitre3.
Une autre caractéristique importante des travaux que nous avons réalisé est l’intégration de langages de spécification standardisés. L’utilisation de standards garantit l’interopérabilité entre les outils qui s’appuient sur ces standards. De plus, cela permet de bénéficier des travaux existants autour de ces standards.
9.1.4
Intégration de langages standards de spécification
Un autre aspect important de notre contribution est l’intégration de langages standardisé : lightweight CCM pour la spécification des composants et de leurs interfaces, et AADL pour la description des caractéristiques de l’architecture propres aux systèmes TR2E.
Bien que l’intégration de AADL se limite aujourd’hui aux constructions de la première ver- sion du standard (AADL 1.0), l’effort que nous avons fait ici constitue une première étape d’intégration. Les construction définies dans la nouvelle version de ce standard (AADL 2.0) permettront sûrement d’étendre cette intégration aux mécanismes d’adaptation dynamique. L’utilisation d’AADL comme langage intermédiaire permet de bénéficier des travaux réalisés autour de ce langage de description d’architecture dédié à la spécification et à l’analyse des systèmes TR2E.
9.1.5
Evaluation expérimentale de nos contributions
Les résultats expérimentaux que nous avons obtenus illustrent le bien fondé de notre approche. Outre la génération de code optimisée, que nous avons déjà évoqué dans ce cha- pitre, les résultats que nous avons obtenus en évaluant le temps moyen de reconfiguration, ou encore en vérifiant formellement le comportement du système de notre cas d’étude industriel, confirment cette assertion.
9.2
Conclusion
L’approche que nous avons développé répond à l’ensemble des problématiques que nous avions identifiées au chapitre3. Bien sûr, cette solution mérite d’être améliorée ; nous détaille- rons ses limitations dans la section suivante. Cependant, les résultats expérimentaux que nous avons obtenus confirment son bien fondé car ils montrent qu’elle permet d’automatiser l’ensemble des étapes de production des systèmes TR2E critiques et adaptatifs.
En conclusion, notre contribution résout les questions de la configuration et de la recon- figuration des systèmes TR2E critiques et adaptatifs dans une approche “pragmatique”. Elle
automatise la production et l’analyse du comportement du logiciel en partant du principe que la spécification est intégralement fournie par un utilisateur final. Nous avons donc atteint notre objectif initial : améliorer l’efficacité des équipes de développement logiciel, en termes de qua- lité et de productivité. Le gain en productivité est assuré par le générateur de code, alors que le gain en qualité est à la fois assuré par le générateur de code et par l’automatisation de la vérification formelle de l’architecture système et logicielle.