Afin d’avoir une expérimentation complète, nous avons généré le réseau de Petri correspondant à l’application de test décrite en sectionVIII-2.1. Le réseau produit 11 états, ce qui permet une analyse extrêmement rapide.
À titre d’expérience, nous avons considéré une configuration d’architecture alternative (lis- tingVIII.10) dans laquelle nous avons supprimé le processus initiateur.
95 system implementation Client_Serveur.i2
96 subcomponents
97 noeud1 : process Processus_Applicatif.i {Arao::Port_Number => 10002;};
98 noeud2 : process Processus_Applicatif.i {Arao::Port_Number => 10003;};
100 connections
101 event data port noeud1.s -> noeud2.e;
102 event data port noeud2.s -> noeud1.e;
103 properties
104 Actual_Processor_Binding => reference processeur applies to noeud1;
105 Actual_Processor_Binding => reference processeur applies to noeud2;
106 end Client_Serveur.i2;
Listing VIII.10 – Configuration alternative de l’application de test
L’analyse du réseau de Petri correspondant fait immédiatement apparaître que le marquage initial est bloqué, traduisant le fait qu’en l’absence du processus initiateur, les deux processus de l’architecture ne se déclenchent pas.
VIII-4 Conclusion
Ce chapitre a été consacré à l’évaluation de notre approche de génération.
Au cours de nos travaux nous avons développé une application, Ocarina, qui implante les différentes transformations que nous avons décrites aux chapitresV,VIetVII. Ocarina constitue donc un compilateur pour AADL.
Pour mesurer les performances d’exécution, nous avons comparé une application AADL simple et différentes contreparties basées sur CORBA. Pour pouvoir établir facilement une comparaison, nous avons dû nous placer dans un contexte correspondant à une utilisation classique de CORBA. Cette situation se révèle en l’occurrence défavorable à l’utilisation d’AADL ; notre application AADL est donc légèrement moins efficace. Nos mesures doivent donc être considérées comme une évaluation d’un pire cas.
Une architecture « naturelle » pour AADL, mise en place avec CORBA ou tout autre implan- tation d’intergiciel impliquerait le développement d’une couche logicielle pour synchroniser l’ar- rivée des données des ports, semblable à celle que nous avons présentée en sectionVI.1, page102, et qui constitue la personnalité AADL pour PolyORB. Le développement d’une telle application pour PolyORB/CORBA serait donc nécessairement plus coûteuse qu’une solution basée sur la personnalité AADL, puisqu’elle ajouterait les traitements de la personnalité CORBA à la couche de synchronisation.
La génération de réseau de Petri permet de mettre en évidence certaines propriétés structurelles comme le blocage des architectures. Le nombre d’état des réseaux produits dépend à la fois du nombre de threads AADL et de leur inter-connexions ; il est assez difficile de prévoir le nombre d’états.
L’étude d’une architecture de grande taille nécessite a priori un travail de préparation afin de réduire la modélisation AADL, tout en conservant la sémantique d’exécution. Certaines opérations de réduction peuvent effectuées de façon systématique ; d’autres s’appuient sur des caractéristiques remarquables de l’architecture considérée.
Nous avons étudié ici un système dans lequel les threads étaient fortement couplés, ce qui a permis de simplifier considérablement l’architecture. Nous n’avons cependant pas eu à prendre en compte les séquences d’appels de l’implantation des threads, qui auraient généré beaucoup d’états. Dans une situation moins favorable, il peut être nécessaire de ne considérer que des sous-parties de l’architecture.
Conclusions et perspectives
Pour le savant, croire la science achevée est toujours une illusion aussi complète que le serait pour l’historien de croire l’histoire terminée.
LouisDEBROGLIE, in Physique et microphysique
La mise en place d’un système réparti repose en général sur la construction d’une couche applicative particulière – l’intergiciel – pour prendre en charge les communications inter-nœuds. L’intergiciel doit pouvoir fournir tous les mécanismes de communication requis par l’application. Nos travaux se sont particulièrement intéressés aux applications pour les systèmes temps- réel répartis embarqués (TR2E), qui doivent respecter un certain nombre de contraintes (temps
d’exécution, taille mémoire, ressources disponibles, etc.). Ces contraintes doivent être respectées par tous les composants applicatifs, et en particulier par l’intergiciel.
Les implantations classiques d’intergiciel ne permettent pas la prise en compte complète de telles contraintes. Certains travaux visent à permettre l’intégration de ces considérations dans le processus de conception de l’intergiciel ; cependant, il s’agit en général d’un processus de confi- guration externe qui ne permet pas la prise en compte automatique des caractéristiques de l’appli- cation.
À ces problématiques de configuration s’ajoute le besoin de fiabilité. Il est impératif de pouvoir s’assurer du fonctionnement correct de l’application et de l’intergiciel qui lui est associé. L’étude du comportement des éléments applicatifs sont en général l’objet d’une série de tests, qui bien qu’utiles sont par nature incomplets.
IX-1 Conception conjointe de l’application et l’intergiciel
Afin d’exploiter de façon efficace les caractéristiques d’une application pour la mise en place d’un intergiciel adapté, il est nécessaire de recourir un formalisme permettant d’en décrire tous les aspects.
Nous avons établi que les langages de description d’architecture (ADL) proposent une ap- proche synthétique pour rassembler tous les éléments nécessaires à une description complète des systèmes. Leur utilisation permet notamment de pouvoir exploiter la description de l’application selon différents aspects – documentation, analyse, génération automatique, etc.
Dans le cadre de nos travaux, nous avons choisi d’utiliser AADL comme langage de modéli- sation. Ce language se distingue par une approche très concrète, centrée sur une identification pré- cise des composants de l’architecture. Il permet ainsi de modéliser à la fois l’application (threads, sous-programmes) et son environnement d’exécution (processeurs, bus).