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

Modélisation des systèmes temps-réel répartis embarqués
Dans la mesure où la signature du code de l’algorithme n’est pas censée dépendre des informations
d’état du sous-programme AADL, ces informations doivent regroupées dans une structure
de données propre au sous-programme AADL. À chaque sous-programme hybride est donc associé
une structure de donnée permettant d’accéder à toutes les déclarations issues de la description
AADL. De cette façon, l’ajout de nouvelles déclarations n’a pas d’influence sur l’algorithme ; de
même le retrait de déclarations qui ne sont pas manipulées par l’algorithme n’a aucun impact. Les
procédures des séquences prennent également cette donnée en paramètre, afin de pouvoir mettre à
jour les différentes variables intermédiaires correspondant aux connexions.
Pour les sous-programmes hybrides, le traducteur AADL doit donc générer une structure de
contrôle que l’implantation comportementale peut manipuler. L’association du code source est
spécifiée de la même façon que pour une implantation opaque.
V-2.3.6 Sous-programme fourni par un composant de donnée
Un sous-programme fourni par un composant de donnée correspond à la modélisation d’un
objet, bien qu’AADL ne possède pas la notion d’objet en tant que telle – l’extension de composant
ne correspond pas exactement à la notion d’héritage, comme nous l’avons expliqué au chapitre III.
La traduction de tels sous-programmes est effectuée en suivant les même mécanismes que ceux
utilisés classiquement dans la compilation des langages orientés objets tels que C++ ou Ada 95 : la
donnée fournissant le sous-programme est passées par référence en premier paramètre de la procédure
correspondante. Elle est donc intégrée à la structure de donnée que nous avons décrite dans
la section précédente. Elle peut donc être manipulée par l’éventuelle description comportementale
fourni par l’utilisateur.
Par convention, le champ correspondant au composant de donnée est appelé « data » ; ce nom
est en effet un mot-clé d’AADL, et nous avons donc la garantie qu’il ne sera pas déjà employé
pour un nom de connexion ou de séquence.
V-2.3.7 Synthèse sur la traduction des sous-programmes
Les trois premiers types de sous-programmes que nous avons étudiées sont en fait des cas particuliers
de sous-programmes hybrides. Dans le cas général hybride, un sous-programme AADL
contient des séquences d’appel et des sous-composants de données ; tous ces éléments sont coordonnés
par le code source de la description comportementale associée au sous-programme.
Les sous-programmes sans implantation correspondent à une absence de séquences, de souscomposants
de donnée et de code source associé ; les sous-programmes opaques correspondent
à une absence de séquences et de sous-composants de donnée ; les séquences d’appel pures correspondent
à une absence de code source associé et de sous-composant de donnée, avec pour
restriction la présence d’une unique séquence d’appel. Les sous-programmes sans implantation
correspondent à une absence de séquences, de composants de donnée et de code source associé ;
les sous-programmes opaques correspondent à une absence de séquences et de sous-composants
de donnée ; les séquences d’appel pures correspondent à une absence de code source associé et de
sous-composant de donnée, avec pour restriction la présence d’une unique séquence d’appel.
Lorsque les propriétés Source_Language, Source_Name et Source_Text sont renseignées, le
code source issu de la description AADL doit appeler la description comportementale fournie par
l’utilisateur. Le sous-programme AADL est alors opaque ou hybride. Nous définissons une règle
systématique pour la signature de l’implantation comportementale.
84 c○ 2007 Thomas Vergnaud