Figure 6.1 – Vue générale de l’architecture de T4VASP
T4VASP (Tool for Variability management and Automation of Software Processes) est l’outil que nous avons développé pour valider l’approche proposée dans cette thèse . La figure6.1illustre ses composants :
– un modeleur de VAM (Variability Abstraction Model, modèle spécifiant la variabi- lité (section2.3.2et chapitre4)),
– un modeleur de VRM (Variability Realization Model, modèle définissant comment dériver un modèle résolu du modèle de base, en fonction de la résolution de la variabilité (section2.3.2et chapitre4)),
– un assistant à la résolution de la variabilité, – un moteur de dérivation CVL,
– un modeleur de CA (Composants d’Automatisation, composants logiciels auto- matisant des TMR (partieII)) abstraits,
– un modeleur de liaisons,
– un framework supportant l’implémentation des CA – et un interpréteur de processus.
Les modeleurs de VAM et de VRM permettent respectivement de produire des VAM et des VRM. L’assistant à la résolution de la variabilité permet de résoudre la variabilité d’un VAM (donc permet de sélectionner les exigences pour un projet particulier) et produit un RM (Resolution Model, modèle permettant de résoudre la variabilité définie dans un VAM (section2.3.2et chapitre4)). Le moteur de dérivation de CVL permet de dériver un modèle de processus résolu, en fonction d’un modèle de processus de base, d’un VRM et d’un RM. Le modèle de processus de base est produit à l’aide d’un modeleur de processus SPEM que nous réutilisons. Le modeleur de CA abstraits permet, comme son nom l’indique, de spécifier des CA abstraits, qui sont des définitions conceptuelles de CA (cf. section 5.2.2). Le modeleur de liaisons permet quant à lui de lier les CA abstraits i) aux unités de travail qu’ils contribuent à automatiser dans une ligne de processus et ii) à leur implémentation. Le framework support à l’implémentation des CA offre un cadre technique pour l’implémentation des CA. Enfin, l’interpréteur de processus permet d’exécuter un processus (obtenu par dérivation d’une ligne de processus), et de lancer au fur et à mesure de son exécution les CA qui l’automatisent. Nous détaillons ces composants dans la suite de cette section, en les présentant en fonction des parties de l’approche de cette thèse qu’ils supportent.
6.2.1 Définition d’une ligne de processus
Les modeleurs de VAM et de VRM supportent la définition d’une ligne de processus de développement logiciel, comme illustré par la figure6.2. L’implémentation de ces modeleurs consiste à développer des éditeurs permettant de créer des VAM et des VRM conformes au métamodèle de la spécification de CVL. Des modeleurs autorisant la définition de VAM et de VRM dans des modèles distincts ont de plus l’avantage de permettre la réutilisation de ces modèles indépendamment les uns des autres. Ce besoin apparaît par exemple lorsqu’une même ligne de processus est définie avec deux langages de modélisation de processus différents, suite par exemple à un changement de modeleur dans l’entreprise. Dans ce cas, le même VAM est réutilisé pour spécifier la variabilité de la ligne de processus, quel que soit le langage de modélisation de processus utilisé, alors que des VRM différents sont utilisés pour chaque langage de modélisation de processus.
6.2.2 Définition des CA
Le modeleur de CA abstraits, le modeleur de liaisons ainsi que le framework support à l’implémentation des CA contribuent à la définition des CA. Plus précisément, ils contribuent à la spécification de CA abstraits, à leur liaison à la ligne de processus et à leur implémentation. La figure6.3illustre la partie de l’approche proposée dans cette
Figure 6.2 – Partie de l’approche supportée par les modeleurs de VAM et de VRM
Figure 6.3 – Partie de l’approche supportée par les modeleurs de CA abstraits et de liaisons et le framework support à l’implémentation des CA
thèse qui est supportée par ces composants.
Le modeleur de liaisons permet de lier des CA abstraits (spécifiés à l’aide du mode- leur de CA abstraits) aux unités de travail d’une ligne de processus qu’ils contribuent à automatiser. Le modeleur de liaisons permet également de lier les CA abstraits à leur implémentation. Lorsque plusieurs CA contribuent à l’automatisation d’une même unité de travail, ce modeleur doit permettre de spécifier l’ordre dans lequel ces CA doivent s’exécuter. Le modeleur de liaisons doit également permettre de spécifier si un CA contribue à automatiser l’initialisation, l’exécution ou la finalisation d’une unité de travail.
Le framework support à l’implémentation des CA permet premièrement aux CA d’accéder à des informations contextuelles nécessaires à leur exécution. Pour s’exécuter, les CA ont en effet besoin d’avoir accès à des informations spécifiques à leur contexte d’utilisation, c’est-à-dire à des informations contextuelles. Par exemple, un CA qui met du code source sous contrôle de version doit avoir accès à l’URL du dépôt distant sur lequel partager ce code source. Selon le langage de modélisation utilisé pour définir la ligne de processus, ces informations contextuelles peuvent, ou non, être capturées dans la ligne de processus (et donc dans le modèle de processus résolu). Par exemple, en SPEM 2.0, il n’est pas possible de capturer l’URL d’un dépôt distant. En effet, même si cette information peut, par exemple, être capturée en utilisant une recommandation (Guidance), elle ne serait pas typée comme étant une information relative à l’URL d’un dépôt distant et ne pourrait donc pas être traitée comme telle par un outil recherchant des informations contextuelles. Il est donc nécessaire d’avoir un mécanisme permettant aux CA d’accéder aux informations contextuelles, qu’elles soient ou non capturées dans le modèle de processus résolu.
Le framework support à l’implémentation des CA permet également d’exécuter les CA de manière générique. En effet, l’interpréteur de processus doit pouvoir être réutilisé indépendamment des CA. Or, il n’est pas possible de déterminer à l’avance un ensemble fini de CA puisque i) il n’est pas possible de prévoir toutes les évolutions qui peuvent être apportées à une famille de processus et ii) il n’est pas possible d’avoir une vision exhaustive de toutes les familles de processus existantes. Il est donc nécessaire de pouvoir, au fur et à mesure de l’exécution de processus, lancer l’exécution des CA de manière générique. Par ceci nous entendons plus précisément que le framework doit permettre de lancer automatiquement l’exécution des CA, quels qu’ils soient.
6.2.3 Dérivation d’un processus en fonction des exigences d’un projet
L’assistant à la résolution de la variabilité et le moteur de dérivation CVL sup- portent la dérivation d’un processus de la ligne de processus en fonction des exigences d’un projet, comme illustré par la figure6.4. L’assistant à la résolution de la variabilité offre un support à la résolution de la variabilité, étape pouvant s’avérer fastidieuse et source d’erreurs. En effet, dans le VAM, la non séparation des préoccupations entre les spécifications de variabilité nécessitant une résolution manuelle et celles dont la réso- lution est dérivée (c’est-à-dire calculée automatiquement en fonction de la résolution d’autres spécifications de variabilité) peut compliquer la résolution de la variabilité
Figure 6.4 – Partie de l’approche supportée par l’assistant à la résolution de la variabilité et le moteur de dérivation CVL
pour un humain. De plus, plus le nombre de contraintes entre des spécifications de variabilité du VAM sera important, plus il sera difficile pour un humain de les prendre en compte. D’autre part, un humain peut toujours faire des erreurs conduisant au non- respect de la spécification de CVL. L’assistant à la résolution de la variabilité apporte donc un support i) en mettant en œuvre la séparation des préoccupations entre les spé- cifications de variabilité nécessitant une résolution manuelle et celles dont la résolution est dérivée, ii) en forçant le respect des contraintes entre les différentes spécifications de variabilité, et iii) en assurant le respect de la spécification de CVL.
Le moteur de dérivation CVL, quant à lui, dérive un processus de la ligne de processus conformément à la spécification de CVL. Afin de créer le modèle de processus résolu, il applique donc sur le modèle de processus de base les points de variation dont les spécifications de variabilité ont été résolues positivement.
6.2.4 Automatisation de l’exécution des processus
L’interpréteur de processus supporte l’automatisation de l’exécution des processus, comme illustré par la figure 6.5. Il exécute un processus résolu en fonction de la sé- mantique du langage de modélisation de processus utilisé. De plus, pour chaque unité de travail de ce processus, il lance, s’il y a lieu, l’exécution des CA associés. D’autre part, comme la réalisation de certaines unités de travail est manuelle [Ben07], l’inter- préteur de processus informe l’acteur courant du processus lorsqu’une intervention manuelle est requise, afin d’assurer le bon déroulement de l’exécution. Enfin, comme
Figure 6.5 – Partie de l’approche supportée par l’interpréteur de processus
le processus à exécuter peut contenir de la variabilité non encore résolue, l’interpréteur de processus permet de résoudre cette variabilité au moment de l’exécution.