Conclusion Les techniques d’adaptation de générateur manquent de méthodologie dans le cadre des SETRC, notamment concernant les transformations relationnelles et hybrides. Les transforma- tions impératives, décrites en langage de programmation, bénéficient cependant des techniques de l’orienté-objet pour être facilement adaptables. Finalement, assurer la portabilité d’un générateur de code présente des difficultés. D’une part, l’utilisation d’un intergiciel générique a un impact né- gatif sur les performances. De plus, l’écriture de composants génériques est une tâche complexe. D’autre part, les techniques d’adaptation du générateur ne sont pas clairement définies dans le cadre des SETRC.
3.3 Adaptabilité du code généré
La génération de code doit ainsi proposer des stratégies afin d’assurer que le code généré soit adapté aux propriétés du système. Cependant, la plate-forme d’exécution contraint la génération de code en imposant des choix d’implémentation. Cela impacte alors les performances du système sur des critères donnés sur lesquels on ne peut intervenir. Un exemple classique est le choix d’une plate-forme d’exécution d’allouer de la mémoire pour stocker des données pré-calculées ou bien de les calculer à l’exécution. Le temps d’exécution et l’empreinte mémoire vont alors être impactées en conséquence.
Le choix d’imposer une implémentation est aussi motivé par les besoins d’analyser le com- portement du système. En effet, l’étude du système requiert une connaissance globale de son com- portement. La génération de code pouvant compliquer l’analyse du système global, voire rendre inopérant les outils d’analyse précédemment utilisés, certaines fonctionnalités sont alors définies statiquement au sein de la plate-forme d’exécution alors qu’elles pourraient être générées et op- timisées. Dans le cas des SETRC, un exemple typique est la gestion des communications. Les communications asynchrones peuvent être implémenté de plusieurs façons, notamment sur la ges- tion des accès concurrents.
L’utilisation de verrou assure à la tâche courante un accès exclusif en bloquant les autres tâches. En terme de validation, il faut déterminer le temps de réponse des tâches en tenant compte de leur temps de blocage et aussi du délai due à la prise/relâche du verrou (hors blocage). Ces délais sont d’autant plus important lorsque le passage en mode privilégié implique des mécanismes coûteux de la plate-forme d’exécution : dans le cas d’une architecture ARINC653[29], le système doit garantir l’isolation temporelle et spatiale de chaque partition. Cela se traduit par des coûts supplémentaires. Dans le cas d’un ordonnancement RMS préemptif, le calcul du temps de réponse d’une tâche peut être formulé ainsi[54] :
ri= Ci+ Bi+ ∑j∈hp(i)⌈Prij⌉Cj
Dans cette formule, le temps de réponse riest dépendant du pire temps de blocage Bi. La valeur
de Bi est calculé en fonction du protocole d’accès à la ressource[18] et est souvent difficile à
estimer finement. On fixe alors cette valeur à une borne que l’on sait inaccessible. Cela garantit que si le temps de réponse calculé est en deça de l’échéance de la tâche, la tâche ne manquera aucune échéance. Au contraire, si le test échoue, cela signifie que la tâche manquera une échéance
dans un pire cas théorique, mais pas nécessairement dans le pire cas réel. Cet exemple montre que l’utilisation de verrou complexifie l’évaluation des performances réelles. Il existe cependant des méthodes pour réduire Bi, mais ce dernier n’est jamais nul. Il est donc toujours nécessaire de
fournir une borne supérieure.
Une implémentation non-bloquante est une alternative à l’utilisation de verrou. On distingue les techniques lock-free [8,45], qui consistent à tenter d’accéder à l’objet partagé jusqu’à ce qu’il devienne disponible, et les techniques wait-free [22, 47, 45] qui dupliquent les objets partagés. Ces techniques introduisent cependant des surcoûts non-négligeables, en temps d’exécution (tech- niques lock-free) ou en empreinte mémoire (techniques wait-free), les rendant souvent inappro- priées pour les SETRC. Cependant, ces solutions sont préférables si leur coût est inférieur à l’util- isation de verrou et que la sémantique des communications permet de s’en abstraire.
L’adaptabilité de l’implémentation est également une problématique dans le domaine de la pro- grammation orientée-aspects. Cette approche part du principe que l’entrelacement de code métier et de code technique nuit au développement et à l’évolution d’une application. Cette approche de programmation orientée composants consiste à séparer le code métier du composant de son code technique lié à l’environnement d’exécution par la définition d’aspects. Différents frame- works mettent en oeuvre ce type d’approche, notamment Fractal [16], Kilim [30] et JAC [81]. Ceux-ci reposent sur l’utilisation du langage Java pour la définition des composants et des aspects. Ils ne sont donc pas applicables dans un contexte non orienté-objet. De plus, ils ne semblent pas adresser les problématiques des SETRC que sont le déterminisme du code exécuté et le respect des contraintes temps-réel.
Conclusion La capacité à produire un code adapté aux contraintes du système est fortement limitée par les choix d’implémentation de la plate-forme d’exécution et des composants logiciels fournis. Cela est justifié par les difficultés d’analyser un système dont le comportement n’est pas défini statiquement et qui dépend du code généré. Ainsi, les fonctionnalités sont définies statique- ment et ne peuvent pas être optimisées en fonction du système modélisé. C’est notamment le cas pour la gestion des communications asynchrones dont l’implémentation est identique à chaque système déployé sur la plate-forme d’exécution. Pouvoir choisir entre l’utilisation de mécanismes d’exclusion mutuelle avec verrou ou sans verrou permettrait d’optimiser le coût induit par ces mé- canismes selon la configuration du système modélisé. Cela faciliterait l’analyse du système, en particulier l’analyse d’ordonnancement, mais nécessiterait un processus de génération favorisant la réutilisation des outils d’analyse pour tenir compte du coût des mécanismes choisis.