|
Automatisation des lignes de produits logiciels en entreprisepar Thomas Petit - M2 Informatique 2019 |
RAPPORT D'ALTERNANCE 2018-2019 Automatisation des lignes de produits logiciels en entreprise
10 MAI 2019 THOMAS PETIT 10 Mai 2019 Table des matières INTRODUCTION 6 L'informatique 6 Les entreprises face aux défis de la réutilisation 9 Les lignes de produits logiciels 9 L'alternance 14 Le plan du mémoire d'alternance 16 LE BUT 17 La réduction des couts de développement 18 Réduction du délai de mise sur le marché des logiciels 18 Réduction des efforts de maintenabilité des logiciels. 19 Amélioration de la qualité des logiciels 19 Etat de l'art et prérequis 20 La ligne de produit logiciel 20 Ingénierie du domaine et ingénierie d'application 23 Analyse du domaine 23 Conception du domaine. 23 Réalisation du domaine 23 Ingénierie d'application 24 Configuration des produits. 24 Génération des produits 24 Les approches de conceptions traditionnelles 25 Le développement from scratch 25 Le clone and own 25 Le répertoire commun 25 Les approches fondamentales pour les LPL 27 L'approche Proactive 27 L'approche Extractive 30 L'approche Réactive 31 Quelle approche adaptée aux PME ? 34 L'analyse Formelle 36 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT La variabilité d'une Ligne de produit logiciel 40 La gestion de la variabilité 40 Caractéristique logicielle 40 Modèle des caractéristiques 41 L'implémentation LPL par annotation et par composition 43 Annotation 43 L'implémentation en compositionnel 45 Le degré de granularité 47 Localisation des caractéristiques 48 Résumé LPL 51 SPL generator 53 Les objectifs de l'approche 53 Mon alternance 55 Les étapes de L'intégration 56 Identification des assets et l'entrée des produits 57 Problématiques lors de mon alternance 57 L'entrée des produits 58 L'entrée des caractéristiques du produit 58 L'identification des assets du code source du produit. 59 L'unicité des Identifiants 60 Acquisition des artefacts 61 Les modèles de variabilité et leur extraction 64 Qu'est-ce qu'un modèle de variabilité ? 65 Comment peut t on extraire automatiquement la variabilité SPL et ses contraintes ? 67 FCA pour la variabilité 67 Le calcul de la variabilité dans notre Outils SLP generator 68 Création du contexte formel (PCM) à partir des assets 70 Extraction de la variabilité à partir du Treillis 71 La localisation des caractéristiques. 72 L'analyse de concepts formels (ACF) pour réaliser la localisation. 72 Conclusion et résultats préliminaires 74 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT Pensées et remerciements envers mes parents pour m'avoir soutenu tout au long de mes études. Merci à Laurent pour ses conseils avisés tout au long de l'année 2018-2019. 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT Mon alternance avait pour but dans un premier temps de participer à la maintenance d'une Ligne de Produits Logiciels (LPL) en tant qu'ingénieur informaticien, puis dans un second temps, d'automatiser les processus de création de LPL afin d'en faciliter d'adoption pour des entreprises clientes du groupe Accenture. Les Lignes de Produits Logiciels ont pour but
d'industrialiser la fabrication 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT INTRODUCTIONL'informatique L'essor de l'informatique au début du XXème siècle, puis d'internet à la fin du XXème siècle ont révolutionné notre quotidien et notre façon de vivre. En France, La transformation numérique a fait basculer les métiers de l'industrie vers le tertiaire et les services faisant accroitre de manière exponentielle le développement d'outils informatique. L'informatique, puis internet ont largement contribué à cette révolution. Cette digitalisation a permis entre autres d'automatiser des taches par des algorithmes en passant par des applications et logiciels. Aujourd'hui, l'informatique occupe une place immense dans notre quotidien. Les nouvelles technologies évoluent constamment chaque jour, cherchant toujours à automatiser ces processus de la vie courante. La demande croissante de nouveaux logiciels oblige les fabricants à accélérer le processus développement ainsi que des logiciels à plus grande échelle. Les programmes sont constitués de code et de données. Le code est la série d'instructions qui indiquent à l'ordinateur la tâche à accomplir ensuite et la manière dont il doit hiérarchiser les tâches. Les programmeurs utilisent ces instructions pour ordonner à l'ordinateur d'exécuter des tâches spécifiques, comme l'enregistrement de fichiers ou l'organisation d'images sur votre bureau ; ce sont les programmes, qui doivent être écrits dans un ou plusieurs langages de programmation. Ces logiciels ont pour but d'automatiser des taches souvent avec une interface graphique permettant à l'utilisateur d'interagir avec le logiciel. Un logiciel, parfois appelé programme, est un ensemble d'instructions qui indiquent à l'ordinateur ce qu'il doit faire. Ce type de programme peut être écrit dans un ou plusieurs 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT langages.
Gutenberg invents the reconfigurable printing press Vaucanson creates his automated Digesting Duck Jacquard invents an automated mechanism for the weaving loom using punched cards ElectricDog, the first robot Grace Hopper invents the first compiler Unimate, the first industrial robot Invention of the CD-ROM 104 ii The CERN invents the World Wide Web Sojourner robot ex® plores planet Mars 1,0 1 billion websites 0 0 Wikipedia is launched Julius Caesar encrypts his military messages 9 0 Al Khwarizmi explains the first algorithms Babbage creates the difference engine Ada Lovelace writes the first computer program
Zuse3 is the first computer
IBM invente la disquette
ARPANET, the ancestor of Internet, is launched DeepBlue, a computer, defeats chess champion Kasparov Honda-P2, one of the first humanoid robots 9 9. Aibo, one of the first entertainment robots a 9 Turing proposes a theoretical model of con-_. WIKIPEDIA TAeFrce.Er dop can. 10 Mai 2019
Dans le monde de l'entreprise la production de ces logiciels n'est pas adaptée pour les productions de masse, en effet chaque entreprise développe son propre logiciel sans possibilité de réutiliser du code déjà existant. Afin de maintenir un équilibre entre vitesse de production et qualité les entreprises ont du s'adapter et évoluer. L'émergence du génie logiciel est due à la nécessité de trouver des méthodes de conception, des outils et des paradigmes qui répondent aux besoins des fabricants, ainsi qu'aux besoins des informaticiens généralistes dans le but de fournir une aide aux développements des logiciels. 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT Les entreprises face aux défis de la réutilisation De plus les entreprises se confrontent à des problèmes de maintenances et d'évolutions des logiciels qui entrainent des pertes de temps et donc d'argent. En effet la maintenance et le support des applications, sont très chronophages pour les développeurs, qui sont parfois contraints de se relayer pour pouvoir assurer ce service en continue. Les développeurs dans les entreprises ne maitrisent pas forcement l'historique de l'ensemble des modifications et des améliorations acquises à travers le temps. Ils doivent parfois ainsi se plonger dans le logiciel parfois mal implémenté avant de pouvoir y apporter une modification. Ceci entraine une perte de temps considérable. La construction des logiciels est relativement statique au départ, une fois celui-ci développé et livré au client, toute maintenance requise et envisagée pour ces systèmes nécessite des modifications potentiellement importantes du code source existant. Ceci n'est plus acceptable pour les systèmes logiciels contemporains, car la complexité de la production et de la maintenance génère souvent des coûts qu'il faut prendre en compte. La réutilisation du code source est donc un point important qui peut aider les entreprises à accélérer le processus de développement maximiser la réutilisation dans un ensemble de produits logiciels créera un ensemble de Le logiciel est conçu autour de fonctionnalités communes. Pour les fabricants, cela offre des possibilités de conception Ce n'est plus un produit séparé, mais une série de produits. Ce changement L'échelle (passage d'un produit unique à une série de produits) leur permettra de produire plus L'important est que la quantité de logiciels augmente, mais cela améliore également la qualité et réduit les coûts. Les lignes de produits logiciels sont un outil permettant de répondre à ces problématiques. Les lignes de produits logiciels La « recherche » sur l'ingénierie des lignes de produits logiciels s'est avérée utile pour l'industrie notamment les petites et moyennes entreprise (PME). Mais elle reste largement peu utilisée dans les entreprises. L'objectif envisagé des LPL n'est plus d'obtenir un système logiciel unique, mais de partir de bases et caractéristiques communes pour développer et affiner les fonctionnalités du logiciel. En somme faire série de produits logiciels avec des caractéristiques communes. Mais garde cet ensemble. Les logiciels peuvent développer de manière laborieuse, et peuvent également engendrer des couts considérables pour les entreprises. 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 L'ingénierie les lignes de produits logiciels a rencontré de nombreux succès ces dernières années. Cependant, il est rapide de constater qu'encore peu d'entreprise du logiciels informatique (tous secteurs confondu) ont adopté le développement de LPL. Ce phénomène peut être expliqué par au moins plusieurs facteurs : la difficulté d'appliquer les trois approches d'adoptions existantes au contexte des PME couplée à une réticence à l'adoption de pratiques à risques dans l'entreprise. La réutilisation logiciel peut jouer un rôle crucial dans cette diminution du temps de développement. Intuitivement, nous observons chez les développeurs une tendance à la réutilisation, qui prend la forme de copié collé successif, depuis des logiciels déjà conçu vers ceux en cours de conception. A terme, cette pratique nommé Clone&Own en anglais, fait émerger des familles de logiciels, ce sont des logiciels qui partagent des caractéristiques communes. Cette pratique est toutefois chaotique, et peut parfois être plus couteuse que de commencer le projet de zéro De plus, elle fait émerger des familles de logiciels dont la maintenance doit être assurée de façon individuelle. C'est pourquoi il est préférable pour les entreprises de considérer l'utilisation de L'ingénierie des Lignes de Produits Logiciels (LPL) comme paradigme de développement pour leurs logiciels. L'objectif est de rendre la réutilisation systémique : les logiciels sont conçus par la réutilisation et pour la réutilisation. La conception d'une famille de logiciels partageant des caractéristiques communes. Pour cela, les lignes de produits logiciels reposent sur la réutilisation et la configuration en masse. De façon générale, l'adoption des LPL dans le processus de développement permet : une diminution des temps de développement ; une augmentation de la qualité des logiciels ; et une amélioration de la maintenabilité des logiciels Concevoir une série de produits à partir de zéro peut être compliquée, il y a de nombreux paramètres à prendre en compte comme le domaine d'activité, le domaine d'expertise du développeur, la technologie utilisée. La demande de nouveaux logiciels a suivi l'augmentation de la popularité des appareils informatiques tels que les ordinateurs personnels, les smartphones, les voitures, appareils Et avec cette augmentation de la demande, les logiciels sont devenus plus complexes à concevoir, nécessitant de plus en plus de temps et d'efforts pour les développeurs de plus en plus de temps et d'efforts de la part des développeurs. Le domaine du génie logiciel s'intéresse à la recherche de méthodologies et des techniques pour faciliter le développement d'un système logiciel. Par exemple, ces méthodes concernent l'amélioration de la qualité du logiciel, son accessibilité à la maintenance et à l'évolution dans le temps, ainsi qu'à la description de nouvelles approches pour faciliter son développement. Parmi ces méthodes, l'ingénierie des lignes de produits logiciels se concentre sur la conception de familles de logiciels de manière systématique. Une famille de logiciels est un ensemble de logiciels qui partage plusieurs fonctionnalités ou aspects RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 logiciels en commun. Le développement d'un logiciel standard permet de proposer une même solution globale pour l'ensemble des clients. Dans l'industrie, chaque utilisateur client accède à un logiciel contenant l'ensemble des fonctionnalités logicielles développées. Pour concevoir ce logiciel, l'entreprise s'adonne d'abord à une étude de marché pour déterminer les fonctionnalités logicielles les plus demandées. Puis, l'entreprise conçoit un logiciel qui implémente toutes ces fonctionnalités, par exemple la réservation, la création de comptes utilisateur ou encore un système de notation. Elle livre ensuite un seul et même logiciel à chacun des clients contenant l'ensemble des fonctionnalités. Le logiciel standard permet de n'avoir qu'un seul logiciel à maintenir par les développeurs. Avec le développement de logiciels individuels, une version du logiciel est conçue spécifiquement autour des besoins de chaque utilisateur. Dans l'entreprise cliente, celle-ci développe trois versions de son logiciel pour convenir aux besoins spécifiques de ses clients. Cette stratégie de développement permet de réduire les coûts des logiciels à proposer aux utilisateurs, et de faire un logiciel qui correspond mieux à leurs besoins. On obtient alors une famille de produits logiciels au sens défini par David Parnas (1976) : « Une famille de produits logiciels est un ensemble de logiciels partageant une certaine proximité dans leurs objectifs et qui disposent de suffisamment de similarité pour justifier d'une mutualisation de leurs concepts et leur maintenance. » Le problème est que ces logiciels sont à maintenir individuellement pour chaque utilisateur, ce qui augmente les coûts de maintenance. Prenons l'exemple d'une automobile. Une famille de logiciels peut être construite à partir des logiciels qui tournent sur l'ordinateur principal d'un constructeur automobile, puisque ces voitures sont toutes équipées d'un système d'exploitation. Mais elles peuvent se différencier par des caractéristiques spéciales (par exemple, climatisation intelligente, écran multimédia). La conception de cette famille peut être considérée Grace a l'ingénierie des lignes de produits logiciels. Les produits logiciels sont les logiciels qui font partie des familles, tandis que la conception de ligne la conception de la plateforme pour construire ces produits' idée principale des LPL est de construire des logiciels en réutilisant la plupart de leur mise en oeuvre (c'est-à-dire leur code source, la structure de données, les données, code source, la structure des données, la base de données et les ressources) pour concevoir les prochains logiciels nécessaires. La réutilisation est facilitée par le fait que la LPL encourage les développeurs à concevoir leurs logiciels autour d'éléments réutilisables. Par conséquent, la motivation de LPL est la suivante développement de logiciels pour la réutilisation et par la réutilisation. Ces éléments seront réutilisés à travers les divers logiciels, de façon à minimiser le temps et les coûts de développement de chacun des logiciels. Nous désignons ces éléments hétérogènes par le terme plus abstrait d'asset (ou artefacts). Des études ont estimé que les entreprises peuvent bénéficier d'un retour sur investissement positif avec les LPL dès le développement du troisième produits (par rapport au RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT développement d'un seul logiciel). Et pour le travail des développeurs, il y a une amélioration de la qualité du logiciel ; une réduction du délai de mise sur le marché du produit ; gain de temps et d'efforts pour tout nouveau logiciel en réutilisant les anciennes parties au lieu de redévelopper. L'idée étant de réutiliser les anciennes parties au lieu de les redévelopper. Cependant, l'adoption des LPL requiert des compétences spéciales pour maîtriser l'ingénierie d'un SPL, et de nombreux développeurs ne sont toujours pas formés pour celles-ci. Parmi elles, il y a l'ingénierie du domaine, l'identification des fonctionnalités et la gestion de la variabilité. Par conséquent, l'adoption des LPL comporte ses propres obstacles et présente des risques qui peuvent être trop élevés pour une entreprise. En somme, L'ingénierie des lignes de produits logiciels promeut une réutilisation logicielle à grande échelle lors du développement de nouveaux produits. Au cours du développement, les caractéristiques de la ligne sont réutilisées pour la conception de nouveaux logiciels, ce qui réduit considérablement ses coûts de conception. Le gain est également visible sur le temps de développement qui tend à diminuer grâce à la réutilisation., cette réduction des coûts est seulement visible sur le temps long Cet investissement permet la conception des artefacts réutilisables en amont du développement des produits.
10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT Lors de mon alternance, nous nous sommes concentrés sur la conception d'une nouvelle approche pour supprimer la barrière d'adoption à laquelle sont confrontés les développeurs. Notre fils rouge dans ce projet d'alternance était « Comment construire une approche automatisée d'adoption de Ligne de produit logiciel » Nous avons établi une liste d'objectifs intermédiaires à atteindre afin de définir notre approche. Tout d'abord, nous décrivons notre approche automatisée et établissons les exigences pour ce que les développeurs devront avoir, afin d'utiliser la LPL et d'adopter l'approche. Pour être, nous notons que les développeurs auront besoin que la LPL soit compatible avec leur environnement de travail puisque le changer représente le principal risque pour l'entreprise. Deuxièmement nous cherchons une approche d'automatisation qui construira la même LPL que ce que les développeurs auront fait manuellement. Enfin, nous voulons que la LPL résultante soit compréhensible pour les développeurs, afin que la maintenabilité et l'évolution soient possibles. Lors de mon travail tout au long de l'alternance, je me suis concentré sur la conception d'une structure de données et d'un algorithme adéquat qui nous permettront d'intégrer itérativement les données. Cela nous permettra d'intégrer itérativement de nouveaux produits à l'intérieur d'une SPL, sans avoir besoin de l'intervention des développeurs. Troisièmement, nous concevons et mettons en oeuvre une technique spécifique pour localiser la fonctionnalité à l'intérieur de la SPL. Et enfin, nous développons des techniques pour simplifier la compréhension de nos sorties SPL pour les développeurs. En suivant notre objectif, nous avons développé une nouvelle approche appelée « SPL Generator », et nous l'évaluons en utilisant différents cas préexistants. Nous L'évaluons en utilisant différentes études de cas préexistantes pour simuler la construction d'une SPL. 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT L'alternance Lors de cette année 2018/2019, j'ai eu l'honneur de faire mon alternance dans une petite entreprise cliente du groupe Accenture. Cette société s'occupe de la création et la maintenance de multiples logiciels pour des PME et autres sociétés. Ces logiciels peuvent être variés, l'entreprise possédant de nombreux clients très divers, d'où le possible nécessité d'avoir recours à des LPL. Les domaines d'activité sont surtout autour du numérique mais aussi de l'aviation ainsi que l'automobile. Dès mon intégration en Septembre 2018, j'ai eu l'occasion de travailler sur les lignes de produits logiciel au sein de l'entreprise et de participer à la maintenance des multiples outils pour le développement des différentes gammes de logiciel à la demande des clients. Outre la maintenance et le support quotidien des logiciels en production, j'ai pu participer à l'élaboration d'un outil d'automatisation de la génération des lignes de produits logiciels. Pour cela il a fallu effectuer une étude de l'art des différentes recherche industrielles sur lignes de produits pour pouvoir par la suite proposer une nouvelle approche innovante avec les équipes R&D et IT. La ligne directrice de mon alternance était, dans un premier temps, d'améliorer l'implémentation la ligne de produit et dans un second, de trouver un moyen d'automatiser l'intégration de nouvelles fonctionnalités dans cette ligne de produit logiciel. J'ai pu lors de mon alternance travailler avec différentes équipes : L'équipe IT, qui s'occupe du support des logiciels et du bon fonctionnement de la ligne de produit se compose d'une dizaine de personne, elle s'occupe de la maintenance et des évolutions des logiciels avec l'équipe commerciale et les maitrises d'ouvrages. L'équipe commerciale et les Maitres d'Ouvrages MOA : ces équipes sont au plus proches de l'environnement métier et dictent les projets ainsi que les nouvelles améliorations à intégrer dans les logiciels dans le but de satisfaire au mieux les attentes des clients. Ils prennent en compte les modification et changements du marché et ont une très bonne connaissance dans le domaine. L'équipe Recherche et Développement, principalement composés d'ingénieurs et de chercheurs en ingénierie, cette équipe effectue une veille des dernières études de recherche dans différent domaine (génie logiciel, IA...) Leur but est d'adapter les travaux de recherche existant à notre entreprise, mais aussi de faire de la recherche en trouvant de nouvelles solutions innovantes. Le but de mon alternance s'inscrivait dans l'optique de la création de l'outil « SPL Generator », un générateur automatique de ligne de produit logiciel qui prend en compte une automatisation complète de la réingénie de la ligne de produit. 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT Lors de mon alternance, j'ai donc pu être en lien permanant tout au long de l'année entre ces différentes équipes, cela m'a permis d'avoir une vision complète du fonctionnement des équipes présentes au sein d'une PME. Ce projet, considéré comme de la recherche industrielle, s'inscrit dans une approche innovante d'automatisation du processus de réingénierie des lignes de produit logiciel liant plusieurs domaine autour du génie logiciel. L'outil développé par mes soins « SPL_Generator » est le travail de 10 mois de recherche et d'implémentation,( 4 mois étude de l'art et découverte des LPL, 2 mois pour la proposition de la solution,3 mois pour la conception 1 mois de test). Ce fut la tâche majeure de mon alternance en plus du support quotidien des différents logiciel, et l'élaboration d'autres outils pour les équipes IT et R&D. Les autres outils développés en marge de mon alternance sont des applications qui permettent de déplacer des dossiers ou des fichiers a des heures précises et de faire tourner des processus permettant le bon fonctionnement des autres applications en production dans l'entreprise. « L'orchestre » 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT Le plan du mémoire d'alternance Le déroulement de ce mémoire d'alternance s'effectuera en plusieurs temps, en première partie nous expliquerons le fonctionnement des lignes de produits logiciel, leur adoption en entreprise, ainsi qu'une étude de l'art des lignes de produits logiciel, leur conception, les différentes approches, ainsi que les méthodes d'ingénierie existantes qui seront utile à notre approche innovante de réingénierie SPL_Generator. La deuxième partie sera consacrée à l'outil SPL Generator, les diverses étapes de la conception, les méthodes utilisées pour l'automatisation du processus de réingénie, l'intégration des produits, l'identification des assets, la gestion de la variabilité de la LPL et la localisation des caractéristiques. Enfin nous dresserons une conclusion avec les premiers résultats de notre application sur des cas concrets ainsi que sur les gammes de logiciels de l'entreprise. 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 LE BUT Comme entrevu précédemment, l'émergence de nouveaux besoins numériques, comme ceux qui accompagnent l'usage des téléphones mobiles ou des ordinateurs personnels, nos sociétés produisent davantage de logiciels et à grande échelle. La recherche menée au sein du génie logiciel définit des méthodes et des techniques destinées à accompagner les ingénieurs dans la conception de ces logiciels. En particulier, le génie logiciel s'intéresse à l'amélioration des pratiques de conception, de maintenance, et d'évolution des logiciels. Parmi les nombreux défis du génie logiciel se pose la question de la diminution des coûts de production et du temps de conception des logiciels. En guise de solution, le génie logiciel recherche de nouvelles méthodes de conception basées sur la réutilisation des logiciels. La réutilisation logicielle systématique vise à concevoir des éléments logiciels réutilisables et à développer de nouveaux logiciels grâce à ces mêmes éléments. On parle généralement de développement pour la réutilisation et de développement par la réutilisation. Grâce à la réutilisation, les ingénieurs peuvent réduire le temps de développement en réutilisant des artefacts déjà conçus. Ils améliorent également la qualité des logiciels puisqu'ils réemploient des artefacts déjà éprouvés. En somme, la réutilisation permet de diminuer les coûts de production en diminuant le temps de développement des logiciels. L'objectif est de Définir une nouvelle approche réactive adaptée au contexte de développement de logiciels des PME. En étudiant les approches d'adoption existante, il n'apparait clairement qu'aucune n'est vraiment adaptée au contexte particulier des PME. Cependant, l'approche réactive semble être la plus proche de leur contexte, mais la difficulté de sa mise en oeuvre reste un obstacle majeur Nous verrons dans la prochaine partie en quoi L'ingénierie des lignes de produits logiciels est un paradigme de développement de familles de logiciels similaires basé sur le principe de la réutilisation systématique des artefacts. La ligne de produits logiciels permet de capturer et de factoriser dans une plateforme configurable l'ensemble des artefacts communs à une même famille de logiciels. Pour le reste des artefacts, spécifiques aux différents logiciels, la LPL capture dans sa plateforme la variabilité sous la forme d'un ensemble d'artefacts optionnels. La production de nouveaux logiciels se matérialise par une sélection méthodique des artefacts à réutiliser, où sont sélectionnés d'office les artefacts communs ; tandis que les RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 artefacts optionnels sont sélectionnés de façon à personnaliser le nouveau produit selon les besoins exprimés par ses concepteurs. Cette réutilisation systématique, qui est organisée au travers d'une sélection d'artefacts préexistants, permet de réduire les coûts de production des logiciels, comparativement à un développement individuel. C'est pour cela que nous proposons l'application de processus automatique pour réaliser l'ingénierie d'application de la Ligne de produit logiciel (LPL) afin d'en réduire ses coûts. Pour cela, notre approche réalisera automatiquement la construction de la plateforme variable, de modèles de variabilités, et des processus de gestion et d'évolution de la variabilité. De plus, notre outil devra effectuer automatiquement la génération des produits depuis la plateforme, dès lors que les développeurs fournissent une configuration hypothèse est que retirer l'effort lié à cette ingénierie permettra une meilleure adoption des LPL. Dans le but d'inciter peut-être plus d'entreprises à construire une LPL, puisque les risques liés aux coûts d'ingénierie se retrouvent réduit par une automatisation des tâches. La réduction des couts de développement Les avantages et bénéfices de l'adoption de l'ingénierie des LPL se mesurent par comparaison avec un développement "traditionnel" L'ingénierie des lignes de produits logiciels promeut une réutilisation logicielle à grande échelle lors du développement de nouveaux produits. Au cours du développement, les artefacts de la ligne sont réutilisés pour la conception de nouveaux logiciels, ce qui réduit ses coûts de conception. Le gain est également visible sur le temps de développement qui tend à diminuer grâce à la réutilisation (c'est d'ailleurs la principale cause de réduction des coûts). Cependant, cette réduction des coûts est seulement visible sur le temps long : des coûts survient à partir du troisième produit développé grâce à la ligne de produits comparativement aux coûts de développement produit par produit. De plus, la réduction des coûts nécessite un investissement initial conséquent. Cet investissement permet la conception des artefacts réutilisables en amont du développement des produits. Réduction du délai de mise sur le marché des logiciels Comme nous l'avons mentionné pour la réduction des coûts, l'application de cette ingénierie permet de réduire les temps de développement de nouveaux produits. Cette réduction de temps améliore les délais de mise sur le marché ou de livraison des produits logiciels. Il en découle des retours sur investissement plus rapides pour les entreprises, à condition là encore de concevoir les artefacts en amont RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT Réduction des efforts de maintenabilité des logiciels. À travers la plateforme configurable d'une LPL, la maintenance d'un artefact se propage virtuellement à tous les produits où cet artefact est implémenté. La plateforme supprime la nécessité de maintenir individuellement chaque produit et permet de factoriser les opérations de maintenance. À terme, cela permet de réduire l'effort de maintenance. De plus, la maintenance peut se faire sans connaître et maîtriser l'intégralité des implémentations des produits, ce qui réduit l'effort de compréhension Amélioration de la qualité des logiciels La réutilisation logicielle impacte également la qualité des produits développés. En effet, les artefacts d'une LPL sont réutilisés et testés à travers les différents produits générés. À force de réutilisation, ces artefacts sont maintenus par les développeurs et ont donc plus de chances d'être corrigés ou améliorés que le code non réutilisé. Cette réutilisation permet ainsi de mieux détecter les erreurs de conception et de les corriger, ce qui augmente la qualité des produits d'une LPL L'emploi de la plateforme configurable permet également d'améliorer la qualité des logiciels de la ligne, car elle regroupe les opérations de maintenance. 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT Etat de l'art et prérequis La ligne de produit logiciel L'ingénierie des lignes de produits logiciels permet la conception d'un ensemble de produits logiciels partageant des caractéristiques communes, elles diffèrent cependant par l'implémentation de caractéristiques spécifiques. Prenons l'exemple d'une gamme d'imprimantes d'un même constructeur : Les logiciels embarqués dans ces imprimantes vont partager des fonctionnalités, comme celle de l'impression en couleur ou en noir et blanc. Mais certaines vont proposer des fonctionnalités supplémentaires et spécifiques, comme l'impression recto-verso, sur papier photo, ou encore un mode scanners de documents. L'ingénierie des Lignes de Produits Logiciels (LPL) vise donc à regrouper des méthodes pour concevoir une famille de produits logiciels comme une ligne de produits logiciels. Ses objectifs se focalisent sur la réduction des coûts de développement, le raccourcissement des temps de livraison, l'amélioration de la qualité des logiciels et la réduction des efforts de maintenance. Dans cette section, nous présentons les différentes notions et concepts qui forment l'ingénierie des LPL. Les caractéristiques logicielles peuvent être définies de plusieurs façon. Souvent, nous les désignons comme des fonctionnalités logicielles de haut niveau, perçu par l'utilisateur. Il s'agit de caractéristique utilisation. Cependant, certaines caractéristiques peuvent être invisible pour l'utilisateur. Nous parlons dans ce cas de caractéristiques métier comme par exemple l'usage d'un protocole de communication, UDP ou TCP entre l'imprimante et l'ordinateur client. Enfin, une caractéristique dépend principalement du domaine d'activité pour lequel le logiciel se destine. C'est pourquoi il est possible de décrire un logiciel de la ligne par les caractéristiques qu'il implémente. Cela nous permet de définir pour chaque logiciel une configuration, un ensemble caractéristique que présente dans un produit logiciel particulier. Puisque les logiciels sont tous différents, et qu'ils sont construit depuis un même ensemble caractéristique, nous retrouvons dans une LPL des caractéristiques communes à tous les logiciels. 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT
10 Mai 2019 L'implémentation des différentes caractéristiques est réalisée par un ensemble de divers éléments logiciels. Il s'agit essentiellement de code source, mais également de ressources comme du texte, des images, des scripts, des modules. Comme les caractéristiques qu'ils implémentent, un artefact peut être commun ou spécifique. C'est donc par l'intermédiaire des artefacts que la variabilité va être exprimé dans l'implémentation d'une LPL.
Plutôt que de concevoir séparément des logiciels différents, les LPLs proposent de les concevoir par une réutilisation systémique, en préservant une forte personnalisation des différents logiciels. L'objectif de l'ingénierie d'une LPL est de concevoir une implémentation logicielle partagée par l'ensemble des logiciels de la ligne. Cette implémentation de la LPL regroupe les points communs entre tous les logiciels, ce qui représente un ensemble d'artefacts invariables. RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT Elle comprend également les parties spécifiques aux produits, représentant l'ensemble des artefacts variables. Cette implémentation est en capacité de varier, ce qui permet la génération des différents produits. Pour cela, on y ajoute des mécanismes de variabilité, comme par exemple des annotations de pré-processing; ou des mécanismes basés sur le paradigme de composition de caractéristiques.
L'ingénierie des LPL intègre la réutilisation de logiciel en deux temps. Le développement pour la réutilisation des artefacts se réalise au travers d'un processus dédié appelé l'ingénierie du domaine Dans ce processus, les artefacts relatifs à un domaine métier choisi sont identifiés, spécifiés et organisés pour former les parties communes et la variabilité des différents produits de la LPL. Quant au développement avec réutilisation, un second processus appelé l'ingénierie d'application est dédié à la production des produits. L'ingénierie des LPL encourage l'application d'opérations de dérivation depuis la plateforme, pour sélectionner et intégrer les artefacts du domaine dans l'ingénierie du produit. 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT Ingénierie du domaine et ingénierie d'application L'ingénierie du domaine est un processus d'analyse et de conception situé en amont du développement des produits d'une LPL. En fonction d'un domaine métier particulier (réservation, santé, automobile, aviation...), ce processus a pour objectif d'identifier tous les artefacts réutilisables et partagés par les produits de la future LPL. On parle généralement de l'ingénierie du domaine comme celle de l'ingénierie pour la réutilisation. Analyse du domaine L'ingénierie du domaine doit avant tout définir et focaliser le champ couvert par la LPL, en le réduisant à un domaine métier particulier. Ce choix est fait pour des raisons économiques et permet de restreindre le développement à des artefacts dont les développeurs pourront maximiser la réutilisation dans les produits ou à ceux qui répondent le mieux aux besoins identifiés par les clients. En d'autres termes, cela permet d'éviter le développement d'artefacts inutiles aux produits de la ligne (gain de temps et d'effort d'ingénierie). L'objectif de l'analyse du domaine est donc de définir et documenter les fonctionnalités et les comportements logiciels communs ou spécifiques aux produits de la LPL. Cette étape permet notamment de concevoir les modèles de variabilité de la LPL, souvent basée sur les fonctionnalités communes et spécifiques, identifiées pour les produits. Conception du domaine. Cette seconde étape s'appuie sur les connaissances acquises lors de l'analyse du domaine pour concevoir l'architecture générale de la plateforme configurable. À partir des modèles de variabilité, les concepteurs décident des points de variation dans l'architecture de la plateforme. Les modèles de variabilité peuvent être corrigés ou raffinés pour mieux correspondre à l'architecture générale de la plateforme et donc de la LPL. Réalisation du domaine Enfin, les concepteurs concrétisent l'architecture définie précédemment dans une plateforme logicielle, composée de l'ensemble des artefacts réutilisables du domaine. La plateforme doit structurer les artefacts et les associer aux points de variation, afin de permettre la personnalisation de masse des produits. Cette personnalisation est faite à travers une sélection des fonctionnalités ou des comportements spécifiques que l'on souhaite avoir dans un produit ;Quant aux modèles de variabilité, ils permettent de rendre compte des combinaisons d'artefacts envisagés. Ces combinaisons définiront les différents produits d'une ligne. 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT Ingénierie d'application L'ingénierie d'application vise à construire les produits de la ligne depuis le résultat de l'ingénierie du domaine. Ce second processus est donc un développement par la réutilisation. L'ingénierie d'application présente souvent deux phases distinctes : la configuration des produits et la génération des produits parfois appelée dérivation de produits dans la littérature. Configuration des produits. Les configurations des produits doivent respecter les contraintes métiers entre les artefacts, Par exemple. si deux fonctionnalités ont été définies comme mutuellement exclusives, alors elles ne peuvent pas apparaître dans le même produit. Des allers-retours sont parfois nécessaires entre l'ingénierie du domaine et celle d'application, afin de compléter l'analyse du domaine, car l'expertise des spécifications des produits peut révéler de nouveaux besoins. Génération des produits Dans un second temps, la génération du code des produits est réalisée à partir de la configuration du produit et de la plateforme. Les artefacts sélectionnés dans la configuration sont assemblés suivant une structure donnée par la plateforme, afin de former correctement le code source du produit. La génération du produit est souvent une étape automatique. Le produit généré est ensuite testé, ce qui permet là encore des allers-retours avec l'ingénierie du domaine (correction, modification, ajout de fonctionnalité, etc.). Les produits peuvent ensuite être livrés aux clients. 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 Les approches de conceptions traditionnelles Le développement from scratch L'approche from scratch signifie simplement commencer à coder un projet à partir de zéro. Quel que soit le domaine métier du projet, le développeur va se lancer dans le développement sans l'utilisation de framework, librairie ou template. Ce développement radical est toutefois de moins en moins utilisé puisque de nombreuses librairies ou code source sont aujourd'hui déjà disponibles en ligne. Mais on peut aussi parler de développement from scratch de façon plus générale lorsqu'on début avec peu d'assistance d'outils déjà existants. Le clone and own L'approche Clone and Own contraste particulièrement avec l'approche from scratch puisqu'elle consiste à partir du code d'un projet existant, et de le cloner pour coder le projet suivant. Cette pratique est très souvent utilisée dans l'industrie et chez les développeurs en général. Elle apparaît surtout lorsque le nouveau projet partage un grand nombre de similarités avec un projet déjà existant. Cela nécessite toutefois une grande connaissance du code existant pour être le plus efficace possible. Beaucoup de temps est souvent consacré à l'appropriation du code ou au nettoyage des parties inutiles du code. Mais cette technique peut être très complexe à mettre en place, car elle dépend trop de la qualité du code existant. Le répertoire commun Le répertoire commun est une approche qu'on trouve principalement à l'échelle d'une équipe de développement. Ce répertoire spécialement créé pour les projets de l'entreprise va contenir les codes sources, schémas, documents et devis client, ressources graphiques, relatives aux différents projets. Ce dossier est souvent volumineux et sa hiérarchie le rend peu pratique lorsque l'on veut y rechercher un élément pour le réutiliser. Et une fois un élément trouvé, il faudra encore l'adapter pour le faire convenir aux besoins du nouveau projet. Cette pratique peut être vu comme une façon ad hoc de réutiliser les éléments du projet. Nous venons de le voir, les approches classiques souffrent de beaucoup de défauts, mais elles démontrent aussi une volonté de vouloir réutiliser un maximum le code ou les artefacts déjà créés. C'est ce constat qui poussa à la création d'un outil généralisant la réutilisation intelligente et pertinente du code et des autres artefacts des projets. Les lignes de produits logiciels vont offrir un environnement qui encourage le développement pour la réutilisation. Plutôt que de coder pour un seul produit, il est désormais possible de coder pour un RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT ensemble de produits qui partageront des caractéristiques communes, mais qui auront surtout des caractéristiques variables. 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 Les approches fondamentales pour les LPL Indéniablement, les lignes de produits logiciels ont montré leur potentiel industriel. Toutefois, nous pouvons encore déplorer le manque d'adoption à grande échelle de cette ingénierie, car rares sont les industriels à s'être emparés de cette ingénierie dans leur processus de développement quotidien. Pour comprendre ce constat, nous commençons par introduire les différentes stratégies d'adoption de l'ingénierie des lignes de produits. Pour la conception d'une LPL il existe 3 approches fondamentales : L'approche Proactive La stratégie proactive est la stratégie conventionnelle où sont réalisées dans l'ordre l'ingénierie du domaine puis l'ingénierie d'application. En réalisant l'ingénierie du domaine en premier, les développeurs s'assurent d'avoir fait une analyse approfondie des artefacts réutilisables du domaine L'investissement initial de cette phase est coûteux et représente donc un risque. Toutefois, il s'avère rentable une fois l'ingénierie d'application amorcée et le retour sur investissement apparaît dès le troisième produit Cette stratégie se destine donc davantage à des entreprises qui disposent d'une expertise dans un domaine précis, ou qui disposent des ressources nécessaires pour financer l'investissement initial L'approche proactive est un processus Top-Down basé sur une analyse approfondie du domaine d'activité de la ligne de produit pour identifier et construire tous ses éléments. L'approche Proactive est souvent décrite en deux phases principales : l'ingénierie du domaine, et l'ingénierie de l'application. Comme vu précédemment dans la partie précédente, L'ingénierie du domaine est une phase dont l'objectif est de s'approprier en profondeur un domaine métier particulier (e.g. le e-commerce, la réservation hôtelière, l'impression, etc.), pour en faire ressortir les cas d'utilisations ou besoins métiers du domaine. Ces cas et besoins vont être décris sous la forme d'exigences logicielles, et vont donner naissance aux différentes caractéristiques de la LPL. Les développeurs d'une LPL tirent de cette analyse l'ensemble de caractéristiques logicielles distinctes et réutilisables. L'enjeu est ici de découvrir un maximum des caractéristiques, et d'évaluer l'intérêt de chacune d'entre elles à être implémentées dans la LPL finale, afin de rester dans des coûts de productions rentable pour l'entreprise. L'ingénierie du domaine permet donc aux développeurs de déterminer la variabilité du domaine. Cette variabilité s'applique aux différentes caractéristiques découvertes et les développeurs ont pour objectifs d'obtenir les relations qui existent entre ces caractéristiques. Par exemple, ils doivent s'interroger des conditions d'utilisation d'une caractéristique particulière dans un produit (e.g. est-il possible d'imprimer en couleur sans pouvoir imprimer en noir et blanc ? Cette conception de la variabilité s'accompagne de la réalisation de modèles de variabilité, comme des modèles de caractéristiques Pour finir, l'ingénierie du domaine permet aux développeurs de définir l'architecture RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 logicielle de leur LPL, en tenant compte des caractéristiques et de la variabilité précédemment obtenus.
L'ingénierie d'application est la seconde phase, celle-ci se consacre au développement de la LPL. Son but est de réaliser l'implémentation de la LPL et ses produits à partir de l'architecture et des caractéristiques définis lors de l'ingénierie du domaine. La structure de la LPL regroupe toutes les implémentations des différentes caractéristiques, c'est à dire leurs implémentations par un ensemble d'artefacts. L'implémentation SPL contient également les mécanismes de la variabilité de la SPL, qui lui permettent de varier pour former les différents produits. C'est donc depuis cette implémentation que les développeurs vont faire émerger les différents produits de la LPL. Pour cela, les développeurs définissent des configurations de produits, lesquelles décrivent les caractéristiques présentent dans le produit. Pour obtenir un produit, un moteur de génération vient, le plus souvent automatiquement, générer le produit à partir de l'implémentation de la LPL en y appliquant la configuration du produit. L'ingénierie d'application se termine par le test des différents produits ou des différentes caractéristiques. En fonction des tests, il est possible de faire des allers-retours avec la phase d'ingénierie du domaine, afin de corriger d'éventuels problèmes de conception Avantages et Inconvénients L'approche Proactive comporte plusieurs avantages. D'une part, son ingénierie (domaine et application) permet d'obtenir une couverte maximale du domaine d'activité de la LPL. Ainsi, le risque d'absence d'implémentation de caractéristiques essentiels à un domaine est minimisé. D'autre part, la réalisation de l'ensemble des constituants de la LPL par les développeurs, - comme les caractéristiques, l'implémentations de la LPL, ainsi que les modèles de variabilités et produits-, leurs offre une maîtrise de la maintenabilité et de l'évolution de leur ligne de produits. Les développeurs savent donc comment sont implémentées les caractéristiques et connaissent les mécanismes de variabilités mis en oeuvre pour construire les produits. Cependant, en pratique cette approche est difficile à mettre en place dans les entreprises. Tout d'abord, s'il existe des IDE pour assister les développeurs, le travail d'ingénierie de la RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT LPL reste essentiellement manuel. Cette ingénierie étant différente de celle d'une conception traditionnelle de logiciels, la première difficulté est de trouver des développeurs compétents pour mener à bien cette approche, et notamment l'ingénierie du domaine. Cette phase est la plus risqué des deux, car elle nécessite des compétences d'analyse du domaine, de gestion de la variabilité et de construction d'architecture. Il est donc important d'anticiper et de couvrir le plus de caractéristiques possibles, afin d'éviter les allers-retours avec l'ingénierie du domaine et d'application. Ainsi l'ingénierie du domaine est inadaptée pour les entreprises qui sont dans l'incapacité d'anticiper les besoins de leurs produits. 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 L'approche Extractive La stratégie extractive est une adoption par rétro-ingénierie, où une famille de produits préexistante est transformée en une ligne de produits logiciels Cette stratégie permet de tirer profit du développement déjà éprouvé des produits. La LPL est construite par extraction, c.-à-d. qu'on vient identifier les artefacts communs et variables des produits pour concevoir la LPL. L'avantage de cette stratégie est son potentiel d'automatisation, et des travaux se sont déjà employés à proposer des mécanismes d'extraction outillés. Si elle est outillée, le coût d'investissement destiné à la transformation peut être largement réduit, en fonction cependant du degré d'automatisation proposé par l'outil. La stratégie extractive se destine donc à des entreprises qui disposent de famille de produits gérés individuellement et qui souhaitent bénéficier des LPL pour réduire leurs efforts de maintenance, d'évolution et de production de nouveaux produits L'approche extractive est un processus Bottom-Up d'extraction des constituants d'une LPL à partir d'un ensemble déjà préexistant produits. Il s'agit donc d'une réingénierie d'une famille de produits vers ligne de produit. Dans le papier « Empirical Software Engineering » (2017) cette réingénierie doit s'articuler selon trois phases génériques : la détection, l'analyse et la transformation. La phase de détection débute le processus d'extraction. Elle se consacre à la récupération de la variabilité des différents produits, en l'étudiant au travers des artefacts des produits. L'objectif est donc étant de différencier les artefacts communs à l'ensemble des produits, des artefacts spécifiques à seulement quelques-uns d'entre eux. La détection s'accompagne souvent d'une localisation de l'implémentation des caractéristiques (ou feature location en anglais), qui permet de rétroactivement faire l'ingénierie du domaine de la ligne de produits La phase d'analyse s'appuie sur la variabilité acquise lors de la détection pour construire les modèles de variabilités de la LPL. Ces modèles prennent le plus souvent la forme de modèle de caractéristiques (ou feature-model en anglais) Enfin, la phase Transformation construit une implémentation pour la LPL qui respecte la variabilité détectée et qui structure l'ensemble des artefacts. Avantages et Inconvénients : Les avantages de l'extraction pour la construction d'une LPL sont multiples. Premièrement, les constituants de la SPL peuvent être récupérés automatiquement (par exemple : les artefacts, les fonctionnalités, le Feature-Model) en analysant les codes sources et autres artefacts associés à ces produits (par exemple les exigences logicielles, le manuel utilisateur, RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 les documents de conception...). Par conséquent, ce processus est généralement automatique, ce qui rend le coût de réingénierie des produits vers la LPL relativement faible. L'automatisation rend cette approche rapide à déployer, et sans risques particuliers pour les entreprises. Cependant, il est à noter que la réalisation et le fonctionnement de ce type d'approche repose sur plusieurs hypothèses dans le code informatique utilisé par les développeurs. Les produits préexistants ont été construit de façon ad hoc, c'est-à-dire que les développeurs ont réutilisé des portions des produits les plus anciens pour créer les plus récents. On retrouve ainsi des portions de codes communes, et le plus souvent une architecture commune à tous ces produits. Le source code des produits est disponibles et est utilisé pour l'analyse la réingénierie. Ainsi, le principal obstacle à l'adoption de cette approche réside dans la disponibilité d'un large ensemble de variants de produits préexistant, développés de manière ad hoc, et suffisant pour couvrir le plus de caractéristiques d'un même domaine d'activité. Si l'ensemble des produits est insuffisant, la réingénierie automatique devra logiquement être complétée manuellement : ce qui augmentera les coûts, et diminuera l'intérêt de l'approche. Il est évident que de nombreuses entreprises ne remplissent pas ces conditions comme les TPE PME. En plus de cette limitation, les travaux existants appliquant une approche extractive se limite à proposer une implémentation fermée de la LPL, très difficile à y analyser (en boîte noir). Ils destinent souvent la LPL extraite à être utilisée par des gestionnaires de produits s'en servent comme d'un inventaire de leurs produits, plutôt que par des développeurs. Ces derniers devant maintenir et faire évoluer une LPL, si nécessaire. Selon la première loi de l'évolution des logiciels de Lehmann - qui stipule que tout logiciel qui n'évolue pas meurt -, l'implémentation fermé de la LPL, a donc un impact négatif sur sa longévité. Cela rend également impossible le fait de compléter manuellement la LPL une fois extraite. Par conséquence, l'approche extractive se révèle intéressante pour une utilisation par un gestionnaires de produits, et pour des entreprises type éditeurs de logiciels, qui souhaitent migrer un ensemble de logiciels gérés individuellement, vers une ligne de produits logiciels. L'approche Réactive La stratégie réactive propose une construction de la LPL par itération, en fonction des besoins Contrairement à la stratégie proactive, les ingénieries du domaine et d'application sont réalisées de façon partielle à chaque itération, de sorte à ne couvrir que les artefacts nécessaires à la production d'un nouveau produit. Cette stratégie permet de répartir l'investissement initial sur plusieurs itérations. La prise de risque est donc réduite, car les produits conçus à chaque itération peuvent être livrés sans délai, ce qui accélère la rentabilité de chaque investissement. Cet avantage est contrebalancé par les difficultés liées à la réingénierie itérative de la LPL. Contrairement à la proactive, chaque itération demande de reprendre l'ingénierie du domaine et d'application, afin d'intégrer à la LPL de nouvelles RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT exigences. Cette stratégie s'adapte au contexte de développement des entreprises qui ne sont pas en mesure de prévoir les exigences de leur LPL. Elle s'adapte aussi aux sociétés ayant à effectuer des cycles de développements occasionnels, ou ne disposant pas des ressources pour adopter une stratégie proactive. L'approche réactive ressemble à l'approche proactive mais elle fonctionne de manière itérative, l'approche se fait de manière plus locale par des petite analyse afin de détecter le minimum d'un nouveau produit L'approche réactive peut être décrite comme un processus itératif afin de construire graduellement une LPL. Plutôt que de concevoir une LPL entière en une seule itération, l'approche réactive répartit l'investissement dans la LPL sur le long terme. La construction de la ligne est motivée par l'apparition de nouvelles exigences pour de nouveaux produits, et donc de nouvelles caractéristiques à inclure dans la LPL. L'arrivée occasionnelle de nouvelles exigences est donc un moteur opportuniste de construction pour la ligne de produit. Cette approche est comparable à un processus de développement logiciel dit traditionnel Dans les deux cas, les développeurs doivent concevoir leurs nouveaux produits à partir des exigences (c'est-à-dire la description d'un nouveau produit formulé par un client). L'approche réactive remplace le fastidieux clone&own que l'on a présenté précédemment. Comme cette approche se concentre principalement sur la livraison de nouveaux produits, elle profite aux entreprises travaillant sur des logiciels sur mesure, qui recherchent un retour sur investissement rapide de leur SPL, ou aux entreprises dont les contours sont encore incertains Avantages et Inconvénients : L'approche réactive apparait comme une approche ayant un potentiel industriel important, du fait sa répartition des coûts d'investissement et son aspect itératif (qui permet d'interrompre la construction à tout moment). Cependant, d'autres études rapportent que l'approche réactive souffre encore de difficultés majeures liées à la réingénierie itérative de la LPL. En effet, le problème est que l'intégration de nouvelles exigences est difficile et nécessite une expertise liée au domaine métier et au domaine technique. Il s'agit d'identifier toutes les fonctionnalités déjà implémentées dans la LPL, les nouvelles fonctionnalités destinées à un nouveau produit, et la relation de variabilité entre elles. Pour l'expertise technique, qui est le rôle des développeurs, il s'agit de modifier l'implémentation existante de la LPL afin d'intégrer les artefacts des nouvelles fonctionnalités requises sans mettre en péril la capacité de la LPL à régénérer ses anciens produits. Comme son ensemble de produits augmente avec le temps, une LPL devient plus complexe à réingénier avec plus de fonctionnalités, plus d'interactions entre les fonctionnalités et une variabilité plus riche. De plus, les développeurs doivent mesurer soigneusement les impacts de leurs choix d'implémentation, car ils peuvent avoir un effet imprévisible sur les itérations suivantes. Dans certains cas, l'effort de réingénierie, et donc son coût, peut être si élevé qu'il devient un risque pour l'entreprise. Par conséquent, cette difficulté à construire et à faire évoluer manuellement un SPL est considérée comme le principal obstacle à l'adoption généralisée de l'approche réactive 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT En résumé : L'adoption de l'ingénierie de lignes de produits propose trois stratégies : proactive, extractive et réactive. La stratégie proactive conçoit l'ingénierie de haut en bas, de l'ingénierie du domaine à l'ingénierie d'application. Cette stratégie est coûteuse et risquée, mais qui permet de construire la LPL en une fois. Elle se destine aux entreprises capables d'en assurer les coûts ou aux éditeurs de logiciels capables de maîtriser les spécificités d'un domaine d'activité particulier. La stratégie extractive est une ingénierie rétroactive, de bas en haut. Elle propose de transformer une famille de produits préexistante en une ligne de produits logiciels. Par conséquent, son adoption est restreinte aux entreprises disposant d'une famille de produits préexistante. Cette stratégie dispose d'un fort potentiel d'automatisation, comme l'ont montré les travaux relatifs à son automatisation. Enfin l'approche réactive étant une version itérative de l'approche proactive, qui dilue l'investissement initial et l'ingénierie de la LPL au fur et à mesure de l'apparition de besoins pour de nouveaux produits. Si l'ingénierie par itération est sa principale qualité, elle oblige cependant à faire la réingénierie manuelle de la LPL à chaque itération. Cette réingénierie est complexe et peut engendrer plus de coûts qu'une approche proactive. En conclusion, nous constatons que ces stratégies souffrent toutes de limitations, et ne peuvent être adoptées par tous types d'entreprises. Pour les stratégies proactive et réactive, les problèmes sont liés à une ingénierie manuelle complexe ; et les tentatives d'automatisation notamment lié à l'extractif se montrent finalement incomplètes.
Figure 1: Voici un exemple 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 Quelle approche adaptée aux PME ? Les exigences d'une PME vis-à-vis de l'automatisation des LPL s'articule autour de 3 points fondamentaux : La facilité de manipulation par des développeurs, l'automatisation par l'intégration de nouveaux produits et enfin l'évolution dans le temps de la LPL. Nous avons vu qu'il existait trois approches pour l'adoption des lignes de produits logiciels. Parmi elles, les approches proactives et extractives s'adaptent difficilement aux PME : la première demande un coût d'investissement initiale trop important et son cycle de développement est inadéquat avec celui des PME (développement à la demande) ; La seconde repose sur l'utilisation de produits préexistant pour construire la ligne, ce qui est rarement le cas des PME. Mais surtout, l'approche extractive n'envisage pas l'évolution de la LPL une fois l'extraction réalisée. La dernière approche d'adoption, dite réactive, s'adapte mieux au rythme de développement des PME, car elle propose un développement opportuniste de la LPL, en fonction du besoin de créations de nouveaux logiciels. Cependant, cette approche demande des compétences en ingénierie des LPL, souvent absente chez les développeurs (analyse du domaine, application du domaine, compréhension et gestion de la variabilité). Et malgré cela, sans doute la plus difficile des trois à maitriser, du fait de la réingénierie de la LPL qu'elle impose à chaque création de nouveaux produits. En plus des problèmes propres aux approches d'adoption, la mise en oeuvre des LPL est freinée par une réticence aux changements des pratiques de développement, établis dans les entreprises. En effet, imposer de nouvelles pratiques de développements est complexe, quelques soient l'entreprise. Cela implique souvent des restructurations d'équipes de développeurs, l'acquisition de nouvelles compétences (par la formation ou le recrutement de développeurs), et autres changements dans le processus de production des logiciels. Mais cela l'est sans doute d'avantage chez les PME, car elles ont construit des pratiques de développements efficaces, pour répondre aux contraintes fortes de temps auxquelles elles font face. Par ailleurs, l'adoption et la mise en oeuvre des LPL comprend deux grands défis : d'une part elle oblige souvent les entreprises à repenser et transformer leurs pratiques de développement afin d'être correctement adoptée D'autre part, les bénéfices des LPL sont visibles sur le long terme. Leur retour sur investissement arrive souvent après le développement du troisième produit issue de la LPL Face à aux défis que représente l'adoption, les entreprises perçoivent souvent l'adoption des LPL comme un risque, plutôt que comme un avantage stratégique. Dans ce contexte particulier des PME, l'adoption des LPL est complexe, compte tenu des par les problèmes rencontrés dans les approches d'adoption existantes, et du fait de leurs réticences l'adoption de nouvelles pratiquement de développement. RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT L'approche réactive apparait donc comme la plus adaptée au contexte des petites et moyenne entreprises Cependant cette approche possède des mauvais côtés que nous allons étudier en profondeur pour pouvoir, peut-être, résoudre par une automatisation de certains processus afin de la rendre acceptable dans le cadre des PME Dans l'approche réactive, l'ajout de nouvelles caractéristiques (ou leurs évolutions pour répondre aux spécifications d'un nouveau produits), peut avoir des répercussions sur le fonctionnement de produits préexistants dans la LPL. Ainsi, la première difficulté pour les développeurs est de s'assurer que leur réingénierie ne compromette pas l'intégrité des caractéristiques, et donc des produits, préexistants. Deuxièmement, il ressort d'études sur la mise en pratique de l'approche réactive, que cette phase peut être simplifié ou complexifié par les choix pris par les développeurs lors des réingénieries précédente. Plus l'implémentation est facile à maintenir, plus il sera facile d'y intégrer le nouveau produit. Pour faciliter cette maintenabilité, il est nécessaire que les développeurs face preuve d'une capacité à anticiper de potentiels ajouts dans leur implémentation. Or, cette anticipation vient se confronter à l'aspect réactif de l'approche, où il est difficile de prédire les besoins des futurs produits. De plus, chaque modification représente un coût, qui ne peut être rentabilisé que si l'anticipation s'avère finalement utile. Cette accumulation de coûts provoque un risque pour ces petites et moyennes entreprises, et donc une probable diminution de son adoption des LPL. Les entreprises nouvelles ou petites n'arrivent peut-être pas à envisager les futurs produits qu'elles vont devoir créer et donc les transformations qu'elles vont devoir apporter à la LPL. Ces entreprises n'ont pas le recul nécessaire pour anticiper ces contraintes en raison de leur taille. Et la création de nouveau produit pourrait compromettre les différents produits déjà préexistants. Comme nous l'avons vu, la stratégie réactive propose une ingénierie basée sur un cycle de développement opportuniste de la LPL. Si l'on prend le cas des PMEs, ces entreprises fonctionnent de façon opportuniste : ceux sont les demandes occasionnelles de clients qui motivent la production de nouveaux produits. Ainsi il apparaît nécessaire que le développement de la LPL soit compatible avec un cycle de production opportuniste et occasionnel : les développeurs doivent pouvoir construire et mettre en pause l'ingénierie de la LPL à tout moment. Dans la deuxième grande partie de mon mémoire d'alternance, nous verrons aussi que notre outil SPL Generator peut également s'appliquer dans une stratégie extractive. Il suffit pour cela de disposer d'une famille de produits en amont de l'utilisation. Cette famille de produits est ensuite intégrée en une seule fois, c'est-à-dire que les produits sont passés un à un et sans délai pour leurs intégrations, dans le but d'obtenir une LPL en sortie. 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT L'analyse Formelle L'analyse formelle des concepts (Formal Contexts Analysis en anglais, FCA) est une méthode générique de classification non supervisée et de regroupement dans sa version primitive. Elle permet, à partir d'une description de données appelée un contexte formel, de former des concepts et une hiérarchie entre ces concepts appelée le réseau de concepts. Un Contexte Formel (CF) est une relation binaire représentant la propriété entre objets et attributs. Représenté sous la forme de tableau, ils matérialisent deux contextes formels. L'un représente les produits logiciels associés aux fonctionnalités qu'ils fournissent et un second, lui, associe les produits logiciels aux artefacts qui les mettent en oeuvres. Un concept représente l'association d'un groupe maximal d'objets avec le groupe maximal d'attributs qu'ils partagent. Chaque concept est divisé en deux parties : une intention et une extension. L'intention représente l'ensemble des attributs. L'extension, quant à elle, représente l'ensemble des objets. Une hiérarchie entre concepts est formée à partir d'un ordre partiel basé sur l'inclusion de l'intention et de l'extension. Cet ordre partiel permet donc une forme d'héritage entre les concepts. Alors un diagramme représentant une hiérarchie de concepts ne montre, pour un concept, que son réduit intention, privé de ses attributs hérités ainsi que son réduit extension, privé de ses objets hérités. Plusieurs hiérarchies peuvent être construites avec FCA, le treillis de concepts étant la hiérarchie contenant tous les concepts. Ce travail utilisera la hiérarchie restreinte aux concepts qui introduisent au moins un objet ou un attribut. L'extraction de relations permet de récupérer les liens entre les attributs des concepts, par exemple des relations de co-occurrence, d'implication, et d'exclusion mutuelle. En particulier, les relations implication, co-occurrence, et exclusion mutuelle. Les implications sont déduites des liens d'héritage entre les concepts introducteurs : les attributs introduits par un concept parent sont impliqués par les attributs introduits par ses enfants. D'autre part, l'exclusion mutuelle est présente entre les attributs de deux concepts dont les extents ne se croisent pas. Une exclusion mutuelle signifie que les attributs de deux concepts ne peuvent jamais être trouvés ensemble. Des techniques sont disponibles dans la littérature pour extraire ces relations 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT
10 Mai 2019 L'Analyse de Concepts Relationnels (RCA en anglais) est une extension de FCA qui crée des hiérarchies de concepts connectés multiples pour apprendre et regrouper à partir de relations dirigées entre des contextes formels multiples. En entrée, RCA prend une Famille de Contextes Relationnels. Une FCR contient deux ensembles, un ensemble de contextes formels et un ensemble de contextes relationnels. Un Contexte Relationnel représente une relation unidirectionnelle entre deux types d'objets. Plus précisément, il s'agit d'une relation binaire, orientée des objets d'un contexte formel source vers les objets d'un contexte formel cible. Pour calculer les concepts, RCA crée des attributs relationnels quantifiés, qui représentent des quantificateurs (par exemple, existentiel 2 ou universel ?), r est une RC et C'est un concept du treillis du Contexte Formel cible de r. Par conséquent, un attribut relationnel décrit les objets d'un contexte formel par leurs liens avec les concepts d'un autre contexte formel. Dans ce travail, nous utilisons le quantificateur 2, qui établit un lien entre un produit et un concept d'artefact ou un concept de caractéristique lorsque le produit possède au moins un élément de l'extension du concept. En sortie, RCA produit de multiples hiérarchies de concepts, par exemple de multiples AOC-Posets, un pour chaque contexte formel. Notez que l'AOC-Poset d'un CF qui est la source d'un ou plusieurs RC, contient deux types d'attributs dans ses concepts intents : attributs natifs ; et attributs relationnels ce sont les attributs pointant à travers une relation vers les concepts du contexte formel cible. Dans les diagrammes, lorsque les concepts cibles sont des introducteurs, ils sont remplacés par leurs propres attributs natifs pour simplifier la lecture et être utilisés dans notre approche. RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT
10 Mai 2019 Un Contexte formel (CF) est donc l'ensemble des relations entre des objets et des attributs. Il peut se décrire dans une matrice comme illustré dans la Table ci-dessus Un concept représente l'association d'un groupe maximal d'objets avec le groupe maximal d'attributs qu'ils partagent. Chaque concept est divisé en trois parties (de haut en bas) : un nom, une intension et une extension L'intention représente l'ensemble des attributs partagés par l'ensemble des objets du concept. L'extension, quant à elle, représente l'ensemble des objets regroupés dans ce concept parce qu'ils partagent les attributs de l'intension Les concepts peuvent être hiérarchisés pour former un treillis de concepts Une hiérarchie est formée à partir d'un ordre partiel basé sur l'inclusion des intensions et extensions des concepts. Cet ordre partiel permet une forme d'héritage entre les concepts. Les concepts sont hiérarchisés pour former un treillis de concepts Dans le treillis de concepts, il est souvent choisi de ne représenter que l'intension réduite et l'extension réduite des concepts pour simplifier la représentation. L'intension réduite d'un concept est privée des attributs mentionnés dans les intensions des super-concepts. De même, l'extension réduite est utilisée pour ne faire apparaître les objets dans un concept seulement si l'intension complète du concept contient l'ensemble des attributs des objets. L'avantage d'utiliser les intensions et extensions réduites est qu'elles permettent de faire apparaître explicitement les concepts introducteurs d'attributs ou d'objets. Un concept est introducteur d'attributs (respectivement d'objets), si son intention (resp. extension) réduite contient au moins un attribut (resp. objet). Dans notre projet, nous utiliserons les concepts réduits pour la représentation des AOC-Posets. Plusieurs hiérarchies peuvent être construites avec l'ACF, le treillis de concepts étant la hiérarchie contenant tous les concepts. Dans notre projet, nous utiliserons la hiérarchie des AOC-Posets. Cette hiérarchie est restreinte aux concepts introducteurs (c.-à-d. aux concepts qui introduisent au moins un objet ou un attribut). RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 La variabilité d'une Ligne de produit logiciel La gestion de la variabilité Lors de l'ingénierie d'une ligne de produits, les concepteurs sont amenés à définir et à exprimer la variabilité des artefacts. Pour concevoir la ligne, ils doivent spécifier les artefacts communs et optionnels, en plus des contraintes de variabilité entre ces artefacts qu'il faut respecter pour construire les produits. Le paradigme de développement multiproduits des LPL exige donc une modélisation de la variabilité d'une LPL. Cette modélisation accompagne les concepteurs tout au long du cycle de vie de la LPL. Les modèles de variabilité facilitent la compréhension, la maintenance et l'évolution de la LPL. En agissant sur autant d'étapes du cycle de vie d'une LPL, il apparaît essentiel que cette modélisation soit la plus compréhensible et accessible possible pour les différents acteurs participant à l'ingénierie (p. ex. développeurs, responsables produits, clients, commerciaux, etc.). Car lors de mon alternance, il est apparu évident de clarifier au maximum les différentes parties des fonctionnalités de la LPL et de son implémentation pour que l'intégralité des équipes IT puissent facilement s'y retrouver. Parmi les techniques de modélisation de la variabilité existante, la modélisation de la variabilité par caractéristiques est la plus populaire comme l'approche de Czarnecki (2012) Caractéristique logicielle La configuration de la plateforme permet de générer l'implémentation du produit souhaité par une sélection les artefacts spécifiés par les développeurs. Cependant, il devient rapidement fastidieux de sélectionner ces artefacts un à un pour générer un produit. C'est pourquoi l'ingénierie des LPL préconise de décrire les produits en termes de caractéristiques logicielles qui les composent. Ce paradigme de description conçoit le logiciel en termes de caractéristiques. La caractéristique logicielle est une fonctionnalité logicielle ou un comportement particulier dans un logiciel, souvent perçu par l'utilisateur du logiciel. Plusieurs dizaines de définitions apparaissent dans la littérature pour tenter de définir formellement ce qu'est une caractéristique. C'est comportement d'un système logiciel visible par un utilisateur. Les caractéristiques sont utilisées dans l'ingénierie des LPL pour spécifier et communiquer les points communs et les différences des produits aux différents intervenants et pour guider la structuration, la réutilisation et les variations à travers chaque étape de vie d'un système logiciel Les caractéristiques permettent de décrire les spécificités implémentées par chaque produit, et de décrire un logiciel comme la somme de ses caractéristiques Dans le contexte d'une même RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT ligne de produits logiciels, deux logiciels partageant les mêmes caractéristiques sont considérés comme égaux. L'ensemble des caractéristiques d'un produit forme la configuration du produit. Lors de l'ingénierie d'application, l'étape de configuration des produits consiste donc à décrire les produits d'après l'ensemble des caractéristiques qui les composent. La variabilité de la LPL est donc le plus souvent exprimée en utilisant les caractéristiques. Les caractéristiques sont directement liées aux différents artefacts réutilisables de la LPL. Au travers de la sélection de caractéristiques, les concepteurs de la LPL peuvent donc sélectionner des artefacts à implémenter dans le produit. Les artefacts sont perçus comme l'implémentation concrète des caractéristiques dans la plateforme configurable de la LPL. La configuration de la plateforme, qui permet d'obtenir un produit, se fait en appliquant à la plateforme une configuration du produit désiré, c.-à-d. en sélectionnant les artefacts des caractéristiques mentionnées dans la configuration du produit. Modèle des caractéristiques L'emploi des caractéristiques pour décrire les produits peut s'appliquer pour la description de la variabilité de la plateforme configurable, et donc de la LPL. La plus souvent, la variabilité est décrite par des modèles de variabilités, le plus commun étant donc le modèles des caractéristiques Les modèles de variabilité, et notamment celui des caractéristiques (appelé feature-model en anglais), décrivent l'espace de la variabilité de la LPL en fonction des caractéristiques qui la composent. Le modèle des caractéristiques représente la variabilité comme une arborescence, où les caractéristiques sont des noeuds et où les branches sont des contraintes de variabilité. Les caractéristiques abstraites servent principalement à regrouper les caractéristiques concrètes (qui en sont des sous-caractéristiques) et donc à structurer le feature-model. Ce type de modèle permet de décrire l'ensemble des configurations possibles que peut accepter la plateforme configurable, et donc l'ensemble des produits de la LPL Les éléments graphiques qui composent le feature-model sont les suivants : 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT Dans l'élaboration de notre outil, nous considérons que les interactions de caractéristiques sont donc des comportements logiciels particuliers, implémentés dans la LPL et ses produits, qui interviennent pour assurer le bon fonctionnement d'un produit lorsque plusieurs caractéristiques peuvent s'influencer entre elles. De plus, nous considérons que chaque interaction peut avoir une implémentation concrète et spécifique dans la plateforme de la LPL. Cette implémentation prend la forme d'un ensemble d'artefacts dans la plateforme. Enfin, nous considérons qu'une interaction n'est présente dans un produit que si les caractéristiques en interaction le sont également. 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 L'implémentation LPL par annotation et par composition On distingue pour cela deux types d'implémentation possible. Annotation L'approche par annotation (ou approche annotative) hérite de son fonctionnement des systèmes de Macro de pré compilation, notamment populaire dans les langages C et C++ À l'image du code avec Macro, le code source d'une plateforme configurable contient des instructions spécifiques à un langage de précompilation, qui permet d'activer ou désactiver certaines portions du code source, afin d'inclure ou non le code spécifique d'une caractéristique. l Une annotation consiste à ajouter un méta donné pour référencer une ou plusieurs parties de code. Chaque annotation doit être définie d'une manière à se déclencher pour une configuration donnée, après avoir exécuté une partie de code statique et commun. Les annotations peuvent être -- implicites -- explicites : Faite manuellement par un utilisateur. Le cas commun d'annotation explicite dans les langages de programmation c'est bien l'utilisation des blocs si et sinon (if else) à l'intérieur d'un programme, comme le montre la figure suivante.
Les annotations délimitent virtuellement le code de la plateforme pour lier les artefacts aux caractéristiques. L'annotation peut se comprendre comme une condition logique à satisfaire pour inclure ou non la portion de code annoté dans un produit. Chaque annotation déclare une formule logique où les noms des caractéristiques sont des propositions. En fonction de RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 la configuration choisie pour un produit, un processus de précompilation parcourt le code de la plateforme à la recherche des annotations. Pour chaque annotation visitée, la formule de l'annotation est interprétée en considérant à "Vrai" les propositions correspondantes aux caractéristiques de la configuration. Si la formule renvoie "Vrai", le code annoté est conservé dans le produit, sinon il est retiré ou rendu inactif par des commentaires L'approche par annotation explicite les mécanismes de variabilité d'une plateforme configurable. Les concepteurs perçoivent en une seule vue l'implémentation de tous les artefacts variables, et donc de toutes leurs caractéristiques. L'implémentation des caractéristiques est dite virtuellement séparée, car elles coexistent toutes dans une même vue, mais elles sont séparées par des annotations. Avec l'approche par annotation, le code d'un produit généré conserve une grande proximité avec le code annoté dans la plateforme. Pour les concepteurs de la plateforme, cette génération permet de conserver le même code dans les produits que celui observé dans la plateforme. Cela facilite la maintenabilité de la plateforme et des produits.Le système d'annotations permet également de facilement implémenter les interactions de caractéristiques. Les interactions de caractéristiques correspondent à l'implémentation d'un comportement spécifique lorsque plusieurs caractéristiques sont présentes ensemble dans un même produit. Pour finir, l'approche par annotations est indépendante du langage de programmation choisi et de la nature de l'élément à annoter. Elle peut d'ailleurs être appliquée à des fichiers de textes, des fichiers XML ou CSV, etc. Limitations des annotations La séparation virtuelle des implémentations peut engendrer des problèmes de compréhension lié à un manque de lisibilité du code de la plateforme. Ces problèmes, dits de l'enfer des if/else, résultent d'une difficulté des concepteurs à interpréter la multiplicité des embranchements du code liée aux conditions des annotations Cette difficulté s'accentue avec la taille des formules, c.-à-d. nombre de propositions dans la formule d'une annotation, et le nombre d'annotations au sein d'un même fichier. Il faut ajouter à ces difficultés deux autres particularités des annotations : elles peuvent être imbriquées pour implémenter la variabilité Elles peuvent également être déclarées n'importe où dans le code, c.-à-d. à l'intérieur d'une méthode, autour du contenu d'un fichier, dans l'entête de la déclaration d'une classe, dans la signature d'une méthode, etc. Ce second point présente cependant un avantage, puisqu'il permet d'annoter finement les artefacts de la plateforme et donc d'annoter précisément l'implémentation d'une caractéristique. Enfin, le dernier point important est que la maintenabilité d'une plateforme annotée est différente de celle d'un code traditionnel. Les RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 outils de vérification statique du code basé sur le parseur ou l'arbre de syntaxe abstrait (AST) sont désactivés ou restreints. Ces outils sont inadaptés, car ils ne sont pas conçus pour tenir compte de la variabilité de la plateforme. Par exemple, deux mêmes attributs déclarés plusieurs fois dans la même classe peuvent appartenir à deux annotations différentes (donc deux caractéristiques différentes). En résumé, l'approche par annotation présente un système simple et intuitif pour implémenter les mécanismes de variabilité d'une plateforme. Toutefois, cette simplicité peut engendrer un manque de clarté du code source, et des difficultés de compréhension plus le nombre d'annotations augmentent (enfer des if/else). L'approche par annotation nécessite donc une certaine rigueur dans son application pour limiter des efforts de compréhension du code. L'implémentation en compositionnel L'approche par composition est souvent présentée comme une alternative aux limitations des approches par annotations. Son objectif principal est de résoudre la séparation virtuelle des implémentations en proposant une séparation physique. Ainsi dans l'approche par composition, les caractéristiques sont chacune physiquement isolées dans des dossiers qui sont propres à leur implémentation Comme son nom l'indique, la composition propose de composer les différentes caractéristiques pour construire l'implémentation du produit lors de la génération. Pour cela, la composition s'appuie sur la structure du code ciblé. Cela consiste finalement à composer une ou plusieurs parties de code. Le choix des parties de code, se fait avant l'exécution du code, en choisissant les parties à exécuter. Pour cela, on s'intéresse à la notion de point de composition, qui est une étape ou on peut ajouter à une partie de code, une autre partie pour pouvoir exécuter les deux. Avantages et inconvénients : Il est notamment possible de comparer ces deux approches en termes de granularité, sûreté, traçabilité des produits pour choisir celui qui répond à notre besoin. Toutefois ces deux approches peuvent être combinées pour tirer le meilleur profit. Cependant, la figure suivante permet de distinguer la différence entre l'implémentation des deux approches. L'approche par composition offre une séparation des implémentations pour chaque caractéristique, ce qui facilite la localisation de leurs implémentations pour les développeurs. Cependant, l'approche par composition est complexe et peu intuitive pour les développeurs. En premier lieu, elle introduit un nouveau paradigme de conception pour la plateforme, où chaque implémentation de caractéristiques doit être isolée. L'approche par RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT composition demande donc plus de temps et d'efforts pour concevoir la plateforme que l'approche par annotation. Deuxièmement, le moteur de composition des produits construit des produits dont l'implémentation est différente de celle de la plateforme. En effet, dans le cas d'une granularité Instruction, le code des méthodes peut être modifié pour réaliser une composition. Ces méthodes d'emballage modifient la structure du code source sans en changer la sémantique, mais cela peut contribuer à perturber la compréhension du code généré pour les concepteurs de la plateforme. Contrairement à l'approche par annotation pour un produit équivalent, le code généré s'éloigne de celui de la plateforme. Troisièmement, bien que les composeurs soient indépendants d'un langage de programmation, leur fonctionnement nécessite de disposer d'une représentation en arborescence du code source pour pouvoir être composés. De plus, ils doivent être adaptés pour chaque langage de programmation, afin de construire les règles de composition propres aux spécificités de chaque langage. Pour finir sur les limitations, l'approche par composition représente souvent difficilement une granularité fine. Ainsi à la granularité Instruction, dans la plupart des approches par composition, il est rarement possible d'introduire des instructions au milieu d'une méthode existante afin d'étendre une séquence. La manipulation d'instructions au milieu d'une méthode, de paramètres ou d'expressions est impossible dans aucune approche par composition, à cause des mécanismes de composition basés sur les emballages de méthodes Synthèse Nous retiendrons de l'étude que l'approche par annotation est plus avantageuse que l'approche par composition, notamment concernant son intuitivité, la granularité permise, et son déploiement quasi universel. Les annotations (notamment dans le contexte du C/C++) ont une réputation négative et sont souvent critiquées pour rendre le code difficile à comprendre et à maintenir. Cependant, certaines expérimentations indiquent que ces critiques ne semblent pas avoir de réels fondements en pratique, puisque l'impact des annotations sur la maintenabilité semble minime comparé au gain précédemment 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT Le degré de granularité La granularité est une notion récurrente dans l'ingénierie d'une LPL. De façon générale, la granularité définit la taille du plus petit élément qui compose un système. Elle désigne donc la limite du niveau d'analyse des éléments, niveau à partir duquel un élément est considéré comme insécable. Dans l'ingénierie des LPL, la granularité peut s'employer à différents niveaux, pour définir la finesse (ou la précision) avec laquelle doivent être déclarés les artefacts et donc la variabilité d'une LPL Ainsi, la granularité de la variabilité donne le niveau de détails avec lequel la variabilité et les artefacts sont définis dans la LPL. Concernant l'implémentation de la variabilité et les artefacts de code source, différents niveaux de granularité existent. Nous proposons ici notre synthèse de ces différents niveaux : Classe : définit une granularité qui considère l'intégralité d'un fichier de code ou d'une classe (en programmation orientée objet OO) comme le plus petit élément à considérer. Par exemple, la variabilité à cette granularité se fait en ajoutant ou retirant des fichiers dans le code source des produits. Méthodes : définit une granularité qui considère les méthodes ou les fonctions qui composent respectivement une classe OO ou un fichier de code. Par extension, cette granularité considère également les déclarations d'attributs ou de variable relative à un fichier. Par exemple, la variabilité se fait en ajoutant ou en retirant une méthode dans une classe. Instruction : définit une granularité qui considère les instructions du code source comme le niveau le plus fin. Cette granularité permet de considérer chaque instruction du corps d'une méthode ou d'une fonction comme un artefact individuel. Expression : définit une granularité qui considère les opérande et opérateur d'une expression (plus fin qu'Instruction). Signature : définit une granularité qui considère les paramètres d'une signature de méthode ou d'une fonction ou d'une classe. Par exemple en ajoutant ou en retirant l'expression qui déclare l'extension du type dans une classe. Plus la granularité est fine, plus elle précise l'implémentation des différentes caractéristiques dans la plateforme. Cette finesse permet également de mieux factoriser le code partagé par plusieurs produits et donc d'améliorer la maintenabilité de ces derniers. La même étude montre qu'il est donc plus pertinent d'adopter une granularité Instruction que des granularités Fichier-Classe et même Méthode-Fonction. Ainsi, plus la granularité est fine, plus le code de la plateforme 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT configurable peut être factorisé, maximisant ainsi le code commun entre les produits de la LPL. Localisation des caractéristiques Dans le cadre des lignes de produits logiciels, la localisation de caractéristiques (ou Feature Location en anglais) consiste à retrouver l'implémentation d'une caractéristique connue, c'est-à-dire à lui associer des artefacts parmi ceux de la LPL. La localisation est à distinguer de l'identification des caractéristiques feature identification, qui consiste à déterminer la caractéristique à associer à des artefacts. Les techniques de localisation s'appliquent généralement dans deux cas : sur un seul produit, ou sur une famille de produits. Dans les deux cas, associer des caractéristiques à des artefacts consiste à lier l'ensemble des artefacts à l'ensemble des caractéristiques. Plusieurs hypothèses sont possibles concernant ces associations. Par exemple, un artefact peut être associé seulement à une caractéristique ; ou il peut être associé à plusieurs caractéristiques. Il faut également considérer la présence d'interactions de caractéristiques dans l'implémentation des produits. Dans nos travaux au sein de l'entreprise, nous nous intéressons principalement à la notion de localisation des caractéristiques dans le contexte des lignes de produits logiciels. Dans ce contexte, nous rencontrons le plus souvent la localisation dans les stratégies extractives. (Cette étape n'est pas encore terminée dans notre implémentation mais elle fera l'objet de modification en fin septembre 2019 par mes soins) Les techniques de localisation existantes pour des artefacts de code source sont classées en trois catégories : analyse dynamique, analyse statique et analyse textuelle. Certaines techniques proposent parfois de combiner ces types d'analyse pour améliorer leur performance. Analyse Dynamique L'analyse dynamique consiste à localiser l'implémentation des caractéristiques lors de l'exécution des logiciels. Cette analyse s'appuie sur une instrumentation du code source des produits pour produire des traces d'exécution. Les scénarios d'exécution du programme sont nécessaires et construits en amont de l'exécution, en accord avec l'instrumentation du code source. Il existe plusieurs techniques de localisation basées sur l'analyse dynamique (voir inventaire complet dans 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 Parmi les premières proposées figurent celles de Wilde (1995). Leur technique propose d'exécuter deux types de scénarios à la suite : l'un activant une caractéristique, et l'autre où la caractéristique n'est pas activée. Les traces d'exécution sont comparées pour déterminer les artefacts qui sont les candidats les plus probables pour être l'implémentation d'une caractéristique spécifique. La localisation basée sur l'analyse dynamique des traces est limitée par la construction des scénarios choisis. En effet, rien ne permet d'affirmer que l'exécution des scénarios suffise à couvrir l'ensemble des artefacts associés à une caractéristique. Analyse statique L'analyse statique se focalise sur une exploration du code source et des ressources ou documents associés à un logiciel pour déterminer l'implémentation des caractéristiques parmi les artefacts d'un logiciel. Nous pouvons distinguer deux types d'analyse statique : sur un seul produit et sur un ensemble de produits. L'analyse statique sur un seul produit consiste essentiellement à regrouper les artefacts du code source sur l'hypothèse qu'il existe une cohésion parmi eux. Cette cohésion peut être structurelle ou lexicale. Dans le cas d'une cohésion structurelle, l'analyse statique considère les dépendances structurelles (p. ex. méthode définie dans une classe ; fichiers définis dans un paquet) ou de références (p. ex. la méthode fait référence à un attribut ; la classe contient un attribut dont le type est défini dans une autre classe). Pour faciliter le regroupement des artefacts, la localisation est parfois semi-automatique, et il est attendu d'un expert qu'il indique une graine ; dans le code à partir de laquelle la localisation peut commencer. Cette graine peut être une méthode, une instruction, une classe, ou tout autre élément du code. Parmi ces approches de localisation sur un seul produit, Chen (2000) a proposé une approche semi-automatique. Leur approche construit un graphe de dépendances à partir des éléments du code source dont les liens sont des invocations de méthodes, références d'attributs, relation d'héritage. À partir du graff, un expert sélectionne un noeud en tant que graine (étiquetée avec le nom de la caractéristique à localiser) à partir de laquelle la localisation va se propager pour atteindre les différents noeuds et obtenir une implémentation pour une caractéristique donnée. L'analyse statique sur une famille de produits est moins étudiée que celle sur un seul produit. De façon générale, les approches proposées se basent sur la variabilité des produits pour isoler l'implémentation des caractéristiques (car on connaît les caractéristiques RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT associées à chaque produit. Pour cela, les approches font l'hypothèse de la cooccurrence entre les caractéristiques décrites dans les produits et les artefacts qui composent ces produits. Ainsi, elles associent artefacts et caractéristiques sur le postulat que si un groupe d'artefacts est toujours présent dans un produit lorsqu'une caractéristique l'est, alors ces artefacts doivent correspondre à l'implémentation de la caractéristique. Les approches de localisation par analyse statique sont nombreuses et présentent toutes leurs limites et leurs forces. Nous pouvons généraliser en disant que les techniques appliquées à un seul produit sont souvent semi-automatiques et utilisent des graines pour propager la localisation. Quant aux techniques appliquées à une famille de produits, elles sont souvent automatiques, mais basées principalement sur l'étude de la variabilité. De plus, ces approches ne prennent souvent pas en compte les interactions de caractéristiques 10 Mai 2019 RAPPORT D'ALTERNANCE 2018-2019 THOMAS PETIT 10 Mai 2019 |
|
