LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN

LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN Les contenues de ce document sont la propriété exclusive de la société REVER. Ils ne sont transmis qu à titre d information et ne peuvent en aucun cas être considérées comme un engagement de la société REVER. Toutes utilisations, en ce compris le référencement, de la totalité ou d une partie de ce document ne sont autorisées qu avec l accord formel et écrit de REVER. REVER S.A. Belgique ; +32 71 20 71 61 ; http://www.rever.eu

La documentation de REVER est structurée sur trois niveaux qui se superposent hiérarchiquement comme le représente le schéma ci-dessous : le premier niveau décrit les technologies de base de REVER et explique le fonctionnement des outils ; le deuxième niveau décrit les méthodes de REVER à suivre pour une utilisation optimale des technologies ; le troisième niveau décrit les solutions de REVER pour répondre aux besoins des clients. Un document de niveau «i» peut faire référence à un ou plusieurs documents de niveaux inférieurs : il est vivement conseillé au lecteur d en prendre connaissance pour avoir une compréhension correcte du document. Afin de rendre les explications plus claires, il est fait un usage régulier de schéma et de couleur. Il est recommandé pour une lecture aisée des documents de les imprimer en couleur. Par cette démarche structurée, REVER poursuit un double objectif : rendre la lecture de la documentation de REVER plus aisée en séparant clairement les différents éléments constitutifs des propositions de REVER ; permettre aux lecteurs de mieux appréhender les aspects innovants des propositions de REVER, en les abordant, soit dans une lecture «top-down» (de la «solution» à la «technologie»), soit dans une lecture «bottom-up» (de la «technologie» à la solution). Le premier type de lecture correspond à une approche de compréhension du «comment» les méthodes et outils de REVER permettent la réalisation de solutions qui semblent à priori complexes, voire impossibles. Le second type de lecture correspond à une démarche de «constructeur de maison» : le premier niveau décrit les matériaux de base, le second niveau explique comment les différents matériaux sont utilisés pour construire des «murs» et, enfin, le troisième niveau définit les architectures de «maisons» possibles. Service Marketing 29/04/2008 TE02 Page 2 / 13

Quelque soit l approche, l équipe de rédaction souhaite que ces documents apportent les éléments d information attendus. Service Marketing 29/04/2008 TE02 Page 3 / 13

Table des matières 1 Description générale... 5 2Description détaillée... 6 2.1Le processus d analyse des codes «source» données... 6 2.2Le processus d analyse des codes «source» procéduraux... 6 2.2.1L analyse macroscopique (AST)... 8 2.2.2L analyse microscopique (SDG)... 11 2.3L analyse des données... 13 Service Marketing 29/04/2008 TE02 Page 4 / 13

1 Description générale Les activités de rétro-ingénierie ont pour objectif de reconstruire les modèles des données à partir des éléments techniques existants. L automatisation de cette reconstruction n est possible qu à travers la mise à disposition de différents types d outils : des analyseurs de codes «source» concernant les structures et les relations des données ; des analyseurs de codes «source» des objets procéduraux tels que triggers, dbprocedure, programmes applicatifs, JCL, ; des analyseurs de données. L ensemble des résultats produits par les analyses sont conservés dans le référentiel de DB- MAIN. Une explication plus détaillée de ces différents points est fournie plus loin dans ce document. Service Marketing 29/04/2008 TE02 Page 5 / 13

2 Description détaillée Les activités de rétro-ingénierie des bases de données ont pour objectif de permettre la reconstruction des différents modèles de données. Pour atteindre cet objectif, elles nécessitent des outils spécifiques pour l analyse des différents types d éléments techniques existants (DDL, triggers, db-procedure, langage de programmation applicatif, JCL, données, ) : 2.1 Le processus d analyse des codes «source» données REVER dispose d outils permettant l analyse des codes «source» (DDL) descriptif des structures et relations des bases de données. L objectif de ces analyseurs est d alimenter le référentiel de DB-MAIN avec les éléments explicitement déclarés pour la base de données. En règles générale, cela concerne : les structures (entités et attributs) ; les relations entre entités ; les éventuels clés d accès ; les éléments d implémentation technique tels que taille des fichiers, type d indexation,. Tous ces éléments sont stockés dans le référentiel de DB-MAIN. 2.2 Le processus d analyse des codes «source» procéduraux En ce qui concerne les codes «source» des objets procéduraux, les outils de REVER sont évidemment dépendants des langages et des environnements techniques. Toutefois afin de pouvoir être le plus universel possible, les outils de base utilisés par REVER sont d un très haut niveau d abstraction permettant, par la suite, de forger des outils spécifiques liés à un environnement technique précis. Pour cette raison, l architecture générale des analyseurs de codes source de REVER (voir schéma ci-dessous) comprend : les outils permettant de générer, si nécessaire, les analyseurs à partir de la grammaire du langage (Backus Naur Form) ; une première phase d analyse des codes source, appelée «analyse macroscopique», permettant d obtenir les arbres syntaxiques (AST) des modules analysés desquels les outils de REVER extraient le «graphe d appel» et le «graphe d utilisation» ; une deuxième phase d analyse des codes source, appelée «analyse microscopique», permettant d obtenir les «graphes d exécution» (SDG) des programmes analysés desquels les outils de REVER extraient, notamment, la liste des flux de données et les «règles données» existantes dans les programmes. Service Marketing 29/04/2008 TE02 Page 6 / 13

Pour bien faire comprendre les différents types et niveaux d analyses de codes source procéduraux, la démarche sera illustrée par un exemple simple de code. Bien que cet exemple ne soit pas un cas réel, il permet de concrétiser la démarche suivie par REVER. Le schéma cidessous présente à gauche le code source comprenant un module principal et deux modules appelés («readfile» et «writefile»). Le processus d analyse et ses résultats sont présentés au centre et à droite du schéma avec ses deux étapes principales : la construction des AST (Abstract Syntaxique Tree) qui permettent de produire le graphe d appel, le graphe d usage et les «treillis de Galois» ; la construction des SDG (Syntax Dependency Graph) qui permettent d extraire, des programmes, les flux de données et les règles données. Service Marketing 29/04/2008 TE02 Page 7 / 13

2.2.1 L analyse macroscopique (AST) L analyse du code source d un programme permet de construire, dans un premier temps, ce qui est convenu d appeler l AST. Ce type d analyse est analogue à celle que les compilateurs utilisent pour l analyse de code source. Cette analyse est réalisée module par module (un programme est en fait un ensemble de modules dont la racine est un module qui n est «appelé» par aucun autre), chaque module fournissant un AST. De ces AST, les outils de REVER retiennent les «appels» vers d autres modules permettant de construire le «graphe d appel» ; les instructions d entrée/sortie pour les données permettant de construire le «graphe d usage». Les «appels» entre modules sont regroupés dans DB-MAIN sous forme d un graphe unique appelé «graphe d appel» qui donne l architecture générale de l application du point de vue des modules : chaque nœud du graphe représente un module, les arcs indiquant l existence d un appel entre deux modules (voir schéma ci-dessous). Service Marketing 29/04/2008 TE02 Page 8 / 13

Les instructions d entrée/sortie sont regroupées dans DB-MAIN sous forme d un graphe unique appelé «graphe d usage» qui donne l architecture générale de l application du point de vue des accès aux données : le nœud «racine» correspond au nom du module, les feuilles correspondent aux entités utilisées par le module, chaque arc spécifie s il s agit d une entrée/sortie modifiant ou non la base de données. Service Marketing 29/04/2008 TE02 Page 9 / 13

Ces deux graphes sont enregistrés dans DB-MAIN. Les technologies de REVER, associées à DB-MAIN, permettent en partant de ces deux graphes de : les combiner entre eux (graphe «d appel et d usage») pour obtenir par exemple le graphe d utilisation des entités utilisées par un programme ; de parcourir les graphes à partir d un nœud vers le haut, vers le bas ou les deux ; d obtenir le graphe minimal entre deux nœuds. Un exemple concret de ce genre d utilisation est la représentation du graphe «d appel et d usage» sous forme d un tableau à deux dimensions, chaque point (X,Y) indiquant que le module X utilise l entité Y. Ces différents points sont ordonnancés en utilisant un algorithme, dit «treillis de Galois», qui permet de regrouper en sous-ensembles les différents points. Un exemple d un tel treillis est donné ci-dessous. Ces «treillis» permettent notamment d identifier rapidement les risques et les possibilités de découpage en «lot» (programmes et entités) des opérations de migrations. Service Marketing 29/04/2008 TE02 Page 10 / 13

2.2.2 L analyse microscopique (SDG) L analyse du code du programme permet de construire, dans un second temps, ce qui est convenu d appeler le SDG ou «graphe d exécution». Ce SDG est en fait une représentation «mathématique» sous forme de graphe du programme. Dans le SDG chaque nœud du graphe est une instruction. Il existe deux types d arcs orientés : un arc dit de «contrôle» (noté «C» ou «CALL») qui indique les instructions qui vont être exécutées à partir du nœud origine, et un arc dit de «flux de données» (noté «D» ou «I» ou «O») qui indique le sens du flux de données entre les nœuds. La construction du SDG se fait d abord module par module, puis les graphes des différents modules sont réunis afin de constituer le «graphe» du programme (voir schéma ci-dessous). Cet «assemblage» n est pas toujours aisé : en effet, le nom du module appelé peut être contenu dans une «variable» du programme et non directement dans l instruction d appel. C est pour cette raison que le processus de construction du graphe est un processus qui peut être itératif, chaque appel au moyen d une variable étant remplacé par un appel avec la valeur de la variable. Service Marketing 29/04/2008 TE02 Page 11 / 13

Une fois le «graphe d exécution» construit, les technologies de REVER permettent de l interroger, c'est-à-dire de le parcourir partiellement, ou totalement, en choisissant le type d arc en fonction des objectifs poursuivis. Une des principales utilisations du SDG faites par les experts de REVER est la détermination des «flux de données» entre deux entités. Ainsi, à titre d exemple, dans le schéma ci-dessous il existe un «flux de données» entre le «READ» à l instruction 12 et le «WRITE» à l instruction 21. Le chemin entre ces deux instructions est ce qu il est convenu d appelé un fragment de programme qui définit la partie de code qui détermine ce flux de données : Service Marketing 29/04/2008 TE02 Page 12 / 13

L intérêt de la détermination des «flux de données» dans les programmes est qu elle permet, d une part d identifier de manière exhaustive tous les liens entre «données» existant dans les programmes, et, d autre part, de retrouver au moyen des fragments de programme les règles données associées. D autres utilisations du SDG sont également régulièrement utilisées par les experts de REVER, notamment pour déterminer, dans les programmes, la propagation de la modification de la structure d une variable. 2.3 L analyse des données L analyse des données a pour objectif d identifier celles qui ne respectent pas les «règles données». A partir des règles données définies dans les modèles, des requêtes d interrogation des données sont générées automatiquement afin de s assurer de la conformité des données aux modèles. Un exemple de résultat d un tel contrôle est donné ci-dessous. Service Marketing 29/04/2008 TE02 Page 13 / 13