Rupture d’analyse entre système modélisé et système généré

Rupture d’analyse entre système modélisé et système généré

Un processus classique de développement de SETRC est constitué de trois grandes étapes : la modélisation du système, sa validation par un ensemble d’analyses effectuées sur le modèle, puis la génération de code si la validation réussie. La validation à la conception facilite la détection de problèmes tôt dans le processus de génération et évite ainsi des modifications du code exécutable, une fois généré [87]. En supposant que l’ensemble des analyses nécessaires à la validation sont réalisées lors de la conception, le code généré peut remettre en cause ces analyses [12] : en particulier, l’introduction de composants intergiciels lors de la génération de code impacte les propriétés du système modélisé telles que le temps de réponse. Le modèle initial n’incluant pas ces composants, la validation ne peut alors tenir compte de leur impact sur les performances. Par conséquent, la validation en amont ne garantit pas le respect des contraintes pour le système final issu de la génération de code. Il est alors nécessaire de conserver les propriétés analysables tout au long du processus : du modèle initial au code exécutable. De cette manière l’analyse s’effectue tout au long des différentes étapes de génération de code. Cependant, étant donné qu’une même analyse peut intervenir à plusieurs étapes du processus, elle peut soit s’effectuer sur le modèle initial ou bien sur le code final (code exécutable en langage de programmation). Ces entités hétérogènes que sont le modèle et le code exécutable requièrent alors des outils distincts pour effectuer une même analyse. Par exemple, un modèle d’architecture décrit en langage UML Marte [77] va être validé par des outils compatibles tels que MAST [42] tandis que le code généré sera évalué par des outils d’analyse de code exécutable (analyse statique du code, analyse à l’exécution). Cela soulève la problématique de la cohérence entre les analyses. Puisque plusieurs outils sont nécessaires pour réaliser les mêmes analyses, il faut s’assurer que leurs méthodes d’évaluation sont identiques ou équivalentes pour garantir une démarche de validation cohérente. Pour obtenir des méthodes d’évaluation équivalentes, le modèle et le code généré doivent donc être homogènes pour être évalués avec les mêmes outils. Dans [13] est proposée une démarche d’analyse indépendante du méta-modèle en proposant de représenter le modèle par une séquence d’opérations de création et d’initialisation. Cependant ce type d’approche se limite à l’analyse structurelle du modèle et à l’analyse du séquencement des opérations. On peut également s’intéresser aux techniques de raffinements de modèle. Notamment, dans le domaine du MDA [79], les transformations de modèle sont des techniques consistant à transformer automatiquement un modèle initial (PIM : Platform Independant Model) pour obtenir un modèle raffiné spécifique à la plate-forme d’exécution visée (PSM : Platform-Specific Model). Parmi ces techniques, les transformations endogènes [67] produisent un PSM dans le même formalisme que le PIM. Cela donne ainsi la possibilité d’utiliser un même outil d’analyse en début et en fin du processus. La capacité à analyser le code généré et la précision des analyses dépendent alors de l’écart entre le PSM et le code généré. Par exemple, dans [60], on réalise une grande partie de la génération de code exécutable au sein d’une transformation endogène. La phase finale étant l’appel à un pretty-printer traduisant le modèle raffiné en code exécutable sans l’ajout de ressources supplémentaires. L’évaluation du PSM donne ainsi la possibilité de déterminer si la stratégie de génération est adaptée aux contraintes du système. Cependant, les processus de transformation permettant d’entrelacer analyses et transformations [82, 58, 43] requièrent une spécification complète des méthodes d’analyse plutôt que d’utiliser des outils dédiés. Leur utilisation n’est donc pas adaptée au domaine des SETRC. Une alternative est d’accompagner le PSM d’un modèle de prédiction de performances. Dans [87], le processus de transformation est dérivé en une seconde transformation, appelée transformation couplée, produisant un modèle d’analyse correspondant. Cette approche nécessite un niveau d’expertise élevé pour déterminer et évaluer les aspects qualitatifs induits par la transformation, la transformation couplée étant écrite manuellement par l’utilisateur. Enfin, l’analyse du PSM nécessite de conserver les propriétés tout au long du processus de transformation : par exemple, en accompagnant la transformation de traces qui indiquent pour chaque élément source les éléments cibles produits[52].

Adaptabilité du processus de génération

La problématique précédente souligne le besoin d’analyser le modèle au cours de la génération afin de déterminer si l’implémentation choisie est adaptée aux propriétés du SETRC. En effet, la génération de code doit pouvoir être adaptée en fonction de ces propriétés. Premièrement, le choix de la plate-forme d’exécution visée implique l’utilisation de composants logiciels dédiés : notamment lorsqu’elle introduit des concepts spécifiques qui ne sont pas partagés avec d’autres plates-formes d’exécution. La stratégie de génération va alors dépendre de la plate-forme d’exécution ciblée. Deuxièmement, on peut également fournir des implémentations alternatives pour une même plate-forme. Le coût des mécanismes offerts par la plate-forme, ou les caractéristiques du système (e.g. nombre de tâches, jigue) peut influencer le choix de la stratégie. En effet, une implémentation sera appropriée pour certaines configurations et pas pour d’autres. Développer un tel processus proposant plusieurs stratégies de génération peut être une tâche difficile, en particulier en terme de maintenance. On peut alors s’intéresser à la portabilité d’un générateur de code existant afin de l’adapter à une autre plate-forme d’exécution ou à un autre choix d’implémentation. Pour illustrer le problème de la portabilité, nous représentons les SETRC comme un empilement de quatre couches, en partant des composants applicatifs à la plate-forme d’exécution : 1. Composants applicatifs : modèles fournis par l’utilisateur. Il représentent le système : topologie, interactions entre composants, propriétés temporelles et de dimensionnement… 36 CHAPITRE 3. PROBLÉMATIQUE Les composants s’accompagnent de code implémentant les fonctions métier de l’application à déployer. 2. Conteneurs pour composants applicatifs : code généré à partir des modèles de l’utilisateur (couche 1) pour faire le lien avec le code fonctionnel de l’intergiciel (couche 3). 3. Intergiciel : composants intergiciels servant de façade à des plates-formes d’exécution spécifiques. Ces composants ont leur propre sémantique d’exécution qui n’est pas nécessairement identique à celle de la plate-forme d’exécution (couche 4). L’intergiciel permet ainsi de s’abstraire des différences architecturales et comportementales. 4. Plate-forme d’exécution : plate-forme matérielle et noyau. Lorsque l’on souhaite fournir plusieurs stratégies de génération, deux solutions peuvent être envisagées pour adapter le générateur existant : la première consiste à assurer la portabilité par un intergiciel générique (couche 3). Celui-ci adapte le code généré (couche 2) à la plate-forme d’exécution (couche 4). Une API générique est alors définie de façon à pouvoir interagir de façon identique avec l’ensemble des plate-formes supportées. Ainsi, lorsque l’on souhaite générer du code vers une nouvelle plate-forme d’exécution, aucune modification du générateur existant n’est nécessaire. Par contre, l’API doit être réécrite pour prendre en compte les spécificités de la nouvelle plate-forme. L’objectif est alors de fournir un intergiciel qui tienne compte des différences architecturales et comportementales des plates-formes visées. Pour conclure, cette solution présente certaines limitations. D’une part, les composants intergiciels doivent alors être suffisamment génériques pour pouvoir être utilisés sur l’ensemble des plates-formes d’exécution visées. C’est une tâche complexe tant les différences architecturales et comportementales sont importantes. D’autre part, cela implique des coûts supplémentaires de développement et un impact négatif sur les performances[49] dû à l’adaptation du code. La seconde consiste à assurer la portabilité par le générateur de code (couche 2). Dans cette situation, ce dernier fournit plusieurs stratégies de génération. Cela revient à développer plusieurs générateurs. Cependant, le développement et la maintenance de plusieurs générateurs indépendants représente un coût important. Pour réduire ce coût, plusieurs techniques sont possibles : – Décomposer la génération en étapes successives : la transformation du PIM en PSM se fait progressivement par un ensemble de raffinements produisant des PSM intermédiaires. Chaque générateur est alors défini par un ensemble de raffinements qui sont sélectionnés et peuvent être partagés. La transformation est alors formalisée dans un workflow [58, 82] qui décrit l’enchaînement des étapes de raffinement. Cependant, il n’y a pas de méthodologie pour identifier et factoriser les raffinements réutilisables. – Structurer les générateurs en couches : la transformation du PIM et PSM est définie de façon modulaire. Chaque couche définit ou redéfinit une partie de la transformation. Ce type d’approche [57, 7] peut être facilement implémentée dans les transformations écrites en langages orientés-objet [7] qui bénéficient des techniques d’héritage et de composition. Cependant, dans le cas des langages de transformation relationnelle ou hybride, cette technique n’a pas été mise en avant. – Dériver le générateur par un processus automatique de transformation : le générateur est vu comme un modèle que l’on peut transformer/raffiner par une transformation d’ordre supérieur (HOT)[79]. On définit alors un module de transformation qui définit des règles pour adapter/dériver le générateur existant. Il faut alors exécuter la transformation pour obtenir le nouveau générateur que l’on peut à son tour exécuter. L’utilisation de HOT dans le cadre des SETRC n’est pas clairement définie : en particulier les relations entre les différentes techniques d’adaptation.