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
Règle V.8 (Signature des implantations comportementales)
La procédure fournie par l’utilisateur doit toujours avoir la signature suivante :
– un premier paramètre en entrée/sortie appelé data, de type _data, qui reçoit une structure de donnée contenant les éventuelles références des
procédures des séquences d’appel, ainsi que les variables locales et les variables issues
des connexions AADL ;
– les différents paramètres du sous-programme AADL.
Le type de données _data est généré par le traducteur pour chaque
sous-programme AADL encapsulant une description comportementale. Du fait que « data » est
un mot-clé AADL, nous pouvons l’utiliser en ayant l’assurance qu’il ne correspond pas à un nom
de paramètre utilisé dans la modélisation.
V-2.4 Gestion des entités distantes
Les évolutions de syntaxe que nous avons proposées au chapitre IV permettent la modélisation
de sous-programmes et d’objets répartis. Dans cette section nous traitons ces cas. Nous montrons
notamment que les aspects répartis de l’application relève exclusivement de la description AADL ;
ils n’ont aucun impact sur la définition des description comportementales.
V-2.4.1 Traduction des appels de sous-programmes distants
Dans la section précédente, nous avons traité le cas des sous-programmes locaux. Un appel
vers un accès à un sous-programme instancié dans le processus local ne pose aucune difficulté de
traduction. Un appel à un sous-programme distant est représenté en AADL par un appel à un accès
à sous-programme qui est instancié dans un autre processus.
Le passage de message, matérialisé par les ports AADL, permet une stricte séparation entre les
deux parties de l’application AADL, l’interface avec l’intergiciel contrôlant l’exécution de l’enveloppe
sans que celle-ci aie une quelconque visibilité sur l’exécutif. L’appel de sous-programme
implique en revanche un appel à l’interface avec l’intergiciel de la part de l’enveloppe applicative.
Un appel à un accès à un sous-programme instancié dans un autre processus doit donc donner
lieu à la génération d’un couple de souche et de squelette, de la même façon que pour les approches
RPC ou CORBA.
Le traducteur doit donc substituer au sous-programme instancié à distance un sous-programme
local, qui sera fourni par l’interface avec l’intergiciel. Ce sous-programme joue le rôle de souche ;
le squelette correspondant, généré au niveau du nœud distant, appellera le sous-programme effectivement
instancié.
Ce processus de génération de souche et de squelette est seulement paramétrée par des éléments
de la description AADL – les processus dans lesquels sont instanciés les sous-programmes.
Les descriptions comportementales n’ont aucune visibilité sur la localisation effective des sousprogrammes,
et ne sont donc pas affectées.
V-2.4.2 Traduction des objets répartis
Dans le cadre de ces travaux, nous ne considérons les objets répartis que sous la forme d’appel
à des sous-programmes fournis par des composants de donnée instanciés dans des processus
distants.
c○ 2007 Thomas Vergnaud 85