GOUVERNANCE DES DONNÉES MÉTHODES. Apports de. l Ingénierie des Données Dirigée par les Modèles

Apports de l Ingénierie des Données Dirigée par les Modèles «La modélisation est au développement informatique ce qu est le solfège à la musique : pour le compositeur un moyen d exprimer dans ses créations toutes les nuances de ses sentiments, pour le chef d orchestre la définition d une œuvre à diriger subtilement pour en dégager l harmonie, pour l instrumentiste ou soliste la description de ce qu il doit interpréter avec toute sa sensibilité, pour les initiés un moyen de communication pour se comprendre dans le temps et l espace, pour les musiciens amateurs un formalisme dont ils pensent pouvoir se passer aisément, pour les profanes une «terra incognita» à explorer pour ses richesses insoupçonnées.» Vincent Ciselet (Ingénieur), Jean Henrard (Ph. D.), Jean-Marc Hick (Ph. D.), Frumence Mayala (Ingénieur), Christophe Mouchet (Ingénieur), Dominique Orban (Ingénieur), Didier Roland (Ph.D.)

SOMMAIRE Enseignée dans toutes les écoles et les instituts de formation, recommandée en tant que «bonne pratique» par de très nombreux experts, la modélisation informatique est peu utilisée dans les organisations. Il existe, sans doute, de multiples raisons à ce paradoxe. Deux raisons sont évidentes : d une part l aspect hermétique du langage qui semble vouloir réserver la modélisation aux seuls spécialistes et d autre part le peu de «résultat» concret produit au regard de l investissement que la modélisation nécessite. Cependant, depuis quelques années cette situation évolue sous l effet de deux courants convergents : la nécessité pour les organisations de se doter de méthodes et d outils face à leur difficulté de garder la maîtrise de leurs applications dont la complexité et le nombre ne font qu augmenter ; la présence grandissante de solutions performantes, résultats de projets dans lequel le code source n est plus considéré comme l élément central d un logiciel, mais comme un élément dérivé de la modélisation. La modélisation des données s inscrit dans cette tendance. C est ainsi que depuis plus de 5 ans la société REVER industrialise et commercialise les résultats des recherches et développements menés depuis 25 ans au sein du Laboratoire d Ingénierie des Bases de Données (LIBD) de l Université de Namur (Belgique). Si la modélisation des données peut sembler pour certains n être qu anecdotique par rapport à l enjeu global, c est à la fois perdre de vue que les données sont au cœur des applications informatiques et sousestimer le rôle vital des données dans le fonctionnement des organisations. Par ailleurs, les coûts très importants que les données engendrent, la valeur patrimoniale et financière qu elles représentent décuplent l obligation pour les organisations de dépasser la simple gestion des données pour entrer dans «la gouvernance des données». À l image de la gouvernance des entreprises et de toutes les autres formes de gouvernance, la gouvernance des données se doit de définir les règles dans lesquelles s exercent les activités de gestion des données, de veiller au respect de ces règles et à leur mise en application et d en assurer les évolutions et les évaluations. C est dans cette perspective qu a été rédigé ce document qui s adresse aux responsables, aux praticiens et à toute personne intéressée par la gouvernance des données. Il montre qu en considérant les données comme un «écosystème», en proposant des fonctionnalités innovantes telles que la cogénération, la coévolution et la comparaison d écosystèmes une démarche d Ingénierie des Données Dirigée par les Modèles 1 (IDDM) contribue aux objectifs de la gouvernance des données. En particulier, il illustre qu outre le maintien permanent de la cohérence de l écosystème, l approche IDDM réalise le lien entre : les exigences stratégiques de la gouvernance exprimées par le «métier» à savoir : o définir des Systèmes d Informations (S.I.) (création de bases de données) ; o évaluer les S.I. existants (qualité des données, qualité des bases de données, risques, ) ; o faire évoluer les S.I. (maintenances évolutives, migrations de bases de données, ) ; o utiliser et réutiliser les données existantes (migration/intégration de données, échanges, extractions, ) les méthodes à appliquer choisies par le service informatique ; les outils opérationnels indispensables aux intervenants techniques pour la réalisation des projets. Les succès incontestables rencontrés projet après projet par l utilisation des solutions (méthodes supportées par des outils) exposées dans ce document démontrent leur pertinence et leur efficacité. Adoptées par nombre de grandes organisations et d intégrateurs, elles sont utilisées dans une grande diversité de projets, d environnements techniques et organisationnels. Ces solutions offrent à leurs utilisateurs : des résultats de très haute qualité professionnelle ; une réduction drastique des risques techniques des projets grâce à la maîtrise de tous les composants de l écosystème ; une réduction très importante de la durée et des charges de travail des projets provenant d une très forte automatisation des processus ; le maintien permanent du lien entre «métier» et «IT» garant d évolutions sereines et de la pérennité des investissements. 1 Les définitions des termes techniques et des acronymes utilisés dans ce document sont fournies à l annexe 1. Page 2

TABLE DES MATIÈRES 1 LES CONCEPTS... 5 1.1 INGÉNIERIE DIRIGÉE PAR LES MODÈLES... 5 1.2 ÉCOSYSTÈME DES DONNÉES... 5 1.3 INGÉNIERIE DES DONNÉES DIRIGÉES PAR LES MODÈLES... 6 1.3.1 LA DÉMARCHE... 6 1.3.2 LES NIVEAUX DE MODÉLISATION... 6 1.3.3 LES OUTILS DE MODÉLISATION... 6 2 GOUVERNANCE DES DONNÉES... 8 2.1 LES DONNÉES DANS L ORGANISATION... 8 2.2 GOUVERNANCE ET INGÉNIERIE DES DONNÉES... 8 2.3 LES EXIGENCES «MÉTIER»... 10 2.3.1 DÉFINIR... 10 2.3.2 ÉVALUER... 13 2.3.3 ÉVOLUER... 20 2.3.4 RÉUTILISER... 24 3 PERSPECTIVES DE L IDDM... 28 3.1 AMÉLIORATION DES INTERFACES HOMMES-MACHINES... 28 3.2 COUPLAGE AVEC D AUTRES SYSTÈMES DE MODÉLISATION... 29 3.2.1 RÉCEPTION D APPLICATIONS... 31 ANNEXE 1 : LEXIQUE... 32 ANNEXE 2 : EXEMPLE D ÉCOSYSTÈME... 34 ANNEXE 3 : BIBLIOGRAPHIE... 37 Page 3

INDEX THÉMATIQUE Ce document donne une vision générale de l apport de l IDDM. Cette description risque cependant de perdre le lecteur qui souhaiterait obtenir des informations concernant un projet spécifique. L objectif de cet index est de répondre à cette préoccupation par l établissement des liens entre des intitulés de projet, la ou les parties du document concernées et.les solutions techniques décrites dans le document intitulé «gouvernance des données : solutions techniques» RÉFÉRENCE solutions techniques TYPE DE PROJET (http://www.rever.eu/whitepapers/solutionstechniquesi libellé numéro DDM-FR.pdf) comprendre 2.3.2.1 2.1 Archivage de données exporter 2.3.4.1 4.1 épuration 2.3.4.3 4.1.1 Compréhension d applications comprendre 2.3.2.1 2.1 Développement de nouvelles applications développer 2.3.1.1 1.2 Évaluation de systèmes comprendre 2.3.2.1 2.1 d informations risques programmes-bd 2.3.2.2.3 2.2.3 Échanges de données exporter 2.3.4.1 4.1 Extraction de jeux de données exporter 2.3.4.1 4.1 jeux de tests 2.3.4.2 4.1.2 Fusion de bases de données comprendre 2.3.2.1 2.1 (création d une méta BD reprenant les structures et les moderniser 2.3.3.1 3.2 données de plusieurs BD) Intégration de données comprendre 2.3.2.1 2.1 (injection dans une BD existante et/ou un progiciel de données provenant d une ou de plusieurs importer 2.3.4.4 4.2 BD) comprendre 2.3.2.1 2.1 Maintenances évolutives modifier 2.3.3.1 3.1 coévolution 2.3.3.2 3.3 Migration de bases de données comprendre 2.3.2.1 2.1 (changement de SGBD) Migration de données (injection dans une BD existante et/ou un progiciel de données provenant d une ou de plusieurs BD) Qualité des bases de données Qualité des données Réécriture d application Rétro-documentation Rétro-ingénierie moderniser 2.3.3.1 3.2 comprendre 2.3.2.1 2.1 exporter 2.3.4.1 4.1 importer 2.3.4.4 4.2 comprendre 2.3.2.1 2.1 qualité BD 2.3.2.2.2 2.2.2 comprendre 2.3.2.1 2.1 qualité des données 2.3.2.2.1 2.2.1 comprendre 2.3.2.1 2.1 développer 2.3.1.1 1.2 importer 2.3.4.4 4.2 comprendre 2.3.2.1 2.1 couplage 3.2 5.2 comprendre 2.3.2.1 2.1 couplage 3.2 5.2 Page 4

1 Les concepts 1.1 Ingénierie Dirigée par les Modèles Aujourd hui, dans de nombreux domaines des sciences et techniques, l utilisation de modèles est quotidienne et a montré son utilité et son efficacité en tant qu outil : de description et de compréhension des systèmes ; de communication entre toutes les personnes concernées par une problématique spécifique ; d abstraction permettant de raisonner indépendamment des contraintes techniques ; de prédiction permettant d identifier a priori les impacts de modifications ou d évolutions ; de simulation et d action sur la réalité. L'Ingénierie Dirigée par les Modèles (IDM, ou MDE en anglais pour Model Driven Engineering) s inscrit dans cette approche et peut être définie comme une forme d'ingénierie générative, qui se singularise par une démarche dans laquelle tout ou partie d'une application informatique est générée à partir de modèles. Cette démarche correspond à un paradigme dans lequel le code source n est plus considéré comme l élément central d un logiciel, mais comme un élément dérivé d éléments de modélisation. Cette approche prend toute son importance dans le cadre des architectures logicielles et matérielles dirigées par les modèles utilisant des standards tels que les spécifications MDA (Model-Driven Architecture) proposées par l'omg (Object Management Group). De telles architectures s'intègrent tout naturellement dans un processus de développement à base de modèles s'assurant, à chaque niveau de modélisation, que les modèles obtenus et réutilisés ont les qualités requises. Cette démarche met le modèle au centre des préoccupations des analystes/concepteurs. Si le nom peut paraître nouveau, le processus, lui, ne l est pas : les activités de modélisation sont le pain quotidien des développeurs depuis toujours. Cependant dans la plupart des cas, les modèles et les solutions restent implicites, ou tout au moins informels et sont appliqués manuellement. Ce que propose l'approche IDM est simplement de formaliser et de mécaniser le processus que les ingénieurs expérimentés suivent à la main. En d autres termes, l IDM est la simple transposition dans le domaine informatique de la démarche «classique» de l ingénieur qui, avant de réaliser une pièce mécanique en dresse le plan. Pour que la démarche IDM soit utile et efficace, il faut bien sûr que les modèles et les processus soient rendus explicites et suffisamment précis pour être interprétés ou transformés par des machines. Dans ce cadre, les processus peuvent alors être vus comme un ensemble de transformations partiellement ordonné des modèles, chacune des transformations prenant un modèle en entrée et produisant un modèle en sortie, jusqu à obtention d artéfacts exécutables. Ainsi, quand on doit dériver une nouvelle solution, qu'elle soit une simple évolution d'un existant ou une nouvelle variante, on peut se contenter de «rejouer» la plus grande partie du processus en changeant simplement quelques détails ici et là dans le modèle. L Ingénierie des Données Dirigée par les Modèles (IDDM) dont il est question dans la suite de ce document est tout simplement une démarche IDM appliquée aux «écosystèmes» des données. 1.2 Écosystème des données Les données «permanentes» des systèmes informatiques sont stockées dans des bases de données. Cette définition est générique et ne préjuge en aucun cas du type de système de gestion utilisé pour le stockage des données : ce système peut être composé de fichiers «plats», de fichiers XML, de Systèmes de Gestion de Bases de Données (SGBD) de type hiérarchique, réseau, relationnel, ou de toute combinaison de ces containers. Quel que soit le système utilisé, les données (pour être plus précis : leur «valeur») sont stockées selon une structure définie pour pouvoir être traitées par des programmes. Par ailleurs, une donnée est comparable aux pièces d un puzzle : prise isolément, chacune des pièces répond à des règles précises de hauteur, de flexibilité, etc. et, ensemble, chacune des pièces doit s ajuster à ses voisines tant dans ses formes que dans ses couleurs. Il en est de même pour les données : isolément, elles doivent répondre à des règles précises (format, longueur, ) ; ensemble, elles ont des liens entre elles qui assurent la cohérence de l information (par exemple : dans une base de données de soins de santé, les soins prénataux ne peuvent être dispensés qu à des personnes de sexe féminin). Ces règles sont nommées «règles de gestion» ou plus simplement «règles données». Page 5

Enfin, les données stockées sont «accédées» par des programmes pour être utilisées, manipulées, modifiées afin d atteindre un résultat défini. S il est commun de considérer que les structures, les valeurs et les «règles de gestion» font partie de «l écosystème» d une base de données, il est plus rare d y inclure les accès aux données qui se trouvent dans les programmes. Dans une démarche d IDDM qui se veut complète, il est cependant obligatoire de les inclure pour la bonne et simple raison que les règles de gestion ne sont pas localisées uniquement dans le système de stockage des données mais se répartissent de manière non homogène dans les systèmes de stockage et dans les programmes. L annexe 2 décrit un exemple de l écosystème de donnée d une application de gestion de panier d achat. 1.3 Ingénierie des Données Dirigées par les Modèles 1.3.1 La démarche Le «cœur» d une démarche d IDDM est l utilisation des modèles afin de produire des outils utilisables dans les environnements techniques des projets. Cette démarche est déjà largement suivie par de nombreux produits du marché pour la création des structures d une base de données. Elle reste toutefois encore trop souvent limitée à ce type d action. Dans une perspective d une utilisation plus large, il convient de se poser deux questions fondamentales : comment structurer la démarche de modélisation pour qu elle puisse être utilisée par tous les types d intervenants concernés (analystes «métier», développeurs, experts base de données, )? quelles sont les fonctions nécessaires et suffisantes que doivent inclure les outils de modélisation pour pouvoir généraliser la démarche d IDDM à des actions opérationnelles autres que la seule création de structures de bases de données? 1.3.2 Les niveaux de modélisation Pour répondre à la première préoccupation, le principe généralement adopté est de «découper» le modèle en niveaux, chacun des niveaux de modélisation correspondant à des «visions» spécifiques. Pour les bases de données, il est classique d envisager trois niveaux de modélisation : le niveau «conceptuel» (ou sémantique) décrit le système d information du point de vue des intervenants «métier». Par nature, ce niveau est indépendant de toutes technologies et est une représentation du système d information nécessaire aux activités du «métier» ; le niveau «logique» décrit le système d information du point de vue des développeurs de l application. Ce niveau de modèle est dépendant de la catégorie de technologie utilisée pour le stockage des données : le modèle logique dérivé d un modèle conceptuel est différent selon que les données seront stockées dans un SGBD relationnel ou dans des fichiers XML ; le niveau «physique» décrit la base de données du point de vue de l expert «base de données». Ce niveau de modèle est dépendant de l environnement technique dans lequel la base de données va être implémentée : le modèle physique d une base de données peut être différent selon qu il s agit d une implémentation dans ORACLE ou DB2. 1.3.3 Les outils de modélisation Dans le contexte d une démarche d IDDM, les outils de modélisation doivent permettre de passer d un niveau de modélisation à un autre au moyen de fonctions dites de «transformations» qui : garantissent le maintien de la même sémantique ; soient réversibles, c est-à-dire que pour chacune des fonctions de transformation il existe, au sens mathématique, une fonction réciproque. Ce principe de «fonctions de transformation symétriquement réversibles» est illustré à la figure 1: les transformations doivent, en partant d un modèle «conceptuel», permettre d obtenir un modèle «logique» pour un SGBD relationnel ou pour un SGBD réseaux ou encore pour un SGBD XML et, réciproquement, en partant d un modèle «logique» permettre de construire un modèle «conceptuel». Page 6

Outre les fonctions de «transformations», les outils de modélisation doivent permettre de faire «évoluer» les modèles pour prendre en compte les changements survenus dans la réalité qu ils représentent. Ces évolutions de modèles sont réalisées soit par des fonctions de transformation, soit par des modifications des modèles (ajouts, modifications, suppressions d élément du modèle), soit encore par une combinaison de transformations et modifications. Dans la mesure où les bases de données sont envisagées comme un écosystème incluant les accès aux données, il est indispensable que ces derniers puissent aussi être représentés dans les outils de modélisation au même titre que les modèles de données. En particulier, les modèles d accès aux données doivent pouvoir être reliés aux modèles des données, afin de permettre aux outils utilisant les modèles de s appuyer sur une vision «complète» du système d information (S.I.). Enfin, les outils de modélisation doivent offrir des possibilités d établir des correspondances entre modèles de différent niveaux (conceptuel-logique-physique) et bien entendu des fonctions de «comparaison» de modèles afin de permettre d identifier leurs différences. Au-delà de la modélisation «pure», et pour que la démarche d IDDM soit utile, il convient d associer à l outil de modélisation : des «générateurs» qui, en fonction des objectifs poursuivis, permettront de produire les codes sources nécessaires. Ainsi, à titre d exemple, il n est pas très difficile d écrire un «générateur» de requêtes SQL vérifiant que les données contenues dans une base de données respectent ou non les règles définies dans le modèle. Il va de soi que de nombreuses autres possibilités de génération pour atteindre d autres objectifs doivent être possibles. des «analyseurs» qui permettent, à partir des codes existants, de reconstituer tout ou partie de la description de l écosystème en ce compris les règles de gestion. (pour en savoir plus au sujet de l IDDM voir notamment http://www.rever.eu/whitepapers/introductionmethodesiddm-fr.pdf). Page 7

2 Gouvernance des données 2.1 Les données dans l organisation Il est de plus en plus courant d entendre que «les données sont un enjeu stratégique des organisations». Ce slogan révèle une double réalité : d une part les organisations ne peuvent se passer de leurs données (sans données l organisation s arrête), et d autre part les données sont un bien précieux puisqu en cas de perte elles ne peuvent être remplacées. Force est de constater également : que les données existent dans l organisation indépendamment des programmes informatiques ; que les données ont une durée de vie différente de celles des programmes ; que le coût des données est de 4 à 6 fois supérieur à celui des programmes ; que les «erreurs» de données engendrent des coûts «cachés» de plusieurs centaines de milliers d euros chaque année. Dans ce sens, les données sont un véritable «patrimoine» qui se transmet de génération en génération au sein de l organisation. C est à ce titre que les recommandations SEC (Système Européen de Comptabilité) préconisent que toutes les bases de données d une durée de vie supérieure à un an soient comptabilisées dans les «actifs» des bilans des États-Membres de l Union Européenne. Cette tendance est confirmée par les recommandations de l OCDE qui souhaiterait également faire apparaître les bases de données dans les actifs des entreprises. Dès lors, des questions se posent : quels sont les critères qui permettent d évaluer la valeur (#coût) d une base de données? Comment mesurer année après année son appréciation ou sa dépréciation? Sur quels critères «objectifs»? Comment assurer les risques «données»? C est aussi à ces enjeux-là que se doit de répondre la gouvernance des données. 2.2 Gouvernance et Ingénierie des Données Comme toute forme de gouvernance, la gouvernance des données nécessite trois niveaux d intervention : le niveau stratégique qui définit la «vision» de l organisation pour la gestion de ses données, indique les règles générales à appliquer, en évalue l efficacité et la pertinence. Ce cadre de gouvernance permet aux utilisateurs de préciser leurs exigences en termes : o de définition de systèmes d information ; o d évaluation des systèmes existants ; o d évolution des systèmes mis en place ; o de réutilisation des données disponibles. le niveau tactique qui définit les solutions (méthodes et outils) applicables aux écosystèmes de données. Ces solutions doivent permettre aux intervenants techniques de répondre aux exigences imposées par le niveau stratégique et plus particulièrement : o de développer des systèmes d informations ; o de comprendre et de mesurer les systèmes existants ; o de modifier et de moderniser les systèmes mis en place ; o d exporter et d importer des données. Page 8

le niveau opérationnel qui se traduit par l application aux écosystèmes de données des solutions retenues au niveau tactique. Dans ce cadre et pour la réalisation des projets, la démarche d IDDM est le lien entre les exigences stratégiques, les méthodes et les outils opérationnels : les modèles définissent et formalisent les exigences «métier» ; les transformations assurent le passage des exigences aux fonctionnalités ; les générateurs produisent les outils nécessaires pour l exécution des fonctions. La gouvernance des données telle que décrite ici ne prend pas en compte les aspects organisationnels, budgétaires et humains qu elle doit nécessairement intégrer. Ces aspects fondamentaux pour la réussite d une «bonne gouvernance des données» au sein des organisations sortent du cadre de cet exposé. La suite de ce document décrit pour chacune des exigences «métier» les différentes méthodes. Ces descriptions méthodologiques sont illustrées par des exemples provenant de projets «réels» réalisés au moyen de la plateforme de modélisation «DB-MAIN» complétée par des solutions techniques intégrant des analyseurs et des générateurs. Les solutions techniques sont décrites plus en détail dans un document complémentaire (http://www.rever.eu/white-papers/solutionstechniquesiddm-fr.pdf) Les exemples utilisés dans ce document proviennent de projets différents réalisés pour différents «clients» ayant bien entendu des environnements technologiques très diversifiés. Dès lors, ce qui pourrait paraître à première vue comme des exemples «erratiques» montre au contraire la généricité de la démarche d IDDM. Par ailleurs, pour des raisons de compréhension, le vocabulaire utilisé est celui du paradigme entitésassociation dans la mesure où les représentations utilisées dans les figures sont principalement exprimées dans ce paradigme. L annexe 1 fournit les correspondances de vocabulaire entre les différents paradigmes de modélisation. Pour rappel, la plateforme de modélisation DB-MAIN a été développée par l Université de Namur et est disponible gratuitement (http://www.db-main.eu ). Une bibliographie synthétique des derniers travaux de recherche est fournie à l annexe 3. Un bibliographie complète est accessible à l adresse : http://info.fundp.ac.be/~dbm/mediawiki/index.php/libd:publications Page 9

2.3 Les exigences «métier» 2.3.1 Définir L expression de nouveaux besoins utilisateurs se traduit in fine par les développements de nouveaux programmes, ou par le développement de l entièreté d une nouvelle application ou encore par la réécriture d une application existante ne répondant plus aux besoins du «métier». Dans toutes ces circonstances, l objectif de l IDDM est de mettre à la disposition des développeurs, quelle que soit leur fonction analyste fonctionnel, programmeur, administrateur de base de données des outils qui leur permettent d accélérer la réalisation des nouveaux écosystèmes. 2.3.1.1 Développer Le but poursuivi par les méthodes et outils est de permettre en partant de sa définition de «co-générer» l écosystème des données : création des structures de la base données et des méthodes d accès aux données. 2.3.1.1.1 Méthode Le processus de «cogénération» est illustré par la figure 6 : 1) il convient d abord de définir le schéma conceptuel des données. Ce schéma est une définition «métier» du S.I. à implémenter indépendante de toute technologie ; 2) à partir du schéma conceptuel, un processus automatique de transformation va produire : un schéma technique et une vue «métier» dont la définition est celle du schéma conceptuel ; 3) à partir du schéma technique, un générateur de code produit le script de création de la BD ; 4) à partir de la vue «métier» des générateurs de code produisent : a) le code source d une couche d intermédiation («middleware») : les modules d accès «métier» (MAM). Cette couche contient l ensemble des méthodes d accès pour la gestion des données ; b) la documentation technique de la couche d intermédiation destinée aux développeurs afin qu ils puissent utiliser les MAM ; c) les codes sources d une application pour l édition de la BD. Cette application s appuie sur la couche d intermédiation générée. La méthodologie de cogénération supportée par les outils adéquats présente plusieurs intérêts majeurs : elle se base exclusivement sur un schéma conceptuel offrant des fonctionnalités de descriptions : o des «types d entité» (p.ex. : le type d entité «personnes» est subdivisé en deux types d entité «clients» et «employés», chacun de ces types d entité ayant ses propres caractéristiques) ; o des «attributs» (p.ex. : «nom», «adresses» est composée de «rue», «nr»,..) o des «types d association» qui lient les types d entité entre eux (p.ex. : un «employé» peut travailler pour une ou plusieurs «agences» et réciproquement dans une «agence» il peut y avoir plusieurs «employés»). Ces définitions sont traduites par le transformateur de schéma en termes techniques ; elle «isole» les processus de gestion des données des processus de traitements offrant ainsi une architecture «agile» permettant de faire évoluer les différentes «couches» techniques avec une certaine indépendance ; la méthodologie n induit ni n impose aucune «architecture technique». Seul le générateur de MAM est dépendant du choix de l architecture pour générer du code source. Ce dernier, lui, doit être conforme à Page 10

l architecture choisie et aux orientations stratégiques définies (centralisée, décentralisée, MDM, applicative) ; il s agit d une approche applicative, les vues «métier» n étant pas cantonnées à une seule base de données. Les MAM accèdent à plusieurs bases, éventuellement implémentées dans différents SGBD ; les MAM sont générés à partir de vues «métier». Les outils de cogénération génère une première vue «métier» reprenant la définition du schéma conceptuel. En partant de cette première vue «métier» il est possible de définir d autres vues «métier» chacune d entre elles donnant une perception différente de la BD : les MAM offrent des accès à la BD en suivant la logique de la vue «métier» dont ils sont issus ; la génération de code source peut se faire dans différents langage de programmation (JAVA, C, COBOL, ) ; elle est automatisée et donc immédiate ; elle est également applicable sur des bases de données existantes. Dans ce cas : o il faut reconstruire le schéma technique par rétro-ingénierie (un outil spécifique est également fourni) ; o en partant de ce schéma technique, les automates reconstruisent un schéma conceptuel «brut», génèrent une vue «métier», les MAM, leur documentation et le programme d édition de la BD. Page 11

2.3.1.1.2 Exemples L utilisation de la méthodologie est illustrée ici sur la base de données BIRT qui accompagne la plateforme de développement Éclipse. Le schéma conceptuel (BIRT/conceptuel figure 7 à gauche) contient cinq types d entité à savoir : des agences (rouge), des employés (brun foncé), des clients (bleu), des paiements (brun clair), des personnes (vert) qui sont soit des employés, soit des clients. À partir de ce schéma conceptuel, sont générés : un schéma «technique» relationnel (BIRT/SQL figure 7 à droite) qui est utilisé pour l implémentation du SGBD, une vue «métier». À partir de cette première vue «métier», résultat de la génération automatique, une seconde vue «métier» (BIRT- Finances/ «métier» figure 8) à été définie : le type d entité «personnes» a été supprimé, ses attributs ont été agrégés aux types d entité «clients» et «employés». Par ailleurs, le type d entité «paiements» a été intégré au type d entité «clients». Enfin certains attributs de «clients» ont été supprimés et/ou renommés. Les MAM générés à partir de la vue «métier» «finances» présentent les données comme si «clients» était une seule table composée des différents attributs décrits dans la vue «métier» (figure 9). Une documentation des MAM à l intention des développeurs est également générée ainsi qu un programme d édition de la base de données qui s appuie sur les MAM. Cet éditeur permet de «naviguer» dans la base en suivant les types d association définis par la vue «métier», de consulter, créer, modifier des données, de se familiariser avec les types d entité, les types d association et les méthodes qui les implémentent, en complément de la documentation générée. Page 12

2.3.2 Évaluer Pouvoir «évaluer» une application, mesurer la qualité des données, estimer les risques d adaptation d une application à des nouveaux besoins sont des fonctions indispensables pour une «bonne» gouvernance des données. Cette exigence se heurte à la réalité des applications. En effet, les programmes s accumulent au cours du temps, formant un agglomérat dont la complexité est renforcée par les évolutions technologiques, les maintenances évolutives et correctives. Cet accroissement de la complexité au cours du temps est accompagné en parallèle d une perte de la «connaissance» de l application : documentation incomplète, dépassée et «sachants» appelés à d autres fonctions ou tâches. Cette complexité des programmes engendre une opacité encore plus grande pour les données qui sont au cœur des applications. Dans ce contexte, le premier objectif de l IDDM est de comprendre l application afin d en avoir une connaissance suffisamment détaillée pour ensuite pouvoir mesurer la qualité des données, la qualité des bases de données, les risques, etc. 2.3.2.1 Comprendre La méthodologie de rétro-ingénierie explicitée ci-dessous a pour objectif de reconstruire la définition de l écosystème du S.I. quelle que soit la diversité des structures de stockage et de gestion des données qui le compose. Cette définition passe par la reconstruction des différents niveaux de modèle. Il va de soi que si un modèle complet ou partiel est déjà disponible, il n est pas obligatoire d exécuter toutes les étapes du processus décrit ci-dessous. Par ailleurs, la précision (la granularité) des modèles est dépendante des étapes réalisées et il convient en fonction des besoins du projet de choisir le niveau de précision adéquat. 2.3.2.1.1 Méthode Pour atteindre l objectif défini, la méthode proposée consiste à analyser deux catégories d éléments disponibles : les éléments techniques : les scripts de création de la BD, les codes sources de l ensemble des processus applicatifs (DB-procédures, triggers, programmes, JCL, scripts, ) et enfin les données elles-mêmes ; les éléments non-techniques tels que les documentations existantes, la connaissance des développeurs et des utilisateurs. L analyse des éléments techniques se déroule en plusieurs étapes successives qui améliorent et valident au fur et à mesure de leur déroulement la précision et la qualité du modèle. la première étape permet de reconstruire le modèle «physique» de la BD par simple analyse des scripts de création et/ou interrogation directe de la BD (pour la plupart des SGBD relationnels) ; la deuxième étape permet de compléter le modèle précédent par des éléments déclarés explicitement dans les programmes et non déclarés dans la BD. Ainsi, à titre d exemple, il est fréquent de trouver dans les BD des «colonnes» de plusieurs centaines de caractères dont la (ou les) description(s) est (sont) définie(s) dans les programmes. Cette étape est obligatoire lorsqu il s agit d applications fonctionnant avec des «fichiers plats» ; la troisième étape permet de produire le modèle «logique» de l application. Ce dernier est construit principalement en enrichissant les résultats de l étape précédente par la découverte des règles de gestion se trouvant dans les programmes ; la quatrième étape consiste à valider les résultats obtenus par l analyse des données. En effet, la nonconformité des valeurs des données aux règles définies dans le modèle a pour conséquence de s interroger sur l origine de l écart : valeur erronée, règle erronée ou règle incomplète? En outre, cette étape permet d enrichir le modèle sur la base des valeurs analysées : colonnes inutilisées, valeurs par défaut, etc. la dernière étape consiste à abstraire les résultats techniques pour produire un «modèle conceptuel» indépendant des technologies. Ce modèle conceptuel «brut» peut être complété par l apport des connaissances provenant de la documentation et des expertises disponibles. Cet apport permet alors d obtenir un schéma conceptuel dont la sémantique est enrichie et tend à exprimer au mieux la perception du S.I. du point de vue des utilisateurs. Le processus décrit ci-dessus est automatisé à plus de 90%. Les tâches manuelles sont les validations des résultats de chacune des étapes ainsi que l enrichissement du modèle conceptuel «brut» au moyen de la documentation et des expertises «humaines». Il convient également de souligner que la méthodologie Page 13

proposée est totalement générique et est utilisable pour tous les types de SGBD, de langages et de systèmes d exploitation. 2.3.2.1.2 Exemples Il n est évidemment pas possible ici de décrire de manière exhaustive tous les résultats du processus de rétro-ingénierie qui vient d être décrit. Deux types de résultats sont essentiellement à mettre en exergue : la précision des modèles ; les dépendances. 2.3.2.1.2.1 La précision des modèles C est le premier objectif recherché. Les copies d écrans ci-dessous illustrent chacune des étapes du processus de rétro-ingénierie montrant l évolution de la précision du modèle. L exemple est un sousensemble d une base de données IDS2 (environnement BULL GCOS8) devant migrer vers un environnement IBM, Z/OS et DB2 : à titre indicatif la base de données complète comprend 255 types de record et l application environ 1,5 million lignes de codes COBOL). L analyse du code de création de la base fait apparaître les types d entité (type de record IDS2) et les types d association déclarés. La notion «owner-member» propre aux bases réseaux indique le «sens» du type d association (p.ex : pour une occurrence de IDENT1 il est possible d avoir plusieurs INSTITUT, et réciproquement une occurrence d INSTITUT ne peut dépendre que d un et un seul IDENT1). Page 14

L analyse des codes sources des programmes permet de compléter le schéma physique notamment par l ajout des décompositions des structures telles qu elles sont utilisées par les programmes. Une analyse plus détaillée des programmes permet de compléter le schéma par des types d association complémentaires (en bleu dans l exemple) utilisés par les programmes. Ces types d association entre types d entité sont des «règles données» qui sont gérées exclusivement par les programmes. On notera sur l exemple que les deux «grappes» de types d entité qui semblaient être indépendantes l une de l autre sont en fait associées par l utilisation qu en font les programmes. Page 15

Afin de s assurer de l exactitude du modèle reconstruit par l analyse des codes sources, un processus automatique confronte les règles définies par le modèle aux données. Les règles ainsi contrôlées concernent tant le respect des formats que les types d association ou les contraintes de dépendances entre attributs. Pour produire le modèle conceptuel, les actions suivantes ont été réalisées : l'analyse des données a montré une équivalence des clés entre IDENT1 et I2DENT, donc ils ont été fusionnés; un record qui était l'implémentation d'une relation N-N est devenu un type d association après suppression des attributs redondants; dans INSTITUT, la contrainte rajoutée mettait en évidence le fait que l attribut IN_MAT était redondant avec le type d association IDIN, et donc cet attribut a été supprimé ; deux des contraintes ajoutées ont été transformées en types d association ; les décompositions des dates en années, mois, jours ont été supprimées, ainsi que la décomposition des comptes bancaires et la décomposition de notes en lignes. On notera que pour obtenir un schéma lisible il convient également de renommer les types d entité, les attributs et les types d association afin d avoir un vocabulaire significatif. Ce travail a bien été réalisé dans le cadre du projet, mais pour des raisons évidentes de confidentialité son résultat n est pas présenté ici. Page 16

2.3.2.1.2.2 L identification des dépendances Outre la reconstruction des modèles, la rétro-ingénierie a pour résultat l identification des dépendances entre composants du système technique. Trois types de dépendances sont identifiées : les dépendances «données-données», les dépendances «données-programmes», les dépendances «programmesprogrammes». Quel que soit le type de dépendance, celles-ci sont modélisées sous forme de graphe, les nœuds représentant les composants et les arcs les liens entre les composants. La connaissance de ces dépendances réduit de manière drastique les risques techniques des projets grâce à l identification de tous les éléments impactés par la modification de n importe quel composant. Dépendances «données-données» : le modèle indique les types d association (les dépendances, en rouge) entre données qui doivent être respectés sous peine de l introduction d une incohérence dans le S.I. Ainsi, à titre d exemple (figure 15), le changement d un code postal doit être répercuté dans les types d entité «adresse-succursale», «adresse-siège-social», «personnes-hors-entités». (projet de modernisation d une application : langage COBOL, sgbd : IDS2) Dépendances «données-programmes» : tous les accès à la BD sont identifiés et sont représentés sous forme d un graphe dans lequel : les nœuds sont les types d entité et les modules de programmation ; les arcs indiquent le type d utilisation (lecture, écriture, mises à jour) des types d entité par les modules. L exemple figure 16, montre la liste des programmes utilisant le type d entité «adresse-succursale» : toute modification de cette dernière peut avoir un impact sur les modules qui sont liés. (projet de modernisation : langage COBOL, sgbd : IDS2) Dépendances «programmes-programmes» : de la même manière que précédemment, tous les «appels» entre modules sont identifiés et sont représentés sous forme de graphe dans lequel : les nœuds sont les modules ; les arcs sont les liens entre les différents modules. Ce graphe est en fait la description de «l architecture» technique de l application. Il permet notamment de «suivre» le ou les chemin(s) de «propagation» d une modification effectuée dans un module. (projet de redocumentation d une application : langage C, sgbd : DB2) Cartographie applicative : elle est obtenue par la combinaison des deux types de graphe précédent et a pour objectif l obtention d une cartographie de l application ou d une de ses parties. (projet de redocumentation d une application : langage NATSTAR, sgbd : ORACLE) Page 17

Documentation : elle est obtenue par la simple exportation du contenu du référentiel de DB-MAIN. Les éléments conservés dans le référentiel de DB-MAIN sont exportés au format XML et traités par des processus automatisés pour les mettre au format souhaité : HTML, WIKI, DOCBOOK,.HLP, 2.3.2.2 Mesurer La «connaissance» détaillée d une application permet d apprécier la qualité des éléments de l application. En fonction des besoins, les évaluations peuvent aller de la simple «mesure» d un ou de plusieurs composants à la mise en place d une solution complète pour leur gestion. À titre d exemple, la connaissance détaillée du modèle des données d une application, permet en partie de mesurer son adéquation aux besoins informationnels des utilisateurs. Il va de soi qu il convient d adapter les méthodes en fonction du type de composants que l on souhaite mesurer voire améliorer. Quelques exemples de mesures possibles sont fournis ci-dessous. On notera toutefois, que dans la mesure où l IDDM se limite aux accès des données, elle ne peut prétendre à une évaluation de la qualité des «programmes» : ce point relève d un autre domaine de l informatique. 2.3.2.2.1 Qualité des données Au cours de la rétro-ingénierie, les processus utilisés à l étape quatre génèrent automatiquement les outils permettant d évaluer la conformité des données aux règles décrites dans le modèle. Cette évaluation est effectuée sur chacune des valeurs contenues dans la BD par rapport à l ensemble des règles que cette valeur doit respecter. Toutes les «non-conformités» sont identifiées et rapportées en indiquant pour chacune d entre elles quelle est la règle qui n est pas respectée, quelles sont les valeurs qui ne respectent pas la règle et quels sont les programmes concernés par ces données. À partir de ce point de départ il est possible de construire une plateforme de «mesure de la qualité des données» dont le fonctionnement est illustré par la figure 20. Le principe est de construire un référentiel qui contient l ensemble «des règles de gestion». Outre les règles provenant du modèle, ce référentiel peut intégrer d autres règles (conformités à des réglementations, des règles internes, ) fournies directement par des intervenants. À partir de ce référentiel, des processus automatisés génèrent les requêtes permettant de confronter les données aux règles. Ce processus permet d identifier : les données «erronées» susceptibles de faire l objet de corrections ; les règles de gestion «incomplètes» ou inexactes et qui doivent être précisées. La connaissance des dépendances «données-programmes» renforce la démarche de «prévention des erreurs» en particulier par l amélioration des contrôles effectués dans les programmes. Page 18

Dans le même ordre d idée il est possible d adjoindre des modules complémentaires : d historisation des résultats des contrôles permettant ainsi une mise en perspective des améliorations de la qualité des données et d une évaluation du ratio «coûts des efforts d amélioration de la qualité / résultats obtenus» ; d évaluation de l impact des données erronées en terme «métier» en se basant sur des règles d évaluation «métier» : par exemple l absence d un code postal dans une adresse empêche l expédition d une facture ce qui représente un impact financier de x% du montant de la facture. Il va de soi que les mesures effectuées par les systèmes décrits ici n ont pas la prétention de résoudre l entièreté des questions concernant la «qualité des données». En effet, les données contenues dans les bases de données informatisées se doivent d être le plus proche possible de la réalité du domaine qu elles décrivent : en particulier elles doivent être exactes, fiables et à jour. Quels qu ils soient, les systèmes techniques de contrôle ne peuvent prétendre atteindre ce résultat qui reste une responsabilité «humaine» et organisationnelle : tout au plus peut-on espérer des systèmes techniques le contrôle d une certaine «cohérence» des données. En d autres termes, il n est pas possible pour un système technique de vérifier que Madame X a bien 3 enfants mais par contre il est possible de mettre en évidence qu une base de données signale qu elle en a 3 alors qu une autre n en indique qu un seul. 2.3.2.2.2 Qualité des bases de données Au-delà de la qualité des données, l IDDM permet d apprécier la qualité de la base de données. Les critères à prendre en compte peuvent être très divers : nombre de colonnes par tables, nombre d identifiants, redondance des attributs, règles de gestion définies dans le SGBD, utilisation des données par les programmes, etc. Il va de soi que ces appréciations viennent compléter les informations fournies par les SGBD en matière de performance, de taux d utilisation, etc. L évaluation de la qualité de la base de données est utile notamment pour : évaluer la complexité des évolutions des applications : degré de dépendances des types d entité, redondances des informations, dépendances des éléments, etc. compléter les évaluations de la qualité des programmes pour fournir une mesure de la qualité d une application. Des travaux plus approfondis en la matière sont actuellement en cours : ils concernent notamment la détection automatique de constructions complexes susceptibles d être sources d erreurs. 2.3.2.2.3 Risques programmes-bases de données La connaissance du modèle et des dépendances programmes-données permet de classifier les programmes par risques-bd. Le principe adopté est de calculer un poids pour chacun des programmes : c est la sommation du poids de chacun des accès pondéré par le type d action (lecture, écriture, ) et le rôle de chacune des types d entité dans le modèle. Les programmes sont alors mis sur l axe des X par ordre de poids croissant. L axe des Y, lui, peut varier en fonction des objectifs de représentation (taux d utilisation des programmes, fréquence de maintenance, ). Cet outil est souvent utilisé dans le cadre des tests. Les programmes «pesant» le plus lourd et utilisés le plus fréquemment sont ceux qui représentent le plus grand risque : ils sont donc à tester prioritairement et sans doute de manière plus approfondie que les programmes à «faibles risques». Page 19

2.3.3 Évoluer Aussi riches qu ils soient, les systèmes d information ne sont et ne seront jamais qu un «discours» sur la réalité. A ce titre ils sont irrémédiablement condamnés à être complétés, enrichis afin de «coller» au plus près à la réalité qu ils prétendent décrire. Par ailleurs, la réalité est changeante et évolue au cours du temps. L exigence de l évolution des systèmes d information est donc une nécessité vitale de la gouvernance des données. Du point de vue des analystes «métier», les évolutions possible d un S.I peuvent être classées en trois catégories : soit il s agit de répondre à des changements fonctionnels liés à des changements organisationnels ou réglementaires, ce qui implique des modifications dans la base de données de l application existante ; soit il s agit de changements «techniques» et en particulier un changement de SGBD tout en conservant l application existante : il s agit d une modernisation de l application ; soit enfin il s agit de remplacer l application existante par une nouvelle. Dans ce cas, il convient d exporter les données d une application existante pour les importer dans une autre base de données : ce type d évolution est traité au chapitre suivant. 2.3.3.1 Modifier et/ou moderniser Si d un point de vue fonctionnel et technique les deux types d évolution pris en compte dans ce chapitre n ont pas les mêmes objectifs, force est de constater que du point de vue méthodologique les méthodes utilisées dans les deux cas sont très proches. 2.3.3.1.1 Méthode Les processus à exécuter sont semblables et synthétisés dans le tableau de la figure 23 : les différences dans la méthodologie sont mises en italique. La méthode prévoit cinq phases principales : 1) COMPRENDRE. C est une des spécificités fortes de la méthode proposée : il faut une connaissance suffisante de l écosystème source. A l image d un GPS qui ne peut pas calculer un chemin sans se situer, la connaissance du point de départ d un projet est indispensable à sa réussite. 2) DÉFINIR. Cette phase consiste à définir dans les modèles les évolutions qui doivent être réalisées pour atteindre les résultats finaux espérés : changements des structures et des règles de gestion. Concrètement cela revient à définir le modèle conceptuel de la base cible. Dans le cas d une «modernisation» le modèle conceptuel de la base cible peut être identique ou différent de celui de la base source. 3) CONTRÔLER. A ce stade, les situations source et cible étant connues, il convient d identifier les obstacles qui pourraient empêcher le passage de la source à la cible. Ces obstacles, qui de fait sont les risques techniques des projets, proviennent de trois origines distinctes qui doivent faire l objet de contrôles a priori : o Contrôle des «compatibilités» : il s agit d identifier les «incompatibilités» entre source et cible, c est-à-dire toute évolution qui ne peut pas être réalisée par un simple «transfert» de valeurs. Les types d incompatibilités Page 20

dépendent bien entendu du type de projet, l essentiel étant de pouvoir, pour un projet spécifique, les détecter. À titre d exemple, et sans que la liste ci-dessous ne soit exhaustive : dans le cas des évolutions de bases de données, les incompatibilités proviennent essentiellement de la «non-conformité» des données aux nouvelles règles de gestion définies pour la base cible : par exemple si une colonne a évolué pour devenir une «clé étrangère» il est nécessaire de vérifier que les valeurs des données soient conformes à cette règle ; dans le cas des changements de SGBD, les incompatibilités proviennent généralement de fonctionnalités supportées par le SGBD source et non supportées en tant que telles par le SGBD cible : par exemple dans la plupart des SGBD «legacy» (IMS, IDS2, IDMS, ) l ordre de présentation des «lignes» d une table est défini au moment de l écriture, alors que dans un SGBD relationnel cet ordre est défini au moment de la lecture. Cet ordre pouvant avoir de l importance pour les programmes applicatifs, il convient dans ce cas de définir les clés de tri adéquates qui permettront le bon fonctionnement des programmes. o Contrôle de la qualité des données : quelles que soient les règles d évolutions à appliquer, il convient de vérifier que les données «source» sont conformes aux règles du S.I. cible. Ce o contrôle s effectue en vérifiant la conformité des données par rapport au modèle cible ; Contrôle de la propagation des modifications : la connaissance des trois niveaux de dépendances («données-données», «données-programmes», «programmes-programmes») permet d identifier pour chacune des modifications d un élément de l écosystème les répercutions sur les autres éléments. 4) EXÉCUTER. Les activités à déployer au cours de cette phase sont : o la génération automatique des outils nécessaires pour la création de l écosystème cible : les structures de la base cible ; dans le cas de modernisation, les accès à la base cible ; les composants (programmes) de la migration des données : les programmes de déchargement en intégrant les transformations de valeur et/ou changements de format nécessaires ; les scripts de rechargement de la base cible ; o o l exécution des programmes de déchargement pour produire des fichiers «plats» au format des tables de la base cible directement chargeables dans la base au moyen des scripts et des utilitaires standard du SGBD ; dans le cas de la modernisation, l adaptation des programmes applicatifs pour qu ils utilisent les accès à la base cible qui ont été générés. On notera que les adaptations des programmes applicatifs pour qu ils prennent en compte les évolutions fonctionnelles sont en dehors de la portée des automates : elles restent donc à réaliser par des intervenants. 5) VALIDER. Cette phase a pour but de garantir que la migration des données depuis le S.I. source vers le S.I. cible n a pas perturbé la cohérence de l écosystème. La démarche utilisée consiste à déduire des modèles source et cible et de leurs correspondances, un modèle «commun» à partir duquel il est possible de générer des programmes qui permettent de valider la migration sous deux angles : o validation de l exhaustivité : les programmes générés pour chacun des environnements source et cible effectuent un comptage du nombre d occurrences physiques dans les bases et un contrôle fonctionnel (checksum) de chacun des attributs. Un rapport publie les résultats de ces comptages en mettant en exergue les éventuelles différences. o validation de la cohérence : les programmes générés extraient de chacune des bases les données. Les résultats des extractions sont comparés et un rapport publie les éventuelles différences de valeurs et d occurrences. On notera que cette méthode est utilisable quels que soient les types de SGBD et les structures des bases source et cible et qu elle permet de valider une migration de données indépendamment de toute application. Page 21

2.3.3.1.2 Exemples Plusieurs phases du processus ont déjà été illustrées dans les pages précédentes. L exemple donné ici concerne la phase de validation de la migration des données et plus particulièrement la validation du maintien de la cohérence des données. Il s agit d un exemple de migration de données d une base source vers une base cible dont les structures étaient différentes. La figure 24 montre une partie du modèle commun issu de la comparaison des bases source et cible. À partir de ce modèle, un générateur de code a produit : le code source d un programme d extraction des données pour la base source ; le code source d un programme d extraction des données pour la base cible. Les exécutions des programmes d extraction dans les environnements source et cible fournissent deux fichiers au format XML qui doivent contenir les mêmes données. Un comparateur de fichier XML permet de vérifier cette assertion. Dans un premier temps, le comparateur met en exergue les différences d occurrences dans les fichiers comparés. Dans un second temps, le comparateur met en exergue les différences de valeurs dans les occurrences identiques des fichiers comparés. Page 22

2.3.3.2 Coévolution La coévolution n est qu un cas particulier de la méthodologie de modification décrite ci-dessus : la seule différence est l ajout dans la phase d exécution du générateur de MAM pour la nouvelle définition de la base. 2.3.3.2.1 Méthode Ce processus est illustré de manière détaillée par la figure 27 : il part d un modèle conceptuel existant et comprend six étapes successives : 1) la première consiste à définir le nouveau schéma conceptuel en partant du schéma conceptuel existant. Une fois que le nouveau schéma conceptuel est défini, un transformateur de schémas produit un nouveau schéma technique et une nouvelle vue «métier» ; 2) la deuxième étape a pour objectif de s assurer que les données contenues dans la base de données sont compatibles avec les contraintes et règles définies pour la nouvelle version de la base. Un rapport indique les données «non-conformes» : il est alors nécessaire soit de corriger et/ou d adapter la ou les donnée(s), soit de redéfinir la ou les contrainte(s) ; 3) la troisième étape produit, en fonction des choix effectués, soit un script d adaptation de la base de données technique existante soit un script de création d une nouvelle base de données. Le choix entre l un ou l autre des scripts est souvent lié à l importance des modifications effectuées ; 4) la quatrième étape a pour objectif d adapter et/ou de migrer les données contenues dans la base existante vers la nouvelle base. Cette étape génère également les processus de validation qui permettent de garantir l exhaustivité de la migration et le maintien de la cohérence des données ; 5) la cinquième étape permet de générer les modules d accès «métier» (MAM) pour la nouvelle version de la base de données. Elle fournit également la liste des MAM existants qui sont impactés par les évolutions ; 6) enfin la sixième et dernière étape a pour objectif de fournir aux développeurs la liste des programmes et/ou modules applicatifs impactés par les modifications et qu il convient d adapter. Page 23

2.3.4 Réutiliser Les données sont les matières premières pour la fabrication de l information. Elles doivent donc pouvoir être utilisées dans d autres contextes que ceux dans lesquels elles sont gérées : il faut pouvoir les exporter c est-à-dire les extraire pour les échanger, les archiver, ou plus simplement produire des échantillons, éventuellement rendus anonymes, à des fins de tests ou de formation. Si les données doivent pouvoir être exportées, elles doivent pouvoir également être importées. Dans ce cas il faut pouvoir, sans qu elles ne perdent leur cohérence et signification, les transformer, les agréger, les désagréger, les intégrer dans d autres S.I. dont les structures et les règles de gestion sont fixées au préalable. 2.3.4.1 Exporter La nécessité d exporter tout ou partie des données d une application est très fréquente : échanges de données avec des partenaires (clients, fournisseurs, ), archivage de données «inactives», mise à disposition d intervenants du «métier» de sous-ensembles à des fins de contrôles, de tests, de formation, etc. L objectif est de permettre d extraire d une base de données des sous-ensembles cohérents de données selon une logique «métier». 2.3.4.1.1 Méthodes Pour atteindre l objectif, la méthode suivie consiste à : 1) définir dans le modèle conceptuel le ou les sous-ensemble(s) «fonctionnel(s)» souhaité(s). Ces sousensembles définissent la liste des types d entité et des attributs à extraire ; 2) définir les critères qui permettent de réduire la volumétrie des données au sein des sous-ensembles fonctionnels créés à l étape précédente ; 3) définir pour chacun des sous-ensembles fonctionnels les modèles «cible» à produire : ces modèles cibles permettent en fait de définir les «formats» résultats de l extraction (fichiers plats, base de données, fichier XML, ) ; 4) générer le code des programmes de sélection : l objectif de ces programmes est d obtenir les «clés» des types d entité «racines» des sous-ensembles fonctionnels ; 5) générer le code des programmes d extraction dont le but est d extraire les données des bases de production pour toutes les occurrences de clés sélectionnées. Page 24

2.3.4.1.2 Exemples La réduction fonctionnelle se fait en partant d une vue «métier» correspondant aux besoins fonctionnels. La définition de la vue «métier» permet de déduire le sous-ensemble des tables nécessaire et suffisant pour la fabrication des jeux de données. L extraction des données d un type d entité «métier» peut nécessiter plusieurs requêtes sur différentes tables techniques : ces requêtes sont gérées par les modules d accès «métier» correspondant à la vue «métier». La réduction volumétrique se fait à partir des attributs définis dans la vue «métier». Dans l exemple, l objectif est de ne retenir que les «personnes ayant au moins une dette exceptionnelle annulée pour cause de faillite». Un premier filtre montre que le nombre de personnes ayant au moins une «dette exceptionnelle» est de 21.824 sur un total de dettes de 156.418. Un deuxième filtrage concernant les «dettes annulées» réduit le nombre à 4.510. Enfin un dernier filtrage sur les valeurs de l attribut «raison» du type d entité «DISPENSE» permet de réduire le nombre final à 159. Pour ces 159 personnes, les données sont extraites au format XML suivant la logique définie par la vue «métier». La DTD du fichier XML résultat est déterminée par le modèle XML de la base réduite. 2.3.4.2 Jeux de tests Pour la fabrication de jeux de tests, les outils d extraction sont complétés par : l utilisation des dépendances données-programmes pour déterminer automatiquement le sous-ensemble fonctionnel nécessaire et suffisant pour les programmes à tester ; des outils permettant : o de générer des données à partir de règles prédéfinies. Cette génération permet : la génération de «lignes» dans les tables ; la génération de valeurs dans les colonnes de chacune des lignes ; o d anonymiser les données à des fins de confidentialité. Ce processus doit assurer le maintien de o la cohérence des données lorsque des identifiants sont modifiés par l anonymisation ; de comparer les valeurs des données avant et après test, apportant une aide efficace au dépouillement ; des outils permettant d évaluer la couverture «technique» des tests. Le but recherché ici est de déterminer le taux de couverture du jeu de données ayant servi aux tests : si le jeu de données n a permis de tester que 30% d un programme, il est probable qu il soit nécessaire de fournir un nouveau jeu de données. 2.3.4.3 Épuration De la même manière que pour les jeux de tests, les outils d extraction peuvent êtres complétés par des outils qui suppriment de la base les données qui ont été extraites. Page 25

2.3.4.4 Importer Si les données doivent pouvoir être exportées, elles doivent pouvoir également être importées. Dans ce cas il faut pouvoir, sans qu elles ne perdent leur cohérence et signification, les transformer, les agréger, les désagréger, les intégrer dans d autres S.I. dont les structures et les règles de gestion sont fixées au préalable. 2.3.4.4.1 Méthode La méthodologie utilisée pour importer des données est proche de celle utilisée pour les évolutions des bases de données ainsi que l illustre la figure 31 : on retrouve dans le processus les mêmes cinq mots-clés : 1) COMPRENDRE. Il s agit de s assurer que l ensemble des éléments constitutifs des écosystèmes source et cible sont identifiés et connus avec un degré de précision suffisant pour atteindre les objectifs du projet. 2) DÉFINIR. Dans les processus d importation, le modèle cible est déjà défini. Dès lors les définitions attendues dans cette phase sont les correspondances sources-cibles. Il va de soi que ces correspondances sont d abord d ordre sémantique puis dans un second temps d ordre technique. 3) CONTRÔLER. Une fois que les correspondances sont définies, il convient : d identifier les «incompatibilités» (voir les exemples plus loin dans le document) qui proviennent : o des différences dans les règles de gestion (en ce compris celles gérées par les programmes), o des différences dans les définitions des structures ; de valider les règles de transformation qui vont permettre de résoudre les incompatibilités détectées. La diversité des situations et des règles de transformation ne permet pas d automatiser cette phase. Les règles de transformations spécifiques doivent donc faire l objet de développements appropriés. Au préalable, un prototypage des règles de transformation est réalisé afin de s assurer de leur validité avant d effectuer les développements proprement dits. Chacune des règles de transformation est testée sur la totalité des données qui la concerne ; à l issue du prototypage de chacune des règles de transformation, il est nécessaire de contrôler la qualité des données transformées par rapport au modèle «cible», afin de s assurer de leur conformité aux règles du système cible. Ce contrôle permet de fait de valider les règles de transformation. 4) EXÉCUTER. Il faut d abord développer, sur base des prototypes réalisés, les modules spécifiques qui assurent les transformations complexes. Ensuite, un générateur de codes sources permet de produire les programmes de «déchargement» en y intégrant les modules développés et les transformations «standard» telles que les changements de type ou les changements de format. Les scripts de chargement pour la base cible sont également générés. Enfin, l exécution des programmes et des scripts générés permet d effectuer la migration. 5) VALIDER. Cette phase permet de garantir que la migration des données depuis le S.I. source vers le S.I. cible a maintenu la cohérence des données existantes dans l écosystème source : en d autres mots il faut s assurer que les commandes de Monsieur X n ont pas été attribuées à Madame Y. La démarche utilisée Page 26

consiste à déduire des modèles source et cible et des correspondances qui ont été établies, un modèle «commun» (souvent au format XML) à partir duquel il est possible de générer des programmes qui permettent de valider la migration : a. validation de l exhaustivité : les programmes générés pour chacun des environnements source et cible effectuent un comptage du nombre d occurrences physiques dans les bases et un contrôle fonctionnel de chacun des attributs. Un rapport au format HTML publie les résultats de ces comptages en mettant en exergue les éventuelles différences ; b. validation de la cohérence : les programmes générés extraient de chacune des bases les données au format XML. Les fichiers résultats des extractions sont comparés et un rapport publie les éventuelles différences de valeurs et d occurrence. 2.3.4.4.2 Exemples Cette partie illustre une des innovations les plus intéressantes de l IDDM : la comparaison de modèles. Elle permet d identifier les «incompatibilités» entre les S.I. source et cible, «incompatibilités» qu il faut résoudre par des règles de transformation. Soit l exemple d une migration de données illustrée par la figure 32. Dans cet exemple, on supposera que les intervenants ont défini qu il existait une correspondance entre les types d entité contrats, avenants et sinistres des S.I. source et cible. En tant que tel cette migration n est pas possible dans la mesure où il existe une «incompatibilité» de règle de gestion des types d entité : dans la base cible, les «sinistres» dépendent des «avenants» alors que ce n est pas le cas dans la base source. Dès lors si, dans la base source, il existe pour un contrat plusieurs avenants et plusieurs sinistres, la question se pose de savoir à quels «avenants» doit être «rattaché» chacun des sinistres. De même, que faire s il existe pour un contrat de la base source des sinistres et aucun avenant? Ainsi que l illustre la figure 33, la comparaison des modèles permet d identifier les incompatibilités des types d association. La comparaison des modèles permet également d identifier les incompatibilités entre attributs des types d entité : format, longueur, présence obligatoire, etc. La résolution des problèmes d incompatibilité relève de la compétence des intervenants du projet. On notera cependant que généralement il s agit de décisions qui sont de la compétence des responsables «métier» et pas des techniciens comme le montrent clairement les deux exemples précédents. Page 27

3 Perspectives de l IDDM Comme on le voit, l approche IDDM offre un ensemble de solutions couvrant une très large part des besoins de la gouvernance des données en termes tactiques et opérationnels. Par ailleurs, l industrialisation de ces solutions permet de se «libérer» de plus en plus des aspects purement technologiques. La pratique de la démarche d IDDM amène à constater qu elle «raccourcit» la distance entre «métier» et IT. Rien de plus normal somme toute : que peut-on espérer de mieux qu une formalisation (les modèles) pour définir les exigences et utiliser cette formalisation pour la réalisation technique? Aussi séduisante soit-elle, l IDDM reste toutefois une pratique qui nécessite une bonne connaissance des bases de données et des modèles. Même si elle a quitté le monde des scientifiques, elle reste encore affaire d intervenants bien formés. Dès lors l objectif du développement de la démarche IDDM est défini : rendre la démarche utilisable au quotidien dans les organisations. Cet objectif sera atteint par : l amélioration et l industrialisation continue des solutions définies ; l amélioration des interfaces hommes-machines ; le couplage avec des produits de modélisation couvrant d autres domaines de l organisation. Le premier point tombe sous le sens : chaque nouveau projet apporte sa pierre à l édifice et renforce à la fois la solidité de la solution et son automatisation. Les deux autres points ouvrent des perspectives intéressantes et font d ores et déjà l objet de réalisations avancées qui seront disponibles prochainement. 3.1 Amélioration des interfaces hommes-machines Une démarche IDDM exige de pouvoir utiliser toutes les potentialités et les richesses des modèles : il n est donc pas pensable d envisager «d appauvrir» la modélisation au prétexte d une trop grande complexité. Néanmoins, à l image de la musique qui peut être entendue de tous sans connaissance de son langage formel (le solfège), l objectif recherché ici est de rendre les modèles et leur langage formel accessibles à tous les intervenants concernés (utilisateurs, analystes «métier», développeurs, DBA, ). L approche choisie est de permettre des «traductions» du langage formel qu est la modélisation vers un langage «usuel» tel que le texte. Idéalement, ces «traducteurs» devraient pouvoir travailler dans les deux sens : depuis le modèle vers le texte et réciproquement du texte vers le modèle. Page 28

Le sens modèle vers texte est illustré par la figure 36 : cette traduction est obtenue au moyen d outils complémentaires de traitements linguistiques. Si le résultat obtenu est déjà séduisant en soi, son utilisation optimale se situe probablement dans son intégration avec des interfaces interactives permettant un dialogue entre «concepteur» et utilisateurs. Des prototypes très avancés ont déjà été réalisés et sont en voie d industrialisation. Le sens texte vers modèle a également été exploré. Les prototypes réalisés qui intègrent également des outils d analyse linguistique permettent effectivement de produire un modèle en partant d un texte français (ou anglais) de spécifications de base de données. Si le développement technique de tels outils n est pas problématique en soi, il semble qu aujourd hui «le marché» n est pas demandeur d une telle démarche. Le développement de tels outils est donc plus une question d opportunité commerciale que de réalisation technique. 3.2 Couplage avec d autres systèmes de modélisation La modélisation décrite jusqu à présent est celle qui permet de représenter les systèmes techniques informatiques : elle est par essence limitée à cet univers. Dans l univers des organisations, la technique informatique n est qu un outil de support à leurs activités qui font également l objet de modélisations plus ou moins avancées. Les buts de ces modélisations sont très divers, les approches multiples et font l objet de débats intenses au sein des communautés spécialisées. La question soulevée ici est pragmatique : est-il possible de «coupler» les modèles utilisés par l IDDM à d autres types de modèles? Pour tenter de répondre à cette question, un cas pratique a été réalisé sur une application du Ministère belge des Finances : l application concerne la gestion des dettes des entreprises et fonctionne dans un environnement DB2 et JAVA. La modélisation de l application informatique a été réalisée au moyen de DB-MAIN et des outils de rétro-ingénierie. La modélisation en amont de l application informatique a été réalisée au moyen de l outil d Ingénierie des Exigences OBJECTIVER de la société RESPECT-IT. Pour synthétiser, et sans vouloir entrer ici dans les détails(pour en savoir plus à propos d OBJECTIVER voir http://www.objectiver.com/index.php?id=4&l=1 ), OBJECTIVER a une approche centrée sur les objectifs «métier» et permet de préciser au moyen de modèles : les besoins «métier» (modèle des exigences) permettant de générer des cahiers des charges ; les activités «métier» (modèle des opérations) mises en œuvre pour répondre aux exigences. Page 29

La figure 37 illustre le processus réalisé dans le cadre de ce projet : d une part l utilisation d OBJECTIVER pour produire le modèle des exigences et le modèle des opérations ; d autre part l utilisation de DB-MAIN pour produire le modèle des traitements et le modèle des fonctions. La confrontation (manuelle) du modèle des opérations et du modèle des fonctions a permis de vérifier la similitude des modèles (ce qui signifie dans ce cas que l application est conforme aux spécifications). De manière pragmatique, l extraction des informations provenant des deux outils a permis de construire un tableau établissant les correspondances depuis l expression des besoins jusqu aux traitements. Le tableau de la figure 38 en est un extrait. Les résultats obtenus ouvrent de nouvelles perspectives pour : la maîtrise continue des applications et en particulier la redocumentation d applications existantes ; la gestion des changements ; la réception d applications informatiques. Ce dernier point fait actuellement l objet d un projet de développement et est explicité ici. Page 30

3.2.1 Réception d applications Le but du projet est de fournir un cadre méthodologique et les outils techniques permettant aux organisations de «réceptionner» les développements d applications informatiques au travers de trois sousobjectifs principaux : s assurer de la conformité de la solution informatique aux exigences «métier» définies dans le cahier des charges ; réduire les coûts et le temps des tests garantissant le «bon fonctionnement» de l outil technique ; identifier les risques «techniques» afin de permettre : o lors de la mise en production, l établissement de solutions alternatives, l élaboration des plans de réversibilité, etc. ; o l évaluation de la capacité du logiciel à répondre aux besoins évolutifs de l organisation. Le dernier point relève des méthodes et outils techniques décrits précédemment : il ne nécessite guère de développements importants mais doit être industrialisé. Pour le deuxième point, deux axes sont envisagés : l enrichissement du tableau des correspondances pour l établissement des priorités de tests ; la génération automatique de «use case» à partir du modèle des opérations. Le tableau des correspondances exigences-traitements peut être enrichi par un certain nombre d informations permettant d établir des priorités de tests et d éventuellement prononcer des réceptions provisoires. L enrichissement du tableau se fait à partir de trois sources d informations complémentaires : la «criticité» de l exigence pour le «métier» ; l évaluation des risques BD fournis par des outils de mesure des dépendances données-programmes ; l évaluation de la complexité des programmes fournis par des outils de mesure de la qualité des programmes. La génération automatique de «use case» à partir du modèle des opérations existe en tant que prototype : elle doit encore faire l objet de développements supplémentaires. Lorsqu elle sera disponible elle permettra notamment d alimenter les outils de test par la définition des critères de sélection volumétrique. L approche proposée permettra de vérifier la conformité de la solution informatique aux spécifications fonctionnelles. Il va de soi que ne sont pas envisagées ici les problématiques de tests de l interfaçage Homme-Machine, de tests des performances, etc. Page 31

ANNEXE 1 : LEXIQUE BD ou base de données : lot d'informations stockées dans un dispositif informatique de manière organisé et structuré afin de pouvoir facilement manipuler le contenu au moyen de programmes et stocker efficacement de très grandes quantités d'informations. Suivant le contexte désigne l'enveloppe (les «structures») ; le contenu de l'enveloppe (les «données») ; ou les deux. IDDM ou Ingénierie des Données Dirigée par les Modèles : processus d IDM appliqué aux données informatiques. IDM ou Ingénierie Dirigée par les Modèles : processus qui construit un objet technique à partir d une description formelle et abstraite de l objet à réaliser. ingénierie est le processus qui permet de concevoir, de décrire, de réaliser et de mettre en production un système technique. Dans le domaine des bases de données, il s agit de réaliser le système de stockage des données. JCL ou Job Control Language : langage de commande des systèmes informatiques permettant de définir l environnement technique nécessaire et suffisant pour l exécution d un ou d un ensemble de programmes. MAM ou Modules d Accès «Métier» : ensemble de programmes permettant d accéder (lire, écrire, modifier, supprimer) des données dans une base de données. MOA ou Maîtrise d Ouvrage : entité organisationnelle donneuse d ordre, au profit de laquelle un ouvrage est réalisé. MOE ou Maîtrise d œuvre : entité organisationnelle chargée de la conduite opérationnelle de la réalisation d un ouvrage. modèle des accès : il permet de représenter l ensemble des accès et des types d accès (lecture, écriture, modification, etc.) aux données. Son objectif est de pouvoir appréhender de manière précise l utilisation des données par les programmes. modèle des activités : il permet représenter la ou les séquence(s) d enchaînement des traitements effectués sur les données. Son objectif est l identification des flux des données dans les processus de traitements. modèle des données : il s agit d un terme générique qui couvre : modèle conceptuel : destiné aux analystes «métier», il est une description de la base de données gérée par l application informatique. Par nature ce modèle est indépendant de toutes technologies, ne contient aucune description ou construction technique et décrit la «sémantique» de la base de données répondant aux besoins opérationnels des utilisateurs ; modèle logique : destiné aux développeurs, il est une description technique de la base de données qui prend en compte et intègre les spécificités du type de SGBD qui la supporte ; modèle physique : destiné aux administrateurs de bases de données (DBA), il est une description technique de la base de données qui prend en compte les caractéristiques du SGBD spécifique qui la supporte. PRINCIPAUX VOCABLES POUR LA MODÉLISATION MERISE ENTITÉS-ASSOCIATION UML entités type d entité classes propriétés attributs propriétés relations type d association type d association modèle «technique» : ce terme désigne le regroupement en un seul modèle des modèles logiques et physiques. En effet, dans l univers «relationnel», les modèles logiques et physiques sont suffisamment proches l un de l autre pour qu ils puissent être confondus au moins au niveau de ce document. Ce modèle est dit «technique» dans la mesure où il sert à l implémentation technique de la base de données. reingéniérie : processus qui permet de transformer un système technique existant pour le rendre conforme à des spécifications. Pour les bases de données, il s agit de transformer une base de données (c'est-à-dire les structures, les données et leurs interactions avec les programmes) pour qu'elle puisse être utilisée pour répondre à de nouveaux besoins organisationnels ou fonctionner dans de nouveaux environnements technologiques. Page 32

règles de gestion (ou règles données) : dans un système d information, les règles de gestion garantissent la cohérence du système d information lorsque celui-ci est «au repos», c est-à-dire lorsqu aucun programme n est en exécution. Dans ce sens, les règles données sont distinctes des règles de traitement qui, elles, définissent comment obtenir un résultat escompté. Ainsi, à titre d exemple, si le montant total d une «commande» est une donnée stockée, la règle données dit que : «le montant total de la commande est la somme du montant de chaque ligne de cette commande». Cette règle données ne précise ni comment ni à quel moment ce calcul doit être fait : ce point relève des règles de traitement. rétro-ingénierie : processus qui étudie des processus techniques existants dans le but d en obtenir une description complète et détaillée. Dans le domaine des données, il s agit d obtenir une description des structures, des règles de gestion, des dépendances et des accès. L objectif est de «reconstruire» les différents modèles à partir d un système technique existant. schéma : d un point de vue strictement formel un «schéma» est une instance, une représentation d un «modèle». Toutefois, dans ce document, les mots «schéma» et «modèle» sont utilisés indifféremment. SGBD ou Système de Gestion de Base de Données : ensemble logiciel qui permet d'organiser, de contrôler, de consulter et de modifier les structures et/ou les données d une base de données. Les SGBD sont classés par type selon les possibilités d organisation des données qu ils offrent : Plat (VSAM, ISAM, UFAS, ) ; Hiérarchique (IMS, ) ; Réseaux (IDMS, IDS2,..) ; Relationnels (DB2, My Sql, ORACLE, Postgres, SqlServer, ) ; XML ; etc. PRINCIPAUX VOCABLES POUR LES SGBD HIÉRARCHIQUE RÉSEAU RELATIONNEL segment type de record table champ champ colonne lien set S.I. ou Système d Information : ensemble de données relevant d un domaine d application défini. transformations : analogues à des fonctions «mathématiques», il s agit de processus d aide à la modélisation qui permettent de changer un objet d un modèle en un autre objet (par exemple une entité en relation). D un point de vue théorique, les fonctions de transformations doivent respecter des règles précises qui garantissent le maintien de la cohérence et de la sémantique des modèles sur lesquelles elles agissent. S.O.A. ou Services Oriented Architecture : approche architecturale pour organiser des composants logiciels sous forme de services interopérables. vues «métier» : elles se situent sur le même niveau d abstraction que le modèle conceptuel : elles sont une description totale ou partielle de la base de données du point de vue des intervenants «métier». Destinés à l utilisation de la base de données, la ou les vue(s) «métier» regroupe(nt) les objets «métier» d accès aux données. Ces objets sont dérivés par transformation du modèle conceptuel mais ne sont pas nécessairement identiques aux types d entité définies dans celui-ci. Ils peuvent être une partie d un type d entité, une agrégation de plusieurs types d entité ou inversement, le même type d entité peut être utilisé par plusieurs objets «métier». Dans ce document le modèle conceptuel et les vues «métier» se distinguent par leurs caractéristiques et leurs finalités: le modèle conceptuel est unique, décrit l entièreté de la base de données, et est la définition qui permet, par transformation, de construire la base de données technique dans laquelle seront stockées les données; les vues «métier» peuvent être multiples, décrire tout ou partie de la base de données, et sont les éléments de définition pour l utilisation des données contenues dans la base de données. Leur sémantique peut être différente de celle du modèle conceptuel. Page 33

ANNEXE 2 : EXEMPLE D ÉCOSYSTÈME Premier composant de l écosystème : les structures. La figure 40 illustre un modèle de structures que l on pourrait définir pour la gestion d un site de vente à distance. Le modèle contient deux types d entité : des paniers : ils sont caractérisés par un numéro de commande, un client, une date et deux totaux ; la valeur d un panier est déterminée par deux attributs : la valeur totale des articles ajoutés et la valeur de la livraison. des articles ajoutés : ils sont caractérisés par un numéro d article une quantité et un prix unitaire. Chacun des attributs est caractérisé par un format, «alphanumérique», «numérique», «date», etc. Ce format est une règle donnée gérée par le SGBD. Le modèle montre également le lien de dépendance entre les paniers et les articles : un panier contient des articles, et les cardinalités 1-N et 1-1 des rôles de chaque type d association précise les règles de cette dépendance : un panier contient des articles ajoutés, pas le contraire ; un panier doit contenir au moins un article ajouté. D autres règles données sont également définies dans le modèle : un panier est identifié par un numéro de commande, ce numéro est unique ; un article ajouté est identifié par un numéro d article, il doit être unique dans le panier qui le contient. Second composant de l écosystème : les valeurs elles-mêmes PANIER Numero_Commande Numéro_Client Date_Commande Total_Articles Total_Livraison 123456789 j.dupont@achat.org 28/02/2011 18,75 5,40 123456790 dubois@tele.com 03/03/2011 21,55 0,00 ARTICLE_AJOUTÉ Numero_Commande Numero_Article Prix_Unitaire Quantité 123456789 A9876 18,75 1 123456790 A9876 18,75 1 123456790 B8765 1,40 2 Troisième composant de l écosystème : les règles de gestion Dans l exemple imaginé ci-dessus on pourrait avoir les règles suivantes : la valeur d un «Article_ajouté» est le produit du prix unitaire de cet article par la quantité ajoutée au panier, arrondi au cent supérieur, ce qui se traduit mathématiquement par : valeurarticleajouté = (((Prix_Unitaire * 100) * Quantité) + 0,5) / 100 l'attribut «Total_Articles» du panier doit être égal à la somme des valeurs des articles ajoutés à ce panier ; si le total des articles est supérieur ou égal à 20,00, la livraison est gratuite. Page 34

Ces règles peuvent elles aussi être modélisées, sous forme de diagrammes d activité. La figure 41 montre le diagramme d activité correspondant à l ajout d un article au panier : L intérêt de la modélisation des règles est de pouvoir facilement analyser l impact de toutes les modifications sur les différents modules de traitement. Si la règle commerciale qui définit les critères donnant lieu à une livraison gratuite est modifiée, la modélisation permettra de retrouver facilement les modules de traitement impactés. On remarquera que le résultat de la règle «si le total des articles est supérieur ou égal à 20,00, la livraison est gratuite» n est pas enregistré dans la base de données et n est donc pas une «règle donnée» mais est une «règle traitement». En conséquence, dans le cadre de la qualité des données, il n est pas possible de vérifier que la règle a bien été appliquée ou non. Quatrième composant de l écosystème : l accès aux données De la même façon qu il est possible de modéliser les processus de traitement, il est très utile de modéliser les accès aux structures de données effectués par ces modules de traitement, comme l illustre la figure 42 : Cette modélisation permettra cette fois de réaliser des analyses d impact très rapides et très précises lorsque l on souhaite modifier les structures de stockage des données. Page 35

Par ailleurs, même si les structures définies pour stocker les données sont relativement figées, les différents utilisateurs de ces données doivent pouvoir les appréhender suivant leur logique propre qui peut parfois être très éloignée de celle de la base de données. Plusieurs «métier» partagent ce patrimoine et doivent pouvoir le consulter et l enrichir suivant des chemins d accès très différents. À nouveau, la modélisation sous forme de vue «métier» permettra de générer automatiquement des modules d accès adéquats pour chaque situation. Deux vues très différentes suivant le «métier» qu elles desservent et qui pourtant partagent certainement une même structure de base de données : le type d entité «Article». Page 36

ANNEXE 3 : BIBLIOGRAPHIE 2011 Zhenjiang Hu, Andy Schürr, Perdita Stevens, and James Terwilliger (Ed.). Bidirectional Transformations bx, Report from Dagstuhl Seminar 11031, Schloss Dagstuhl Leibniz-Zentrum für Informatik, Dagstuhl Publishing, Germany, pp. 42-67 2011. Anthony Cleve, Jean-Luc Hainaut. Inter-artefact Analysis for Information System Understanding, DB- MAIN Technical report, January 2011, 14 pages. Carlos Parra, Xavier Blanc, Anthony Cleve, Laurence Duchien. Unifying Design and Runtime Software Adaptation Using Aspect Models, Science of Computer Programming, to appear. 2010 Anthony Cleve, Anne-France Brogneaux, Jean-Luc Hainaut. A Conceptual Approach to Database Applications Evolution, in Proceedings of the 29th International Conference on Conceptual Modeling (ER'2010), Lecture Notes in Computer Science No 6412, pages 132-145, Springer-Verlag, 2010. Carlos Parra, Anthony Cleve, Xavier Blanc, Laurence Duchien. Feature-based Composition of Software Architectures, in Proceedings of the 4th European Conference on Software Architecture (ECSA 2010), Lecture Notes in Computer Science, Springer-Verlag, 2010. Jonathan Lemaitre. Evaluation and Improvement of Database Schemas: A transformation-based framework, in Proceedings of the 22th International Conference on Advanced Information Systems Engineering - Doctoral Symposium, (CAiSE 10), Lecture Notes in Computer Science, Springer-Verlag, 2010. 2009 Jean-Luc Hainaut, Transformational Database Engineering, Short tutorial, Actes des 25e journées Bases de Données Avancées (BDA'08), 2008 Jean-Luc Hainaut. Network Data Model, in Encyclopedia of Database Systems, Liu, L. and Özsu, T. (Eds), Springer-Verlag, 2009. Jean-Luc Hainaut. Hierarchical Data Model, in Encyclopedia of Database Systems, Liu, L. and Özsu, T. (Eds), Springer-Verlag, 2009. Jean-Luc Hainaut, Jean Henrard, Vincent Englebert, Didier Roland, Jean-Marc Hick. Database Reverse Engineering, in Encyclopedia of Database Systems, Liu, L. and Özsu, T. (Eds), Springer-Verlag, 2009. Jean-Luc Hainaut. Legacy and Future of Database Reverse Engineering, Keynote, Proceedings of the 16th Working Conference on Reverse Engineering, (WCRE'09), IEEE Computer Society, 2009. 2008 Jean-Luc Hainaut, Anthony Cleve, Jean Henrard and Jean-Marc Hick. Migration of Legacy Information Systems, in Software Evolution. Mens, T. and Demeyer, S. (Eds), Springer, pp. 107-138, 2008. Jean-Luc Hainaut, Jean-Marc Hick, Didier Roland, Jean Henrard and Vincent Englebert. Database Reverse Engineering, in Encyclopedia of Database Technologies and Applications (2d Ed.), IDEA Group, 2008. Page 37

Anthony Cleve, Jean Henrard, Didier Roland and Jean-Luc Hainaut. Wrapper-based System Evolution - Application to CODASYL to Relational Migration, in Proceedings of the 12th European Conference on Software Maintenance and Reengineering (CSMR 08), pages 13-22, IEEE Computer Society, 2008. Anthony Cleve, Jonathan Lemaitre, Jean-Luc Hainaut, Mouchet, Jean Henrard. The Role of Implicit Schema Constructs in Data Quality, Proceedings of the Workshop on Quality in Databases, QDB'08, VLDB, September 2008. Jean Henrard, Didier Roland, Anthony Cleve, Jean-Luc Hainaut. Large-scale Data Reengineering: Return from Experience, Proceedings of the 15th Working Conference on Reverse Engineering, (WCRE'08), Industrial track, IEEE Computer Society, 2008. Anthony Cleve, Jean-Luc Hainaut. Dynamic Analysis of SQL Statements for Data-Intensive Applications Reverse Engineering, Proceedings of the 15th Working Conference on Reverse Engineering, (WCRE'08), IEEE Computer Society, 2008. Jonathan Lemaitre, Jean-Luc Hainaut. A Combined Global-Analytical Quality Framework for Data Models, Proceedings of the Workshop on Quality in Models, (QiM'08), MODELS conference, 2008. Voir également http://info.fundp.ac.be/~dbm/mediawiki/index.php/libd:publications Page 38