Archéologie logicielle

L'archéologie logicielle est l'étude d'implémentations de logiciels hérités mal documentés ou non documentés, dans le cadre de leur maintenance logicielle[1],[2].

L'archéologie logicielle, nommée par analogie avec l'archéologie[3], comprend la rétro-ingénierie des modules logiciels et l'application de divers outils et processus permettant d'extraire et de comprendre la structure de programmes et de récupérer des informations de conception[4]. L'archéologie logicielle peut révéler des processus d'équipe dysfonctionnels ayant produit des modules logiciels mal conçus, voire inutilisés[5]. Le terme est utilisé depuis des années[6] et reflète une métaphore assez naturelle : un développeur lisant un code ancien peut sentir qu'il ou elle est dans la même situation qu'un archéologue explorant les ruines d'une ancienne civilisation[7].

Techniques

[modifier | modifier le code]

Un atelier sur l'archéologie logicielle à la conférence OOPSLA de 2001 (Programmation orientée objet, systèmes, langages et applications) a identifié les techniques d'archéologie logicielle suivantes, dont certaines sont spécifiques à la programmation orientée objet[8] :

  • Langages de script pour créer des rapports statiques et pour filtrer le rapport ressortant
  • Documentation dans les pages HTML ou les wikis
  • Analyse de signature synoptique, analyse statistique et outils de visualisation de logiciels
  • Outils de rétro-ingénierie
  • Suivi au niveau du système d'exploitation via truss ou strace
  • Moteurs et outils de recherche pour rechercher des mots-clés dans les fichiers source
  • Navigation dans les fichiers IDE
  • Framework de tests unitaires tels que JUnit et CppUnit
  • Génération de documentation API à l'aide d'outils tels que Javadoc et doxygen
  • Débogueurs

Plus généralement, Andy Hunt et Dave Thomas notent l'importance du contrôle de version, de la gestion des dépendances, des outils d'indexation de texte tels que GLIMPSE et SWISH-E, et «[dessiner] une carte lorsque vous commencez à explorer»[8].

Comme dans l'archéologie, l'archéologie logicielle implique un travail d'investigation pour comprendre les processus de pensée de ses prédécesseurs[8]. Lors de l'atelier OOPSLA, Ward Cunningham a suggéré une technique d'analyse de signature synoptique qui a donné une «impression» générale pour un programme en ne montrant que la ponctuation, comme les points-virgules et les accolades[9]. Dans la même logique, Cunningham a suggéré de visionner des programmes en police 2 afin de comprendre la structure globale[10]. Une autre technique identifiée lors de l'atelier était l'utilisation d'outils de programmation orientés aspect tels qu'AspectJ pour introduire systématiquement du code de traçage sans modifier directement le programme existant.

Les techniques d'analyse de réseau et d'historiques des modifications peuvent révéler les modèles d'activité collaborative des développeurs de logiciels hérités, qui à leur tour peuvent mettre en lumière les forces et les faiblesses des artefacts logiciels produits[11].

Michael Rozlog d' Embarcadero Technologies a décrit l'archéologie logicielle comme un processus en six étapes qui permet aux programmeurs de répondre à des questions telles que « De quoi est-ce que je viens d'hériter ? » et « Où sont les sections effrayantes du code ? »[12]. Ces étapes, similaires à celles identifiées par l'atelier OOPSLA, incluent l'utilisation de la visualisation pour obtenir une représentation visuelle de la conception du programme, l'utilisation de métriques logicielles pour rechercher les violations de conception et de style, l'utilisation de tests unitaires et de profilage pour rechercher les bogues et les goulots d'étranglement des performances, et rassembler les informations de conception récupérées par le processus. L'archéologie logicielle peut également être un service fourni aux programmeurs par des consultants externes[13].

Mitch Rosenberg de InfoVentions.net, Inc. revendique [réf. nécessaire] que la première loi de l'archéologie logicielle (il l'appelle l'archéologie de code ou de données) est : « Tout ce qui est là est là pour une raison, et il y a 3 raisons possibles :

  1. Cela avait besoin d'être là mais ce n'est plus le cas
  2. Cela n'a jamais eu besoin d'être là et la personne qui a écrit le code ne le savait pas
  3. Cela doit toujours être là et vous ne le savez pas ».

Le corollaire de cette « loi » est que, jusqu'à ce que vous sachiez quelle était la raison d'être du code, vous ne devez pas modifier le code (ou les données).

L'archéologie logicielle a continué d'être un sujet de discussion lors de conférences plus récentes sur le génie logiciel[14].

La profession de programmeur-archéologue figure en bonne place dans A Deepness in the Sky de Vernor Vinge[15].

Voir aussi

[modifier | modifier le code]

Notes et références

[modifier | modifier le code]
  1. ↑ (en) Gregorio Robles, Jesus M. Gonzalez-Barahona, Israel Herraiz, « An Empirical Approach to Software Archaeology », Poster Proceedings of the International Conference on Software Maintenance,
  2. ↑ (en) Scott W. Ambler, « Agile Legacy System Analysis and Integration Modeling », sur agilemodeling.com,  : « Without accurate documentation, or access to knowledgeable people, your last resort may be to analyze the source code for the legacy system... This effort is often referred to as software archaeology. »
  3. ↑ Bryon Moyer, « Software Archeology: Modernizing Old Systems », Embedded Technology Journal,
  4. ↑ Richard Hopkins et Kevin Jenkins, « Eating the IT Elephant: Moving from greenfield development to brownfield », Addison-Wesley,
  5. ↑ (en) Diomidis Spinellis et Georgios Gousios, Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design, "O'Reilly Media, Inc.", (ISBN 978-0-596-55439-2, lire en ligne), p. 29.
  6. ↑ Judith E. Grass, Object-Oriented Design Archaeology with CIA++, Computing Systems, vol. 5, no 1, hiver 1992.
  7. ↑ Andy Hunt, Dave Thomas, Software Archaeology, IEEE Software, vol. 19, no 2, p. 20-22, mars-avril 2002, DOI 10.1109/52.991327.
  8. ↑ a b et c Hunt et Thomas, « Software Archaeology », IEEE Software, vol. 19, no 2,‎ march–april 2002, p. 20–22 (DOI 10.1109/52.991327, lire en ligne)
  9. ↑ Cunningham, « Signature Survey: A Method for Browsing Unfamiliar Code », Workshop Position Statement, Software Archeology: Understanding Large Systems, OOPSLA 2001,
  10. ↑ Cook, « Software Archeology », The Endeavour,
  11. ↑ Cleidson de Souza, Jon Froehlich et Paul Dourish, Proceedings of the 2005 International ACM SIGGROUP Conference on Supporting Group Work, , 197–206 p. (ISBN 1595932232, DOI 10.1145/1099203.1099239), « Seeking the Source: Software Source Code as a Social and Technical Artifact »
  12. ↑ Rozlog, « Software Archeology: What Is It and Why Should Java Developers Care? », java.sys-con.com,
  13. ↑ Sharwood, « Raiders of the Lost Code », ZDNet,
  14. ↑ « 32nd ACM/IEEE International Conference on Software Engineering », .
  15. ↑ Rees, « Software archaeology and technical debt »,

Liens externes

[modifier | modifier le code]