EVOLUTIONS EXOGENES Les contenus 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és 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 Tél : +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 REVER-ME06 Page 2 / 11
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 REVER-ME06 Page 3 / 11
Table des matières 1 Description générale... 5 2Description détaillée... 7 2.1Reconstruction des modèles de la base «source»... 7 2.2Reconstruction des modèles de la base «cible»... 7 2.3Etablissement de la correspondance modèle «source» modèle «cible»... 7 2.3.1Objectifs... 7 2.3.2Éléments en entrée... 8 2.3.3Activités déployées... 8 2.3.4Résultats... 9 2.4Contrôle de la compatibilité des modèles... 9 2.4.1Objectifs... 9 2.4.2Éléments en entrée... 9 2.4.3Activités déployées... 9 2.4.4Résultats... 9 2.5Définitions des règles de transformation... 10 2.5.1Objectif... 10 2.5.2Éléments en entrée... 10 2.5.3Activités déployées... 10 2.5.4Résultats... 10 2.6Codages des règles de transformation... 10 2.6.1Objectifs... 10 2.6.2Éléments en entrée... 10 2.6.3Activités déployées... 11 2.6.4Résultats... 11 2.7Migration des données... 11 Service Marketing 29/04/2008 REVER-ME06 Page 4 / 11
1 Description générale Une migration de données exogène est probablement l exemple le plus significatif de l intérêt de l Ingénierie Dirigée par les Modèles. En effet, le processus proposé par REVER offre un double avantage : le premier réside dans la quasi absence de risques une fois les modèles «source» et «cible» établis ; le second réside dans le type de processus proposé qui permet une approche itérative. En effet, en cas d erreur de correspondance et/ou de règles de transformation il suffit d effectuer les corrections dans DB-MAIN et de re-générer les programmes de déchargement. La méthode de REVER pour les migrations de données exogènes est synthétisée dans le tableau ci-dessous : Le déroulement, au cours du temps, de cette méthode est illustrée dans le schéma cidessous (en bleu, les étapes dans lesquelles les outils de REVER sont utilisés). Les livrables fournis au client sont également indiqués. Service Marketing 29/04/2008 REVER-ME06 Page 5 / 11
Afin de bien faire comprendre la méthode suivie par REVER, la suite de ce document détaille chacune des phases et des étapes. Pour chaque étape les points suivants sont explicités : objectifs de l étape ; éléments en entrée ; activités déployées ; résultats produits. Service Marketing 29/04/2008 REVER-ME06 Page 6 / 11
2 Description détaillée 2.1 Reconstruction des modèles de la base «source» La reconstruction des modèles de la base «source» est décrite en détail dans le document intitulé «rétro-ingénierie des bases de données». Lorsque, ce qui arrive de temps à autre, la reconstruction par des processus automatisés n est pas possible, notamment lorsque les codes «source» des programmes ne sont pas disponibles, la reconstruction du modèle «source» est effectuée «manuellement» en s appuyant sur la documentation existante, la connaissance des intervenants du client et l analyse des données. 2.2 Reconstruction des modèles de la base «cible» La reconstruction des modèles de la base «cible» est décrite en détail dans le document intitulé «rétro-ingénierie des bases de données».. Lorsque la reconstruction, par des processus automatisés, n est pas possible notamment lorsque les codes «source» des programmes ne sont pas disponibles, la reconstruction du modèle «source» est effectuée «manuellement» en s appuyant sur la documentation existante et la connaissance des intervenants du client ou des experts du domaine d application. Dans le cas de la mise en place de progiciels, la reconstruction des modèles peut se faire en suivant d autres voies : soit en accord avec l éditeur du progiciel ; soit en modélisant, non pas la base de données elle-même, mais les interfaces de «chargement» des données dans la base du progiciel. Cette modélisation peut se faire assez simplement, en s appuyant sur les spécifications fournies par l éditeur du progiciel. 2.3 Etablissement de la correspondance modèle «source» modèle «cible» 2.3.1 Objectifs Cette étape est réalisée par les experts du domaine de l application. Elle consiste à établir, sur base des modèles sémantiques, la correspondance entre les entités et attributs de la base «source» et ceux de la base «cible». Service Marketing 29/04/2008 REVER-ME06 Page 7 / 11
L outil DB-MAIN possède, à cet effet, une fonction spécialisée qui permet d établir cette correspondance manuellement. Dans certains cas, il est possible d automatiser cette correspondance sur base de règles spécifiques, tels que le nommage des attributs, des entités, etc.. On notera, qu à ce stade, il ne s agit pas encore de définir les règles de transformation des données à appliquer lors de la migration. Seules, les correspondances entre les entités et attributs sont à définir à ce niveau. 2.3.2 Éléments en entrée Modèles «source», modèle «cible» 2.3.3 Activités déployées Au moyen de l outil de «mapping» de DB-MAIN, les intervenants «métiers» définissent les correspondances entre les entités et les attributs de la base «source» et les entités et attributs de la base «cible». Service Marketing 29/04/2008 REVER-ME06 Page 8 / 11
2.3.4 Résultats Les correspondances entre la base «source» et la base «cible» sont enregistrées dans le référentiel de DB-MAIN et peuvent être visualisées, et modifiées, au moyen de l outil de mapping. 2.4 Contrôle de la compatibilité des modèles 2.4.1 Objectifs L objectif de cette étape est de vérifier la compatibilité des modèles «source» et «cible». En effet, il existe de très nombreuses situations pour lesquelles les «règles» (relations et règles «données») suivies par une donnée de la base «source» ne sont pas les mêmes dans la base «cible». Il conviendra, dans ce cas, de définir une règle de transformation de la donnée «source». 2.4.2 Éléments en entrée Modèle «source», modèle «cible», correspondance «source-cible». 2.4.3 Activités déployées Ce processus est réalisé par des automates qui détectent : les différences de définitions des données ; les différences dans la hiérarchisation des entités. 2.4.4 Résultats Rapport des différences entre les modèles «source» et les modèles «cible». Service Marketing 29/04/2008 REVER-ME06 Page 9 / 11
2.5 Définitions des règles de transformation 2.5.1 Objectif Les différences entre les modèles ayant été déterminés, il convient de définir, à ce stade, les règles de transformation. A ce niveau il s agit juste de donner une définition «métier» de la règle de transformation : ce travail est généralement réalisé par les experts «métier». 2.5.2 Éléments en entrée Modèles «source», modèles «cible», correspondance «source-cible». 2.5.3 Activités déployées La définition des règles est réalisée en utilisant l outil de «mapping» de DB-MAIN. Pour chacune des correspondances, il est possible d introduire, dans une méta-propriété la définition de la règle (la «sémantique» de la règle). Ces définitions sont enregistrées, au fur et à mesure, dans le référentiel de DB-MAIN. 2.5.4 Résultats Le référentiel de DB-MAIN contient l ensemble des correspondances «source-cible» et, pour chacune d entre elles, la définition de la règle de transformation. 2.6 Codages des règles de transformation 2.6.1 Objectifs Cette étape a pour objectif de traduire, en langage technique, les règles de transformation définies à l étape précédente. 2.6.2 Éléments en entrée Modèles «source», modèles «cible», correspondances «source-cible», définition des règles de transformation. Service Marketing 29/04/2008 REVER-ME06 Page 10 / 11
2.6.3 Activités déployées Les définitions des règles de transformation sont codées pour pouvoir être intégrées dans le programme de déchargement, lors de sa génération. Le codage des règles doit dont être fait dans le langage de programmation de la plateforme à partir de laquelle le déchargement sera effectué. 2.6.4 Résultats Le référentiel de DB-MAIN contient l ensemble des correspondances «source-cible» et, pour chacune d entre elles, la règle de transformation. 2.7 Migration des données Ce processus est décrit dans le document REVER-ME03 : déchargement et chargement massif des données. On notera que la génération des programmes de déchargement intègre automatiquement les règles de transformation codées dans le référentiel de DB-MAIN. Service Marketing 29/04/2008 REVER-ME06 Page 11 / 11