Retrouvez la maîtrise de votre système d’information

Processus consistant à retrouver la description la plus correcte possible de la structure d’une base de données (BD) peu (ou pas) documentée, la rétro-ingénierie constitue, comme l’a souligné l’exposé de Jean-Luc Hainaut, professeur aux FUNDP de Namur (voir le diaporama) , une étape indispensable à la réalisation de nombreux projets. Les processus requérant une documentation complète et à jour d’une BD sont en effet légion :

• Maintenance d’une BD : cette maintenance pouvant être de correction (correction d’erreurs), de prévention (amélioration de la structure) ou d’adaptation (lors de changements d’infrastructure) ;
• Evolution d’une BD suite à l’apparition de nouvelles exigences ;
• Réingénierie d’une BD ;
• Migration d’une BD/application : transfert, en tout ou en partie, de l’application existante vers une autre plate-forme ;
• Conversion de données vers un format défini ;
• Interfaçage entre processeurs incompatibles (ex : relationnel <-> XML) ;
• Intégration ou fédération de systèmes.

Défis et méthodologie de la rétro-ingénierie de bases de données

Un processus de rétro-ingénierie comprend deux phases principales :

• L’extraction de la structure de données  : il s’agit de retrouver la structure des données et les contraintes sur ces données, afin d’aboutir à un schéma logique complet. Cette notion de complétude implique la découverte non seulement des structures explicites (déclarées dans le SGBD), mais également des structures implicites (non déclarées dans le SGBD mais vérifiées par les programmes).
• Conceptualisation  : lors de cette deuxième phase, la description fonctionnelle de la base de données est réalisée, afin d’obtenir un schéma conceptuel complet. Le principal défi de cette phase est la compréhension de la sémantique qui régit cette structure.
  L’expérience a démontré que la dimension "sémantique" de ces deux phases, qui en constitue le défi majeur, était souvent laissée pour compte. Dans beaucoup de projets de migration de données ou de ré-ingénierie, l’économie prime sur la qualité : une solution de type "one-to-one", consistant simplement à traduire les données d’une technologie vers une autre, se substitue à une réelle restructuration, qui présuppose une réelle compréhension de ces dernières, qu’elles soient explicites ou implicites...

Quelques aspects techniques...

L’exposé de Jean Henrard (voir le diaporama) , consacré aux aspects techniques de la réalisation de projets de rétro-ingénierie, a également opéré cette distinction entre la découverte des structures explicites, réalisée de façon automatique par l’analyse de la partie déclarative du code et la recherche des structures implicites, dont une part plus ou moins importante est disséminée dans la partie procédurale du code.

Les outils réalisés traduisent ces variations de complexité. Les structures explicites sont décelées grâce à l’analyse automatique du code DDL (Data Description Language), qui produit un premier schéma physique. La recherche des structures implicites, fastidieuse s’il en est, nécessite la mise en oeuvre de techniques et d’outils de compréhension de programmes, à l’instar du calcul du graphe de dépendance des variables, permettant d’établir les relations qui existent entre les différentes variables, et la fragmentation de programmes, ou program slicing, qui permet d’extraire le fragment de code nécessaire et suffisant pour comprendre et expliquer le comportement du programme en un point déterminé.

DaimlerChrysler : une double expérience en rétro-ingénierie

Pour ponctuer ce groupe de discussion, Pascal Cousin, Directeur Information Technology chez DaimlerChrysler Belgium Luxembourg s.a., a fait part à l’assemblée de son expérience en matière de rétro-ingénierie (voir le diaporama) .

Disposant d’un Logiciel de Gestion des Pièces de Rechange et Accessoires déployé dans un environnement technique IBM DOS/VSE, ADS + Cobol et IDMS, le groupe DaimlerChrysler AG décida d’abandonner cet environnement au profit d’une orientation client / serveur avec le système Oracle de gestion de bases de données. Dans ce premier projet, la Belgique, au même titre que l’Australie, faisait figure de pilote. Après trois ans, le retour vers IDMS consacra l’échec de ce premier projet, non sans un impact certain au niveau des coûts. Entre autres causes de cet échec, la
faiblesse d’une conversion one-to-one et le recours à une société Off-Shore (Inde) ont été épinglés.

L’angle d’approche spécifique adopté par DaimlerChrysler Belgium Luxembourg s.a. dans le cadre de sa préparation au déploiement de VisionPlus (système de gestion de ventes des véhicules Mercedes-Benz, Chrysler/Jeep et Smart) est le résultat de la prise en considération des enseignements tirés lors de cette première expérience de rétro-ingénierie. Au niveau des données, le passage d’un DBMS réseau Codasyl vers un modèle relationnel a été réalisé en collaboration avec le LIBD (FUNDP) et Cooperact sprl. Suite à la réalisation d’un projet prototype visant à déterminer la faisabilité du projet et à en estimer le temps et le budget nécessaire, un projet d’environ 70 jours hommes a démarré, suivant les méthodes et outils explicités précédemment. L’enchaînement des différentes phases (préparation, architecture des applications, extraction des structures explicites et implicites, nettoyage et validation du schéma obtenu, conceptualisation) a mené à une structure fidèle au domaine d’application et indépendante des spécificités d’IDMS.

Pascal Cousin, directeur Information Technology DaimlerChrysler Belgium Luxembourg s.a. :"Tout processus de rétro-ingénierie est en partie heuristique. Sa mise en oeuvre se partage entre automatismes et efforts manuels..."