Un inconvénient

Un inconvénient de M4RAC est qu’il est difficile d’identifier les contextes d’utilisa-tion des CA. En effet, avec la définid’utilisa-tion en intend’utilisa-tion des processus, il est difficile pour un humain de visualiser explicitement chacun des processus de la ligne. Par exemple, l’architecte peut avoir des difficultés à visualiser ce qui se passe avant et après une variante d’unité de travail, et donc il peut avoir des difficultés à déterminer à quelles unités de travail il est pertinent d’associer un CA. La définition de processus en ex-tension n’est pas une solution satisfaisante à ce problème. En effet, plus le nombre de processus est élevé, plus il est tout aussi difficile pour un humain d’identifier les différents contextes d’utilisation des CA. Une solution serait d’avoir un outil support à l’identification des contextes d’utilisation des CA (étape 3 de M4RAC). Celui-ci pour-rait par exemple calculer et afficher les différents processus d’une famille en fonction de leur spécification en intention, et afficher également les CA associés aux unités de travail de ces différents processus, au fur et à mesure de leur association. Afin de limiter le nombre de processus affichés, une idée serait de définir des contextes d’utilisation de CA similaires, et donc de n’afficher qu’un seul de ces contextes. De plus, cet outil pourrait vérifier la consistance entre des pré et post-conditions associées aux CA, afin de détecter d’éventuelles erreurs au moment de l’association d’un CA à une unité de travail.

5.4 Synthèse

Nous avons proposé, dans ce chapitre, une méthodologie qui permet d’améliorer l’identification du niveau de réutilisation d’un CA. Le principe de cette méthodologie consiste à lier chaque CA aux unités de travail qu’il contribue à automatiser dans une ligne de processus. Cela permet d’identifier les différents contextes d’utilisation de chacun de ces CA. Ensuite, en réfléchissant à la conception d’un CA afin qu’il soit

réutilisable à travers ses différents contextes d’utilisation, il est possible d’identifier le niveau de réutilisation de ce CA. Cette méthodologie permet d’expliciter les différents contextes d’utilisation d’un CA. De ce fait, cela permet à l’architecte en charge de la conception des CA de ne pas oublier certains contextes d’utilisation et de ne pas prendre en compte des contextes d’utilisation inutiles. Une limitation de cette métho-dologie en revanche est que son efficacité dépend des langages utilisés pour définir la ligne de processus. En effet, les contextes d’utilisation que la ligne de processus peut capturer dépendent des informations que les langages utilisés pour définir la ligne de processus permettent de capturer. D’autre part, avoir un outil permettant d’explici-ter les différents processus d’une ligne ainsi que les CA déjà associés à ces processus aiderait l’architecte à identifier les contextes d’utilisation des CA.

Outillage et application

101

Dans cette partie, nous commençons par présenter dans le chapitre 6 l’outil que nous avons développé afin de démontrer la faisabilité de l’approche proposée dans cette thèse. Ensuite, dans le chapitre 7, nous appliquons cet outil à une famille de processus de métamodélisation ainsi qu’à une famille de processus de développement web Java issue de Sodifrance.

Outil pour la gestion de la

variabilité et l’automatisation des processus

Ce chapitre traite de l’outil développé comme support à l’approche proposée dans cette thèse. Nous commençons par introduire, en section6.1, l’exemple dont nous nous servons pour présenter cet outil. La vue générale de l’outil est présentée en section6.2 et son implémentation est décrite en section6.3. Nous présentons, dans la section6.4, des éléments de méthodologie relatifs à l’utilisation de l’outil, ainsi que des extensions possibles. Enfin, nous faisons la synthèse de ce chapitre dans la section6.5.

6.1 Exemples de tâches manuelles récurrentes

Cette section introduit les exemples de TMR (Tâches Manuelles Récurrentes) utili-sés pour illustrer l’utilisation de l’outil développé dans cette thèse. Ces TMR, issues de l’exécution de processus de la famille des processus de métamodélisation (présentée dans la section4.1), gagneraient à être automatisées. Elles correspondent à la manière de réaliser des processus de métamodélisation dans l’équipe de recherche Triskell. Il existe d’autres manières de réaliser des processus de métamodélisation qui ne sont pas traitées ici (utilisation d’un outil autre que Kermeta, utilisation différente d’EMFText, etc.).

TMR Unité de travail

pendant laquelle la TMR a lieu

Étape de l’unité de travail

Itération

Création projet EMF et fichier Ecore vide

déf. métamodèle initialisation première Validation métamodèle déf. métamodèle finalisation toutes

105

TMR Unité de travail Mise à jour fichier contenant la

syntaxe concrète du métamodèle

déf. éditeur arbo-rescent

initialisation à partir de la seconde Génération éditeur arborescent déf. éditeur

arbo-rescent

Création projet XText déf. éditeur tex-tuel avec XText

initialisation première Génération éditeur textuel déf. éditeur

tex-tuel avec XText

finalisation toutes Création projet Kermeta initilisé

avec un appel à une fonction Ker-meta qui vérifie qu’un modèle res-pecte bien les contraintes définies

déf. interpréteur initialisation à partir de la seconde Mise sous contrôle de version

in-terpréteur

déf. interpréteur finalisation première Propagation, sur un dépôt

par-tagé, du code source de l’interpré-teur

déf. compilateur initialisation à partir de la seconde

Table6.1 – Exemples de TMR réalisées durant un processus de métamodélisation

Nous avons identifié 16 exemples de TMR. Le tableau6.1les répertorie et précise pour chacune d’elle l’unité de travail, son étape (initialisation, exécution ou finalisa-tion), ainsi que l’itération de processus concernées.

Deux TMR sont liées à la définition d’un métamodèle. La première consiste à créer un projet EMF ainsi qu’un fichier Ecore vide, qui contiendra plus tard la définition d’un métamodèle. Cette TMR a lieu au moment de l’initialisation de la définition d’un métamodèle, lors de la première itération. La seconde TMR consiste à valider un métamodèle et a lieu au moment de la finalisation de la définition d’un métamodèle, à chaque itération.

Trois autres TMR sont liées à la définition d’un éditeur arborescent. Celle-ci est initialisée par la création d’un fichier destiné à contenir la syntaxe concrète du mé-tamodèle, lors de la première itération. La mise à jour de ce fichier a lieu lors des itérations suivantes, toujours à l’initialisation. À chaque itération, la définition d’un éditeur arborescent est finalisée par la génération de l’éditeur en lui-même.

Quatre TMR sont liées à la définition d’un éditeur textuel. Si celui-ci est défini avec EMFText, alors, dans le cadre de cet exemple, la TMR consistant à générer la syntaxe textuelle est réalisée à l’initialisation, lors de la première itération. Si l’éditeur textuel est défini avec XText, alors la TMR consistant à créer un projet XText est réalisée, à l’initialisation et lors de la première itération également. Dans les deux cas, la définition d’un éditeur textuel se termine par la TMR consistant à générer l’éditeur en lui-même.

Une TMR concerne la définition d’un vérificateur. Elle consiste à créer un projet Kermeta et à l’initialiser avec un appel à une fonction Kermeta vérifiant qu’un modèle respecte bien les contraintes définies sur son métamodèle. Elle a lieu au moment de l’initialisation, lors de la première itération.

Quatre TMR concernent la définition d’un interpréteur. Au moment de l’initiali-sation, lors de la première itération, une TMR crée un projet Kermeta et applique le patron de conception interpréteur à chaque méta-classe du métamodèle. Lors des itéra-tions suivantes, la définition d’un interpréteur est initialisée par une TMR appliquant le patron de conception interpréteur seulement aux nouvelles classes du méta-modèle. Le cas des méta-classes du métamodèle supprimées ou modifiées n’est pas traité dans cet exemple. Lors de la première itération, la définition d’un interpréteur est finalisée par la TMR consistant à mettre l’interpréteur sous contrôle de version. De plus, à chaque itération, une TMR de propagation du code de l’interpréteur sur un dépôt distant a également lieu au moment de la finalisation.

Enfin, deux TMR sont liées à la définition d’un compilateur. La première consiste à créer un projet Kermeta et à appliquer le patron de conception visiteur à chaque méta-classe du métamodèle. Elle initialise la définition d’un compilateur et n’a lieu que lors de la première itération. La deuxième TMR applique le patron de conception visiteur seulement aux nouvelles méta-classes du métamodèle. Elle initialise la définition d’un compilateur à partir de la deuxième itération. Tout comme pour la définition d’un interpréteur, le cas des méta-classes du métamodèle supprimées ou modifiées n’est pas non plus traité dans cet exemple.

D’autres TMR non spécifiques au processus de métamodélisation, comme la confi-guration de l’environnement de développement, la conficonfi-guration de l’environnement

d’intégration continue ou la configuration du schéma de compilation, peuvent égale-ment être réalisées dans ce contexte.