Les SETRC requièrent des processus d’ingénierie qui assurent leur bon fonctionnement. La modélisation, la validation et la génération de code font partie intégrante de ces processus. Dans la problématique de la rupture d’analyse entre système modélisé et système généré (section 3.1), nous avons souligné que la génération de code pouvait remettre en cause les contraintes du SETRC. Les propriétés doivent donc rester analysables du modèle initial au code final. Dans cette optique, les transformations endogènes semblent être une bonne solution car favorisent la réutilisation des mêmes outils de validation sur le modèle initial et le modèle raffiné final proche du code généré. Cela assure ainsi une démarche de validation cohérente. Cette capacité à évaluer le coût de la génération de code détermine si cette dernière est adaptée aux contraintes du système. Dans le cas contraire, il faut s’orienter vers d’autres choix d’implémentation. Il faut alors intégrer des phases d’analyses au sein du processus afin d’évaluer la stratégie choisie et de la modifier si nécessaire. Les processus de génération ayant la capacité d’intégrer des phases décisionnelles nécessitent cependant un haut niveau d’expertise sur la formalisation des étapes d’analyse : les rendant diffi- cilement utilisables dans le contexte des SETRC qui nécessitent des outils d’analyse dédiés.
FIGURE4.1 – Processus de raffinement incrémental
Notre première contribution est alors la définition d’un processus de raffinement incrémental qui évalue le coût de sa stratégie de génération pour l’adapter si elle remet en cause les contraintes du système. Il s’appuie alors sur des transformations endogènes (raffinements de modèle) afin d’obtenir un modèle d’implémentation. Le raffinement donne la possibilité de valider le modèle d’implémentation avec les outils de l’utilisateur utilisés sur le modèle initial. Cela assure ainsi une démarche de validation cohérente.
Le processus dispose alors d’un ensemble de stratégies de raffinement pour chaque système. Les stratégies sont testées les unes après les autres jusqu’à obtenir un raffinement qui garantisse le respect des contraintes. Ce processus est illustré par la figure 4.1. Un ensemble d’exigences est fourni par l’utilisateur. Le processus de transformation doit alors proposer une architecture qui garantisse le respect de ces exigences. Le processus dispose alors d’une liste d’architectures candidates. La première architecture candidate est évaluée. Celle-ci détaille la mise en œuvre des abstractions du modèle utilisateur. Un plan de validation détermine ensuite si cette architecture
4.1. PROCESSUS DE RAFFINEMENT INCRÉMENTAL 43
garantit le respect des exigences. Le plan de validation peut avoir une portée globale au système ou locale à un composant. Un exemple d’analyse globale est l’analyse d’ordonnancement qui nécessite d’étudier le comportement de l’ensemble des tâches. Au contraire, une analyse de WCET va s’appliquer à une unique tâche pour évaluer son pire temps d’exécution. Si la validation échoue, l’architecture candidate suivante est évaluée. Dans le cas contraire, le modèle de l’architecture est raffiné afin d’obtenir un modèle plus détaillé. Ce dernier fait alors l’objet d’un nouveau plan de validation qui va tenir compte des nouvelles caractéristiques du modèle raffiné. Ce processus est répété jusqu’à obtenir un modèle valide et suffisamment proche d’une implémentation réelle : au sens où un raffinement supplémentaire n’introduirait plus de nouvelles ressources. Enfin, le modèle raffiné est traduit en code source (e.g. C, Ada) et peut être compilé.
Nous formalisons ce processus à l’aide d’une chaîne de raffinement qui décrit l’enchaînement des stratégies et des étapes d’analyses. Chaque stratégie de raffinement est implémentée à travers des étapes de transformation endogènes écrites dans un langage hybride comme ATL. L’utilisation d’un tel langage est motivé par le fait qu’il combine les approches relationnelles et impératives, et offre ainsi plus de flexibilité [24]. Avant la première transformation, une analyse globale est réal- isée sur le modèle d’entrée pour déterminer si la spécification respecte les contraintes du système, avant même de tenir compte du raffinement. Cette première analyse est nécessaire pour déterminer si une future analyse échoue à cause du surcoût induit par un raffinement ou si cela est dû au mod- èle initial, et dans ce cas, aucun raffinement n’est possible. Ensuite, chaque transformation produit un modèle raffiné qu’il est possible d’analyser. Dans ce cas, à la transformation peut succéder une ou plusieurs analyses réalisées par les mêmes outils que ceux utilisés sur le modèle d’entrée. Pour évaluer l’écart entre le modèle précédent et le modèle raffiné, on réévalue le WCET de chaque tâche du modèle raffiné pour prendre en compte le coût des composants intergiciel introduits dans leur spécification. Les annotations du modèle sont mises à jour, notamment la propriété WCET. On peut alors réaliser de nouveau les analyses précédentes qui vont pouvoir prendre en compte ces coûts supplémentaires et ainsi déterminer si l’implémentation choisie assure le respect des con- traintes du système. Dans le cas contraire, un raffinement alternatif doit être choisi. Pour se faire, le modèle raffiné actuel n’est pas conservé et la transformation alternative s’effectue alors sur un modèle antérieur. Les alternatives sont testées les unes après les autres dans un ordre prédéfini : le coût d’une alternative n’étant connu qu’une fois appliquée. Ce processus s’assure donc qu’une fois le code généré, l’écart de performances avec le modèle initial ne remet pas en cause la validité du système.
La spécification des exigences et des plans de validation d’un tel processus peut être formal- isée à l’aide d’un langage de spécification tel que RDAL[15]. Notre contribution se focalise sur les phases de raffinement d’architecture. La spécification du processus de raffinement de l’archi- tecture peut être formalisée en langage XML comme illustré par le listing 4.1. Un identifiant est donné au modèle initial en spécifiant l’attribut IN de la balise process (ici l’identifiant donné est inputModel). Une analyse initiale identifiée par l’attribut startAnalysisID est effectuée sur le modèle d’entrée et stoppe le processus si celle-ci échoue. Sinon, le processus teste une première transformation endogène strategie1 dont l’implémentation est fournie par les fichiers listés dans l’attribut modules. Le modèle d’entrée à transformer est identifié par l’attribut IN tandis que l’at- tribut OUT affecte un identifiant (re f ined1) au modèle raffiné. Le coût du raffinement est ensuite évalué par une analysis WCET réalisé sur le modèle raffiné re f ined1. Cette analyse réévalue et met à jour les propriétés temporelles du modèle. Ensuite, le modèle raffiné est analysé de nouveau. Si l’analyse réussie, alors le surcoût du raffinement ne remet pas en cause les contraintes du sys-
tème et le code exécutable peut alors être généré (balise yes). Dans le cas contraire, une seconde transformation est testée sur le modèle initial. De la même façon, les mêmes analyses sont réal- isées pour déterminer l’impact de la seconde stratégie de raffinement. Le code exécutable est alors généré si l’analyse réussie. Le formalisme XML est donc tout à fait adapté à la mise en œuvre des phases de raffinement d’architecture du processus décrit précédemment par la figure 4.1.
1 < p r o c e s s IN=" i n p u t M o d e l " s t a r t A n a l y s i s I D =" ResponseTime " >
2 < t r a n s ID=" s t r a t e g i e 1 " modules = " . . . " IN=" i n p u t M o d e l " OUT=" r e f i n e d 1 " > 3 < a n a l y s i s ID="WCET" IN=" r e f i n e d 1 "/ >
4 < a n a l y s i s ID=" ResponseTime " IN=" r e f i n e d 1 " > 5 <yes >< g e n e r a t i o n IN=" r e f i n e d 1 " / > < / yes > 6 <no>
7 < t r a n s ID=" s t r a t e g i e 2 " IN=" i n p u t M o d e l " OUT=" r e f i n e d 2 " modules = " . . . " > 8 < a n a l y s i s ID="WCET" IN=" r e f i n e d 2 "/ >
9 < a n a l y s i s ID=" ResponseTime " IN=" r e f i n e d 2 " > 10 <yes >< g e n e r a t i o n IN=" r e f i n e d 2 " / > < / yes > 11 <no > . . . < / no>
12 </ t r a n s > 13 . . .
Listing 4.1 – Exemple de formalisation en XML d’un processus de raffinement incrémental
Le respect des contraintes du SETRC peut ainsi être assuré par ce type de processus, en four- nissant des stratégies alternatives automatiquement évaluées. La prise en compte de l’impact de la génération de code sur les performances du système n’est alors pas dépendante du niveau d’- expertise de l’utilisateur. Cependant, le développement de multiples alternatives est relativement coûteux et rend difficile la maintenance d’un tel processus. Nous abordons ce second point dans la section suivante.