Technologies

Gestion de la variabilité dans les processus de développement logiciel avec CVL

Publié le : Auteur: Emmanuelle ROUILLE 2 commentaires
technologies

Introduction

Un processus de développement logiciel (processus dans la suite de cet article) décrit la séquence de tâches à réaliser afin de mener à bien un projet de développement informatique. Les processus sont utiles car ils permettent de capitaliser le savoir-faire pour réaliser des projets. Réutiliser ce savoir-faire permet ensuite d’améliorer la productivité des équipes de développement.

Cependant, la variabilité au niveau des exigences des projets implique de la variabilité au niveau des processus. Ainsi, dans une entreprise réalisant des projets de développement informatique, il n’y aura pas un seul mais plusieurs processus, en fonction des exigences des projets. Le nombre de processus devient vite très important.  Par exemple, chez Sodifrance, rien que pour les projets de développement Java, 384 processus différents ont été répertoriés. Il est évidemment impossible pour un humain de connaître tous ces processus, et donc de les réutiliser. D’où l’importance d’avoir des techniques permettant de capitaliser des processus et de les réutiliser automatiquement en fonction des exigences des projets.

Parmi les approches existantes, certaines consistent à définir les différents processus dans un dépôt, et proposent des mécanismes permettant d’extraire automatiquement un processus de ce dépôt en fonction des exigences des projets. Le problème est que dans ce cas les processus sont définis en extension dans le dépôt. C’est-à-dire que tous les processus sont décrits de A à Z et indépendamment les uns des autres. En particulier, les parties communes à plusieurs processus ne sont pas factorisées, ce qui pose de sérieux problèmes de maintenance lors de l’évolution de ces parties communes.  Afin d’adresser ce problème, d’autres approches s’appuient sur l’ingénierie des lignes de processus. En effet, l’ingénierie des lignes de processus préconise de définir des lignes de processus (c.-à-d. de définir en intention – en factorisant les parties communes – une famille de processus) et de dériver automatiquement un processus depuis cette ligne de processus en fonction des exigences des projets. Ces approches s’appuient également sur l’IDM (Ingénierie Dirigée par les Modèles) afin de définir une ligne de processus, en modélisant les processus, les parties de ces processus qui varient et les possibles variations. Cependant, ces approches se révèlent être dépendantes des méta-modèles de processus qu’elles utilisent. Ainsi, certaines approches modifient un méta-modèle de processus existant avec des concepts permettant de modéliser la variabilité des processus. Cela nécessite d’adapter ces concepts si on veut les utiliser avec un autre méta-modèle de processus, et cela nécessite également de modifier cet autre méta-modèle de processus. La modification d’un méta-modèle de processus implique également que les outils spécifiques à ce méta-modèle (modeleurs…) deviennent inutilisables à moins d’être adaptés au nouveau méta-modèle. D’autres approches proposent de transformer des modèles de processus en des structures pivots sur lesquelles sera définie la variabilité. Là encore, ces approches dépendent des méta-modèles de processus utilisés puisqu’elles nécessitent la définition d’une transformation pour chaque méta-modèle de processus.

D’un autre côté, il existe un standard de l’OMG en cours de spécification, CVL (Common Variability Language), qui permet de définir et de résoudre de la variabilité sur n’importe quels modèles pourvu que leurs méta-modèles soient conformes à MOF. Des travaux, présentés dans un article publié à la conférence APSEC (Asia-Pacific Software Engineering Conference) en 2012, investiguent donc l’utilisation de CVL pour gérer la variabilité dans les processus, indépendamment des méta-modèles de processus.

Le présent article montre un aperçu de CVL et de son utilisation dans le domaine des processus. Pour plus de détails, les lecteurs peuvent se référer à l’article publié dans la conférence APSEC (ici) ou au wiki dédié à CVL (ici).

CVL

Cette partie donne un aperçu du principe général de CVL, illustré par la Figure 1.

Figure 1: aperçu du principe général de CVL
Figure 1: aperçu du principe général de CVL

Le modèle de base est une instance de n’importe quel méta-modèle conforme à MOF. Il permet d’instancier les concepts propres à un domaine métier particulier. Le MAV (Modèle d’Abstraction de la Variabilité), le MRV (Modèle de Réalisation de la Variabilité) et le MR (Modèle de Résolution de la variabilité) sont trois modèles qui permettent de spécifier et de résoudre la variabilité de ce modèle de base. Leurs méta-modèles sont définis dans la spécification de CVL. N’est présentée dans cet article qu’une partie des concepts de ces méta-modèles, suffisante pour comprendre le principe général de CVL. Cependant, tous les autres concepts peuvent être utilisés pour gérer la variabilité dans les processus.

Le MAV permet de spécifier la variabilité. Parmi les concepts définis dans son méta-modèle, un choix est une caractéristique qui peut être sélectionnée ou non. Un choix peut contenir des choix enfants et il est possible d’exprimer des contraintes de sélection de ces choix enfants. Par exemple, un choix enfant peut être optionnel, ou deux choix enfants peuvent être mutuellement exclusifs.

Le MRV définit comment transformer le modèle de base en fonction de la résolution de la variabilité. Pour ce faire, il permet de définir les opérations à appliquer au modèle de base en fonction de la variabilité spécifiée dans le MAV. Un exemple d’opération est l’affectation de lien, qui permet de rediriger un lien vers un nouvel objet. Ce lien est identifié grâce à l’objet le contenant dans le modèle de base et grâce au nom de la référence qu’il instancie. Une affectation de lien est également liée à un choix du MAV. Cela signifie que quand ce choix sera sélectionné, l’affectation de lien sera appliquée au modèle de base, et sinon elle ne le sera pas.

Le MR permet quant à lui de résoudre la variabilité. Par exemple, le MR permet de sélectionner ou pas des choix du MAV en les résolvant à vrai ou faux.

Un modèle résolu peut être dérivé du modèle de base, en fonction de la résolution de la variabilité (spécifiée dans le MR) et en fonction des opérations définies dans le MRV. Le modèle résolu est ainsi une autre instance du méta-modèle auquel est conforme le modèle de base.

La Figure 2 montre comment les concepts de CVL seront représentés dans la suite de cet article.

Figure 2: représentation des concepts de CVL
Figure 2: représentation des concepts de CVL

Utilisation de CVL pour gérer la variabilité dans les processus

Cette partie donne un aperçu de l’utilisation de CVL pour gérer la variabilité dans les processus, que la Figure 3 illustre.

Figure 3: principe général de l'approche pour utiliser CVL avec les processus
Figure 3: principe général de l’approche pour utiliser CVL avec les processus

Le modèle de base est un modèle de processus de base, qui contient tous les éléments de processus nécessaires pour créer les différents processus d’une famille de processus. La Figure 4 montre comment seront représentés des processus dans la suite de cet article. Un processus a un début et une fin, et est composé d’une séquence de tâches, qui correspondent à des unités de travail à réaliser. Les flots de contrôle permettent de définir le séquencement entre les tâches. Une tâche peut-être réalisée à l’aide d’un outil, et peut prendre des produits de travail en entrée et en produire en sortie. En considérant une famille de processus de développement Java simplifiés, le modèle de processus de base peut prendre la forme de celui présenté dans la Figure 5. Il est composé d’une variante de processus de développement Java, qui consiste en les tâches de spécifications, développement et tests, et qui utilise une BDD MySQL. Il y a également d’autres éléments de processus (tâche de génération de code et outil Oracle), qui ne sont pas reliés à la variante de processus, mais qui sont utiles pour créer d’autres variantes de processus.

Figure 4: concepts pour représenter les processus
Figure 4: concepts pour représenter les processus
Figure 5: modèle de processus de base
Figure 5: modèle de processus de base

Le MAV sert à spécifier la variabilité au niveau des exigences des projets. La Figure 6 montre le MAV correspondant à la famille de processus de développement Java utilisée comme exemple. De la génération de code et une BDD peuvent optionnellement être utilisées. Si une BDD est utilisée, ce peut être soit une BDD Oracle, soit une BDD MySQL.

Figure 6: MAV de la famille de processus de développement Java
Figure 6: MAV de la famille de processus de développement Java

Le MRV sert à spécifier les modifications à appliquer au modèle de processus de base pour obtenir le processus correspondant aux exigences d’un projet. La Figure 7 montre un extrait du MRV correspondant à la famille de processus de développement Java utilisée comme exemple. Si la génération de code est choisie, alors il faudra entre autres rediriger la cible du flot de contrôle sortant de la tâche spécifications vers la tâche génération de code.

Figure 7: extrait du MRV de la famille de processus de développement Java
Figure 7: extrait du MRV de la famille de processus de développement Java

Le MR sert à sélectionner les exigences correspondant à un projet particulier. La Figure 8 montre un exemple de MR pour la famille de processus de développement Java. La génération de code est sélectionnée mais pas la BDD.

Figure 8: MR de la famille de processus de développement Java
Figure 8: MR de la famille de processus de développement Java

Enfin, le modèle résolu devient un modèle de processus résolu. Il contient une variante de processus, dérivée du modèle de processus de base, en fonction des exigences pour un projet particulier (spécifiées dans le RM), et du MRV. La Figure 9 montre le modèle de processus résolu correspondant au modèle de processus de base, au MAV, au MRV et au RM ci-dessus. Il s’agit d’un processus de développement Java avec génération de code et sans BDD.

Figure 9: modèle de processus résolu
Figure 9: modèle de processus résolu

Conclusion

CVL permet donc de gérer la variabilité dans les processus indépendamment des méta-modèles de processus utilisés. Ceci permet de réutiliser CVL avec différents méta-modèles de processus, sans modifier CVL et sans modifier ces méta-modèles de processus. En revanche, une limitation de CVL est qu’il permet de dériver des modèles résolus non conformes à leur méta-modèle. En effet, il est possible de définir dans le MRV des opérations sur le modèle de base qui produisent un modèle résolu invalide. Par exemple, suite à une affectation, un lien peut pointer vers un objet du mauvais type. Certaines opérations peuvent également aboutir au non respect de la multiplicité d’une référence. Une solution pour éviter les erreurs de type durant les affectations serait de définir des contraintes (ex: contraintes OCL)  sur le méta-modèle du MRV qui assureraient le respect des types. Une solution pour éviter les problèmes liés au non respect de la multiplicité d’une référence serait de définir un outil d’analyse statique qui vérifierait avant la dérivation que les multiplicités des références sont bien respectées. Cet outil préserverait bien entendu l’indépendance vis-à-vis du méta-modèle du modèle de base en raisonnant sur ce méta-modèle et sur le modèle de base en utilisant le MOF.

  • Vincent Hanniet

    Ce « meta » point de vue industriel sur notre métier du développement montre en tout cas que la maîtrise de nos processus de développement logicielle n’est pas industrielle : 384 processus de développement Java ! Certes, je comprend qu’il suffit de changer un petit bout d’étape quelconque pour obtenir un « nouveau » processus, et que ce décompte est donc largement exagéré par rapport à, par exemple, un décompte des « patterns » de processus de développement, mais je suis certain qu’on obtiendrait des nombres de même ordre dans tout organisation développant de nombreux projets !

    Reste une question tout de même : d’un point de vue pragmatique, quel est le niveau d’exigence nécessaire et suffisant pour décrire un processus dont on admet qu’il est réutilisable par des équipes de développement ?

    • Emmanuelle Rouillé

      Grande question…

      Dans un monde idéal on pourrait imaginer décrire les processus au niveau de granularité le plus fin possible, afin de capitaliser toutes les informations sur ce processus. Certains diront que c’est inutile car certaines tâches sont tellement « évidentes » que ce n’est pas la peine de trop les décrire. Et en même temps une personne novice pourra tout à fait « mal » faire ces tâches car pour elle elles ne sont pas du tout évidentes. D’où l’utilité de capitaliser le plus possible.
      Dans la réalité je pense cependant qu’une telle approche n’est pas réalisable car il y aura toujours des contraintes qui feront qu’on ne pourra pas passer une éternité à décrire les processus.
      Dans ce cas il faut bien identifier à quoi va servir la réutilisation des processus, afin d’identifier les informations que l’on va vouloir capturer. Si les processus sont juste utilisés à titre informatif, dans ce cas peut-être que les décrire au niveau de granularité le plus fin possible, en fonction des contraintes de temps et de ressources, sera déjà bien. Si, par contre, comme dans le cas de ma thèse, on veut utiliser les processus pour piloter l’automatisation de tâches manuelles récurrentes qui ont lieu à l’exécution de ces processus, alors il faudra que le processus capture les informations nécessaires à l’automatisation de ces tâches manuelles récurrentes. Par exemple, si on veut automatiser la mise sous contrôle de version d’un projet Java, il faudra que le processus nous dise quel système de contrôle de version est utilisé (CVS, SVN, Git,…).
      Je pense donc que le niveau de description des processus dépend de l’utilisation que l’on veut faire de ces processus.