Ocarina est constitué d’un cœur sur lequel sont branchés différents modules. Ces modules se comportent comme des applications faisant appel aux services et à l’API du cœur. Il en existe trois types, dont l’agencement est décrit sur la figureVIII.1:
– modules d’entrée/sortie ; – modules de transformation ; – générateurs.
Les modules d’entrée/sortie permettent de parser des fichiers AADL ou d’afficher l’arbre du cœur selon une différentes syntaxes (textuelle, graphique, représentation XML. . .). Ocarina fournit actuellement un parseur/afficheur pour la syntaxe textuelle d’AADL ainsi qu’un module pour les fichiers de l’éditeur de diagramme Dia.
Les modules de transformation peuvent permettre l’expansion de l’arbre du cœur pour mettre en place des transformations d’architecture que nous avons décrites en sectionVI-3, page107.
Les générateurs permettent de produire différentes représentations – en l’occurrence du code source ou des réseaux de Petri – à partir de la représentation AADL. Nous avons développé un générateur appelé Gaia [Vergnaud et Zalila,2006] qui prend en charge les différentes générations que nous avons décrites dans les chapitresVetVII, et un autre générateur appelé PN permettant
cœur parseurs/afficheurs parseurs/afficheurs transformateur générateur application tierce
FIG. VIII.1 – Organisation des modules d’Ocarina
de produire des réseaux de Petri selon les règles que nous avons présentées au chapitreVII. Ocarina [Vergnaud et Zalila,2006] est une application autonome utilisable en ligne de com- mande permettant de produire du code exécutable, un réseau de Petri, de passer d’une représen- tation AADL à une autre ou simplement de vérifier la validité d’une description AADL. Tous les modules ainsi que le cœur d’Ocarina peuvent également être utilisés comme des bibliothèques lo- gicielles, intégrées dans une application tierce afin de permettre à des outils existants de manipuler une description AADL.
VIII-1.3.1 Organisation du cœur
Le cœur permet de manipuler les deux niveaux d’une description AADL : le modèle et l’ins- tance d’architecture. Il fournit un ensemble de fonctions pour manipuler l’arbre de modèle AADL pour le construire, le vérifier ou le consulter. D’autres fonctions permettent de manipuler l’arbre d’instance. De la même façon que pour le modèle, il est possible de construire, vérifier et consulter l’arbre d’instance. Cependant, l’arbre d’instance ne peut pas être construit directement : il est cal- culé à partir de l’arbre de modèle par instanciation des déclarations de composants. L’utilisation typique des fonctions du cœur est la suivante :
1. appel des fonctions de construction de l’arbre de modèle par les parseurs ou l’éventuelle application tierce ;
2. vérification de l’arbre de modèle ;
3. transformations éventuelles dans l’arbre de modèle ; 4. éventuelle instanciation de l’arbre de modèle ;
5. exploitation de l’arbre d’instance par un générateur ou une application tierce.
L’arbre de modèle permet de recueillir les informations décrites dans les différentes syntaxes AADL. La phase de vérification consiste à s’assurer que tous les composants référencés par les sous-composants et les éléments d’interface ont bien été déclarés, que les associations de proprié- tés sont cohérentes avec leur définitions, etc.
La racine de l’arborescence des instances de composants est le système racine décrit dans le modèle, c’est-à-dire une implantation de système dont le type n’a aucune interface.
Les composants de données associés aux éléments d’interface demeurent dans leur paquetage de déclaration dans la mesure où ils ne font pas partie de la hiérarchie d’instance. Les déclarations
de composants qui ne sont pas référencées par des sous-composants à partir du système racine ne sont pas instanciées.
VIII-1.3.2 Organisation des générateurs de code
Ocarina comprend deux modules de génération de code : l’un pour produire des systèmes exécutables, l’autre pour produire des réseaux de Petri. Ils mettent tous deux en place un arbre intermédiaire comprenant les informations pertinentes issues de l’arbre d’instance du cœur d’Oca- rina.
Gaia : le générateur d’applications
Le module Gaia rassemble toutes les fonctions de génération que nous avons exposées dans les chapitresVetVI. La figureVIII.2résume le processus de génération au sein de Gaia.
arbre d'instance du cœur arbre applicatif de Gaia code source de l'enveloppe interface pour l'intergiciel
FIG. VIII.2 – Processus de génération dans Ocarina/Gaia
Gaia est un générateur d’application1; l’instance d’architecture AADL est donc considérée essentiellement à travers ses composants logiciels (threads, sous-programmes et données) tandis que les les autres composants de l’architecture (processus, processeur, bus. . .) sont exploités pour la configuration de l’exécutif. Afin de faciliter l’exploitation de l’architecture pour la génération de code, Gaia est constitué de deux parties : le traducteur en code source et le générateur d’exécutif. L’organisation des deux parties de Gaia est structurée selon les processus de l’architecture, qui représentent les nœuds de l’application répartie.
La traduction en code source ne dépend que du langage cible, comme nous l’avons montré au chapitreV; un arbre est extrait de l’arbre de Gaia pour la traduction d’AADL en code source, reproduisant les structures que nous avons décrites pour les langages impératifs dans la sectionV- 2, page72. Les paquetages sont transformés en espaces de noms associés à chaque processus ; ces espaces de nom contiennent les déclarations de sous-programmes et de composants de donnée correspondant à des appels ou des éléments d’interface instanciés dans chaque processus. Un générateur syntaxique est ensuite appliqué à l’arbre du traducteur afin de produire le code source dans le langage de programmation choisi. La prise en charge d’un nouveau langage consiste donc à changer la dernière étape de la génération.
La génération de l’exécutif dépend à la fois du langage cible et de l’intergiciel utilisé. Il est donc a priori nécessaire de construire un générateur complet pour chaque intergiciel pris en charge ; dans le cas général, la génération de l’exécutif AADL correspondant à chaque processus est par conséquent effectuée à partir de l’arbre d’instance. Dans le cadre de nos travaux, nous avons construit un générateur qui produit une personnalité applicative pour PolyORB.
PN : le générateur de réseaux de Petri
La génération de réseaux de Petri2 se fait également à l’aide d’un arbre intermédiaire (fi- gure VIII.3) permettant d’avoir une représentation abstraite permettant de produire différentes syntaxes de représentation. Nous n’exploitons que les éléments logiciels, en ignorant cette fois complètement les informations de déploiement associées aux composants de plate-forme.
arbre d'instance du cœur arbre de réseau de Petri code petriscript
FIG. VIII.3 – Processus de génération dans Ocarina/PN
Les réseaux de Petri sont habituellement représentés sous forme graphique, peu adaptée à la génération de code. Afin de faciliter la génération des réseaux, nous nous reposons sur une syntaxe textuelle développée au laboratoire d’informatique de Paris 6, appelé PetriScript [Hamez et Re- nault,2005]. PetriScript est un langage de construction de réseaux de Petri associé à la plateforme de model checking CPN-AMI [Kordon et Paviot-Adet,1999] conçue au laboratoire d’informatique de Paris 6 ; il permet notamment d’automatiser les opérations de fusion entre places et transitions, ce qui facilite grandement les constructions que nous avons décrites dans le chapitreVII.