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 pour la ...
Modélisation des systèmes temps-réel répartis embarqués pour la ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Chapitre V – Génération du code <strong>pour</strong> l’enveloppe applicative<br />
19 s : out parameter entier;<br />
20 end spC;<br />
21<br />
22 subprogram implementation spA.impl<br />
23 calls<br />
24 {appel1 : subprogram spB;<br />
25 appel2 : subprogram spC;};<br />
26 connections<br />
27 cnx1 : parameter appel1.s -> appel2.e;<br />
28 cnx2 : parameter appel2.s -> s;<br />
29 end spA.impl;<br />
Listing V.10 – Exemple de séquence d’appel pure<br />
Le sous-programme apparaît alors comme un moyen de connecter entre eux plusieurs autres<br />
sous-programmes. La séquence est accompagnée de <strong>la</strong> <strong>des</strong>cription <strong>des</strong> connexions entre les paramètres.<br />
Une telle modélisation permet de générer directement un code complet : les appels<br />
aux autres sous-programmes correspondent à <strong>des</strong> appels de procédures, et les connexions correspondent<br />
à <strong>des</strong> variables intermédiaires. Le code généré reflète alors strictement <strong>la</strong> <strong>des</strong>cription<br />
AADL.<br />
Règle V.6 (Traduction <strong>des</strong> séquences d’appels pures)<br />
Un sous-programme constitué seulement d’une séquence d’appel est traduit par une procédure<br />
ou une fonction effectuant les différents appels indiqués par <strong>la</strong> séquence.<br />
Là encore, le code est généré de façon systématique ; les erreurs de structure, telles que l’absence<br />
ou <strong>la</strong> mise en concurrence de certaines connexions, doivent être détectées par d’autres<br />
moyens.<br />
V-2.3.5 Imp<strong>la</strong>ntation hybride<br />
Les sections précédentes ont présenté <strong>des</strong> cas simples, dans lesquels un sous-programme<br />
AADL était soit un composant à l’imp<strong>la</strong>ntation opaque soit une séquence d’appels inconditionnelle.<br />
Ces situations extrêmes n’offrent pas beaucoup de souplesse : dans un cas général, un sousprogramme<br />
est susceptible d’appeler différents sous-programmes, en fonction <strong>des</strong> valeurs <strong>des</strong> paramètres<br />
qu’il reçoit.<br />
Une modélisation efficace de ce genre de situation doit faire apparaître une séparation c<strong>la</strong>ire<br />
entre les conditions d’appel (c’est-à-dire <strong>la</strong> manipu<strong>la</strong>tion algorithmique <strong>des</strong> données) et les sousprogrammes<br />
à appeler (c’est-à-dire l’enchaînement <strong>des</strong> appels et <strong>la</strong> <strong>des</strong>cription <strong>des</strong> connexions) ;<br />
il demeure ainsi facile de changer l’assemb<strong>la</strong>ge <strong>des</strong> composants tout en conservant l’algorithme<br />
inchangé.<br />
Coordination de plusieurs séquences d’appel<br />
Cette approche nécessite de pouvoir décrire plusieurs séquences d’appel possibles au sein du<br />
sous-programme, en adjoignant une <strong>des</strong>cription comportementale capable de contrôler l’exécution<br />
<strong>des</strong> séquences en fonction <strong>des</strong> paramètres du sous-programme.<br />
Le standard actuel d’AADL permet de décrire plusieurs séquences d’appel au sein d’un même<br />
sous-programme. Il précise que chaque séquence doit être associée à un mode de configuration<br />
particulier. Il s’agit donc de se ramener au cas d’une séquence d’appel pure que nous avons abordé<br />
c○ 2007 Thomas Vergnaud 79