Définir un générateur de code proposant plusieurs stratégies (section 4.1) dont le coût de cha- cune est évalué répond ainsi à la problématique de la rupture d’analyse entre système modélisé et système généré. Le développement de stratégies de génération indépendantes est néanmoins relativement coûteux, notamment en terme de maintenance. On s’intéresse alors à répondre à la problématique de l’adaptabilité du processus de génération (section 3.2) afin de faciliter la mise en place d’un tel processus. Notre deuxième contribution est alors la définition d’une démarche pour réutiliser une transformation existante afin de la dériver en une nouvelle transformation, adap- tée aux nouveaux besoins. Pour réaliser cette adaptation, nous ajoutons à la transformation des couches supplémentaires qui la redéfinissent partiellement. La nouvelle transformation est donc obtenue par assemblage de la transformation existante et des couches ajoutées. Pour cela, nous nous appuyons sur un mécanisme existant de composition qui sera abordé en section 5.1.3. Nous proposons alors des patrons de transformation pour faciliter l’adaptation de règles de transforma- tion.
La mise en œuvre de ces patrons nécessite de réécrire une règle existante afin de l’adapter selon les besoins. Les parties de la règle que l’on souhaite adapter sont déléguées à des fonctions annexes. De cette manière, l’adaptation de la règle ne requiert qu’une modification des fonctions
4.2. ADAPTATION DE TRANSFORMATION 45
annexes et conserve la définition globale de celle-ci. Pour réaliser l’adaptation, on ajoute à la trans- formation une surcouche (i.e. une seconde transformation) qui redéfinit ces fonctions annexes. La transformation dérivée est alors obtenue en assemblant et en compilant ensemble la transformation initiale et les couches ajoutées. Ainsi, selon les objectifs, on sélectionne les couches à ajouter à la transformation. On conserve ainsi la définition de la transformation initiale, que l’on peut utiliser séparément. Cette approche facilite le développement de stratégies de génération alternatives en favorisant la réutilisation. Ces patrons de transformation sont inspirés des patrons de conception de l’orienté-objet [34]. Ils répondent à des objectifs similaires :
Stratégie La mise en place d’un processus de raffinement incrémental, comme celui proposé en section 4.1 repose sur des stratégies de transformation alternatives. La définition de variantes né- cessite de spécialiser la logique de transformation. Le patron Stratégie, de l’orienté-objet, a pour objectif d’altérer le comportement d’un objet en fonction du contexte en déléguant une partie du comportement à un objet tierce que l’on peut remplacer. Dans le cas d’un processus de transfor- mation, l’objectif est de pouvoir adapter la transformation au contexte. Ainsi, la définition d’un tel patron consisterait alors à fournir des variantes d’une transformation en remplaçant les objets annexes à la transformation. Les étapes de transformation et d’analyse sont alternées de manière à déterminer si la transformation est adaptée aux exigences ou si son comportement doit être altéré en remplaçant les objets annexes à la transformation. Soit M le module contenant la définition initiale de la règle R que l’on souhaite modifier par la suite. La partie à altérer de la règle R est ex- ternalisée dans une fonction annexe H. Un second module M′modifie la définition de la fonction
Hde manière à altérer le comportement de la règle R. Dans le cas où l’on souhaite utiliser la règle initiale, seul le module M est chargé. Sinon, on charge M puis M′ afin de redéfinir H.
Adaptateur La définition d’une logique de transformation est dépendante de l’interface des élé- ments manipulés. Plus les interfaces sont hétérogènes plus le nombre de règles de transforma- tion est important, et plus le processus est difficile à maintenir. La complexité d’un processus de transformation dépend donc en partie de l’homogénéité de ces éléments. Le patron Adaptateur de l’orienté-objet répond justement à ce type de problématique : l’objectif est d’intégrer dans une architecture des types externes qui n’ont pas été conçus pour. Le principe est d’alors de définir de nouveaux types, compatibles avec l’architecture, qui encapsulent les types externes. Du point de vue d’un langage de transformation, il s’agit de réutiliser une règle de transformation sur un type d’élément d’entrée qui n’est initialement pas compatible avec l’interface des éléments d’entrée de la transformation. Cela permet de bénéficier d’une règle existante plutôt que définir une nouvelle règle au comportement similaire.
FIGURE4.2 – Utilisation du patron Adaptateur pour factoriser deux règles définies sur des types
Substitution partielle Ce patron n’a pas d’équivalent dans l’orienté-objet. L’objectif est d’as- surer la compatibilité d’une transformation sur des plates-formes d’exécution distinctes. En effet, certains concepts sont spécifiques à une plate-forme. Pour tout autre type de plate-forme, ces con- cepts n’existent pas et sont assimilés à d’autres concepts plus généraux. En conséquence, ils sont traduits de la même façon. Si l’on souhaite adapter une transformation définie pour une première plate-forme d’exécution, afin de la porter vers une seconde, il faut s’assurer que l’interprétation des concepts de la première soit compatible avec l’interprétation qui en faite dans la seconde. Si ce n’est pas le cas, les concepts assimilés dans la première, doivent être distingués dans la sec- onde. On souhaite alors redéfinir une règle de la première plate-forme pour qu’elle réduise son champ d’application aux concepts assimilables. La réalisation de ce patron consiste alors à exter- naliser l’expression définissant l’ensemble d’entrée de la transformation afin de pouvoir le réduire ultérieurement en redéfinissant cette expression. Ce principe est illustré par la figure 4.3. Une règle Rest initialement appliquée sur tous les éléments de type T . La prise en compte d’une nouvelle plate-forme d’exécution nécessite de distinguer deux sous-ensembles d’éléments. Les éléments de type T qui valident la condition a ≤ 0 ne doivent pas être traités par la règle R. L’application de Substitution partielle favorise la réutilisation de la règle R en réduisant son champ d’application dans le cas de la seconde plate-forme d’exécution.
FIGURE4.3 – Principe du patron Substitution Partielle
Memento Ce patron s’applique dans le cadre de la certification du processus de génération. La certification requiert d’assurer une cohérence globale du processus. On souhaite par exemple déterminer l’origine du code généré (quelle exigence a conduit à la production de cette partie du code ?) ou au contraire vérifier que les exigences exprimées en amont (lors de la conception) se retrouvent dans le code généré. On parle alors de traçabilité des exigences. Pour cela, on produit un ensemble de traces lors de la génération de code afin de faire le lien entre les propriétés définies par l’utilisateur et le code généré à partir de celles-ci. Concrètement, il s’agit de retrouver pour chaque élément cible crée, l’ensemble des éléments source qui ont conduit à sa création. La conservation des traces de transformation donne la possibilité de mettre en correspondance des éléments du modèle source et des éléments de code et de vérifier la cohérence du processus. La figure 4.4 décrit un exemple de métamodèle définissant les structures nécessaires à la mise en oeuvre du patron.
Pour conclure, nous avons présenté des patrons de transformation facilitant la mise en œuvre du processus de génération défini en section 4.1. Nous illustrerons l’utilisation des patrons en sec- tion 5.2. Le patron Stratégie aide à implémenter des stratégies alternatives par réutilisation d’une transformation existante. Le patron Adaptateur réduit la complexité de la logique de transforma- tion en homogénéisant les interfaces des objets. L’intégration de nouvelles plates-formes d’exécu-