Une famille de produits logiciels (FPL) désigne une collection de systèmes logiciels qui ont une cohérence générale dans leur objectif et qui partagent assez de similarités pour justifier leur gestion comme une seule entité (en considérant d’abord leur points communs) plutôt que de manière individuelle (en considérant d’abord leurs spécificités) [Par76]. L’ingénierie des lignes de produits logiciels [CN02, PBvdL05, VdL02] rassemble un ensemble de méthodes ayant pour objectif de produire une telle collection de systèmes logiciels similaires tout en réduisant leur coût de production, leur délai de commercialisation et en augmentant leur qualité ainsi que l’offre proposée [KBB+01]. C’est un paradigme de développement basé sur la dérivation d’une collection de variantes logicielles à partir d’un ensemble d’artefacts logiciels réutilisables, dont les assemblages possibles sont structurés par une architecture logicielle générique. L’expression « ligne de produits logiciels » (LPL) désigne à la fois l’architecture, les artefacts et les variantes qui peuvent en être dérivés. La construction proactive d’une telle structure requiert deux processus successifs, le premier ayant pour objectif de définir et de développer l’architecture et les artefacts (développement pour la réutilisation), et le second la mise en place de la dérivation de variantes depuis la plateforme définie précédemment (développement par la réutilisation) [CN02, PBvdL05].

Ces méthodologies ont été appliquées plusieurs fois et avec succès dans certaines entreprises, comme en témoigne le product line hall of fame  de la conférence Software Product Line Conference spécialisée sur les LPLs. Cependant, mettre en place une LPL ex nihilo en suivant la stratégie de construction proactive est un investissement à long terme, qui demande un temps et un coût non négligeables en amont, avant de produire les premiers produits logiciels commercialisables. A contrario, le développement de produits logiciels individuels est une stratégie qui s’avère rentable à plus court terme, mais la collection de variantes logicielles ainsi produite est plus difficile à maintenir et à faire évoluer par la suite. On note alors l’émergence d’une stratégie extractive combinant les avantages des deux précédentes, qui cherche à extraire une LPL en se basant sur les variantes existantes plutôt que de la construire ex nihilo [Kru01, Kru02]. Dans un premier temps, des variantes logicielles sont développées individuellement ou bien en utilisant des méthodes de réutilisation ad-hoc [DRB+13], assurant ainsi la rentabilité à court terme. Puis, dans un second temps, une LPL est construite à partir des variantes existantes [BRN+13], facilitant la gestion de la collection et assurant cette fois une rentabilité à plus long terme. Nos travaux se concentrent sur la mise en place d’une telle migration. La problématique principale étudiée dans ce manuscrit concerne donc la rétro-ingénierie des lignes de produits logiciels.

Les modèles de variabilité ont pour but de représenter les éléments communs, les éléments qui varient et comment ces éléments varient entre les produits de la LPL [KCH+90, MP07, CGR+12]. Ils sont établis au début du processus de développement pour la réutilisation et jouent un rôle central dans la gestion de la collection de variantes. Ils ont donc une importance toute particulière dans le processus de migration vers une LPL. Cependant, leur construction depuis des variantes existantes, qu’elle soit manuelle ou automatique, est une tâche ardue qui se heurte à différents problèmes [BABN16].

L’ingénierie des lignes de produits logiciels

Dans cette section, nous donnons une définition de l’ingénierie des lignes de produits logiciels, un paradigme de développement qui vise à produire des variantes logicielles similaires en réduisant leur coût et leur temps de développement grâce à la réutilisation. Nous faisons tout d’abord un point sur la terminologie, qui a évolué et qui varie encore aujourd’hui en fonction du continent, de la conférence ou des auteurs . Puis, nous discutons du contexte dans lequel l’ingénierie des LPLs s’est développée , avant d’en donner une définition .

Un point sur la terminologie

David Parnas définit en 1976 une famille de programmes [Par76] comme un ensemble de systèmes logiciels assez similaires pour qu’il soit plus avantageux et pertinent de considérer d’abord leurs propriétés communes avant d’étudier celles qui sont spécifiques à chacun de ces produits. Il préconise alors de considérer et de développer l’ensemble de ces programmes comme une seule entité plutôt que de développer chacun d’entre eux séparément. La stratégie ainsi définie requiert de mettre en évidence les éléments communs à plusieurs systèmes logiciels afin de réutiliser les artefacts correspondants.

On retrouve par la suite le terme famille de produits logiciels [Bos00], qui décrit généralement un ensemble de systèmes logiciels similaires, accompagné d’une architecture générique autour de laquelle est organisé un ensemble d’artefacts communs utilisés pour produire de manière systématique ces produits logiciels. Ce terme est utilisé de manière analogue à celui de ligne de produits logiciels, défini par le software engineering institute comme un ensemble de systèmes logiciels qui partagent un ensemble de caractéristiques communes, satisfaisant les besoins spécifiques d’un segment de marché et qui sont développés selon un cadre déterminé à partir d’un ensemble d’artefacts communs. David Parnas différencie cependant une famille de produits logiciels d’une ligne de produits logiciels, le premier terme faisant référence à un concept d’ingénierie et le second à un concept marketing et commercial.

D’autre part, le terme de famille de produits logiciels fait souvent référence à un ensemble de produits similaires, sans architecture générique ni artefacts logiciels réutilisables, de manière assez similaire à la famille de programmes. Pour qu’il n’y ait pas d’ambiguïté par la suite, nous parlerons de famille de produits logiciels (FPL) pour désigner des produits logiciels ayant des éléments et propriétés communs mais qui n’ont pas été développés avec des méthodologies axées sur la réutilisation. Nous utiliserons le terme ligne de produits logiciels (LPL) pour faire référence à une FPL décrite par une architecture générique définissant les éléments communs et spécifiques à ses différents systèmes et autour de laquelle s’articule un ensemble d’artefacts logiciels réutilisables. Ce dernier terme est en effet plus utilisé dans la littérature actuelle et il est plus cohérent avec celui d’ingénierie des lignes de produits logiciels.

Supposons qu’un certain nombre d’utilisateurs souhaitent utiliser une même catégorie de logiciels pour réaliser une certaine tâche, mais que les fonctionnalités utilisées par chaque utilisateur puissent être légèrement différentes. Dans ces cas, deux stratégies de développement prédominent : le développement de logiciels standards et le développement de logiciels individuels [PBvdL05, HP03]. Le développement d’un logiciel standard consiste à regrouper dans une même distribution du logiciel toutes les fonctionnalités pouvant intéresser les utilisateurs d’un segment de marché. Cette distribution est ensuite proposée à tous ces utilisateurs. Les exigences auxquelles doit répondre un tel logiciel sont identifiées lors d’analyses de marché préalables et doivent prendre en compte un périmètre assez étendu afin de répondre aux attentes du plus grand nombre d’utilisateurs possible. Cette stratégie demande un temps et un coût de production important, mais une seule fois. Cependant, l’utilisateur acquiert un logiciel onéreux et de taille importante alors que potentiellement, seule une partie des fonctionnalités offertes lui sera utile.

L’INGÉNIERIE DES LIGNES DE PRODUITS LOGICIELS

Une stratégie intéressante est d’allier les avantages des deux précédentes : la capacité d’adapter un système logiciel aux exigences d’un utilisateur (avantage du développement de logiciels individuels) et la capacité de satisfaire à moindre coût le plus grand nombre d’utilisateurs possible (avantage du développement de logiciels standards), grâce au « développement en une fois » couplé au large périmètre d’utilisation. Le premier défi est d’être capable de prendre en compte les exigences d’un grand nombre d’utilisateurs potentiels. On cherche pour cela à produire des logiciels plus spécifiques et adaptés que les logiciels standards, mais de manière plus rapide et moins chère que les logiciels individuels : c’est la personnalisation de masse.

Définition 2.1 (Personnalisation de masse). La personnalisation de masse est la production à grande échelle de produits adaptés aux exigences de clients individuels.

Définition 2.2 (Réutilisation systématique). Dans le domaine du développement logiciel, la réutilisation systématique est une approche organisationnelle du développement qui consiste à définir des artefacts réutilisables et flexibles, qui seront ensuite utilisés à travers plusieurs systèmes logiciels d’une manière prescrite afin de minimiser le temps et le coût de production de ces logiciels.

La personnalisation de masse couplée à la réutilisation systématique font naître une stratégie de développement laissant à l’utilisateur la possibilité de définir ses exigences et de faciliter et d’accélérer le développement du logiciel adéquat en sélectionnant les artefacts correspondants afin de composer efficacement le logiciel final. C’est sur ces deux principes que se base l’ingénierie des lignes de produits logiciels.

Définitions 

L’ingénierie des lignes de produits logiciels [PBvdL05] est une approche basée sur la réutilisation systématique et la personnalisation de masse visant à réduire le temps et le coût de développement d’un ensemble de systèmes logiciels similaires. Ce paradigme cherche à développer une FPL comme une seule entité (en privilégiant les éléments communs des variantes logicielles), plutôt que comme une somme de logiciels similaires individuels (en privilégiant leurs éléments spécifiques). Le cœur de cette approche est basé sur le développement d’une architecture logicielle générique, qu’il est possible de combiner avec divers artefacts logiciels réutilisables en fonction d’un ensemble d’exigences. Ainsi, plusieurs systèmes logiciels différents bien que fortement similaires, appelés variantes logicielles, peuvent être dérivés de cette architecture commune couplée à des artefacts variables. L’architecture générique regroupe donc l’ensemble des fonctionnalités communes à toutes les futures variantes et présente en plus des points de variation correspondant à des fonctionnalités optionnelles qu’un utilisateur peut choisir d’ajouter ou non à la variante finale. L’architecture générique, les artefacts réutilisables et l’ensemble des variantes logicielles qui peuvent en être dérivées forment ce que l’on appelle une ligne de produits logiciels (LPL).