NDLR: dans le cadre du partenariat de recherches entre Arolla et l’INRIA, nous avons le plaisir d’accueillir des articles de chercheurs avec lesquels nous collaborons activement. C’est le cas de Nour qui signe pour nous un article introductif sur les visualisations en rapport avec les code legacy.
Cet article est le premier d'une série sur la visualisation des logiciels pour l'évolution et la maintenance des systèmes informatiques. Nous explorerons les visualisations et les défis associés, en particulier les défis auxquels sont confrontés les grands systèmes logiciels.
Tout logiciel efficace doit évoluer pour conserver sa pertinence. Cependant cette évolution a des conséquences inévitables sur la qualité du système informatique/d'information, ce qui rend les changements évolutifs ultérieurs encore plus fastidieux. Avant de procéder à ces changements, les développeurs doivent d'abord comprendre la logique qui se cache derrière des milliers de lignes de code source en utilisant des techniques de rétro-ingénierie telles que les visualisations afin d'optimiser les efforts.
Inéluctabilité de l’évolution des logiciels
Pour que les entreprises et les organisations puissent prospérer, elles doivent faire face aux nouvelles exigences. Ces nouvelles exigences sont principalement motivées par la concurrence du marché et par les besoins humains en constante évolution. Cependant, à mesure que le système évolue au fil du temps, de nombreux facteurs contribuent à la diminution de la qualité du système, ce qui entraîne des activités de maintenance difficiles et coûteuses. L’évolution et la maintenance des logiciels sont fortement liées. Au fur et à mesure que le système évolue, sa complexité augmente et sa maintenance devient à la fois difficile et exigeante.
Certaines approches ont été proposées afin de réduire les coûts des activités de maintenance, comme la visualisation des logiciels. Celle-ci est une technique d'ingénierie inverse, basée sur l'exploitation d'analogies pour mieux comprendre l'architecture des logiciels. L'objectif est d'optimiser les efforts financiers et humains consacrés aux tâches de maintenance.
Dans cet article, nous expliquerons pourquoi l'évolution des logiciels est une arme à double tranchant et comment la maintenance des logiciels est un défi quotidien. On présente également quelques visualisations utilisées dans ce domaine pour aider à la compréhension et donc à la gestion de données.
Contexte de l’évolution des logiciels
Tout au long du cycle de vie du logiciel, de nouvelles fonctionnalités sont ajoutées, de nouveaux concepts émergent et de nouveaux problèmes logiciels apparaissent. En effet, plus de 65% du coût du cycle de vie des logiciels est consacré aux activités de maintenance. Ainsi, en plus de toutes les pressions externes et internes que les entreprises et les organisations doivent surmonter, voire dépasser, elles doivent également faire face aux problèmes liés aux logiciels.
On liste ci-dessous certains des aspects techniques et non techniques de l'évolution des logiciels :
une bonne lecture soit Object-Oriented Reengineering Patterns qui est disponible ici.
Perte de connaissance : Les logiciels ayant une longue durée de vie sont plus susceptibles d'avoir perdu des informations. Souvent, les développeurs d'origine ne sont plus présents. L'information est dispersée, de même que la documentation, qui dans la plupart du temps est dé-priorisée ou mise de côté pour être oubliée plus tard. Par conséquent, les décisions prises dans les premières phases de développement et leur évolution sont perdues. Cependant, les systèmes informatiques doivent être intégrés à différentes technologies. Ces technologies ont un impact sur l'architecture du système. Mais, comme les nouveaux développeurs n'ont pas une connaissance suffisante du système, il devient crucial de comprendre le flux d'informations et les processus intégrés.
Les logiciels vieillissants : on ne sait jamais quand un code devient un code patrimonial, à savoir continuellement modifié lui-même ainsi que les développeurs chargés de sa maintenance, chacun détenant une pièce du puzzle de la connaissance du logiciel - si, par la nature de la mémoire humaine, ces connaissances n'ont pas été complètement oubliées. Dans ce cas, les nouveaux développeurs confrontés à la tâche de maintenance ne comprennent pas le design de conception du système, en raison des différentes logiques dans le code source mises en œuvre par différents développeurs. Par conséquent, la probabilité de faire face aux problèmes tels que du code mort, du code dupliqué, l'absence de tests et une documentation obsolète devient très élevée, ce qui rend les modifications ultérieures du logiciel encore plus délicates. Une bonne lecture sur le vieillissement des logiciels peut être trouvée ici.
Modifications coûteuses : le manque de connaissance fine du code du système couplé au manque de tests rend chaque changement risqué. L'évolution des logiciels est un véritable défi certes, encore plus difficile lorsqu'il s'agit d'entreprises ayant un code patrimonial. Dans la plupart des cas, ces entreprises préfèrent ne pas prendre le risque d'affronter les incertitudes liées à la création d'un nouveau logiciel. Cependant, le code du logiciel patrimonial représente lui-même des règles et une valeur commerciale, qui fait que sa modification peut indirectement influencer ces contraintes. L'entreprise fait donc face à des coûts élevés, les développeurs ont du mal à faire plus que des corrections ou de traiter les besoins immédiats des clients. Ces systèmes souffrent alors de sclérose (en raison de la peur du changement). Cette sclérose, tout en préservant la situation existante, détruit l'innovation et l'adaptation aux nouveaux clients et marchés.
Dette technique : un concept introduit pour la première fois par Ward Cunningham dans un rapport en 1992 et inspiré par la dette financière. La dette technique survient lorsqu'un développeur opte pour une solution rapide plutôt que pour une solution bien conçue. Une solution rapide n'aborde généralement pas les problèmes sous-jacents et ne doit donc pas être une solution permanente, sinon la dette augmente au fil du temps à chaque modification du logiciel. Ça ne s'arrête pas là, car la dette technique conduit à un problème plus grave, à savoir la faillite technique. Cela se produit dans des cas extrêmes, où l'accumulation de la dette technique au fil des années devient si importante que le système ne fonctionne plus correctement et ne répond plus aux besoins des clients, où toute modification peut provoquer l'effondrement du système et son abandon sans aucune utilité. Un bon livre pour en savoir plus sur la dette technique peut être trouvé ici.
Dégradation de la structure : les évolutions successives de ces systèmes, dans des directions qu'il n'était pas possible d'anticiper lors de leur conception, résultent en une évolution désordonnée. Cela contribue à la perte d'une bonne structure logicielle qui conduit à des systèmes monolithiques, avec de nombreuses dépendances qui peuvent être contre-intuitives. Par conséquent, ces logiciels sont très difficiles à modifier ou un changement, qu’on pensait innocent, peut produire des effets inattendus dans d’autres parties du système qui n'auraient pas dues être affectées. La modularité du système est alors compromise.
Perte de qualité : tous les problèmes énoncés ci-dessus, combinés ensemble, conduisent à des systèmes de qualité décroissante, sur lesquels les développeurs craignent de mettre la main en raison des conséquences incontrôlables et inattendues. De plus, ces systèmes sont difficiles à appréhender pour les nouvelles recrues et demandent des investissements humains importants pour chaque action.
Si la recherche et le développement (R&D) permettent aux entreprises de garder une longueur d'avance et d'anticiper les demandes des clients ou les tendances commerciales, sans un effort constant pour contrôler son entropie, le logiciel se détériorera au fil du temps et présentera les symptômes mentionnés ci-dessous.
Visualisation comme solution à la maintenance des logiciels
Les chercheurs ont exploré ce domaine afin de mieux comprendre la maintenance des logiciels et de trouver des solutions plus efficaces pour réduire les ressources financières et humaines consacrées aux tâches de maintenance. Ces solutions sont basées sur la compréhension des programmes et l'analyse des logiciels. La compréhension des codes sources et l'analyse de la structure et des fonctionnalités des logiciels font partie d'un plus grand processus qui est la rétro-ingénierie.
Celle-ci consiste à appliquer une analyse précise pour extraire des informations plus abstraites du code source. La motivation de la tâche de rétro-ingénierie définit le résultat des données extraites, dans le sens où les informations récupérées correspondent exactement aux requêtes appliquées au logiciel.
Il faut d'abord comprendre le logiciel avant de poursuivre toute action. Cependant, comprendre des milliers de lignes de code source n'est pas une tâche facile. Elle requiert non seulement de l'énergie humaine, mais aussi beaucoup de temps (et de patience). Mais pour automatiser cette tâche, les logiciels doivent être compréhensibles non seulement par les êtres humains, mais aussi par les machines, pour fournir des résultats exacts. C'est là qu'intervient l'analyse par ingénierie inverse. Le résultat de cette analyse peut prendre de nombreuses formes, en fonction de l'utilisateur final et de ses besoins, du code source lui-même aux informations textuelles et aux visualisations.
Les visualisations des systèmes informatiques représentent le résultat des requêtes appliquées au code source. En effet, c'est une approche qui a prouvé son efficacité dans la compréhension du code source et la structure des logiciels. Pourquoi cet impact positif ? Car le cerveau humain est une machine d'association! Il relie les choses entre elles pour mieux comprendre le monde. On s’ensuit que la visualisation joue un rôle énorme dans le raisonnement humain- un domaine qui a été nommé Intelligence Amplification. Représenter les données informatiques sous forme d'images et de couleurs, reconnaissables et familières pour l'être humain, comme des métaphores, invoque les capacités de son cerveau pour mieux mémoriser et comprendre les concepts concernant les structures et les fonctions des logiciels.
Il est à noter que la visualisation n'est pas seulement utilisée en informatique, mais aussi en génie mécanique, en chimie, en physique et en médecine (cf. Stephan Diehl)
On présente ici brièvement quelques visualisations courantes et utiles pour la représentation des données. Des descriptions plus détaillées seront l'occasion de nouveaux articles de blog.
Distribution Maps : Les Distribution Maps sont l'une des techniques génériques permettant de fournir une vue d'ensemble de la manière dont une propriété (auteur, nombre de bugs …) est distribuée dans les entités du système (classes, méthodes …). La visualisation est basée sur des cases et des couleurs qui permettent à l'utilisateur d'identifier la distribution d'une propriété dans le système.
La figure ci-dessus montre une simple visualisation de la distribution de 4 propriétés, où chaque propriété est représentée par une couleur dans 5 packages différents.
À propos des Distribution Maps.
Polymetric Views: une autre approche destinée à la compréhension des logiciels et à la détection des problèmes, est la visualisation Polymetric Views. Cette visualisation utilise des métriques logicielles pour évaluer la qualité et la complexité d'un système. Le système est représenté sous la forme d'un arbre dont les nœuds représentent les entités logicielles et les arêtes les relations entre ces nœuds (entités). La taille des nœuds peut varier en fonction de plusieurs propriétés. Ainsi, il est possible de représenter le système logiciel sous la forme d'un arbre où les classes sont des nœuds dont la taille varie en fonction du nombre de lignes de méthodes pour la hauteur, du nombre d'attributs pour la largeur et du nombre de lignes de code pour la couleur ; les arêtes sont des relations d'héritages.
À propos des Polymetric Views.
Code City 3D : une bonne métaphore utilisée pour visualiser la structure des logiciels est la visualisation 3D CodeCity. Où le système prend la forme d'une ville : les classes sont représentées comme des bâtiments et les packages comme les quartiers de la ville. La taille du bâtiment varie comme dans la vue polymétrique éventuellement en fonction de plusieurs critères.
La figure ci-dessus représente la visualisation CodeCity du projet ArgoUML - 130 000 lignes de code source. Les bâtiments bruns représentent les classes et les interfaces, placées dans des tuiles bleues représentant les packages.
Les visualisations présentées ci-dessus sont à la fois faciles à utiliser et efficientes dans la représentation des données volumineuse en une forme plus abstraite et compréhensible, dont le but est d'avoir un bon aperçu de l'architecture du système.
Conclusion
La recherche et le développement jouent un rôle important dans le choix des orientations futures des entreprises, où l'étude des comportements sociaux et humains est un aspect essentiel pour évoluer et répondre aux exigences les plus récentes.
Il se trouve que même les logiciels subissent un processus de sélection naturelle darwinienne. Les logiciels qui peuvent facilement s'adapter à de nouvelles conditions et à un nouvel environnement ont plus de chances de survivre.
Tant que leur survie dépend fondamentalement de la satisfaction des besoins des clients, et donc permet de maximiser les profits de l'entreprise- tout le monde est gagnant !
Au cours du cycle de vie du logiciel, plusieurs facteurs influencent la faisabilité des activités de maintenance, de l'absence de tests et de documentation à l'absence de développeurs et à la dégradation de la structure du logiciel. Un tel impact conduit à d'autres risques en matière de sécurité, de faible productivité et de manque de confiance des clients. L'évolution des fonctionnalités des logiciels est souvent associée à la détérioration de leur structure. Les logiciels ayant une longue durée de vie sont plus difficiles à maintenir que les logiciels conçus récemment, on peut dire qu'il est toujours plus coûteux de faire une tâche de maintenance plus tard que plus tôt. Les activités de maintenance ne sont pas seulement exigeantes en termes de temps, mais aussi en termes de ressources financières et humaines.
Les visualisations, en tant que technique d'ingénierie inverse, sont pratiques pour résoudre les problèmes liés aux activités de maintenance, cette approche métaphorique donne vie aux données virtuelles sous forme d'images et de couleurs familières pour le cerveau humain. Cela réduit le temps consacré à la lecture du code source et donc facilite la compréhension et la mémorisation de données volumineuses pour une bonne évolution des systèmes informatiques.
Références
David Lorge Parnas. Software Aging (1994). Dans les actes de la conférence internationale sur le génie logiciel (pp. 279-287) . IEEE. Ontario, Canada.
Ducasse, Stéphane, (2006). Distribution Maps. In Proceedings International Conference on Software Maintenance (ICSM'06), (pp. 203-212). IEEE.
Lanza, Michele et Ducasse, Stéphane. Polymetric views- a lightweight visual approach to reverse engineering (2003). Dans Transactions on Software Engineering (pp. 782-795). IEEE.
Richard Wettel et Michele Lanza. CodeCity (2008). Dans Companion of the 13th international conference on Software engineering (ICSE Companion '08),p. 921. New York.
Stephan Diehl. Introduction. Software Visualization- Visualizing the Structure, Behaviour and Evolution of Software (2007), p.2. Berlin-Allemagne : Springer.
Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma. Refactoring for Software Design Smells Managing Technical Debt (2015). Elsevier Inc.
