de chargement mise en œuvre par un chargeur de plugins prend en paramètre le nom de la descrip-tion ADL décrivant l’architecture d’un plugin. Elle instancie un composant de ce type et retourne
son interface serveur appeléeplugin4. Notons que le chargeur de plugins possède un cache afin
d’optimiser le temps de chargement des plugins lorsque ceux-ci ont déjà été chargés.
– Les sélecteurs de plugins prennent l’initiative de charger des plugins en utilisant un chargeur de plugins. Leur rôle est de rendre transparents au reste du système la présence de plugins. Les sélecteurs peuvent être considérés comme des intercepteurs implantant une interface fonctionnelle identique à celle qui aurait été implantée par le plugin s’il avait été présent. Dès lors que le plugin est chargé, le sélecteur lui transmet les appels interceptés. Par exemple, dans le cas d’un plugin responsable du chargement des contrôleurs, le sélecteur est un composant interceptant l’opération
loadet chargeant le plugin dès que cette méthode est invoquée. Par ailleurs, notons que nous
avons implanté deux sélecteurs génériques : le premier est responsable des plugins de la chaîne de chargement ; le second se charge des plugins de traitement de l’AST. Le comportement de ces sélecteurs peut être programmé par le biais d’attributs.
La figure 6.15 illustre l’utilisation du mécanisme de plugins dans le cadre du chargement dynamique de membranes de composants. Un composant sélecteur de membrane est inséré dans la partie traitement de l’AST comme étant un composant visiteur devant être invoqué pour chaque nœud de type composant. Le sélecteur est connecté à un chargeur de plugins (lié, dans ce cas à une usine de déploiement d’ADL standard). Initialement (instant t0), une implantation de membrane est déjà chargée. A l’instant t1, le
sélecteur de membraneest invoqué pour un composant dont la membrane est d’un type spécifique, appelé
loggingController. Le sélecteur procède au chargement du plugin fournissant le visiteur nécessaire
à la génération de cette membrane. Pour ce faire, le sélecteur transmet au chargeur de plugins l’ADL du visiteur à charger. A l’instant t2, le chargeur utilise l’usine de déploiement pour charger le visiteur demandé et retourne son interface serveurplugin. A l’instant t3, le sélecteur se lie à l’interface retournée
et invoque son opérationvisitpour accomplir l’opération qu’il avait interceptée.
L’utilisation de plugins présente plusieurs avantages. En premier lieu, dans la mesure où les plugins sont chargés de façon paresseuse, il est possible de concevoir une version "exo" de l’outil, uniquement constituée des sélecteurs, des chargeurs de plugins et de quelques composants de base. L’outil est ensuite enrichi au cours des opérations de traitement ultérieures. D’autre part, étant donné que la sélection des plugins est effectuée dynamiquement à l’aide de règles de sélection bien précises, il est possible de dé-terminer l’usage de plugins particuliers en les plaçant à dessein dans les paquetages où les sélecteurs par convention effectuent leurs recherches. Par ce biais très simple, l’extension de l’outil devient possible sans que le moindre fichier de description de l’outil de base ne soit modifié. Cela permet, entre autres, de développer des extensions dans des équipes de développements distinctes et de les utiliser complète-ment séparécomplète-ment. Enfin, le mécanisme de plugins que nous avons présenté est généraliste : différentes implantations de chargeurs et de sélecteurs sont permises. Ainsi, les plugins peuvent être utilisés à divers endroits de la chaîne d’outils.
6.6 Conclusion
Dans ce chapitre, nous avons présenté le canevas logiciel que nous avons conçu pour la construction d’outils de traitement d’ADL. Ce canevas définit principalement une architecture extensible à base de composants et des modèles de programmation adaptés aux divers types de traitements qui doivent être effectués par une chaîne d’outils de traitement d’ADL. Par ailleurs, il fournit des mécanismes de base qui peuvent être réutilisés pour la construction de divers types d’outils de traitement d’ADL. De plus, il est doté d’un mécanisme de plugin permettant aux tierces-parties d’intégrer des extensions de manière à adapter la chaîne de traitement à leurs besoins.
Module de traitement MembraneParDéfaut Cache Cache Sélécteur de membrane Visiteur par défaut Backend par défaut Chargeur de plugin Module de traitement Sélécteur de membrane Chargeur de plugin Module de traitement Sélécteur de membrane Chargeur de plugin Visiteur
loggeur Backendloggeur
load( MembraneLoggeur ) t1 t2 t3 t0 Temps Cache Visiteur loggeur Backend loggeur Usine ADL Usine ADL Usine ADL MembraneParDéfaut Visiteur par défaut Backend par défaut MembraneParDéfaut Visiteur par défaut Backend par défaut MembraneLoggeur Visiteur loggeur Backend loggeur
FIG. 6.15 – Flot d’exécution du chargement et de l’utilisation d’un plugin.
Les contributions principales de ce canevas par rapport aux outils existants sont sa capacité de fusion de descriptions d’architectures hétérogènes, sa capacité d’intégration de différents composants d’analyse effectuants des opérations de vérification et d’enrichissement d’architectures, et sa flexibilité en ce qui concerne l’intégration de divers modules de traitement. Ce dernier point est obtenu grâce à l’utilisation d’un canevas de tâches permettant une gestion hiérarchique des opérations à réaliser et grâce à une architecture à base de composants à grain fin permettant de mettre en œuvre des modules de traitements de façon modulaire. Nous pensons qu’une telle infrastructure présente un apport intéressant pour la construction d’outils de programmation spécifiques dans le cadre du processus de développement de logiciels à base de composants.
Chapitre 7
Construction d’un outil de traitement d’ADL pour la
généra-tion de code
Sommaire
7.1 Objectifs . . . 111 7.2 Architecture de l’outil de génération de code . . . 112 7.2.1 Architecture du module de chargement . . . 112 7.2.2 Spécialisation du canevas de tâches . . . 114 7.2.3 Architecture du module de traitement . . . 118 7.3 Génération d’adaptateurs de communication . . . 122 7.3.1 Insertion automatique d’adaptateurs de communication . . . 123
7.3.2 Génération du code d’implantation des adaptateurs de communication . . . 124
7.4 Conclusion . . . 126
Ce chapitre est consacré à la présentation d’un outil de traitement d’ADL dédié à la génération de code, conçu en utilisant le canevas logiciel présenté dans le chapitre précédent. Plus précisément, le compilateur ADL en question est une personnalisation des modules de chargement et de traitement
génériques du canevas dont le but est de générer une partie du code des composants FRACTAL. Une
particularité de cette personnalité est sont aspect multi-cibles, c’est à dire sa capacité à supporter la programmation des composants dans divers langages de programmation tels que le C, le C++ et le Java. Elle permet, par ailleurs, la compilation de l’ensemble du code généré et des codes sources écrits par les programmeurs.
7.1 Objectifs
Le rôle de la personnalité de génération de code est de fournir deux fonctions fondamentales : – L’assemblage d’un système à base de composants permet aux programmeurs de construire et
de configurer une application à partir des descriptions d’architectures qui lui sont liées, faisant référence à une ou plusieurs bibliothèques de composants. L’assemblage nécessite la génération de code glue qui permet d’assembler les composants. Dans la plupart des cas, l’opération d’as-semblage comprend aussi la compilation de l’ensemble des codes, générés et implantés, afin de compiler le résultat d’assemblage sous une forme binaire.
– La simplification de l’implantation des composants vise à fournir des guides de programmation offrant aux programmeurs un ensemble de macro-opérations (e.g. invocation d’interface cliente, accès aux attributs, etc). De tels guides de programmation s’appuient sur la génération effective de ces macro-opérations par le compilateur ADL selon l’architecture de chaque composant. Il
s’appuie, de même, sur la génération de portions de codes dépendant de l’architecture interne des composants comme des structures de données et des aspects de contrôles. Le support développé
pour le canevas THINKdécrit un exemple d’aide à l’implantation de composants écrit en C. Les
lecteurs intéressés trouveront une description détaillée de ce support dans l’annexe A.1.
À ces objectifs d’aide à la programmation et à l’assemblage d’architectures logicielles à base de composants, se rajoutent la nécessité de supporter les trois caractéristiques suivantes du modèle de
com-posants FRACTAL:
1. La possibilité d’intégrer différents langages d’entrée : il est nécessaire de permettre d’intégrer
différents langages de description d’architectures (e.g. FRACTALADL, THINKIDL), mais aussi
différents langages de programmation comme C, C++ et Java. Cela implique en particulier le support de différents guides de programmation.
2. La possibilité d’assurer différents types d’implantation de membranes : il est nécessaire de fournir un mécanisme d’extensions permettant aux tierces-parties d’étendre l’outil de génération de code afin d’y intégrer de nouveaux tisseurs de membranes.
3. La possibilité de produire différents types de résultats : il est nécessaire de savoir générer différents types de résultats : exécutable binaire monolithique, librairie destinée au chargement dynamique, image binaire de noyaux de système d’exploitation, etc. Le fait que différents lan-gages de programmation et différentes plates-formes d’exécution puissent être utilisées implique la nécessité d’être compatible avec différentes chaînes de compilation existantes (e.g. gcc, JDK, etc.). Par ailleurs, nous pouvons citer la nécessité de la génération des adaptateurs de communica-tion en fonccommunica-tion des descripcommunica-tion d’architecture, qui constitue un autre type de résultat intéressant pour les systèmes répartis et pour les logiciels hétérogènes écrits dans différents langages de pro-grammation (e.g. C, Java).
Afin de répondre aux besoins suscitées, l’outil de génération de code doit avoir une architecture mo-dulaire et extensible. Notons que l’extensibilité est également requise du fait du caractère expérimentale des projets de développement réalisés par les utilisateurs de ce compilateur ADL. En effet, le compilateur doit pouvoir être étendu pour répondre aux changements fréquents des besoins de ces projets.