Dans cette section, nous discutons du processus de transition vers une LPL à partir d’une FPL. Nous exposons d’abord le contexte et les problématiques qui font émerger plusieurs stratégies d’adoption des LPLs (Section 2.5.1), puis nous détaillons ces stratégies et leur utilisation (Section 2.5.2). Enfin, nous étudions les défis liés à la rétro-ingénierie des LPLs (Section 2.5.3).
2.5.1 Contexte et problématiques
Dans la Section 2.2, nous avons défini une LPL comme la succession de deux processus de développement, i.e., l’ingénierie du domaine et l’ingénierie d’application. Cependant, construire une LPL en suivant ce double processus montre des inconvénients. En effet, ce
n’est qu’après avoir réalisé l’ingénierie du domaine et à la fin de la mise en place de l’ingénie- rie d’application que les premières variantes logicielles peuvent être dérivées. L’adoption et la mise en place de telles méthodes prend parfois plusieurs années et demande dès le départ un très fort investissement sans profits immédiats [Kru01]. De plus, les effets bénéfiques de la réutilisation ne se font ressentir qu’après le développement de plusieurs variantes logicielles ; Pohl et al. [PBvdL05] fixent ce nombre minimal de variantes à développer à trois. Ils illustrent le coût de développement de n variantes en fonction de leur méthode de développement (i.e., logiciels individuels ou ingénierie des LPLs) par un schéma reproduit en Figure 2.7. Coûts accumulés Nombre de variantes logicielles Investissements Environ 3 variantes développement individuel ingénierie des LPLs
Figure 2.7 – Coût de développement de variantes logicielles avec une ligne de produits logiciels et par développement individuel [PBvdL05]
Construire une LPL en suivant ce processus nécessite donc 1) un fort investissement de départ, 2) du temps et de la main d’œuvre et 3) de quoi subsister jusqu’à la dérivation de la 4ème variante logicielle. La construction ex nihilo d’une LPL est donc un investissement à long terme.
De par la difficulté de réunir ces trois conditions, d’autres stratégies d’adoption des LPLs ont fait leur apparition.
2.5.2 Stratégies d’adoption
On peut trouver dans la littérature trois stratégies d’adoption différentes [Kru01, Kru02, ABKS13] :
— La stratégie d’adoption proactive suit les deux processus définis en Section 2.2. Dans le cas où les variantes à produire et leurs exigences peuvent être déterminées à l’avance et si celles-ci ne sont pas susceptibles de beaucoup évoluer, alors définir les artefacts et le périmètre de la LPL en amont durant l’analyse et la représentation du domaine peut s’avérer suffisant. Dans ces cas-là, un fort investissement est nécessaire pour la mise en place de l’architecture générique, des artefacts réutilisables et plus généralement de tout le cadre de dérivation au début du projet. Cependant, l’effort de développement est fortement réduit une fois la LPL mise en place.
— Lorsque les exigences de la LPL à produire ne sont pas entièrement déterminées à l’avance, la stratégie d’adoption réactive est plus appropriée. C’est une approche incrémentale, qui cherche à développer la LPL au fur et à mesure des nouvelles exigences qui apparaissent sur le marché. Le point de départ peut être un unique système logiciel, à partir duquel sont développées d’autres variantes en augmentant petit à petit le cadre de gestion de la variabilité.
— Enfin, la troisième stratégie d’adoption diteextractive, consiste à faire de la rétro- ingénierie d’une LPL depuis un ensemble de variantes existantes. Lorsque plusieurs systèmes logiciels sont développés de manière individuelle et qu’ils présentent des similarités, il peut être utile de les analyser et de s’appuyer sur leurs éléments communs et spécifiques pour extraire des modèles, des architectures et des artefacts sans devoir suivre le processus de construction d’une LPL ex nihilo.
Une enquête [BRN+13] menée sur 35 professionnels ayant travaillé sur des LPLs au sein d’une entreprise montre que l’adoption proactive n’est pas la stratégie la plus utilisée. Dans cette étude, 50% des participants affirment avoir travaillé sur une approche extractive, 47% sur une approche réactive et 35% sur une approche proactive.
Cette tendance s’explique par le fait qu’il est plus facile de développer des variantes individuelles qu’une LPL. Krueger accusait en 2001 le "manque d’outils et de techniques pour construire et pour gérer des collections de variantes logicielles" [Kru01], qui existent cependant en abondance pour le développement de systèmes logiciels individuels. De nom- breux outils ont été développés depuis, tels que pure::variants [Beu12], GEARS [Kru08] ou encore FeatureIDE [KTS+09], mais on trouve encore beaucoup de pratiques de réutili- sation ad-hoc. On peut donner comme exemple le clone-and-own ("cloner et s’approprier") qui est une pratique très répandue dans les entreprises, comme le révèle l’enquête de Du- binsky et al. [DRB+13]. Cela consiste à cloner un système logiciel existant, puis à ajouter ou supprimer des fonctionnalités à ces clones pour créer une nouvelle variante répondant à un nouvel ensemble d’exigences. Certains participants indiquent qu’ils n’ont pas d’autres mécanismes disponibles pour produire des variantes de logiciels existants et témoignent d’un manque d’organisation et de traçabilité en ce qui concerne la réutilisation logicielle. 2.5.3 La rétro-ingénierie des LPLs
Il est donc fréquent qu’un ensemble de variantes logicielles soit développé de manière individuelle et dans ce cas, les professionnels peuvent être confrontés à une double pro- blématique. D’une part, il est difficile de maintenir et de gérer un ensemble de variantes logicielles sans effort de réutilisation, particulièrement lorsque leur nombre, leur taille et leur complexité s’accroissent. Afin de surmonter cette première problématique, nous avons vu que les techniques de réutilisation systématique et de personnalisation de masse sur lesquelles se base l’ingénierie des LPLs forment une approche viable pour gérer des collec- tions de variantes logicielles. D’autre part, mettre en place un processus de transition vers l’ingénierie des LPLs depuis une FPL (i.e., stratégie d’adoption extractive) est une tâche ardue [Kru01].
Notons que la transition vers ce type d’approche n’est pas nécessairement complète. En effet, il y a des cas où la gestion d’une FPL et de sa variabilité peut être grandement améliorée par des méthodes inspirées des LPLs, sans pour autant devoir faire une migration totale vers ce paradigme.
Prenons par exemple le cas de fork-insight [RZK18], qui est un outil académique en ligne permettant de regrouper sous forme tabulaire un certain nombre d’informations sur les différents forks d’un projet Github. Un des objectifs de cet outil est de faciliter l’analyse et la recherche de variantes d’un projet Github, afin de trouver celles qui cor- respondent le plus aux attentes de l’utilisateur. Cela fait en partie écho à l’enquête de Dubinsky et al. [DRB+13], qui rapporte qu’il est parfois difficile de trouver la bonne va- riante à cloner en fonction des exigences requises par la nouvelle. Les initiatives comme fork-insight permettent donc de faciliter la gestion de telles variantes, mais pourraient bénéficier des méthodes de sélection et de configuration de produits des LPLs pour ai- der l’utilisateur dans ses recherches. Un autre exemple est les matrices de comparaison de
produits [BSA+14, SAB13] que l’on trouve en abondance sur internet, notamment sur Wi- kipedia2. Ces matrices représentent des FPL en fonction de leurs caractéristiques sous une forme tabulaire qui facilite leur comparaison. Pouvoir passer de cette représentation ex- tensionnelle vers une représentation intensionnelle complémentaire décrivant la variabilité de la FPL permettrait de donner une vue globale et synthétique à un utilisateur [SAB13]. La migration complète ou partielle d’une FPL vers une LPL est donc un moyen d’amé- liorer la gestion et la manipulation de la variabilité, dans le but de faciliter la gestion, l’évolution et la maintenance d’un ensemble de variantes logicielles. Nous avons vu précé- demment que dans l’ingénierie des LPLs, la plupart des opérations de gestion de la varia- bilité se basent sur un modèle de variabilité, défini lors de la première étape du processus d’ingénierie du domaine. Construire un tel modèle pour une FPL apparaît naturellement comme la première étape de la migration [Kru01].
Cependant, même avec un nombre restreint de variantes, la construction manuelle d’un tel modèle est un processus long, difficile et faillible. Pour faciliter cette migration, des recherches ont été faites sur la synthèse automatique de FMs [RPK11, ACP+12, LLG+15, AMHS+14, HLE11, BABN16, DDH+13]. En général, ces approches cherchent à extraire des relations correctes et cohérentes entre les caractéristiques qui décrivent les variantes existantes et s’en servent comme base pour construire un modèle représentant la variabilité de la FPL. Cependant, comme nous l’avons vu en Section 2.4, plusieurs modèles différents (i.e., ayant des sémantiques ontologiques différentes) peuvent décrire le même ensemble de variantes. Cette sémantique ontologique des FMs rend donc leur extraction difficile et sujette à produire des modèles incorrects du point de vue du domaine étudié. Baser la gestion de la variabilité de FPLs sur de tels modèles peut provoquer des erreurs importantes [BABN16] rendant plus difficile encore la gestion de ces variantes.
En résumé (2.5) :
— Il existe trois stratégies d’adoption des LPLs : proactive lorsque la LPL est construite ex nihilo, réactive lorsqu’elle est construite incrémentalement selon un système logiciel de départ et extractive si la LPL est obtenue par rétro-ingénierie depuis une collection de variantes logicielles existantes.
— De nombreuses FPLs sont développées à partir de procédés ad-hoc sans organisation de la réutilisation.
— La migration partielle ou complète vers des LPLs est une solution efficace pour faciliter la gestion de ces collections de variantes.
— De ce fait, la stratégie d’adoption extractive est la plus répandue dans les orga- nisations qui adoptent une LPL.
— La transition vers les LPLs est unetâche ardue qui nécessite des techniques et des méthodes pour l’encadrer.