MyCCM-HI est un générateur de code qui interprète une spécification d’architecture logi- cielle (aujourd’hui au format COAL) pour produire l’ensemble des exécutables d’une applica- tion TR2E critique pseudo-dynamiquement reconfigurable. Il s’agit donc d’un compilateur dont
le format d’entrée est une spécification COAL, et le format de sortie est un ensemble de fi- chiers source (code C) qui seront eux même compilés pour produire les exécutables binaires. Comme tout compilateur, MyCCM-HI se décompose en trois parties (frontale, centrale, et dor- sale) que nous allons décrire dans les sous-sections qui suivent. La figure6.1illustre, à travers ces trois parties, l’ensemble des étapes nécessaires à la génération de code. Sur cette figure, sont également représentées les étapes qui s’appuient sur les méthodes de génie logiciel que nous avons présentées à la section précédente (voir légende, en haut à droite de la figure).
Le modèle AADL produit (représenté en bas à droite de la figure) est ensuite utilisé par Ocarina pour produire le code d’activation et de communication des applications. Ce code s’appuie alors sur l’intergiciel schizophrène PolyORB-HI (C).
6.3.1
Partie frontale
Pour des raisons de simplicité de mise en œuvre et d’adaptation, nous avons choisi de nous appuyer sur une représentation textuelle des architectures à base de composants. Nous avons donc conçu un analyseur syntaxique et un méta-modèle qui permettent d’obtenir, à partir d’une spécification COAL donnée, l’arbre syntaxique abstrait (AST4) correspondant. Afin de réaliser cette partie frontale de notre outil de génération de code, nous nous sommes appuyés sur un générateur d’analyseur syntaxique et sur une technique de métamodélisa- tion : nous avons utilisé ANTLR pour réaliser l’analyseur syntaxique, et EMF pour modéliser et générer le code correspondant à l’arbre syntaxique abstrait de ce langage d’entrée (voir figure6.1, du fichier COAL à l’AST).
ANTLR (ANother Tool for Language Recognition) est un outil de génération de code dédié à la réalisation d’interpréteurs de langages : à partir d’une description de la grammaire du langage et d’un ensemble d’actions associées, ANTLR génère le code de reconnaissance du langage et exécute les actions associées dès que la règle de grammaire est rencontrée. Il permet également de représenter l’AST d’un exemple de test, de représenter graphiquement les règles grammaticales du langage, ou encore de détecter les ambiguïtés de la spécification.
6.3. Structure générale du compilateur
Partie
Partie
Frontale
Fichier COAL Analyse syntaxique Analyse sémantique Modèle d’instance Modèle d’instance Instanciation AST AST Méta-modèle Code généré LégendePartie
Dorsale
Partie
Centrale
AST automates de modes (C) Modèle de déploiement Aplanissement Fichiers C AST instances de composants (C) AST instances d’interfaces (C) AST modèle AADL (AADL) Fichiers C Fichiers C Fichiers AADLGénération Génération Génération Génération
FIGURE6.1 – Processus de conception d’un système TR2E reconfigurable
EMF (Eclipse Modeling Framework) est un outil de modélisation et de génération de code qui permet (i) de modéliser graphiquement un méta-modèle sous la forme d’un diagramme de classe, (ii) de générer le code des interfaces Java correspondant à ce diagramme de classes, et (iii) de générer le code d’un “plugin eclipse” correspondant à un éditeur arborescent d’ins- tances de ce méta-modèle. Cet outil a été utilisé dans le cadre de la réalisation de MyCCM-HI afin de modéliser l’AST du langage COAL, ainsi que pour modéliser les modèles intermé- diaires qui permettent d’aboutir à la génération de code (voir sur la figure6.1les éléments qui correspondent à la légende).
Comme le montre la figure6.1, MyCCM-HI effectue dans la partie frontale certaines vérifi- cations sémantiques sur l’instance de modèle obtenu. MyCCM-HI vérifie par exemple que :
– tout puit d’événement doit être associé par une activité sporadique, qui traitera les évè- nements arrivant sur ce puit ;
– toute instance de composant primitif est bien associée à un processus d’exécution ; – toutes les activités sporadiques et périodiques définissent une période strictement posi-
tive et une priorité positive ;
– toutes les implémentations de composants primitifs doivent être instanciées au moins une fois ;
– tout port “client” (réceptacle ou source d’évènements) d’une instance de composant primitif doit être connecté à un port “serveur” (facette ou puits d’évènement) d’un com- posant primitif.
– aucune communication synchrone (via une connexion facette/réceptacle) ne doit être effectuée entre deux processus d’exécution différents ;
– la priorité plafond associée à une instance d’automate doit être supérieure à la plus haute priorité des tâches impactées par cette instance d’automate ;
– etc...
Une fois que MyCCM-HI s’est assuré que les règles syntaxiques et sémantiques du lan- gage COAL sont bien respectées, la partie centrale du traitement (phases de transformations de modèle) peut commencer.
6.3.2
Partie centrale
La partie centrale du générateur de code consiste en une série de transformations de modèle qui produisent une représentation simplifiée de l’architecture logicielle. Comme nous l’avons expliqué au chapitre6, COAL est un langage de description d’architecture “hiérarchi- que” dans la mesure où un composant peut être un composite, c’est-à-dire contenir d’autres composants (composites et/ou primitifs). Une première étape de transformation de modèle (voir figure6.1) vise donc à obtenir une représentation “aplatie” de l’architecture. Dans la suite de ce chapitre, nous appellerons “modèle de déploiement” la structure de donnée associée à cette représentation aplatie.
Pour obtenir le modèle de déploiement équivalent à une spécification COAL donnée, une première étape consiste à construire un modèle d’instance de l’architecture. Il s’agit alors d’en- richir le modèle obtenu en sortie de la partie frontale afin d’obtenir une représentation qui ne contient plus que des instances de composants (primitif et composites) et des implémentation de composants primitifs.
Construction du modèle d’instances Lorsque l’architecte logiciel décrit une implémenta- tion de composant, celle-ci peut être constituée de plusieurs sous-composants (voir exemple de spécification COAL 5.9). Chaque instance de ce composite contient alors les “sous- instances” correspondant à ces sous-composants. Les figures6.2et6.3illustrent ce propos : sur la figure6.2, l’implémentation de composant cpt_impl contient deux instances de compo- sants. Supposons alors, comme l’illustre la figure6.2, que cette implémentation de composant soit instanciée deux fois (cpt_inst1 et cpt_inst2). Dans ce cas, les instances de composants contenus dans cpt_impl doivent chacune être instanciées deux fois. D’où le résultat de la transformation, décrit sur la figure6.3.
cpt_impl
cpt_inst1 cpt_inst2
instantiates
cpt_inst1 cpt_inst2
FIGURE 6.2 – Exemple de modèle issu de la
partie frontale cpt_inst1 cpt_inst2 cpt_impl cpt_inst1 cpt_inst2 instantiates cpt_inst1 cpt_inst11 cpt_inst12 cpt_inst2 cpt_inst21 cpt_inst22
6.3. Structure générale du compilateur La construction du modèle d’instance nécessite non seulement de recopier les instances de composants qui sont créées plusieurs fois du fait de l’instanciation multiple d’un composant composite, mais également de recopier leurs paramètres de configuration (connections, initia- lisation d’attributs, déploiement sur un processus donné, etc...). Les figures6.2et6.3illustrent ce propos à travers la connexion entre les composants cpt_inst11 et cpt_inst12 d’une part, et cpt_inst21 et cpt_inst22 d’autre part.
Construction du modèle de déploiement Une fois le modèle d’instance obtenu, il s’agit de transformer ce modèle en un modèle “aplati”, c’est-à-dire ne contenant que des instances de composants primitifs. Il s’agit alors de contracter l’ensemble des connections entre composites et/ou primitifs à un ensemble de connections entre instances de composants primitifs. Ainsi, pour chaque composant primitif du modèle d’instance, on récupère les primitifs auxquels il est connecté et on recopie ses paramètres de configuration dans une structure de donnée non hiérarchique représentative du modèle de déploiement. Le but de cette étape est d’obtenir une représentation simplifiée de l’architecture, donc plus facile à parcourir pour créer les modèles correspondant aux AST des langages cibles.
Intergiciel schizophrène et construction du modèle AADL Comme nous l’avons expliqué à la section précédente, nous avons fait le choix d’utiliser un intergiciel schizophrène. En outre, nous avons voulu que cet intergiciel soit dédié aux systèmes TR2E critiques. Nous avons
donc choisi l’intergiciel PolyORB-HI (en langage C), ainsi que le générateur de code associé (Ocarina) qui s’appuie sur le langage de description d’architecture AADL. Nous avons donc conçu un générateur de code qui, à partir d’une spécification COAL, produit un modèle AADL équivalent (voir figure6.1en bas à droite).
La construction du modèle AADL est une étape importante du processus de génération de code puisqu’elle permet de bénéficier des travaux et outils réalisés autour de ce langage. Dans un premier temps, nous limitons l’utilisation de ce langage au périmètre des composants AADL suivants : processus (process), tâches (thread ), canaux de communication (event data ports, connections, et associations aux bus), processeurs (processor ), et bus (bus).
L’algorithme de création du modèle AADL s’appuie sur deux hypothèses :
– toute opération de composant est susceptible de solliciter chacun des ports de sortie de ce composant (réceptacles ou source d’évènement) ;
– les communication de types “facettes-receptacles” sont systématiquement réalisées dans la tâche qui exécute le code du composant “client”.
L’algorithme de création du modèle AADL consiste alors en un parcours d’arbre dont les élé- ments sont des composants logiciels (de type CCM) et dont la racine est le point d’entré une activité COAL. A partir de ce composant racine, on crée un processus AADL correspondant au processus sur lequel est instancié le composant, puis une tâche AADL (thread ) équivalente à l’activité (c’est à dire périodique si l’activité est périodique, ou sporadique si l’activité est sporadique). Cette tâche AADL est alors un sous-composant (au sens AADL) du processus que nous venons de créer. On parcourt ensuite l’ensemble des connections du composant racine. Pour une connexion du type source/puit(s) d’évènements, on ajoute un port de sor- tie/d’entrée (event data port) à la tâche AADL correspondante, et au processus AADL si le destinataire du message n’est pas co-localisé avec l’émetteur. Pour une connexion de type réceptacle→facette, le composant courant devient le composant connecté au réceptacle, et on étudie ses connections.
Ce premier traitement permet de définir l’ensemble des tâches et processus AADL ainsi que leurs ports de communication (entrées/sorties). Une table de correspondance associe un ensemble port AADL à une source ou un puits d’évènements CCM. Il suffit alors de parcourir les connections définies dans le modèle de déploiement pour définir les connections corres- pondantes dans le modèle AADL.
6.3.3
Partie dorsale
La partie dorsale de MyCCM-HI a pour objectif de générer le code correspondant à l’archi- tecture logicielle spécifié par l’architecte logiciel. Ceci comprend :
– l’instanciation et l’initialisation des composant ;
– la définition du CIF5 (Component Implementation Framework) [(OMG), 2003] ; – les connections entre les composants ;
– le code d’activation des composant ; – l’implémentation des automates de mode ;
– le code de synchronisation entre tâches impactées par la reconfiguration et tâches confi- gurant les automates de mode ;
– le code permettant de réaliser les actions de reconfiguration (mise à jour de valeurs d’attributs, modification de connections) ;
Patron de génération Afin de faciliter l’implantation de l’ensemble du générateur de code, nous l’avons divisé en différentes étapes de génération dont le patron de génération est tou- jours le même. Il consiste en une phase d’expansion, et une phase de génération.
La phase d’expansion consiste en une transformation de modèle. Le modèle d’entrée est le modèle de déploiement. Le modèle de sortie est un modèle représentatif de l’ensemble des données nécessaires à la génération de code (AST du langage cible sur la figure 6.1). Par exemple, pour la génération du modèle AADL, le modèle d’entrée est le modèle de dé- ploiement, qui sera transformé pendant la phase d’expansion en un modèle AADL équivalent utilisé par Ocarina pour la génération de code C. Dans ce cas, la phase d’expansion consiste à définir le modèle AADL en suivant les principes décrits précédemment.
La phase de génération utilise l’outil “StringTemplate”, un langage constitué de balises qui constituent le degré de variabilité de la génération : ces balises seront remplacées pendant la génération de code par les chaînes de caractères contenues dans le modèle résultant de la phase d’expansion.
Dans ce chapitre, nous avons jusque-là présenté la structure générale de MyCCM-HI. Nous allons maintenant illustrer son fonctionnement à travers la production du code dédié à la mise en œuvre de la reconfiguration dynamique.
5. le CIF d’un composant correspond à l’ensemble des opérations que le développeur de composant doit im- planter pour que son composant puisse être déployé, configuré, et connecté aux autres composant. Cette spécifica- tion contient également les opérations correspondant aux ports du composant, y compris celle que le développeur de composant peut utilise pour envoyer un message via une source d’évènement ou appeler un autre composant via un réceptacle.