Méthodes de réingénierie des logiciels.

Transcription

1 Université Saint Denis Paris VIII Méthodes de réingénierie des logiciels. Mémoire de Maitrise d informatique Option transversale Rédigé sous la direction de M. Le professeur Jean-François Degremont Par Depoortere Franck Département informatique Septembre 2002 Depoortere Franck - 1 -

2 Depoortere Franck - 2 -

3 Université Saint Denis Paris VIII 2, rue de la liberté, Saint Denis Cedex 02 Département Informatique Méthodes de réingénierie des logiciels. Mémoire de Maitrise d informatique Option transversale Rédigé sous la direction de M. Le professeur Jean-François Degremont Par Depoortere Franck Etudiant n franck@depoortere.eu.org Paris, Septembre 2002 Depoortere Franck - 3 -

4 Résumé: Un problème souvent rencontré dans l industrie du logiciel: on dispose d un logiciel et ses codes sources, mais on n a pas ou peu de documentation, et aucune possibilité de contacts avec les auteurs du code. A partir de ce code source, il faut reconstituer l architecture du logiciel, afin de l entretenir, de le faire évoluer, de le faire vivre. De nombreuses sociétés sont tombées devant ce cas difficile : un vieux logiciel Cobol qui l on doit convertir dans un nouveau langage. D innombrables systèmes bancaires utilisent pour partie d anciennes applications écrites dans d anciens langages, que l on doit maintenir ou transformer régulièrement. Ces dernières années, d ailleurs, les entreprises ont vécu avec l an 2000 et l Euro les deux plus grandes opérations de maintenance que l informatique n'ait jamais connue. La maintenance des applications est une préoccupation majeure pour les applications de grande taille. Le problème de maintenance du logiciel est souvent du à l'incohérence qui existe entre le code source et la documentation. C est une phase de plus en plus coûteuse par rapport aux phases de développement. Les outils développés pour la maintenance ne sont pas encore efficients. Les publications sur la maintenance ont été plutôt rares comparativement aux publications sur le développement, abondamment fourni. Dans les années 80, le terme restructuration a été remplacé par le terme réingénierie. La réingénierie est devenue très importante pour l'évolution d'une application. Son rôle est d'améliorer la maintenabilité des systèmes existants. On peut la définir comme un processus de récupération d'une application existante. La réingénierie inclut la rétro-ingénierie, la restructuration, l ingénierie en avant, et redocumentation. Pour ne pas échouer, les projets de réingénierie doivent être conduit par des processus élaborés, formalisant leur déroulement, le suivi des étapes conduisant au bon déroulement du projet. Certains prônent la fusion des outils de conception, devenus désormais abondant, compatibles avec la représentation UML, et complémentaires, et les outils de maintenance qui font figure de parents pauvres de l industrie logiciel. Nous nous sommes mis dans la situation d une application non documentée, et nous avons appliqué des méthodes de retro-ingénierie. Nous sommes parvenus à re-documenter l ensemble du code, à décrire l architecture de l application dans le but, d une part d une reprise plus aisée par d autres développeurs, et pour entamer d autre part quelques modifications fonctionnelles sur le logiciel. Depoortere Franck - 4 -

5 Mots Clés : UML Centre for Software Maintenance AGL outils CASE : Un atelier de génie Logiciel est un logiciel aidant à la réalisation de logiciels. Un AGL est basé sur des méthodologies qui formalisent le processus logiciel, et à l'intérieur de ce processus, chacune des phases qui le composent. génie logiciel : «Le génie logiciel est l'ensemble des activités de conception et de mise en oeuvre des produits et des procédures tendant à rationaliser la production du logiciel et son suivi» (arrêté du 30 déc. 83) cycle de vie du logiciel retro-conception / rétro conception Ingénierie inverse / reverse engineering : Le jargon français définit les rétro techniques utilisées dans le reverse engineering (ou ingénierie inverse) de la manière suivante : En général, il s'agit de décompiler ou de désassembler un programme, c'est-à-dire de prendre quelque chose de compréhensible par une machine mais pas par un être humain et d'en faire quelque chose de lisible pour un homme mais plus pour un ordinateur. Dans la pratique, le reverse engineering consiste à analyser le fonctionnement d'un programme ou d'un périphérique (typiquement en analysant la communication qu'il a avec le reste du système), ou alors en examinant pas à pas les résultats de son exécution. La réingenierie (reengineering) : La réingenierie est le processus d analyse et de modification d un logiciel afin de le reconstituer dans une forme améliorée. C est une technique consistant à déterminer l'utilité d'un objet que l'on voit pour la première fois, en analysant cet objet. On est amené à se poser des questions comme : «Si j'avais voulu fabriquer une machine ayant telle fonction, aurais-je réalisé cet objet précis?», ou «Cet objet pourrait-il être une machine qui a telle fonction?». Voir rétrotechnique. cross - compilation pour transférer une application, un module, d'un langage ancien vers un nouveau ; Rétrotechnique : Littéralement, «technique inverse». En général, il s'agit de décompiler ou de désassembler un programme, c'est-à-dire de prendre quelque chose de compréhensible par une machine mais pas par un être humain et d'en faire quelque chose de lisible pour un homme mais plus pour un ordinateur. S'écrit aussi «Rétro-Technique». S.I.G. : Système d Information Géographique. Un système d Information Géographique est un outil informatique permettant de représenter et d analyser toutes les choses qui existent sur terre ainsi que tous les événements qui s y produisent. Les SIG offrent toutes les possibilités des bases de données (telles que requêtes et analyses statistiques) et ce, au travers d une visualisation unique et d analyse géographique propres aux cartes. Les enjeux majeurs auxquels nous avons à faire face aujourd hui (environnement, démographie, santé publique ) ont tous un lien étroit avec la géographie. Depoortere Franck - 5 -

6 Sommaire : RESUME:... 4 MOTS CLÉS :... 5 SOMMAIRE :... 6 LISTE DES TABLEAUX... 8 LISTE DES FIGURES... 8 LISTE DES SIGLES ET ABREVIATIONS... 8 REMERCIEMENTS... 9 CHAPITRE 1 : INTRODUCTION CHAPITRE 2 : LA MAINTENANCE "!$# % & '"()+* &,- "!$. /+0 -(1 + 0* + * 2$ +* 435,5 "! 6 / () : ;+*& 0, "! < = '>? ;+ "! < CHAPITRE 3 : LA REINGENIERIE DU CODE :... A()+,B C D % 0 +: E2$ +* F GH 83I 5 CI! /+I(1 : &,J CI! CHAPITRE 4 : LA CRISE DU LOGICIEL... 25! " # $ # % CHAPITRE 5 : LE PROCESSUS LOGICIEL, OU CYCLE DE VIE DU LOGICIEL KL * ;&* &F * M C N KL * ;&PO1 # D KL * ;&F (1 #I! /+ * ;&* 9Q? R,S # # /+ * ;&*)T U : # V /+ * ;&* &? 21 #I6 " CHAPITRE 6 : LA PRESENTATION DES DONNEES & # Depoortere Franck - 6 -

7 -K /, 0 GH * ; # N / T? *1T -K /. D ' ( = '>? ;,. V $ CHAPITRE 7 : APPLICATION: RETRO-INGENIERIE D UN VIEWER DE DONNEES CARTOGRAPHIQUES " ) ) # $ * ) $ * + CHAPITRE 8 : CONCLUSION REFERENCES : BIBLIOGRAPHIE : Depoortere Franck - 7 -

8 Liste des tableaux ", Liste des figures - ' *. ( + + " FIGURE 6.2 : LE MODELE EN V " " % " + ) + " ", " & & & $ + / + $ ) # $ * + $ * 0 0 Liste des sigles et abréviations CASE AGL API CASE DTD IEEE OMG SIG UML XML Computer Aided Software Engineering Atelier de Génie Logiciel Application Programming Interface Computer-Aided Software Engineering Document Type Definition Institute of Electrical and Electronic Engineers Object Management Group Système d'information Géographique Unified Modeling Language Extensible Markup Language Depoortere Franck - 8 -

9 Remerciements En premier lieu, je tiens à remercier mon directeur de recherche, Jean-Francois Degremont. Son encadrement, et sa disponibilité m ont grandement aidé pour réaliser mon projet dans mes conditions particulières de salariés à plein temps. Ses remarques pertinentes et éclairées m ont permis de mieux structurer mon travail, mes idées et, de mieux les décrire. Je remercie également ma sœur qui m a aidée à sa manière afin que je puisse terminer mon mémoire. Enfin, je remercierai les dirigeants de la Société ConnectSuite, dans laquelle j ai travaillée 2 ans en tant que développeur, qui m on fait profiter des locaux et du matériel informatique lors du développement du projet. Mes remerciements vont aussi à tous mes ami(e)s pour leur soutien moral. Depoortere Franck - 9 -

10 Chapitre 1 : Introduction Les développements informatiques constituent désormais un facteur économique important qui conditionne la croissance, la mutation et la survie de la plupart des secteurs de l économie moderne. Incontournable, l informatique s est donc imposée comme un outil stratégique aux chefs d entreprise, mais la plupart ignorent que 53% des projets dérivent ou ne satisfont pas les utilisateurs et que 31% sont abandonnés avant leur mise en exploitation (sources 1996 : Standish Group et Sema Group). Ces chiffres sont édifiants mais non surprenants. Peut-on imaginer de construire un immeuble de 20 étages sans faire de plans, sans organiser la succession des différentes étapes de constructions. C est pourtant ce que l on fait couramment en informatique. Durant les trois dernières décennies, peu d organisations utilisaient des processus de qualité, formalisés, détaillés, complets et spécialisés pour guider leurs développements. Au mieux, une approche de modélisation comme Merise ou une méthodologie de conduite de projet proposaient quelques grandes lignes directrices. Les statistiques résultantes de ces pratiques sont éloquentes quant à leur efficacité et à leur effectivité, ce qui n est pas la même chose. L histoire des développements informatiques est celle d'une série de catastrophes le plus souvent bien dissimulées. Le constat statistique de 84% d échecs relatifs ou totaux met en évidence la réalité d un problème que la complexité des applications et des technologies amplifie dramatiquement. Des centaines, des milliers d années d ingénieurs ont été ainsi englouties en pure perte dans des projets pharaoniques aux frontières du réel. Une réingénierie des procédés de développement s impose. L objectif de ce mémoire est d identifier les problèmes auxquels sont confrontés les communautés de maintenances logiciel, et de proposer des solutions à mettre en place dès la conception du logiciel, et tout au long de sa vie. Si beaucoup de projets de développement échouent par manque de méthodes, il existe également beaucoup de projets de reingénierie qui échouent également par manque de procédures. La réingénierie s effectue bien-sur plus aisément lorsque le produit logiciel a suivie des règles de développements, de documentation évoluées. Car c est lors du développement et même lors de la conception que l on prépare la phase de maintenance du logiciel. Le maître mot de notre concept sera donc l emploi de méthodes, de procédures de suivi, de contrôle de processus. La mise en place de processus a un coût que certaines entreprises pensent économiser en ne les respectant pas, mais elle sont indispensable dans la vie d un logiciel. Lorsqu un logiciel ne peut évoluer, il disparaît. Contexte de la recherche : Ce projet a été réalisé dans le cadre de la reprise d un logiciel de cartographie, nommé «Compilo Graphic Database» déjà utilisé par quelques départements et communes Francaises, afin de visualiser de informations sur des cartes, d effectuer des études et statistiques sur leurs réseaux routiers, le trafic, et exploiter toutes autres informations stockées dans la base de données du logiciel. Le projet consiste à reprendre le projet, abandonné depuis maintenant plusieurs années, et effectuer un travail de maintenance sur l ensemble de l application. Cette étude comprend d abord un objectif de redocumentation du code source, du design global de l application, mais également de petites modifications, des améliorations, des corrections de comportements de l application. Le travail se découpera en plusieurs étapes : - Nous commencerons par un travail de recherche afin de reconstituer à partir des quelques documents commentant l application, une documentation énumérant les fonctionnalités de l application, coté utilisateur. Depoortere Franck

11 - nous passerons ensuite au code source, nous définirons l architecture du logiciel, et les aspects fonctionnels des modules composant le projet, puis nous effectuerons un travail de documentation du code source. Les buts à atteindre sont d une part de remonter l indice de maintenabilité du logiciel, et de rendre l application plus aisément reprenable par les prochains développeurs, et d autre part d effectuer des corrections, et changements de comportements sur le logiciel. Structure du mémoire : Le mémoire est organisé de la façon suivante : Le chapitre 2 définie le terme de maintenance, et propose une vue synthétique sur le monde actuel de la maintenance logiciel, ces défauts, des types de maintenances appliquées au logiciel en production. Le chapitre 3 définie les grandes étapes de ce qu on nomme la «réingénierie», c est à dire la rétro-ingénierie, la redocumentation, et la restructuration et le but de reingénierie, à savoir l amélioration de la compréhension du logiciel, l amélioration du logiciel lui-même, et enfin l amélioration du niveau de maintenabilité et d évolution et de réutilisation de l application.. Le chapitre 4 met en lumière l échec actuel des procédures d ingénierie logicielle, du manque de méthodes et de processus employés dans l industrie informatique. Le chapitre 5 introduira l étude et l emploi de modèles formels connus de procédures de développement et de maintenance dans le cycle de vie des logiciels. Dans le chapitre 6, nous allons introduire deux progrès récents dans le monde du développement Orienté Objet (OO) que nous supportons dans notre approche, à savoir, le langage UML qui est un langage visuel pour la modélisation des systèmes OO, ainsi que les patrons de conception qui permettent de documenter et de communiquer l expertise en matière de conception logicielle OO. Enfin, dans le chapitre 7, nous mettrons en pratique nos théories en effectuant une procédure de réingénierie sur un outils de cartographie en production depuis 5 ans. Il s agira d effectuer des représentations, de retrouver l architecture globale du logiciel, d ajouter un module d aide utilisateur, et d effectuer un travail de redocumentation, de corriger les bugs identifiés, et enfin d énumérer les changements à effectuer. Depoortere Franck

12 Chapitre 2 : La maintenance Alors que les entreprises viennent de vivre avec l an 2000 et l Euro les deux plus grandes opérations de maintenance que l informatique ait jamais connues, le thème de la maintenance n occupe qu une place modeste dans la presse spécialisée et les séminaires professionnels. Faut-il en conclure que la maintenance n est plus une préoccupation majeure des responsables informatiques? La réalité du terrain vient contredire cette apparente indifférence. En effet, la maîtrise de la maintenance devient des plus critiques pour les raisons suivantes : Les coûts de maintenance, déjà très importants, continueront de croître et deviendront d autant plus visibles que le prix des matériels diminuent. La rapidité d adaptation des entreprises à l environnement économique est un facteur clé de réussite. Cette flexibilité est conditionnée par leur capacité à faire évoluer rapidement leurs applications stratégiques, c est à dire à maîtriser la maintenance évolutive. Les entreprises doivent également maîtriser la maintenance adaptative si elles veulent ouvrir leurs applications existantes (saisie de commande, suivi des livraisons, ) au client final via des infrastructures de type Internet. En ouvrant leurs applications à l Internet les entreprises affichent leur niveau de qualité. Elles doivent donc maîtriser leur processus logiciel, notamment leurs activités de maintenance (corrective, adaptative, perfective et évolutive). Soulignons de plus que la problématique de la maintenance ne concerne pas uniquement les vieilles applications qu il suffirait de remplacer pour éliminer le problème. En fait, dès qu une application nouvelle est mise en production elle entre dans le cycle de maintenance. Il est essentiel pour un gestionnaire de systèmes de bien gérer la maintenabilité pour planifier et contrôler adéquatement les projets de maintenance. Puisqu'on ne peut gérer ce qu'on ne peut pas mesurer, il apparaît nécessaire de pouvoir quantifier la maintenabilité pour bien gérer la maintenance. Nous discutons aussi des approches pour estimer cet indicateur durant la phase de développement. Nous tentons également de clarifier le concept de maintenabilité, et de le distinguer des autres caractéristiques du logiciel. Il est inutile de produire un logiciel s il ne peut être compris et utilisé par ses développeurs, et s il est très difficile, voire impossible à modifier. Définition de la maintenance : La maintenance, ce n est pas seulement la détection et la correction des erreurs trouvées dans un programme. On trouve différentes définitions de la maintenance logiciels. Des acteurs important du domaine définissent l activité de la façon suivante : 1. L organisme de standardisation des logiciels, L IEEE, définie dans la référence «software maintenance standard», IEEE STD , le terme de maintenance logiciel comme ceci : «la modification d un logiciel après son entré en production, afin de corriger ses erreurs, d améliorer ses performances et autres attributs, ou pour adapter le produit à son environnement» 2. Martin et Mc Clure, éminents théoriciens du domaine définissent la maintenance comme «Les changements effectués sur les programmes informatiques après livraison à leurs utilisateurs» 3. Von Mayrhauser: «La maintenance couvre le cycle de vie des systèmes logiciels à partir de leur mise en production jusqu'à la fin de leur utilisation.» Le thème commun de ces multiples définitions est que la maintenance est une activité qui poursuit la réalisation d un travail. L activité de maintenance commence dès la mise en production du logiciel. Depoortere Franck

13 Pourquoi la maintenance est nécessaire? Pour répondre à cette question, on se doit simplement d observer la mise en production d un logiciel livré à des utilisateurs. Lorsque les premiers utilisateurs vont utiliser le produits, ils vont trouver de nombreux problèmes, et disfonctionnements, et trouver d innombrables fonctions à rajouter. Ces changements vont être demandés aux mainteneurs de l application, qui vont corriger et améliorer le système. Puis les utilisateurs vont s adapter aux changements et nouvelles fonctionnalités et à nouveau perturber les mainteneurs. Dans la plupart des cas, le cycle de maintenance d un logiciel constitue la plus grosse part de son cycle de vie, en temps et en argent. Cette maintenance sans fin se justifie par le fait qu une application doit sans cesse évoluée pour continuer à être utilisée, et ne pas mourir. Environnement organisationnel Besoins des utilisateurs Maintenance Application Logiciellle Process et personnel Influence Environnement opérationnel Figure 2.1 : Inter-relation entre les différents facteurs influençant la maintenance logicielle Faits et chiffres Deux études américaines (General Accounting Office), menées sur un nombre conséquent de projets informatiques dans les années 90, illustrent bien la problématique de la maintenance : L étude identifie les 3 facteurs les plus négatifs rencontrés dans la maintenance : 1. L absence de processus de maintenance logicielle (73% des cas). 2. Le manque de documentation à jour (68% des cas) qui se traduit par sa non-utilisation. 3. Le manque de temps pour mettre à jour la documentation (54% des cas). Elle démontre également que les coûts de maintenance augmentent dans le temps au fur et à mesure que les multiples modifications apportées au code rendent les interventions de plus en plus complexes. Depoortere Franck

14 Quatre types de maintenance : Maintenance Adaptative Maintenance Corrective Maintenance Corrective Maintenance Préventive Implique Figure 2.2 : Relations potentielles entre les différents types de maintenance logicielle Maintenance corrective : La maintenance corrective ce réfère aux modifications initiées du aux défauts du logiciel. Ces défauts peuvent résulter d erreur de spécifications, de choix d architecture ou d erreur de programmation, ou de tests invalides ou incomplets. Les défauts peuvent également provenir de problèmes de performances ou de traitements de données. Ces erreurs sont souvent nommées «erreurs résiduelles», empêchant le logiciel d être conforme aux spécifications. Lors de l apparition de problèmes bloquants sur un système, la maintenance résout le problème en proposant des «patchs». Maintenance perfective : Ce terme est utilisé afin de décrire les changements mis en œuvre afin d étendre le système et d améliorer l'efficacité d'un système d'information en exploitation. Une application tend à devenir performante grâce à la succession de changements résultant de l accroissement des fonctionnalités. Imaginons une application faite sur l architecture constituée d un noyau central et des multiples modules implémentant les fonctionnalités du logiciel. On peut dans ce cas, ajouter à volonté de nouvelles fonctionnalités, à la demande des utilisateurs. Durant les diverses étapes, le système évolue grâce à l ajout de petits programme, ou modules, facilement intégrable, aisément maintenable. On constitue ainsi une grosse application offrant une bonne résistance à la modification. Ce peut donc être l ajout de nouvelles fonctionnalités ou la redéfinition de fonctions existantes, ou la suppression, de fonctions inutiles ou redondantes, alourdissant inutilement le système. Maintenance adaptative : Elle a pour but d'effectuer les modifications nécessaires pour adapter un système d'information aux changements. Même en l absence d erreur résiduelle, une application est vouée à changer pour s adapter à l environnement. Lorsque l on emploi le terme d environnement dans notre contexte, on se réfère aux conditions influençant le système : Par exemple, les règles fiscales, les changements de stratégies commerciales, les changements de législation, les changements de plates-formes, ou de Depoortere Franck

15 matériel. Tous ces facteurs sont des éléments déterminant l adaptation des logiciels, à de nouvelles contraintes. La maintenance adaptative inclus tout travail autours d une plate-forme, d un OS ou d un compilateur différent. Elle peut être rendue nécessaire afin d améliorer les performances d une application pour cause de demandes accrues et donc migrer par exemple d un système séquentiel de traitement de taches, vers un système de traitement en parallèle. Similairement, des applications peuvent être portées sur d autres plates-formes afin de tirer avantage d un nouvel OS, ou le support d une nouvelle base de données, pour des gains de performances, une sauvegarde plus facile, ou une résistance à la défaillance accrue. Un exemple de maintenance adaptative, pour cause de changement de règle économique, est le passage à l Euro. Tous les systèmes d informations bancaire ont du être adaptés pour supporter la nouvelle monnaie. Maintenance préventive : La maintenance préventive a pour but d'anticiper tous les problèmes possibles. Les phases de maintenance corrective, adaptative, et perfective peuvent être considérées comme des travaux qui détériorent généralement peu à peu la structure de l application si aucun travail de maintient n est réalisé. Ce travail constitue des changements préventifs. La maintenance préventive est une entreprise de prévention de disfonctionnement, ou d amélioration de la maintenabilité du logiciel. Ces changements sont souvent initiés par le département de maintenance souhaitant rendre plus simple la compréhension ou la structure du programme pour des futurs travaux de développement. Les changements préventifs ne donnent généralement pas d amélioration substantielle des fonctions de base. Le changement préventif peut être une restructuration du code, ou la mise à jour de la documentation. La mise à jour du système documentaire est fréquemment oubliée. Les documents affectés par les changements doivent être modifiés afin de refléter l état courant du système. En principe, les activités de maintenance logiciel peuvent être classées dans ces quatre catégories. En pratique, elles s entremêlent souvent. Par exemple, lors de l adaptation d une application à un nouvel OS, donc une activité d adaptation, de curieux bugs peuvent apparaître. On effectue donc une correction dans une maintenance corrective. Similairement, l activité d amélioration d algorithme peu impliquer la restructuration du code, et donc une activité de maintenance préventive. Pourtant, malgré l enchevêtrement des ces diverses activités, il est bon de garder la distinction entre les différents types de changements. En premier lieu, ceci permet d allouer des niveaux de priorités aux demandes de changements. Certains changements requièrent des réponses plus rapides que d autres. Depoortere Franck

16 Les implications économiques des modifications de logiciel : Une proportion substantielle des ressources dépensées dans les l industries logicielles sont versées dans la maintenance. Dans les années 90 95, 70% des dépenses de développement logiciel ont été occupée par des activités de maintenance, et seulement 30%, par les nouveaux développement. Les coûts de maintenance croissent de 10% chaque année, suivant la tendance de grossissement, de complexification des applications informatiques. Une étude réalisée aux USA, auprès de 490 sociétés éditrice de logiciels, ont ressorti les statistiques des différentes catégories de maintenance. La maintenance corrective comptait 20% du temps, adaptative 25%, 50% du temps était dédié aux perfectionnements et enfin, 5% était occupé par la maintenance préventive. Chaque application représente un grand investissement financier et ne peut être écartée suite à l'arrivée d'une nouvelle technologie. Abandonner un système et développer un nouveau devient pour la plupart de compagnies très dispendieux. Alors on essaie une alternative : ajouter de nouvelles fonctionnalités dans le système actuel et s'assurer qu'il soit compatible avec les autres systèmes. Les entreprises fournissent un effort considérable pour mettre en œuvre les modifications souhaitées par l'utilisateur. Il est très important d'être en mesure de réaliser ces modifications sans affecter la qualité des applications. Les systèmes d'exploitation par exemple, demeurent en exploitation plus longtemps que prévue, et restent en maintenance et en exploitation plusieurs dizaines d années. On peut citer certains systèmes bancaires conçus dans les années 70 écrites en Cobol, toujours en activité à l heure actuelle. Le département de la défense américaine a un budget alloué pour la maintenance supérieur à 5,5 milliards $ par année, soit 60% du budget total de 9 milliards dédié aux développement des systèmes informatiques. On trouve des applications crées même dans les années Le grand nombre et types d'applications et l étendue des centres ont crée de gros problèmes, parce que la plupart des applications avaient été crées sans utiliser un standard de développement. La DISA (Defense Systems Agency) et le DAPMO (Data Administration Management Office ) ont été chargé du développement d'une structure standard pour les applications du ministère de la Défense, afin de pallier les difficultés d entretient de ces gros systèmes. Le fait de ne pas mettre la documentation à jour ne fait que rendre la compréhension éventuelle du système plus difficile. Il est très fréquent de trouver des systèmes de logiciels dotés d'une documentation incomplète ou quasi inexistante. Le coût de la maintenance a eu une croissance exponentielle et couramment on l'estime entre 50 à 80 % du budget total du système informatique. Au cours du développement d'un logiciel, les exigences des utilisateurs varient énormément. Comme résultat, les changements des spécifications au niveau de la documentation sont souvent retardés en raison de plusieurs contraintes, comme les échéanciers de livraison et les coûts. Ce qui explique l'absence de la documentation de certaines fonctions ou l'incohérence du code par rapport à la structure conceptuelle de la plupart des systèmes existants. Les entreprises n'ont pas de philosophie de maintenance claire et articulée malgré le fait qu'elles utilisent des méthodes structurées pour la conception ou le développement des applications. la maintenance est très mal planifiée et on surveille peu l'exécution des travaux de maintenance. Depoortere Franck

17 Les solutions aux problèmes de maintenances : En se basant sur l observation que la maintenance logiciel coûte au moins autant que les nouveaux développements, certains proposent de mettre moins de ressources sur la maintenance des systèmes difficilement maintenable et de consacrer davantage de temps dans le développement, la spécification et le design de systèmes plus maintenable. Il est maintenant convenu que l utilisation d approches plus avancées dans les spécifications, les techniques et les outils de design, et les processus d assurance qualité, durant le cycle de développement des logiciels procurent des systèmes beaucoup plus maintenable à long terme. Les phase de maintenance sont obligatoires, car le remplacement complet des systèmes ne donne pas la garantie d un fonctionnement meilleur que l ancien. On découvre même souvent que les nouveaux logiciels ont des erreurs sur des fonctionnalités que l ancien système gérait parfaitement. En effet, il est impossible qu un nouveau système soit totalement parfait et sans erreur. L ancien système possède intrinsèquement des richesses d expérience, un réservoir d idées que les nouveaux systèmes sont souvent incapables de reprendre. Le complet remplacement des systèmes n est souvent pas une bonne solution. L alternative est de rendre le système potentiellement capable d évoluer, de rendre son management plus sophistiqué et plus facile à gérer. Synthèse Nous avons donc défini le terme de maintenance comme la modification d une application en production, afin de corriger les erreurs, d améliorer ses performances ou de l adapter à un environnement ou des contraintes modifiées. La maintenance logicielles peut donc être percue comme la continuité naturelle du développement, malgré des différences sur certains points. La qualité du logiciel en production influence directement la productivité de la maintenance. Les activités de maintenance sont constituées par les changements correctifs, adaptatifs, perfectifs et préventifs. En pratique, ces activités s entremêlent souvent. Les coûts de maintenance des systèmes tournent souvent autours de 40 à 70% des ressources allouées tout au long du cycle de vie du logiciel. Les problèmes de maintenance sont souvent liés à un code non structuré, ou à une documentation incomplète ou inexistante. Les solutions aux problèmes de maintenances se trouvent souvent dans l investissement de davantage de ressources sur les méthodes employées lors des premières phases de développement du logiciel pour avoir des systèmes plus maintenable. Le remplacement total des applications est souvent économiquement non viable. Les solutions employées sont donc la restructuration, le reverse ingeniering. Depoortere Franck

18 Chapitre 3 : La réingenierie du code : Depuis de nombreuses années, l industrie du logiciel s était concentrée sur le développement de nouvelles applications. La plupart des efforts de recherche étaient investis dans la création de procédures de développement plus efficaces, améliorant la qualité du logiciel, réduisant le temps de développement et sa mise sur le marché. En se focalisant sur ces aspects de développement, un autre aspect du cycle de vie du logiciel, la maintenance de l application, n obtenait qu une attention insuffisante dans le cycle de production. La pression du marché rendait les cycles de production très courts. Il en résultait une situation ou la plupart de versions de logiciels ne rentraient jamais en phase de maintenance, mais étaient sans cesse remplacées. Beaucoup de sociétés ont du faire face à de sérieux problèmes lorsque les systèmes d informations étaient devenus si complexe, si gros et représentaient des couts d investissements tels, qu elles ne pouvaient plus changer leur système d information par un nouveau. Il n est donc pas rare de voir des grandes compagnies garder leur système une quinzaine d années, et donc organiser une maintiennent régulièrement. Pourtant, leurs applications, fruit de nombreuses années de modifications de développements non structurés et de maintenances non documentées devenaient des amas d informations non documentées et de savoirs perdus. Ce savoir était présent dans la tête de quelques ingénieurs qui avaient souvent quitté l organisation, l information était donc perdue. Remplacer l application par un nouveau système peut avoir de gros effets pervers. Dans certains cas, les nouvelles applications risquent d avoir des fonctionnalités ne répondant pas aux besoins. Afin d éviter ces problèmes, la solution alternative est la rétro-ingénierie. De 50 à 75 % de l'effort logiciel est consacré à la maintenance de systèmes. La productivité des équipes de maintenance est fortement influencée par la maintenabilité. Il est donc essentiel pour un gestionnaire de systèmes de bien gérer la maintenabilité pour planifier et contrôler adéquatement les projets de maintenance. Un logiciel est le fruit de plusieurs années de recherche, et d énormes investissements financiers. Malgré cet investissement, certains logiciels sont abandonnés du fait des difficultés parfois trop importantes pour les maintenir, les modifier. Ceci peut être du à une perte du savoir-faire, à l impossibilité de contacter les auteurs du code. On préfère dans ce cas refaire en partie ou totalement l application. Que de travail, de savoir-faire, de temps et d argent perdu On inclut dans la réingénierie d un logiciel, les étapes de rétro-ingénierie, «d ingénierie en avant», de restructuration, et enfin de redocumentation. La rétro-ingénierie représente la première étape de la réingénierie qui consiste à effectuer le chemin inverse par rapport au processus de développement. On pourrait la définir comme le contraire de l'ingénierie autrefois nommée "forward engineering". Le reverse engineering est une partie indispensable de la maintenance logiciel, puisque celle-ci ne peut être réalisée sans une compréhension complète du système. Parfois, la compréhension d'un logiciel est si complexe en l'absence de toute documentation, que la tache est presque impossible. C'est la raison pour laquelle la retro-ingénierie est un processus qui a pour rôle de comprendre les différentes informations inconnues ou cachées du système logiciel. La redocumentation constitue la forme la plus ancienne du processus de rétro-ingenierie puisque c est la révision ou la création des représentations équivalentes à un code source donné. La restructuration est la transformation d'une forme de représentation en une autre au même niveau d'abstraction en préservant l'interface externe du système. On peut utiliser la restructuration afin d'adapter un système à de nouvelles contraintes, ou comme maintenance préventive pour améliorer l'état physique du système en respectant par exemple des standards existants. Depoortere Franck

19 La rétro-ingénierie On l utilise pour accroître la compréhension du système ou pour remplacer une partie du système. La rétro-ingénierie représente la première étape du processus de réingenierie et constitue une portion très importante du processus de réingenierie dans son ensemble. Il existe des similitudes entre la retro-ingénierie logiciel et dans le monde matériel lorsque l on étudie le produit d un compétiteur afin d en trouver sa conception et ses secrets de fabrication. Dans ces cas précis, la documentation n est pas fournie... Dans le monde logiciel, le code du système et sa documentation sont souvent incohérentes, en raison de plusieurs changements de code, qui n ont pas fait l objet d une mise à jour de la documentation. La rétro-ingénierie part du code source, retrace ou recrée les décisions de conception et déchiffre les exigences mises en œuvre par le système, en permettant d identifier les différents modules du système et leurs relations. Ces taches sont la plupart du temps exécutées à la main. Les approches de base de la compréhension sont : L approche systématique ou on examine le programme en entier en identifiant les interactions entre les modules. L approche pragmatique qui essaie de trouver les sections ou se trouvent les composants du programme à modifier, mais qui ouvre le risque à l omission de composantes qui peuvent influencer le comportement d autres composantes. La lecture du code représente une méthode intéressante pour comprendre une application. La méthode «top down» donne des programmes assez lisibles. Toutefois, le style de conception des applications à une grande influence dans le processus de compréhension. Un programme écrit par une seule personne sera souvent moins lisible que celui d un groupe de travail. Pour les grands programmes les noms de variables significatifs simplifient la conversion d'une représentation syntaxique en une représentation sémantique. Pour automatiser la lecture du code on utilise les techniques statiques et dynamiques : L analyse statique est l analyse d un programme sans son exécution afin d identifier des variables non initialisées, l identification du code non utilisé, produire des algorithmes d analyse incrémentale pour mettre à jour un système sans ré-analyser le système en entier. L analyse dynamique, c est l analyse des applications avec leur exécution. Le but de la rétro-ingénierie est d identifier les composantes du système et leurs relations, et de créer des représentations du système dans une forme ou un plus haut niveau d abstraction. La rétroingénierie n entraîne pas un changement du système ou la création d un nouveau système. La plupart des ingénieurs logiciel préfèrent le développement plutôt que le maintient d anciens systèmes. La rétro-ingénierie est un retour en arrière par rapport au processus de développement. C est un travail perçu comme moins enthousiasment et assez fastidieux. Il n en est pas moins important. Pour générer une description on a besoin d'identifier : Les modules qui peuvent être des fonctions simples ou une série de fonctions ; Les ressources échangées entre les modules, les types de données, les variables et les procédures ; Les propriétés fonctionnelles identifiées avec l'aide des assertions qui caractérisent les ressources ; Les propriétés dynamiques par la conversion de l'algorithme de bas niveau dans un langage de spécification ; Un système est composé d'une hiérarchie de sous-systèmes qui doivent être identifiés ; Avec l'analyse statique on identifie les propriétés structurelles des modules. Depoortere Franck

20 Le processus de rétro-ingénierie commence par l'extraction de l'information de conception à partir du code source et de la documentation existante. Des abstractions de hauts niveaux sont extraites à partir de cette information. Ces représentations de conception sont exprimées par des diagrammes de structure, de flux de données et de flux de contrôle. Etapes : 1. La collecte de l'information : C'est un rassemblement de toutes les informations possibles sur le programme. Les sources d'information peuvent comprendre le code source, les documents et les personnes connaissant le système. 2. L'étude de l'information : Il s'agit de la revue des informations rassemblées. Cette étape permet aux intervenants de se familiariser avec le système et ses composantes. Un plan pour analyser le programme et enregistrer l'information récupérée, peut être formulé durant cette étape. 3. L'extraction de la structure : Il s'agit de l'identification de la structure du programme et de la création d'un ensemble de diagrammes de la structure. Chaque nœud dans un diagramme de la structure correspond à une routine appelée dans le programme. Chaque arrête dans le diagramme représente les entrées/sorties des données dans les nœuds. 4. L'enregistrement des fonctionnalités: Pour chaque nœud dans les diagrammes de structure, il faut enregistrer le traitement effectué dans le programme. La fonctionnalité peut être décrite en langage naturel ou en une notation plus formelle. 5. L'enregistrement du flux de données : La structure du programme récupéré peut être analysée pour identifier les transformations des données dans le système. Ces étapes de transformation montrent le traitement des données réalisé dans le programme. Cette information est utilisée pour développer un ensemble de flux de données hiérarchique qui modélisent le système. 6. L'enregistrement du flux de contrôle : Il s'agit de l'identification de la structure de contrôle de haut niveau qui affecte l'opération générale du système. 7. Passer en revue la conception récupérée : C'est la vérification de l'exactitude des informations disponibles. Il faut détecter les items d'informations manqués et tenter de les récupérer, vérifier si l'information de conception récupérée représente correctement le programme. 8. La génération de la documentation : C est l'étape finale de la documentation de conception. Depoortere Franck

21 Quelles sont les bénéfices de la rétro-ingenierie? Il est plus facile de modifier le code existant que de recommencer à nouveau. Ces options, parfois inéluctables, ont l inconvénient d être risquées, car de type " big bang ", et coûteuses. On trouve dans le code existant des informations sur l application qui pourraient ne pas exister ailleurs. La possibilité d utiliser les outils CASE On améliore le potentiel de réutilisation du code, des objets. On améliore souvent l application en la rendant plus claire, plus fiable, plus maintenable et on augmente la qualité du programme. Des outils existent aujourd hui, pour la rendre plus facile et automatique Elle est très utile pour les outils stratégiques qui ont une longue durée de vie. Elle est indispensable pour la maintenance du système La problématique : Beaucoup d anciens systèmes ont été développés de facon «artisanale», au fur et à mesure des besoins des utilisateurs, sans s appuyer sur des règles de développements précises ou des outils de conception, et souvent sans aucune documentation ou avec une documentation qui est totalement inutile. En conséquence, les ressources nécessaires pour faire fonctionner l'application consomment entre 50% et 90 % du temps de maintenance. Les coûts sont en croissance parce que chaque nouvelle fonction va augmenter les coûts de la maintenance. Il devient de plus en plus difficile de faire des changements. Le temps nécessaire pour faire les changements augmente progressivement et des opportunités d'affaires pourraient être perdues. L investissement des des procédures de rétroingénierie permet de résoudre ces problèmes. Après la rétro-ingénierie il faut s'assurer que le système satisfait la plupart des standards qui ont été appliqués aux systèmes et il faut faire de la retro-ingénierie une part de qualité du système. Une documentation de qualité doit être produite, il faut inclure dans le plan une représentation graphique de la retro ingénierie. Les outils statiques peuvent être appliqués pour vérifier la conformité entre le code et le «coding standards ". Les outils des mesures donnent la possibilité de comparer la complexité du logiciel avant et après la restructuration. Pour que la phase soit totalement complète et tracable, la conduite du processus de rétro - ingénierie doit être décrite, afin de vérifier la qualité, la conformité de la tache effectuée. On nomme se document le REQP (Retro-Engineering Quality Plan ). La documentation produite est à plusieurs niveaux de détails. Il faut mettre en place une gestion de toutes les versions de retro-ingénierie réalisées, pour avoir une vue d'ensemble de tous les processus et produits réalisés. Ce document va permettre de valider la qualité du produit logiciel, en répondant aux questions suivantes : - Est-ce que la documentation satisfait les standards? - Est-ce qu'elle est clairement et correctement décrite? - Est-ce que le système est compréhensible pour la maintenance future? La vérification peut être faite par l'introduction d'une revue après un jalon dans le projet. La plupart des standards utilisés pour l'ingénierie en avant pourraient être utilisés pour la rétro ingénierie. Le besoin d'avoir des standards est certain. Les standards pour la maintenance doivent être bien définis pour donner au système un niveau de qualité satisfaisant. Depoortere Franck

22 La redocumentation La documentation des applications a toujours été le maillon faible des projets applicatifs. Chez les grands comptes, les applications développées pour des grands systèmes sont souvent anciennes et leur documentation est souvent jugée insuffisante ou obsolète. Pour les équipes chargées de la maintenance logicielle, la difficulté est d autant plus grande que les personnes qui maintiennent les programmes ne sont pas celles qui les ont écrit. Si la maintenance logicielle est de mauvaise qualité, c est la plupart du temps pour les raisons suivantes : le manque de modèle de processus logiciel, le manque de documentation, ou le manque de temps consacré à la mise à jour de la documentation. Cette tâche de redocumentation, même si elle n ait pas nécessairement porteuse de motivation, est malgré tout indispensable à la maintenance du logiciel. Le constat est navrant, mais il s avère selon l étude de NGSET (NGSET : que 95% des applications logicielles ne sont pas ou peu documentées. Le corollaire de ce manque de connaissance sur les applications est que 60% du temps de maintenance est passé, non pas en améliorations ou corrections, mais en recherche, lecture et tentatives de compréhension. L implémentation représente 15%, et les tests 25% du temps. Une documentation véritablement utile dépasse les simples commentaires décrivant une ligne de code ou un ensemble d instructions. Elle contient l ensemble des informations nécessaires à la maintenance de l application, notamment l organisation de l application (découpage fonctionnel, organisationnel, ), l ensemble des composants mis en jeux : Programmes, fichiers et base de données, transactions, les relations entre les composants ou à l intérieur d un composant, et le dictionnaire des données. Soulignons bien que la qualité de la documentation d un logiciel est aussi importante que son code. Pour respecter cette qualité, il est important de mettre en place une procédure de production, de présentation et de vérification des documents. Il ne faut pas sous-estimer l importance du contrôle de qualité des documents. Une documentation mal faite ne sera pas utilisée. Les standards de documentation doivent décrire précisément le contenu et les notations utilisées pour chaque document. Notamment les formats de couverture, la numérotation des pages, les conventions à suivre pour les notes de bas de page, les renvois, les titres, L évolution technologique des outils de développement et de maintenance permet aujourd hui une automatisation partielle de cette documentation. Ces logiciels sont capables de générer des documents automatiquement à partir du code source des logiciels, des bases de données, des commentaires insérés dans le code, de présenter une vision hiérarchique globale du système applicatif, et des visions détaillées au niveau composant, de construire les interrelations entre les composants de l application. Cette automatisation de documentation est aujourd hui indispensable sur les applications importantes. Certains logiciels atteignent plusieurs centaines de milliers, voire plusieurs millions de lignes de code. Il serait difficile d avoir une documentation à jour et avec des coûts raisonnables, en effectuant celle-ci manuellement. En matière de diffusion et de visualisation de l information, la technologie Internet, à base de serveurs centralisés de fabrication de pages HTML et XML, de serveurs de pages et de postes de travail dotés de navigateurs, est très adaptée à la documentation des applications. Cependant, même si ces outils allègent considérablement les taches fastidieuses de documentation, tout le processus de documentation n est pas entièrement automatisable. Les connaissances du logiciel ne sont pas seulement dans le code source, mais également chez les experts. Cette capture des connaissances des experts doit être également être rendue accessible par des documents s ajoutant à la documentation automatique. Les logiciels de documentation sont capables de lier l ensemble des documents à une version du logiciel. La majorité des documents associés à un projet logiciel sont mal écrits, difficile à comprendre, périmés ou incomplets. D une façon générale, le travail de documentation est largement sous-estimé. La production de documents de qualité n est ni facile, ni bon marché. Néanmoins, la qualité de documentation est au moins aussi importante que la qualité du programme. Depoortere Franck

23 La restructuration L objectif premier de la restructuration est d améliorer la maintenabilité du code pour diminuer les coûts de maintenance. Au-delà de cet objectif, la rénovation a des implications sur la stratégie d évolution des applications. En effet, lorsqu une application devient trop difficile à maintenir le management a deux options : Réécrire l application. Remplacer l application par une autre application ou un progiciel par exemple. Figure 3.1 : Stratégies de maintenance et coûts de maintenance (source : Economics of SW Reengineering Harry M. Sneed) La restructuration vise à améliorer la représentation d un système sans en changer les fonctionnalités. L activité de restructuration est basée sur le principe que par la suite d une chaîne de modifications, la structure globale du programme tant à ce dégrader. Le code devient de plus en plus difficile à comprendre et sa structure de moins en moins saine. Le programme doit donc être restructuré. Cette activité de restructuration recouvre différents types d actions, qui vont s adapter à la façon dont est fait le logiciel. On va recourir souvent à trois étapes de travail : 1. la restructuration des flux : on va tenté d améliorer la structure globale des modules composants l application. Ceci va se traduire par exemple par le regroupement de routines éparpillées dans divers modules, de classer les diverses fonctions avec plus de cohérence. Le but de ce travail de nettoyage du code est de retrouver une structure globale tout à fait cohérente sur l application. 2. La restructuration peut également s effectuer sur l algorithmique du code, afin de le rendre plus efficace, ou plus clair. On va dans cette phase, supprimer le code mort et les variables non utilisées, supprimer les fichiers devenus inutiles, remplacer par exemple les structures IF- ELSE IF imbriqué par des structures CASE, plus clair, et surtout moins coûteux en temps de calcul (L interprétation d un case consomme une seule évaluation d instruction booléenne, tandis qu il y a autant d instructions et de test évalués que de IF imbriqués). Ce peut être également la normalisation du code et des noms. Depoortere Franck