Soutenance mémoire
La prolifération des outils de développement logiciel
La variabilité et l’évolution des exigences d’un projet de développement logiciel sont connues comme une des sources principales de complexité de l’activité de création logiciel [TI93, JMD04, Mar03]. En outre, les projets de développement logiciel sont de plus en plus réalisés de manière collaborative [HMR06], dans un contexte géographiquement distribué [CBHB07], et dans un contexte de globalisation faisant collaborer un ensemble d’entreprises au sein d’un même projet. Ces caractéristiques apportent une complexité accidentelle supplémentaire à la problématique du développement logiciel. Un des objectifs du génie logiciel est de conserver l’intelligibilité du processus de construction et de maintenance de ces applications. Dans ce cadre, de nombreux outils sont apparus afin de gérer, voire automatiser, une partie de cette complexité. Cependant, de part le nombre d’acteurs intervenant dans la construction d’un logiciel et leurs multiples préoccupations, il existe maintenant un écosystème riche et lui-même complexe lié à la problématique de développement logiciel.
Parmi ces outils, sans être exhaustifs, nous pouvons citer :
– des systèmes de contrôle de version (SVN, Git…) qui permettent de gérer les difficultés liées au travail collaboratif et géographiquement distribué,
– des outils de compilation (Maven, Ant, PDE…) qui permettent de gérer les problématiques d’intégration de composants ou de librairies réutilisables au moment de la construction d’un logiciel complexe,
– des outils d’analyse statique comme PMD, Findbugs ou Sonar qui aident à améliorer la qualité du logiciel,
– des outils de support à l’exécution des différents types de test logiciel (JUnit, Selenium, Quality Center…),
– des environnements de développement intégrés (IDE, Integrated Development Environment) permettant d’intégrer les différentes technologies utilisées sur un projet (langages, outils, frameworks, librairies…),
– des outils d’intégration continue permettant d’automatiser une partie de l’orchestration de la problématique de production logicielle.
La forte variabilité des exigences entre différents projets logiciels motive l’existence d’outils différents prenant en compte des préoccupations similaires, mais chacun avec des spécificités permettant de répondre au mieux aux exigences des différents projets. Ceci permet de comprendre le nombre d’outils existants et l’utopie de viser l’émergence d’un unique outil. Ainsi, certaines équipes de développement font le choix de l’IDE Visual Studio pour développer des applications Windows afin de profiter de toutes les facilités proposées par Microsoft pour ce faire, alors que si l’application à développer a des contraintes d’indépendance vis-à-vis du système d’exploitation sur lequel elle sera déployée, une équipe de développement pourra préférer l’IDE Eclipse pour faire du développement en Java. L’utilisation de tous ces outils est généralement bénéfique au bon fonctionnement d’un projet mais elle engendre aussi un ensemble de tâches d’ingénierie logicielle qui sont réalisées manuellement par les équipes de développement. Utiliser ces différents outils peut impliquer de devoir s’en procurer une version, de devoir les installer, les configurer, ou encore les mettre à jour. Par exemple, un développeur utilisant un IDE peut être amené à installer les librairies et les plug-ins nécessaires pour un projet, ainsi qu’à configurer ces derniers. Ces tâches sont de plus récurrentes dans le sens où elles peuvent avoir lieu plusieurs fois pendant un même projet mais aussi qu’elles se répètent d’un projet à l’autre, toujours dans un contexte différent. Par exemple, dans un projet, chaque développeur doit installer un IDE conforme aux exigences de ce projet. Nous appelons dans cette thèse ces tâches répétitives et réalisées manuellement des Tâches Manuelles Récurrentes (TMR). Ces TMR, bien qu’étant toujours similaires, doivent prendre en compte le contexte particulier dans lequel elles sont réalisées. Elles se révèlent être coûteuses en temps et sources d’erreurs pour les équipes de développement [RCB+11].
Le défi : réutiliser des automatisations de tâches manuelles récurrentes
L’automatisation des TMR liées à l’utilisation des outils de développement logiciel doit permettre de gagner en productivité. Cela doit aussi permettre d’éviter les erreurs humaines inhérentes à toute activité répétitive. Cependant, l’intérêt de la mise en place d’une telle automatisation est limité si les automatisations de TMR ne sont pas réutilisées, au sein d’un même projet mais également d’un projet à l’autre. Or, la réutilisation d’automatisations de TMR est un exercice difficile pour les trois raisons suivantes :
1. Bien qu’une automatisation de TMR puisse être utile pour différents projets, toutes les automatisations de TMR ne sont pas forcément utiles pour chaque projet. La difficulté est donc de déterminer quelles automatisations de TMR réutiliser pour un projet donné.
2. Une automatisation de TMR pouvant avoir des dépendances avec d’autres tâches d’un projet, une difficulté supplémentaire est de déterminer à quels moments d’un projet utiliser une automatisation de TMR.
3. La problématique du niveau de généralisation est aussi un problème complexe. Comment déterminer qu’une automatisation de TMR utile pour des projets différents, ou à des moments différents d’un même projet, soit bien réutilisable à travers ces différents cas d’utilisation ?
L’ingénierie dirigée par les modèles (IDM)
La séparation des préoccupations [Dij82] est un moyen de gérer la complexité des logiciels. En effet, il est plus simple et efficace pour l’esprit humain de résoudre un problème complexe en le décomposant en sous-problèmes de complexité moindre plutôt que de considérer le problème complexe dans son ensemble. L’IDM [JCV12] est un moyen de mettre en œuvre la séparation des préoccupations, en s’appuyant sur le principe de l’abstraction. En effet, le principe général de l’IDM est d’utiliser une représentation simplifiée d’un aspect du monde réel (c’est-à-dire un modèle) dans un objectif donné, en s’abstrayant des détails qui n’ont pas de rapport avec cet aspect. Dans le domaine de l’ingénierie logicielle, chaque aspect d’un système logiciel peut donc être représenté par un modèle. Ce modèle est lui même exprimé avec un langage de modélisation généraliste tel qu’UML [OMG11b, OMG11c] ou avec un langage de modélisation dédié à un domaine métier particulier. L’intérêt de ces langages est qu’ils soient plus simples à appréhender pour des humains que les langages de programmation classiques (Java, C#, …) ou que le langage machine. Un modèle peut alors être vu comme un support plus adapté pour des humains pour exprimer un aspect particulier d’un logiciel ainsi que pour réfléchir et communiquer sur cet aspect. Une problématique clé de l’IDM est également de rendre les modèles opérationnels. Cependant, à cette fin, ceux-ci doivent être interprétables par des machines. Le langage dans lequel ils sont exprimés doit donc être clairement défini. Comme tout langage informatique, un langage de modélisation est caractérisé par sa syntaxe abstraite, sa syntaxe concrète et sa sémantique [JCV12]. La syntaxe abstraite est la syntaxe manipulée par l’ordinateur. Dans le contexte des langages de modélisation, elle sert généralement de base à la définition de la syntaxe concrète et de la sémantique. La syntaxe concrète est la syntaxe manipulée par l’utilisateur du langage à l’aide d’un éditeur. Elle comprend des éléments syntaxiques dont le but est de faciliter l’utilisation d’un langage pour des humains. Elle associe des représentations pour chacun des éléments de la syntaxe abstraite. Il est tout à fait possible de définir des syntaxes concrètes différentes pour une même syntaxe abstraite, en fonction des besoins. La sémantique d’un langage de modélisation est définie en associant un sens à chacun des éléments de la syntaxe abstraite. Il est également possible de définir des sémantiques différentes pour une même syntaxe abstraite, en fonction des besoins (ex : vérification, simulation, compilation, etc.).
Dans le domaine de l’IDM, la syntaxe abstraite peut prendre la forme d’un modèle, appelé métamodèle. On dit d’un modèle m qu’il est conforme à un métamodèle mm si chaque élément de m est une instance d’un élément de mm [Guy13]. Cependant, face à la prolifération des métamodèles, le besoin est apparu de les unifier avec un langage de description commun, afin de les rendre compatibles entre eux et de pouvoir définir des outils capables de les manipuler de manière générique. L’OMG a donc proposé un langage de description des métamodèles, qui prend lui aussi la forme d’un modèle : le métamétamodèle MOF (Meta-Object Facility) [OMG06]. La particularité du métamétamodèle est qu’il se définit lui même, limitant ainsi le nombre de niveaux de modélisation. Quand le métamétamodèle MOF ne permet pas d’exprimer toutes les propriétés d’un métamodèle, il est possible d’utiliser un langage de contrainte, tel qu’OCL (Object Constraint Language) [OMG10], afin d’exprimer ces propriétés. Dans la pratique, l’utilisation de modèles de manière opérationnelle peut prendre plusieurs formes. Nous ne présentons ici que celles qui sont pertinentes pour la compréhension de cette thèse. Ainsi, les modèles peuvent être utilisés directement comme le système logiciel final à produire, en les exécutant tout comme il est possible d’exécuter n’importe quel programme informatique. Deux méthodes existent pour exécuter des modèles : l’interprétation et la compilation. L’interprétation consiste à analyser chaque élément d’un modèle et à l’exécuter en fonction de sa sémantique. La compilation consiste à transformer un modèle conforme à un langage en un modèle ou du texte conforme à un autre langage, et ensuite à exécuter le modèle ou le texte obtenu après transformation.
Il existe à ce jour de nombreux outils support à l’IDM. Dans cette thèse, nous utilisons EMF (Eclipse Modeling Framework) [SBPM09], un framework de l’environnement de développement Eclipse , afin de définir des métamodèles, de générer des éditeurs arborescents permettant de créer des modèles conformes à ces métamodèles, ainsi que de manipuler ces modèles et métamodèles en Java. EMF s’appuie sur le langage de métamodélisation Ecore [BSE03], qui est similaire au MOF. Nous faisons également référence dans cette thèse à l’utilisation d’UML afin de définir des langages de modélisation dédiés à un domaine métier particulier. Le mécanisme de profil UML permet en effet d’étendre UML de façon générique. Plus précisément, il permet d’ajouter de nouveaux concepts propre à un domaine métier particulier, de définir leurs propriétés, de spécifier des contraintes sur ces concepts et également de leur associer une représentation graphique. Un profil est définit principalement à l’aide de stéréotypes, où un stéréotype définit un nouveau concept, mais toujours sous la forme d’une extension d’un élément UML. Un stéréotype peut avoir des propriétés ainsi qu’une représentation graphique. Des contraintes (telles que des contraintes OCL) peuvent également être définies sur ce stéréotype.
|
Table des matières
1 Introduction
1.1 La prolifération des outils de développement logiciel
1.2 Le défi : réutiliser des automatisations de tâches manuelles récurrentes
1.3 Contributions de la thèse
1.4 Contexte de réalisation de la thèse
1.5 Plan de la thèse
I Contexte scientifique
2 Background
2.1 L’ingénierie dirigée par les modèles (IDM)
2.2 Les processus de développement logiciel
2.2.1 Introduction aux processus de développement logiciel
2.2.2 Modélisation des processus de développement logiciel avec SPEM 2.0
2.3 L’ingénierie des lignes de produits logiciels
2.3.1 Introduction
2.3.2 CVL
2.4 Synthèse
3 État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus
3.1 Support à la réutilisation des processus sans spécification de leur variabilité
3.1.1 Identification du processus correspondant à un projet
3.1.2 Réutilisation de processus définis en extension
3.1.3 Les patrons de processus
3.2 Ingénierie des lignes de processus
3.2.1 Utilisation des mécanismes d’un langage
3.2.2 Extension d’un langage de modélisation de processus
3.2.2.1 Utilisation de processus agrégats
3.2.2.2 Modification d’un processus de base
3.2.2.3 Spécification des points de variation et des variantes d’un processus
3.2.2.4 Configuration de processus par composition
3.2.2.5 Association de plusieurs techniques
3.2.3 Transformation en une structure pivot
3.2.4 Spécification de la variabilité sans réutilisation automatique
3.2.5 Synthèse sur l’ingénierie des lignes de processus
3.3 Synthèse
II Automatisation des tâches manuelles récurrentes pilotée par les processus de développement logiciel
4 Gestion de la variabilité dans les processus
4.1 Exemple illustratif : une famille de processus de métamodélisation
4.2 Approche
4.2.1 Définition de la ligne de processus de développement logiciel
4.2.1.1 Méthodologie pour la modélisation des éléments de processus (étape 1)
4.2.1.2 Spécification de la variabilité des exigences des projets (étape 2)
4.2.1.3 Liaison entre les exigences des projets et les processus (étape 3)
4.2.2 Dérivation d’un processus en fonction des exigences d’un projet
4.2.2.1 Résolution de la variabilité des exigences des projets (étape 4)
4.2.2.2 Dérivation automatique de processus (étape 5)
4.2.3 Exécution d’un processus résolu
4.3 Discussion
4.3.1 Capacité de CVL à gérer la variabilité des processus en fonction de la variabilité des exigences des projets
4.3.2 Indépendance de CVL vis-à-vis des métamodèles de processus
4.3.3 Validité du modèle de processus résolu
4.3.4 Extension possible à la méthodologie pour modéliser le processus de base
4.4 Synthèse
5 Création de composants d’automatisation réutilisables
5.1 Exemple illustratif : automatisation de la configuration de l’espace de travail local d’un développeur
5.2 La méthodologie
5.2.1 Définition d’une ligne de processus de développement logiciel (étape 1)
5.2.1.1 Méthodologie
5.2.1.2 Illustration
5.2.2 Spécification des composants d’automatisation (étape 2)
5.2.2.1 Méthodologie
5.2.2.2 Illustration
5.2.3 Liaison entre les CA et leurs contextes d’utilisation (étape 3)
5.2.3.1 Méthodologie
5.2.3.2 Illustration
5.2.4 Conception des composants d’automatisation (étape 4)
5.2.4.1 Méthodologie
5.2.4.2 Illustration
5.2.5 Implémentation des composants d’automatisation (étape 5)
5.2.5.1 Méthodologie
5.2.5.2 Illustration
5.3 Discussion
5.3.1 Bénéfices
5.3.2 Une limitation
5.3.3 Un inconvénient
5.4 Synthèse
III Conclusion
