Modélisation des systèmes temps-réel répartis embarqués pour la ...

Chapitre V – Génération du code pour l’enveloppe applicative
nommé partition.c, et les fichiers correspondant aux espaces de nom sont nommés partition
-.c. Étant donné que toutes les déclarations C se trouvent dans l’unique espace
de nom géré par le langage, nous appliquons une règle différente d’Ada pour le nommage des
entités issues des composants AADL : leur nom est le résultat de la concaténation du nom de leur
paquetage de définition et de leur nom à l’intérieur de ce paquetage.
V-4.1.2 Traduction des composants de donnée
Le langage C permet de manipuler les mêmes types de données qu’Ada. La traduction des
composants de donnée suit donc les mêmes principes. Les chaînes de caractères sont implantées
par des tableaux de caractères, de la dimension spécifiée en AADL, plus un octet pour stocker le
caractère de fin de chaîne 0.
Dans la mesure où C n’offre pas de mécanisme permettant de définir des sous-programmes génériques,
il est nécessaire de générer plus de code, s’appuyant sur une structure de liste manipulant
des pointeurs vers les structures de données à stocker.
V-4.1.3 Traduction des sous-programmes
Règle V.12 (Traduction des sous-programmes AADL en C)
Les sous-programmes AADL sont traduits en C par des fonctions dont le type de retour
est void.
Les accès aux composants de donnée sont traduits par un pointeur sur le type de donnée considéré
; de même, les accès aux sous-programmes sont traduits par des pointeurs sur procédure. Les
autres paramètres sont traduits selon les mêmes principes que pour Ada. Les paramètres AADL
déclarés « out » ou « in out » sont traduits par des pointeurs sur les types de données correspondants.
Les paramètres « in » sont traduits par un passage de paramètre classique.
V-4.2 Traduction vers Java
La traduction en Java reprend en partie les mêmes principes que pour Ada et C. Cependant,
du fait qu’il s’agisse d’un langage orienté objet implique quelques différences notables. AADL
ne développe en effet pas les concepts que l’on retrouve habituellement dans les langages objets
(telles que les classes, notamment). La traduction d’AADL vers Java conduit donc à générer du
code qui, dans sa logique, n’est pas orienté objet ; le code produit, bien que correct, ne correspond
donc pas nécessairement à ce qu’écrirait naturellement un programmeur.
V-4.2.1 Traduction des espaces de nom
Java possède la notion de paquetage ; la notion de paquetages d’AADL s’en inspire d’ailleurs
largement. Cependant, du fait que Java se fonde sur l’usage des classes alors que cette notion
n’existe pas dans AADL, il n’est pas possible de traduire simplement les paquetages AADL en
paquetages Java ; bien que de sémantique très proche, les paquetages Java et AADL ne contiennent
en effet pas les mêmes genres de déclarations. Notamment, il n’est pas possible de déclarer une
méthode Java directement dans un paquetage. Il est donc impératif de tenir compte à la fois des
notions de classe et de paquetage dans la traduction d’AADL vers Java, tout particulièrement pour
les sous-programmes.
c○ 2007 Thomas Vergnaud 91