Modélisation XML

-

Livres
528 pages
Lire un extrait
Obtenez un accès à la bibliothèque pour le consulter en ligne
En savoir plus

Description

Modèles de données - Flexibilité du SI - Correspondance UML/XML - Entité & association - Stockage en base - Optimisation des schémas


Les architectes et développeurs logiciels qui ont en charge la conception de systèmes d'information doivent souvent recevoir et traiter d'importants volumes de données XML. Ce livre leur explique comment adapter en profondeur leurs méthodes traditionnelles de conception aux spécificités de la modélisation XML.




  • Avant-propos


  • Introduction générale


  • Etapes de la démarche de modélisation


  • Modèles de référence


  • Annexe A : représentation UML avancée pour XML Schema


  • Annexe B : ressources


  • Annexe C : sigles et acronymes


  • Annexe D : Infoset


  • Glossaire


  • Index

Sujets

Informations

Publié par
Date de parution 07 juillet 2011
Nombre de visites sur la page 236
EAN13 9782212850291
Langue Français

Informations légales : prix de location à la page 0,0225 €. Cette information est donnée uniquement à titre indicatif conformément à la législation en vigueur.

Signaler un problème
A n t o i n en j o nL o e a n  J a c q u e sJ a s s o nT h o m O u v r a g e d i r i g é p a r L i b e r oM a e s a n o Modélisation XML
a r c h i t e c t el o g i c i e l
Modélisation XML
A n t o i n eL o n j o nJ e a n  J a c q u e sT h o m a s s o n O u v r a g e d i r i g é p a r L i b e r oM a e s a n o
Modélisation XML
ÉDITIONS EYROLLES 61, bd Saint-Germain 75240 Paris Cedex 05 www.editions-eyrolles.com
er Le code de la propriété intellectuelle du 1 juillet 1992 interdit en effet expressément la photocopie à usage collectif sans autorisation des ayants droit. Or, cette pratique s’est généralisée notamment dans les établissements d’enseignement, provoquant une baisse brutale des achats de livres, au point que la possibilité même pour les auteurs de créer des œuvres nouvelles et de les faire éditer correctement est aujourd’hui menacée. En application de la loi du 11 mars 1957, il est interdit de reproduire intégralement ou partiellement le présent ouvrage, sur quelque support que ce soit, sans autorisation de l’éditeur ou du Centre Français d’Exploitation du Droit de Copie, 20, rue des Grands-Augustins, 75006 Paris. © Groupe Eyrolles, 2006, ISBN : 2-212-11521-0
Préface
En 2000 a circulé sur Internet une histoire qui s’est révélée par la suite une imbrication inextricable d’informations vraies et de légendes. Elle peut être résumée comme suit.
L’écartement standard entre les rails aux États-Unis est de 4 pieds et 8,5 pouces, ce qui est une mesure particulièrement biscornue. Pourquoi cette mesure ? Parce que les premières lignes de chemin de fer ont été bâties principalement par des expatriés anglais et sûrement avec de la technologie et des outils anglais, les Anglais étant à l’époque à la pointe de la technologie. Pourquoi les Anglais ont-ils exporté cette mesure ridicule ? Parce que les premiers chemins de fer ont été construits par les hommes et avec les outils des fabricants de tramways sur route, et donc la distance entre les roues de ces tramways est devenue l’entre-rails. Et pourquoi cette distance entre les roues des tramways ? Parce que chaque fois qu’une autre distance avait été mise en œuvre dans le passé, le tramway, ou tout autre véhicule, s’était « cassé la figure » à cause de profonds sillons, sortes de rails, creusés à cette distance et présents sur toutes les routes d’Angleterre et d’Europe. Pourquoi des ornières avec cette dis-tance entre elles ? Parce que ces routes avaient été d’abord bâties pour faciliter les déplacements des légions de l’empire romain, et les chariots de guerre romains, leurs principaux usagers, exhibaient une telle distance entre les roues.
À partir d’ici, l’histoire se perd un peu, et on évoque les dimensions des postérieurs des chevaux pour expliquer la distance entre les roues des chariots de guerre. Quoi qu’il en soit, c’est à partir d’une spécification des ingénieurs de l’armement de Rome que, au troisième millénaire et aux États-Unis, la voie standard des chemins de fer est spécifiée. L’histoire ensuite prend un tournant particulièrement technologique, avec les dimensions dessolid rocket boostersde la navette spatiale, qui seraient définies ainsi
VI
Modélisation XML
parce que les SRB doivent être transportés par chemin de fer, à travers des tunnels dont la largeur est à peine supérieure à l’écartement des rails, de l’usine Thiokol (Utah) au site de lancement… La conclusion péremptoire est que les dimensions d’un des systèmes de transport les plus modernes et avancés du point de vue technologique sont déterminées par la largeur des postérieurs des chevaux des légions romaines ! Cette histoire est une légende (http://www.snopes.com/history/american/gauge.htm, http://truthorfiction.com/rumors/r/railwidth.htm:), mais sa morale est édifiante «Specifications and bureaucracies live forever». En d’autres termes, nous manifestons la tendance forte, par conformisme (diraient les pessimistes) ou par sens pratique (diraient les optimistes), à garder en vie certains éléments des architectures que nous construisons dans tous les domaines au-delà de toute attente. Ces éléments ne sont pas matériels (on passe des chariots de guerre à la navette spatiale, en passant par les tramways, les chemins de fer…), mais bien immatériels : c’est desmesures, desfor-mats, desprotocoles, desspécifications, des choses que les anglo-saxons appellent effi-cacement « software », ce qui ne veut pas dire simplement « code de programmation », mais se définit par opposition à l’« hardware », qui ne veut pas dire simplement « ordinateur ». C’est à première vue étonnant de se rendre compte que beaucoup de choses « soft » sont si dures à mourir, beaucoup plus que le « hard » qui est en dessous. Si on y réfléchit, il est pourtant clair que le « hard » est matériel et donc certainement périssable, alors que le « soft » est immatériel et donc a priori immortel. Lorsque la base de données stratégique était le point de rencontre de toutes les appli-cations, son schéma était l’objet de toutes les attentions, l’enjeu fondamental de la maîtrise du système d’information. À l’époque des systèmes répartis et intercon-nectés, du Web et des services Web, les schémas XML sont les « spécifications » du format de l’information. La légende nous apprend que ces spécifications dureront beaucoup plus longtemps que les machines, les réseaux, les bases, les systèmes et les programmes qui interprètent, transportent, stockent, manipulent et présentent l’information. En plus, elles détermineront de façon essentielle la capacité à inter-opérer des dits systèmes et programmes. Le livre dense et intéressant de Jean-Jacques et Antoine nous fait bénéficier de leur grande expérience et compétence, pour nous expliquer comment bâtir au mieux nos « spécifications » de l’information. Je dis au mieux, car il est clair, et le livre insiste là-dessus (c’est même son leit-motiv), que la spécification parfaite est précisément et modestement le meilleur compromis entre exigences contradictoires. C’est pour cela que le métier d’architecte de l’information n’est pas facile, mais peut s’appuyer effica-cement sur des méthodes et techniques de modélisation qui lui simplifient partielle-ment la vie.
Préface
On pourrait dire : d’accord, mes schémas ne sont pas bons, je peux les changer facile-ment, finalement tout cela ce n’est que du soft ! La morale de l’histoire est que les spécifications qui s’affirment, qu’elles soient bonnes ou non, sont destinées à rester longtemps, car le nombre de gens qui se les approprient et bâtissent par-dessus devient vite non maîtrisable et après c’est trop tard. Cette vitesse devient foudroyante lorsque les systèmes en question ne manipulent pas la matière ou l’énergie, mais l’information et, en plus, sont immergés dans l’économie de réseau, à l’intérieur comme à l’extérieur de l’entreprise. Les spécifications, soumises à l’« effet réseau » (plus on les utilise, plus elles deviennent intéressantes, indépendamment de leur qua-lité, et on les utilise encore plus car elles sont intéressantes) deviennent inévitable-ment des verrouillages (lock-in). La qualité des spécifications n’allonge pas leur vie, mais diminue l’inconfort et la fatigue des usagers et des développeurs, ce qui devrait être considéré par tout professionnel comme un objectif de nature déontologique.
Que le lecteur ne se trompe pas : la qualité des modèles et des schémas XML est beaucoup plus importante, par son incidence sur les systèmes d’information, que toute architecture matérielle, logicielle, de processus, car ces dernières peuvent être beaucoup plus facilement modifiées, adaptées, remplacées. Donc, si l’on doit choisir, c’est là qu’il faut dédier la plus grande attention et l’ouvrage de Jean-Jacques et Antoine est le livre de chevet de celui qui en a la lourde tâche.
VII
Table des matières
Avantpropos ............................................................................. XIX
Introduction générale ................................................................... 1 Pourquoi des modèles ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 UML et XML : un duo gagnant4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UML et les différentes vues d’un système d’information . . . . . . . . . . . . . . . . 5 XML au cœur des systèmes d’information . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Apports de XML à la modélisation7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . L’universalité de XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 L’interopérabilité des documents XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 L’indépendance entre modèles et données . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 La forme des modèles XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Les apports du travail de normalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Un facteur d’adaptation des applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 L’adressage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Le stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 L’archivage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 L’expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 La pérennité et la flexibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 En résumé. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
PREMIÈREPARTIE Étapes de la démarche de modélisation ....................23
CHAPITRE1 Étape 1  La préparation du projet ............................................. 25 Bref aperçu de la méthode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Principes généraux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
X
Modélisation XML
Limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Contexte idéal d’utilisation de la méthode . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Présentation détaillée des quatre principes de base de la méthode. . . . . . . . . . . . 28 Principe n°1. Un système d’information repose toujours sur un même modèle de base. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Principe n°2. Un système d’information est un ensemble de fonctions et services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Principe n°3. Un système d’information est obligatoirement flexible. . . . . . . 31 Principe n°4. La représentation du système d’information doit être synthétique et simple. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Mise en œuvre de la méthode. . . . . . . . . . . . . . . . . . 34. . . . . . . . . . . . . . . . . . . . . . Étape n°1. Établir un plan de classification des fonctions et services du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Étape n°2. Identifier et classer les fonctions du système . . . . . . . . . . . . . . . . 37 Étape n°3. Identifier et classer les services du système . . . . . . . . . . . . . . . . . 39 Étape n°4. Comparer les scénarios d’implémentation . . . . . . . . . . . . . . . . . . 40 En résumé…. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
CHAPITRE2 Étape 2  Réaliser le modèle conceptuel .................................... 47 Différence entre modèle hiérarchique et modèle d’association. . . . . . . . . . . . . . . 48 Modèle d’objet UML et document XML50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modèle d’objets UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Modèle de base des documents XML : Infoset . . . . . . . . . . . . . . . . . . . . . . . 51 Notion de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Modèles et métamodèles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Modèles de données conceptuels, logiques et physiques58. . . . . . . . . . . . . . . . . . . Le cas PiloteWeb. . . . . . . . . . . . . . . . . . . . . 59. . . . . . . . . . . . . . . . . . . . . . . . . . . . Présentation du cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Modèle conceptuel de données de PiloteWeb . . . . . . . . . . . . . . . . . . . . . . . 60 Découverte des principaux concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Découverte des principales relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Recherche et formalisation des concepts et relations intermédiaires . . . . . . . 64 Synthèse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67. . . . . . . . . . . . . . . . . . . . . . . . En résumé…. . . . . . . . . . . . . . . . . . . . . . . . . . . . 68. . . . . . . . . . . . . . . . . . . . . . . . .
CHAPITRE3 Étape 3  Réaliser les modèles logiques..................................... 69 Découpage du modèle conceptuel en modèles logiques. . . . . . . . . . . . . . . . . . . . 70