Développement d'applications et intégration de bases de données hétérogènes : une approche méthodologique

TEXTES DES COMMUNICATIONS - Tome I Développement d'applications et intégration de bases de données hétérogènes : une approche méthodologique Gabriella SALZANO Gabriella.Salzano@univ-mlv.fr Université de Marne-la-Vallée, 5, Boulevard Descartes, Champs-sur-Marne, 77454 Marne-la-Vallée Cedex 2. Mots clés : Méthodologie, Développement de logiciel, Modernisation, Intégration, Hétérogénéité, Bases de données. Keywords : Methodology, Software Development, Modernization, Integration, Heterogeneity, Databases. Palabras claves : Metodología, Desarrollo de software, Modernización, Integratión, Heterogeneidad, Base de datos. Sommaire Un des défis majeurs pour les systèmes d'information est la coopération entre applications : d'une part, on souhaite utiliser le capital d'information présent dans les applications existantes et d'autre part les bases de données propriétaires, construites pour répondre à des besoins spécifiques, ne peuvent pas être utilisées telles quelles, car elles présentent une très forte hétérogénéité. Cet article présente une approche méthodologique dont les étapes prennent en compte aussi bien les besoins de modernisation que d'intégration. Cette approche est comparée explicitement par rapport à d'autres et ses caractéristiques sont détaillées. Un exemple illustre comment les problèmes d'intégration entre applications peuvent être étudiés et résolus très en amont dans le cycle de développement des systèmes logiciels. 1 Introduction Les besoins actuels d'information nécessitent un contexte coopératif de différentes applications, impliquant l'échange et le partage des informations, mais aussi, parfois, des nouvelles formes d'organisation. Tous les domaines d'applications (production, administration, finance, commerce, santé) sont touchés par ces défis informationnels et organisationnels, relevant du travail coopératif et du "pilotage", dans des systèmes d'information dits étendus. Le développement du Web, lui-même assimilable à une énorme base de données, extrêmement hétérogène et distribuée, accélère inévitablement ce mouvement. Plus généralement, la maturité atteinte par de nombreuses technologies (les nouvelles technologies de l'information et de la communication), comme les bases de données, les réseaux, les technologies objets, et dans les méthodologies, poussent les utilisateurs à exprimer des nouveaux besoins informationnels, concernant aussi bien la technique que l'organisation et le domaine de la décision. Ces besoins sont plus complexes qu'autrefois, mais réalistes : on pourra par exemple prendre en compte l'évolutivité des sources, réaliser la traçabilité des actions et évaluer les impacts de la coopération. Les systèmes jugés satisfaisants il y a quelques années, s'appuyant sur des bases de données dites "propriétaires", sont perçus maintenant comme incontournables, pour le capital d'information qu'ils contiennent, mais répondant seulement à des besoins d'information limités aux domaines pour lesquels ils ont été conçus et développés. Les bases de données propriétaires, tout en continuant à évoluer, aussi bien sur le contenu que sur la forme, ne peuvent pas être utilisées, dans l'état actuel, pour bâtir des systèmes coopératifs ou décisionnels, compte tenu de leur grande hétérogénéité. Un problème se pose donc : moderniser les systèmes actuels et leur permettre de s'intégrer avec d'autres applications dans un contexte coopératif. IRIT - DELTA VEILLE 97

VSST'2001 La solution à ce problème requiert une approche méthodologique, car les problèmes d'intégration sont très difficiles à traiter a posteriori. Or nous avons constaté que d'une part les méthodes de modernisation (ou de développement) d'applications ([2], [4], [6]) n'évoquent pas de façon explicite les problèmes d'intégration de bases de données hétérogènes, et que d'autre part les approches d'intégration de bases de données hétérogènes ([1], [7], [9]) ne se situent pas explicitement dans le cycle de vie du développement logiciel. Dans cet article nous présentons une approche méthodologique qui définit explicitement les différentes étapes à effectuer pour moderniser des systèmes d'information et résoudre les problèmes d'intégration. Nous définissons cette approche par le sigle M&I (Modernisation & Intégration). Afin de positionner M&I par rapport à une méthode récente de conception de systèmes d'information, nous présentons rapidement les principes du processus unifié de développement logiciel [6], (désigné par PUDL dans la suite), ainsi que l'approche d'intégration de bases de données hétérogènes. Ensuite nous développerons les caractéristiques propres de M&I, à savoir : le pilotage par les cas d'utilisation et l'intégration, l'architecture basée sur des composantes de référence, destinées à résoudre les problèmes d'hétérogénéité, l'itérativité et enfin les différents types de documentation produite. Un exemple illustrera les apports de cette méthodologie lors de la spécification d'une application devant intégrer plusieurs bases de données hétérogènes. 2 Approches méthodologiques En vue de présenter l'approche méthodologique M&I, nous synthétisons les principes du processus unifié de développement de systèmes logiciels (PUDL) [6], ainsi que du processus d'intégration de bases de données hétérogènes ([7], [9]). 2.1 Processus unifié de développement de systèmes logiciels Le cycle de développement d'un système à forte composante logicielle comprend les phases de Création, Élaboration, Construction et Transition. Chaque phase réalise un ensemble d'activités, et il est à noter qu'une activité peut se dérouler pendant plusieurs phases. Les activités macroscopiques identifiées classiquement sont : Recueil des besoins, Analyse, Conception, Implémentation, Tests (fig. 1). Fig. 1 Enchaînement des phases et des activités (à partir de [6]). 98

TEXTES DES COMMUNICATIONS - Tome I On résume ici très schématiquement le contenu des différentes phases et activités. Les phases de Création et d'élaboration sont les plus riches et innovantes du point de vue conceptuel: dans la Création, le produit est "imaginé" dans ces grandes lignes, les principes des cas d'utilisation sont tracés, une étude de rentabilité est effectuée, les coûts relatifs au projet sont estimés et une ébauche d'architecture est esquissée. L'Élaboration précise tous ces éléments : en particulier on élabore en détail les différents modèles du système. Les phases de Construction et Transition amènent respectivement à la production du système et à sa livraison aux utilisateurs. Concernant les activités, le Recueil des besoins identifie les besoins et les exprime sous forme compréhensible par les utilisateurs, en terme de cas d'utilisation et types d'acteurs. L'Analyse produit des modèles conceptuels d'analyse, basés sur des classificateurs et sur leurs collaborations, pour réaliser les cas d'utilisation. La Conception produit des modèles plus proches du physique, en détaillant précisément les modèles d'analyse et en spécifiant les éléments, comme les composantes ou les bases de données. Ces éléments seront réalisés dans la phase d'implémentation. Enfin la phase de Test procède à l'intégration du système développé avec les systèmes existants et effectue les tests sur les différentes parties. Les phases et les activités que nous analysons plus en détail dans cet article sont celles dites généralement "amont", à savoir la Création et l'élaboration, dans lesquelles sont réalisées presque en totalité les activités de Recueil des besoins et d'analyse, avec une vaste partie de Conception, et sont aussi fixés les principes de l'implémentation (fig. 1). Les problèmes posés par l'hétérogénéité des bases de données associées aux systèmes existants ne sont pas identifiés explicitement dans le processus PUDL. En vue de prendre en compte ces problèmes dans M&I, et d'indiquer une approche pour les résoudre, nous rappelons synthétiquement le processus d'intégration. 2.2 Intégration de bases de données hétérogènes Les différentes phases du processus d'intégration des bases de données hétérogènes, sont ([7], [9]): Pre-intégration, Recherche de correspondances, Mise en conformité des schémas, Fusion et Restructuration. Nous résumons ici les principales activités menées lors de ces phases. La Pre-intégration commence par définir les langages et outils de modélisation, qui vont être utilisés dans la modélisation des contextes des différentes bases de données locales. Cette phase recommande également l'utilisation d'ontologies, de standards ou, en général, de formalismes qui devront être satisfaits par la solution intégrée. Elle définit aussi les objectifs de l'intégration (simplicité, complétude, exhaustivité), la stratégie d'intégration des différentes bases (priorités, ) et la typologie de la solution (multidatabase, fédération, datawarehouse, ). Concernant cette typologie, on peut distinguer au moins deux grandes familles de solutions d'intégration, selon que la solution est basée sur des vues (multidatabase avec schéma global, sans schéma global, fédération) ou sur des bases de données matérialisées (bases de données distribuées, datawarehouses, bases de données interopérables) (fig. 2). Trois facteurs, parfois liés au domaine d'application, ont une influence sur le choix du type d'intégration : la distribution, l'autonomie (de conception, d'exécution, de contrôle), et le degré d'hétérogénéité [1]. Ceux-ci déterminent la nature des composantes d'intégration et les modalités d'interaction entre celles-ci et les composantes locales. La Recherche des correspondances compare les schémas des bases de données existantes, en cherchant des portions de schémas qui soient intéressantes pour l'application cible. Ces portions de schémas peuvent être identiques dans les différentes bases, similaires ou bien concerner des concepts différents mais pouvant être rapprochées dans un but applicatif ([9], [12]). La Mise en conformité des schémas traite les conflits induits par les correspondances, en suivant les objectifs fixés dans la phase de Pré-intégration. Ces conflits peuvent être de différents types, liés à la définition des entités, des structures, des domaines de valeurs. Ils peuvent aussi porter sur des contraintes : en effet, des contraintes existantes au niveau local peuvent générer implicitement des contraintes au niveau de la solution intégrée. La résolution des conflits est une étape très délicate de l'intégration : la proposition de solutions conformes aux objectifs requiert parfois l'intervention d'experts des différents domaines. Enfin, la Fusion des schémas et la Restructuration produisent les schémas des solutions intégrées, et indiquent comment accéder aux données intégrées et les manipuler. IRIT - DELTA VEILLE 99

VSST'2001 vues couplage fort Multidatabase avec schéma global Multidatabase sans schéma global Fédération couplag e Bases de données distribuées Datawarehouse bases de données matérialisées Bases de données interopérables Fig. 2 : Typologie d'intégration de bases de données hétérogènes. 2.3 Définition et Positionnement de M&I Dans [10] et [11] nous avons présenté une architecture d'intégration s'appuyant sur des composants de référence ([5]), dont l'objectif est de résoudre les problèmes d'hétérogénéité et de satisfaire les contraintes induites par l'intégration. Nous y avons également souligné les apports des ontologies ([13]) pour résoudre de façon rigoureuse les conflits, surtout s'ils sont sémantiques et liés aux contraintes. Dans cet article nous définissons globalement les phases et activités de M&I, en précisant celles plus concernées par l'intégration. Notre présentation est axée sur des besoins d'intégration de bases de données hétérogènes, mais elle peut être généralisée à un contexte plus général, d'intégration de systèmes, en considérant aussi, en plus des bases de données, d'autres aspects des systèmes, au niveau logique, organisationnel et physique. Le principe conducteur de M&I consiste dans le fait de poser explicitement les problèmes d'intégration très en amont du cycle de développement, et de trouver les solutions à ces problèmes de façon rigoureuse, en suivant une approche éprouvée. Nous commençons donc par expliciter quelles sont les phases du processus de développement des systèmes logiciels dans lesquelles il faut prendre en compte la démarche d'intégration des bases de données hétérogènes. Nous soulignons que les deux approches (processus PUDL et d'intégration) doivent être menées simultanément, en particulier dans les phases de Création et Élaboration, fondamentales pour le développement des systèmes que nous analysons, et, à l'intérieur de ces phases, dans les activités de Recueil des besoins, Analyse et Conception, qui y sont prépondérantes (fig. 1). Compte tenu des phases et des activités du processus d'intégration, nous remarquons en effet que l'intégration se prépare et se construit essentiellement pendant ces trois phases, tout en influençant fortement les phases en aval. Pour le nouveau processus de développement, M&I, on peut préciser les phases et les actions à réaliser. M&I est caractérisé par les phases de Création, Élaboration, Construction et Transition, et, dans chaque phase, par des activités de Recueil des besoins, Analyse, Conception, Implémentation, Tests. Les activités de chaque phase seront obtenues à partir de celles définies pour PUDL, enrichies par un sous-ensemble opportun des activités propres à l'intégration (fig. 3). Nous remarquons aussi que, à chaque phase, les différents aspects de l'intégration sont traités, avec des mailles d'étude (granularités) différentes. En particulier, en phase de Création, la Pré-intégration et la Recherche des correspondances sont largement traitées et on aborde seulement la Résolution de conflits et la Fusion, qui seront amplement traitées dans la phase d'élaboration. 100

TEXTES DES COMMUNICATIONS - Tome I M&I = PULD + Intégration I 1 I 2 I 3 I 4 a c t i v i t é s Recueil des besoins Analyse Conception Recueil des besoins Analyse Conception I 1 I 2 I 3 I 4 Création Élaboratio n phases Fig. 3 : Phases et activités de M&I. Dans certains cas, notamment si l'intégration est très faible, les phases d'intégration seront parcourues rapidement. Si l'intégration est possible, la Pré-intégration spécifiera les objectifs des composantes de référence, les principes de l'architecture, les standards de modélisation à suivre, les standards de documentation ainsi que les outils de modélisation. Nous soulignons enfin que M&I n'est pas simplement une liaison de deux approches (PUDL et Intégration), car les phases des deux processus se retrouvent modifiées, dans leurs objectifs et dans la façon de les conduire : par exemple, les tests d'intégration seront anticipés dans M&I par rapport à PUDL. Nous allons maintenant détailler des caractéristiques de M&I par rapport aux approches PUDL et d'intégration. 3 Caractéristiques de l'approche M&I 3.1 Pilotage par les cas d'utilisation et l'intégration L'architecture d'un système logiciel ([6]) s'intéresse aux éléments structurants du système (comme les sous-systèmes, les classes, les composantes, les nœuds), aux compositions de ces éléments et à leurs interactions au travers d'interfaces. L'architecture logicielle est décrite d'abord au niveau conceptuel, ensuite au niveau logique et enfin au niveau physique, par un ensemble de vues issues de différents modèles (cas d'utilisation, analyse, conception, implémentation et déploiement). 1 cas d'utilisation 2 architecture cas d'utilisation 1 3 architecture type d'intégration 2 PUDL M&I Fig. 4 : Pilotage par les cas d'utilisation (PUDL) et par les cas d'utilisation et par l'intégration (M&I). Comme illustré dans la fig. 4, dans PUDL, les cas d'utilisation pilotent la spécification de l'architecture, et à son tour, celle ci influence la réalisation des cas d'utilisation. IRIT - DELTA VEILLE 101

VSST'2001 Dans M&I, les cas d'utilisation représentent les aspects fonctionnels que le système doit satisfaire ; ils pilotent une ébauche d'architecture pour le système. Le choix de l'architecture d'intégration est proposé aussi dans les activités de Pré-intégration, en phase de Création. Celles-ci seront menées très en amont et constituent donc une contrainte forte pour la détermination de l'architecture du système. Une fois celle-ci dessinée dans ses grandes lignes, elle sera affinée et validée dans les phases suivantes (Analyse, Développement, Tests), toujours en référence aux cas d'utilisation. 3.2 Architecture basée sur l'utilisation de composantes d'intégration L'approche M&I permet de déterminer différents types d'architecture, caractérisées par l'existence de composantes d'intégration. Celles-ci facilitent l'utilisation de standards de différents domaines, permettent le partage des données, avec contrôle décentralisé ou centralisé aux données partagées, et peuvent concerner aussi d'autres aspects, comme les présentations externes liées aux cas d'utilisation. L'étendue et la structuration de ces composantes de référence, destinées à résoudre les problèmes d'hétérogénéité, dépendent d'un ensemble de critères. Pour illustrer la complexité et la variété des critères à prendre en compte, nous allons en classer certains, selon différents niveaux : niveau décisionnel : - la politique d'évolution du /des système(s) d'information de l'entreprise, en termes de définition du niveaux d'intégration et de traçabilité souhaités, de degré d'autonomie (de conception, de contrôle, d'exécution) entre les systèmes existants et le système cible, - l'ouverture (à court et moyen terme) vers l'exploitation des nouvelles technologies (Internet, SGBD, ) - les besoins en terme de coûts et délais niveau conceptuel et logique : - la prise en compte de standards et classifications - le nombre de types d'organisations, de domaines, d'activités, de types d'acteurs, dont il faut couvrir les besoins - le nombre de bases à intégrer, leurs volumes - la fiabilité et la représentativité des différentes bases locales par rapport aux nouveaux objectifs - la diversité des types de données (numérique, texte, son, image, multimédia, non structuré, ) gérés par les différents systèmes locaux niveau organisationnel : - le degré de connaissance sur les différentes applications, la documentation existante, l'expertise que l'on peut solliciter, - la formation des différents acteurs - la gestion simultanée des applications existantes et des évolutions Ainsi, des types d'architecture sont illustrés dans la figure 5. Les composantes de référence déterminées dans chaque type d'architecture sont respectivement : - des vues constituant un schéma global dans un système de type multidatabase (a) ; - des vues constituant des portions de schémas dans un système de type fédération (b) ; - des bases de données réalisant des intégrations partielles entre systèmes (avec duplication de données), avec contrôle centralisé des accès ( c ) et sans contrôle centralisé des accès (d). Ces composantes d'intégration permettent aux systèmes locaux, S 1, S 2 et S 3, d'évoluer : pour la lisibilité de la figure, les nouvelles configurations de ces systèmes (les systèmes modernisés) sont marquées en pointillé seulement pour S 1. Le type d'architecture (a) conviendra par exemple dans les cas de forte intégration et très faible autonomie, tandis que dans les cas d'intégration sur quelques portions des schémas, avec archivage et contrôles partiels des transactions sur ces données, on optera pour des solutions de type (d). Grâce à l'utilisation des composantes, les phases du développement du système ne voient pas celui-ci de façon monolithique : à partir des cas d'utilisation et de l'intégration choisie, on mènera les différentes phases en partie système par système et en partie sur les composantes de référence, qui représentent les parties intégrées. 102

TEXTES DES COMMUNICATIONS - Tome I Nous remarquons aussi que la valeur ajoutée, apportée par l'intégration des systèmes, doit être mesurée : pour cela, au sein de ces composantes, il faudra spécifier et mettre en place des indicateurs permettant de mesurer la réelle coopération des systèmes par rapport aux objectifs d'intégration. Schéma global S 1 S 3 S 2 S 1 S 2 S 3 a) Multidatabase b) Fédération S S 2 S 3 S 3 1 S 2 S 1 c) Interopérabilité centralisée d) Interopérabilité décentralisée Fig. 5 : Exemples d'architectures d'intégration. 3.3 Documentation Une bonne documentation assure que le système pourra être utilisé et maintenu. La documentation produite par le processus M&I comprend deux familles de documents : 1. ceux qui décrivent le système logiciel en termes d'objectifs, utilisations, architecture, conception détaillée et outils de développement. Ces documents accompagnent le déroulement de chaque phase et de chaque activité. PUDL en prévoit un certain nombre (les artefacts), comme les diagrammes UML, les commentaires, les descriptions des composantes, des interfaces utilisateurs, des plans de tests, des réalisations de tests, ([3], [6]). On inclura dans cette famille tous les documents traçant les différentes phases et activités relevant de l'intégration, comme par exemple les choix de pré-intégration, la détection et la caractérisation des correspondances parmi les différentes bases de données, les choix liés à la résolution des conflits, la fusion des modèles en correspondance. 2. ceux qui constituent des documents générés par le système logiciel produit par M&I (par exemple des documents liés aux diverses activités du domaine d'application et apparaissant en entrée ou en sortie). Cette deuxième famille de documents sera le plus possible structurée comme un ensemble de "patterns", qui seront ensuite spécifiés au cas par cas. Pour ces documents, il est important de prévoir l'utilisation de standards de documentation garantissant la pérennité des productions. Une certaine souplesse dans ces patterns peut être introduite grâce aux formats semi structurés [8]. Ces formats permettent la définition de structures de données partielles, incomplètes, hétérogènes ou parfois inconsistantes, répondant ainsi à des besoins de gestion et manipulation de données issues du Web. Compte tenu de la particularité des systèmes visés par M&I, nous incluons dans cette famille de documents aussi ceux qui correspondent à l'activité d'évaluation de la qualité du système logiciel produit, par rapports aux objectifs de la coopération (il s'agira en particulier du cahier des charges de l'évaluation, avec spécification des indicateurs, des sources et des modalités d'évaluation). IRIT - DELTA VEILLE 103

VSST'2001 3.4 Processus incrémental Le processus M&I peut être utilisé de façon itérative pour intégrer des nouvelles bases de données, voire (après généralisation) des nouveaux systèmes, à chaque fois que des besoins d'extension se présentent. Chaque itération tirera profit des documents établis à l'itération précédente, dont certains pourront être exploités de façon automatique. Dans ce sens, le processus est incrémental. Comme illustré dans la figure 6, à une itération n de M&I, à partir des systèmes S 1, S 2, S n, on a créé un système nouveau, coopératif, CS 1. Si l'évaluation de CS 1 est positive, et si on recense des besoins de coopération de CS 1 avec d'autres systèmes S n+1, S n+2, S n+k, le même processus M&I sera réappliqué. Lors de cette nouvelle itération, la phase d'analyse sera plus rapide, car on s'appuiera sur tous les artefacts produits pour CS 1 et sur l'évaluation de son fonctionnement. itération n S 1 S 2 S 3 M&I CS 1 avec documentation itération n+1 S 4 CS 1 M&I CS 2 avec documentation avec documentation Fig. 6 : Itérativité du processus M&I. 4 Un exemple Nous présentons ici un exemple pour illustrer les contributions de l'intégration dans la phase de Création de M&I. La figure 7 illustre trois applications, chacune s'appuyant sur une base de données : - la base Travaux Publics, avec des informations concernant des bâtiments et des rues ; - la base Environnement, avec des informations concernant l étude des matériaux et des forêts ; - La base Transport, avec des informations concernant les routes et les trains. ENVIRONNEMENT TRAVAUX PUBLICS TRANSPORTS Matériaux Trains Forêts Routes Bâtim ent_m atériaux Bâtim ents Rues Fig. 7 : Informations "vues" différemment dans différents domaines. D'une part, les informations concernant les routes sont vues différemment par les bases Travaux Publics et Transport, d autre part, les Matériaux sont étudiés en détail dans la base Environnement, et seulement mentionnés dans la base Travaux Publics. La figure 8 résume les relations et contraintes des trois bases. Chaque application existante est sous le contrôle d'organismes différents. Ceux-ci nécessitent la mise en cohérence et le partage des informations. Ainsi, la phase de Création pour un nouveau système va recueillir les besoins décisionnels des différents organismes. En particulier, l'organisme chargé des Travaux Publics souhaite utiliser les informations relatives à la nocivité des matériaux utilisés dans les bâtiments et celles concernant l'état des routes. Base TRAVAUX PUBLICS 104

TEXTES DES COMMUNICATIONS - Tome I R 1 =BATIMENTS_MATERIAUX (N bâtiment, Nom_matériel, Quantité) R 2 =BATIMENTS ( N bâtiment, Type_bâtiment) R 3 =RUES ( N rue, Type_rue, Année) Contraintes: (N bâtiment, Nom_matériel ) Quantité; N bâtiment Type_bâtiment; N rue Type_rue, Année Type_rue in [1,200] Π N bâtiment (BATIMENTS_MATERIAUX ) Π N bâtiment (BATIMENTS) Base ENVIRONNEMENT S 1 =MATERIAUX ( N matériel, Libellé_matériel, Nocivité) S 2 =FORETS ( N parc, Nom_parc) Contraintes: Libellé_matériel N matériel; N matériel Libellé_matériel, Nocivité; Nocivité in [1,5 ] Base TRANSPORT T 1 =ROUTE ( N route, Type_route, Nb_voies, État) T 2 =TRAINS ( N train, Train_type) Contraintes: Type_route in [1,50] N route Type_route, Nb_voies, État Fig. 8 : Relations et contraintes des bases propriétaires. Compte tenu des objectifs de la coopération et du degré d'autonomie souhaité par les trois organismes, l'architecture choisie en Pré-intégration est la fédération. Les correspondances détectées sont : Nom_matériel Libellé_matériel entre R 1 et S 1, N rue N route et Type_rue Type_route entre R 3 et T 1 Après avoir déroulé la suite du processus d'intégration pendant la phase de Création, les résultats de la fédération, vus par le système gérant les Travaux Publics, sont illustrés par la figure 9. R 3 R 1 ER Nom_matériel 1 Nocivité Type_rue Type_route R 2 Type_route ER 3 Largeur N rue Nb_voies ER 2 Fig. 9 : Construction de la base étendue TRAVAUX PUBLICS. Les nouveaux schémas définis pour l'extension de la base sont résumés dans la figure 10. Nous remarquons que la contrainte Type_rue in [1,50] limite le contexte de validité de la fédération. ER 1 =MATERIAUX_NOCIVITE (Nom_matériel, Nocivité) ER 2 =CARACTERISTIQUES_RUES(N rue, Type_route, Nb_voies, État) ER 3 =RUES_ROUTES (Type_rue, Type_route) avec les contraintes : Nom_matériel Nocivité N rue Type_route, Nb_voies, État Type_rue Type_route Type_route Type_rue ; Type_rue in [1,50] Fig. 10 : Schémas définis pour l'extension de la base Travaux Publics. IRIT - DELTA VEILLE 105

VSST'2001 Ces réflexions sur l'intégration alimentent donc l'élaboration, qui est la phase suivante dans le développement du système. 5 Conclusions Dans cet article, nous avons introduit les principes généraux du processus M&I pour moderniser des systèmes logiciels, auxquels sont associées des bases de données hétérogènes, dans l'objectif de permettre l'évolution de ces systèmes dans un contexte intégré et coopératif. Nous allons poursuivre cette recherche avec trois objectifs successifs : approfondir l'analyse des besoins d'intégration et de coopération sur des domaines d'activité spécifiques ; identifier des classes de problèmes pour lesquels préconiser des choix d'architecture et des types de composantes d'intégration les plus adaptées ; préciser, pour ces classes de problèmes, le contenu des phases et activités de M&I. Bibliographie [1.] CONRAD S. et SAAKE G., Integrating heterogeneous Databases, EDBT'98, Valencia, March 23, 1998. [2.] CORNELLA-DORDA S., WALLNAU K., SEACORD R.C. et ROBERT J., A survey of Legacy Modernization Approaches, CMU/SEI-2000-TN-003. [3.] ERIKSSON H.E. et PENKER M., UML Toolkit, Wiley Computer Publishing, 1998 [4.] GABAY J. et BERHANOU GEBRE, La conduite des projets d'évolution des systèmes d'information, InterEditions, 1999, Dunod Paris 1999, ISBN 2 10 004862 7. [5.] HAINES G., CARNEY D. et FOREMAN J., Component Based Software development / COTS Integration, SEI, Software Technology Review, 1998. [6.] JACOBSON I., BOOCH G. et RUMBAUGH J., Le Processus Unifié de développement logiciel, Eyrolles, 2000. [7.] JARKE M., LENZERINI M., VASSILIOU Y., VASSILIADIS P., Fundamentals of Data Warehouses, Springer, ISBN 3-540-65365-1, 2000. [8.] MENCGCHI L. et TOK WANG L., A data model for Semistructured Data with Partial and Inconsistent Information, Zaniolo et al. (eds.): EDBT 2000, LNCS 1777, pp. 317-331, Springer- Verlag, 2000. [9.] PARENT C. et SPACCAPIETRA S., Intégration de bases de données: panorama des problèmes et des approches, Ingénierie des Systèmes d'information, Vol. 4, n. 3, p. 333-358, 1996. [10.] SALZANO G., Building integrated components for heterogeneous, distributed systems, such as telemedicine applications, HEALTHCOM 2001, 3 rd International Workshop on Enterprise Networking and Computing in Health Care Industry, June 29 th July 1 st, 2001 - L Aquila, Italy. [11.] SALZANO G., Integration Methodology for Heterogeneous Databases in Heterogeneous Information Exchange and Organisational Hubs, Kluwer (to appear in 2001). [12.] SALZANO G. et BESTOUGEFF H., Finding Related Information in Distributed Heterogeneous Systems, in Proceedings of 16th International CODATA Conference Data Management in the Evolving Information Society, New Delhi, November 1998. [13.] WIEDERHOLD G. et JANNINK J., Composing Diverse Ontologies, prepared for IFIP Working Group on Database 8 th Working Conference on Database Semantics (DS-8), in Rotorua, New Zeland, Jan. 1999. 106