Sce Samir Adouane

Rpublique Algrienne Dmocratique et Populaire
Ministre de lenseignement suprieur et de la recherche scientifique Universit El Hadj Lakhdar - Batna Facult des sciences de lingnieur Dpartement dinformatique
Mmoire
prsent en vu de lobtention du diplme de
Magister
en Informatique
Option : Informatique industrielle
Intgration des moyens de modification dynamique des contenus sur le WEB
Samir ADOUANE
Jury : Dr. S. Pr. M. Dr. A. Dr. S. Chikhi Benmohammed Zidani Zidet Universit Universit Universit Universit de de de de Constantine Constantine Batna Batna Prsident Rapporteur Examinateur Examinateur
Remerciements
Je remercie le Pr Mohamed BENMOHAMMED, Matre de confrence luniversit de Constantine davoir accept de prendre en charge la direction et le suivi de ce travail, pour sa patience, son coute et sa comprhension.
Ma gratitude sadresse tout particulirement aux membres du jury, qui ont accept de juger ce modeste travail.
Je ne permette pas doublier les collgues ECS Schindler o la plupart des applications ont t dveloppes et testes ; Driss Elkhalouki, Bertrand
PARMENTIER, Fabrice TOMACITE et en gnrale tout le personnel dECS-Shindler Mulhouse.
Je tiens aussi prsenter mes remerciements tous ceux qui mont, de prs ou de loin, permis de mener bien ce travail, qui sest rvl une exprience de grande ampleur et la hauteur de ses promesses.
Je remercie ma famille pour son soutien continu et son encouragement pour mener terme ce travail.
RESUME
Le monde de conception des applications est enrichi chaque jour par de nouveaux designs architecturaux, rpondant des problmes
dimplmentation rcurrents, la majorit de ces solutions tournent autours de la programmation oriente objet qui facilite leur intgration et mise en uvre. Dans ce mmoire nous proposons une approche base sur le modle MVC que nous appellerons les dlgus des packages , cette
approche vise faciliter et acclrer le processus de dveloppement web. Elle tente dapporter des lments pratiques, facilitant le
dploiement du modle MVC dans un contexte de la programmation oriente objet. Mots-cls : Modlisation, Mthode de conception, UML, Design Patterns, XML, XMI, application web, Entrept de donnes.
ABSTRACT
The world of applications design is enriched every day by new architectural designs that The majority of these answer recurring implementation problems. solutions address the Object-Oriented integration and
Programming implementation.
(OOP)
which
facilitates
their
In this report we propose an approach based on the MVC model which we shall call "packages delegates", this approach aims to facilitate and to accelerate the process of web development. moreover it tries to come up with practical elements, facilitating the deployment of the MVC model in an OOP context. Keywords : Modeling, Conception method, UML, Design Patterns, XML, Web application, Data Warehouse.
Intgration des moyens de modification dynamique
des contenus sur le WEB
Liste des Figures

Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 2.1 2.2 2.3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 4.1 4.2 4.3 4.4 4.5 5.1 5.2 5.3 5.4 5.5 5.6 Un processus itratif [Kruchten00] .. Le modle, un artefact Central du processus De dveloppement . Traitement d'une page statique . Traitement des pages dynamiques .. Accs une base de donnes ... Problmes de conception des applications Web Une approche centralise de la validation des entres . Stratgie de validation des entres : contraignez, rejetez et assainissez la saisie de la validation des entres . Sparation des donnes et de la prsentation avec XML . Exemple de fichier XML avec sa DTD . Transformation avec XSL Historique dUML ... Dcomposition fonctionnelle . Dcomposition Objet .. Communication des objets par des messages Les diagrammes UML par axe de modlisation Hritage des diagrammes UML .. Extrait du mtamodle. Caractristiques de la classe Un ou plusieurs automates peuvent tre associs chaque classe du modle . Niveaux dabstraction de la mta-modlisation . Package EMOF (MOF 2.0) . Le design pattern Singleton Le design pattern Decorator .. Le design pattern Observer Structure de classe MVC Comportement du modle passif .. Utilisation de l'observateur pour dissocier le modle de la vue dans le modle actif . Comportement du modle actif .. Modle MVC avec les dlgus des Packages . Sources de donnes MERLIN .. Diagramme des cas dutilisations Dtail du cas dutilisation : CommandeVente . Prsentation dynamique avec le diagramme de squence Diagramme des packages MERLIN 0 Diagramme de classe partiel du package CONTROLE (MVC avec les dlgus des packages) . Diagramme de classe partiel du package MODELE (MVC avec les dlgus des packages) Diagramme de classe partiel du package VUE (MVC avec les dlgus des packages) Base de donnes classiques et Data Warehouse . Modle physique de donne Modle en toile . Modle physique de donne Modle en flocon "neige" Plusieurs tables de fait dans un modle en toile Eclatement des tables de fait Profils daccs la base de donnes Ecran : Affichage de plusieurs indicateurs . Ecran : Dtail dun indicateur .. Ecran : Statistiques de consultation Architecture gnrale .. 08 10 15 16 18 24 26 27 32 37 42 51 54 54 56 56 56 57 59 67 68 72 72 73 76 77 78 79 82 90 91 91 92 94 94 95 95 97 98 98 100 101 102 104 105 106 111
Figure 5.7 Figure 5.8 Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18
Figure 5.19 Une partie du diagramme de classe de l diteur des contenus Figure 5.20 Aperu du schma XML des fichiers XML gnrs par lditeur des contenus Figure 5.21 Exemple dun fichier XML gnrs par lditeur des contenus .. Figure 5.22 Ecran : Lditeur des contenus . Figure A.1 Vue Multidimensionnelle des Data Warehouse. Figure A.2 Architecture dun Data warehouse. Figure A.3 Reprsentation graphique dun RELAX NG .
111 112 113 113 118 119 121
Liste des Tableaux

Tableau 1.1 Langages de script . Tableau 1.2 Vulnrabilits des applications Web et problmes potentiels dus une conception mdiocre . Tableau 3.1 Description textuelle dun Cas dUtilisation . Tableau 3.2 Outils de modlisation UML . Tableau 3.3 Liste des Design Patterns . Tableau A.1 Comparaison OLTP/OLAP . 20 13 61 63 73 120
SOMMAIRE
INTRODUCTION ------------------------------------------------------------------- 2 LES APPLICATIONS WEB --------------------------------------------------------- 6 1.1 Introduction ------------------------------------------------------------------------- 6 1.2 Dfinition dune application WEB--------------------------------------------------- 6 1.3 Sites ou applications web? --------------------------------------------------------- 6 1.4 Utilisations courantes des applications Web --------------------------------------- 7 1.5 Le processus de dveloppement --------------------------------------------------- 7 1.5.1 Le modle----------------------------------------------------------------------- 9 1.5.2 Le workflows -------------------------------------------------------------------10 1.5.3 Les risques---------------------------------------------------------------------14 1.5.4 Les itrations ------------------------------------------------------------------14 1.6 Contenu des sites web-------------------------------------------------------------14 1.6.1 Page dynamique et page statique --------------------------------------------14 1.6.2 Traitement des pages Web statiques-----------------------------------------15 1.6.3 Traitement des pages dynamiques -------------------------------------------16 1.6.4 Accs une base de donnes ------------------------------------------------16 1.6.5 Cration de pages dynamiques -----------------------------------------------18 1.6.6 Choix dune technologie de serveur ------------------------------------------20 1.7 Patterns architecturaux pour les applications WEB ------------------------------20 1.8 Scurit des application web ------------------------------------------------------21 1.8.1 Introduction -------------------------------------------------------------------21 1.8.2 Principes fondamentaux de la scurit ---------------------------------------21 1.8.3 Menaces, vulnrabilits et attaques : dfinitions ----------------------------22 1.8.4 Comment crer une application Web scurise ? ----------------------------23 1.8.5 Aspects architecturaux pour la conception des applications Web -----------23 1.9 Critres ergonomiques pour lvaluation des interfaces Web -------------------27 1.9.1Guidage -------------------------------------------------------------------------27 1.9.2 Charge de travail --------------------------------------------------------------28 1.9.3 contrle explicite --------------------------------------------------------------28 1.9.4 Adaptabilit --------------------------------------------------------------------29 1.9.5 Gestion des erreurs -----------------------------------------------------------29 1.9.6 Homognit/Cohrence ------------------------------------------------------29 1.9.7 Signifiance des codes et dnominations--------------------------------------30 1.9.8 Compatibilit --------------------------------------------------------------------30 Conclusion ------------------------------------------------------------------------------30 TECHNOLOGIE XML --------------------------------------------------------------31 2.1 Introduction ------------------------------------------------------------------------31 2.2 Pourquoi utiliser XML ? ------------------------------------------------------------32 2.3 Structure dun document XML-----------------------------------------------------33 2.3.1 Les composantes des documents XML ---------------------------------------33 2.3.2 Unicode ------------------------------------------------------------------------34 2.3.3 Unicode et XML ----------------------------------------------------------------34 2.3.4 La question de l'encodage ----------------------------------------------------34 2.4 XML oppos HTML ---------------------------------------------------------------35 2.4.1 Exemple de HTML/XML : ------------------------------------------------------35 2.5 Les DTD ( Document Type Dfinition/Dfinition de Type de Document)--------36 2.6 Les schmas XML ------------------------------------------------------------------38 2.6.1 langages de schma-----------------------------------------------------------39 2.7 DTD ou XML-Schema ? ------------------------------------------------------------40 2.8 Feuilles de style --------------------------------------------------------------------40 2.8.1 CSS feuilles de style en cascade----------------------------------------------43 2.9 Les rgles du jeu XML -------------------------------------------------------------43 2.10 Les espaces de nommage (namespaces) ---------------------------------------44 2.10.1 Problmatique: espaces de nommage et validation------------------------44 2.11 XML et les bases de donnes ----------------------------------------------------45
2.11.1 XML est-il une base de donnes ?-------------------------------------------46 2.12 Rsum ---------------------------------------------------------------------------47 Conclusion ------------------------------------------------------------------------------49 MODELISATION UML-------------------------------------------------------------50 3.1 Introduction ------------------------------------------------------------------------50 3.2 Les principes de la modlisation --------------------------------------------------53 3.3 Pourquoi lapproche Objet ? -------------------------------------------------------53 3.4 Les objets --------------------------------------------------------------------------55 3.5 Les diagrammes UML --------------------------------------------------------------56 3.5.1 Vue fonctionnelle : ------------------------------------------------------------57 3.5.2 Vue statique : -----------------------------------------------------------------57 3.5.3 Vue dynamique : --------------------------------------------------------------58 3.6 Nouveaut de UML 2.0 ------------------------------------------------------------59 3.7 UML est un langage pour communiquer ------------------------------------------60 3.8 Etude base sur les cas dutilisation ----------------------------------------------60 3.9 Le choix dun outil de modlisation -----------------------------------------------62 3.10 UML et la Mta-modlisation-----------------------------------------------------65 3.11 Les Design Patterns --------------------------------------------------------------69 3.11.1 Dfinition ---------------------------------------------------------------------70 3.11.2 Exemple de design Patterns -------------------------------------------------71 APPROCHE DES DELEGUES DES PACKAGES -----------------------------------74 4.1 Le Modle MVC---------------------------------------------------------------------74 4.1.1 Introduction -------------------------------------------------------------------74 4.1.2 Problmatique -----------------------------------------------------------------75 4.1.3 Facteurs prendre en compte ------------------------------------------------75 4.1.4.Solution ------------------------------------------------------------------------76 4.1.5 Variations ----------------------------------------------------------------------77 4.1.6 Comportement du modle actif-----------------------------------------------77 4.1.7 Considrations relatives au test ----------------------------------------------79 4.2. Approche des dlgus des packages--------------------------------------------81 4.2.1 Introduction : ------------------------------------------------------------------81 4.2.2 Approche des dlgus des packages : --------------------------------------81 4.2.3. Amlioration du faible couplage M-V-C --------------------------------------82 4.2.4 Avantages de Approche des dlgus des packages ------------------------83 4.2.5 Inconvnients Approche des dlgus des packages------------------------84 4.2.6 Exemple dimplmentation de lapproche des dlgus des packages -----84 Conclusion ------------------------------------------------------------------------------85 APPLICATION & IMPLEMENTATION--------------------------------------------86 5.1 Introduction ------------------------------------------------------------------------86 5.2 Le projet MERLIN ------------------------------------------------------------------86 5.2.1 Contexte -----------------------------------------------------------------------86 5.2.2 Dnomination du projet -------------------------------------------------------87 5.2.3 Problmatique -----------------------------------------------------------------87 5.2.4 Solution ------------------------------------------------------------------------87 5.2.5 Technologies employes ------------------------------------------------------88 5.2.6 Notion dindicateur ------------------------------------------------------------88 5.2.7 Alimentation du Data Warehouse---------------------------------------------89 5.2.8 Diagramme des cas dutilisation ----------------------------------------------90 5.2.9 Diagramme de squence : Comportement dynamique du systme --------92 5.2.10 Diagramme des packages ------------------------------------------------94 5.2.11 Utilisation de lapproche des dlgus des packages ----------------------94 5.2.12 Modle de donnes :---------------------------------------------------------96 5.2.13 Interface (Ecrans)---------------------------------------------------------- 103 5.2.14 Avantages constats avec lutilisation de lapproche des dlgus des packages --------------------------------------------------------------------------- 106 5.3 Site WEB AFPLemans ------------------------------------------------------------ 107
5.3.1 Prface ----------------------------------------------------------------------- 107 5.3.2 Contexte --------------------------------------------------------------------- 107 5.3.3 Technologies utilises ------------------------------------------------------- 107 5.3.4 Choix de la technologie XML ------------------------------------------------ 108 5.3.5 Structure du site ------------------------------------------------------------ 108 5.3.6 Intgration des moyens de modification dynamique ---------------------- 108 5.3.7 Exemple doutils facilitant ldition des contenus : ------------------------ 109 5.3.8 Editeur des contenus intgr ----------------------------------------------- 109 5.3.9 Le fichier XML---------------------------------------------------------------- 112 5.3.10 Interface de lditeur des contenus --------------------------------------- 113 CONCLUSION ------------------------------------------------------------------- 115 ANNEXE A : DATA WAREHOUSE ---------------------------------------------- 117 ANNEXE B : TUTORIAL RELAX NG [CLARK01] ---------------------------- 121 ANNEXE C : GLOSSAIRE DE VOCABULAIRE --------------------------------- 127 REFERENCES BIBLIOGRAPHIES ---------------------------------------------- 135
Introduction
La proccupation des professionnels de linformatique est de recruter de nouveaux utilisateurs, cet objectif est vital pour la survie de ce mtier, la voie la ralisation de cet objectif est la simplicit et louverture de portes franchissables par tout le monde. Les dernires annes ont marqu la croissance exponentielle de lintroduction de loutil informatique dans les divers mtiers de la vie quotidienne de lhumanit, notamment Internet, ce phnomne qui ne cesse de crotre et de prendre de la puissance. Internet doit sont succs lefficacit et la fiabilit des solutions informatiques proposes dans le march, et ladoption des processus de dveloppement logiciels bien labors. Cette thse sinscrit dans un processus de dveloppement de nouvelles approches pour la gestion des sites web et le trafic dinformations sur Internet. Plusieurs diteurs de logiciels, notamment Microsoft avec le framework .Net [Microsoft], Adobe avec ses produits multimdias (GoldFusion Dreamweaver) [Adobe], et plus rcemment SUN Microsystems avec JSF (JavaServer Faces) [SUN] ont lanc, depuis plusieurs annes, des projets de recherche pour promouvoir cette nouvelle tendance, qui vise rduire la distance entre la conception et limplmentation des applications web. On trouve de plus en plus des EDI intgrant des ateliers de gnie logiciel couvrant tout le processus de dveloppement logiciel. Les travaux que nous prsentons dans ce mmoire visent faciliter et acclrer le processus de dveloppement web. Ils tentent dapporter des lments de rponses des questions thoriques dans le dveloppement web mais surtout, par la mme occasion, de proposer une approche pratique, facilitant le dploiement du modle MVC dans un contexte de POO. Le dveloppement d'un programme se rsume souvent pour beaucoup de personnes une phase de codage, bien que cette tape soit essentielle, elle ne reprsente qu'une petite partie du cycle de vie d'un logiciel. Il est tout fait possible de raliser un logiciel sans utiliser d'autres tapes de conception, et tout le monde peut prtendre tre en mesure de concevoir des interfaces ergonomiques, mais peu sont les dveloppeurs en mesure dapporter une preuve formelle (au sens mathmatique) que leurs uvres sont garanties et volutives. La conception oriente objets repose sur une solide assise thorique ayant dj obtenu des rsultats concrets, elle permet la matrise complte du processus, non seulement au niveau de la modlisation (analyse, conception) mais galement en conduite de projet, dfinition des activits, rgles de production, dmarche qualit, rutilisation des modles Plusieurs approches ont vu le jour, permettant de structurer larchitecture des systmes informatiques, larchitecture trois-tiers tant un exemple dont le principe est relativement simple : Il consiste sparer la ralisation des trois parties classiques (stockage des donnes, logique applicative, prsentation). Les lments permettant la ralisation classique d'un systme en architecture trois-tiers sont les suivants: systme de base de donne (SGBD) pour le stockage des donnes, serveur applicatif pour la logique applicative, navigateur web pour la prsentation. Il y a aussi le modle MVC (Modle, Vue, Contrle) bien quil ait t cr en 1979 par Trygve Reenskaug, reste toujours dactualit, car il rpond une architecture rcurrente utilise dans la plupart des systmes informatiques. Cependant, malgr sa popularit, le modle MVC prsente linconvnient de la difficult que trouvent les dveloppeurs pour limplmenter dans leurs applications.
De la description thorique au codage existe une distance importante rendant quivoque limplmentation du modle MVC. Le langage Java, tente de faciliter cette tape, en mettant la disposition des dveloppeurs la classe Observable et linterface Observer, mais ce moyen reste inadapt au dveloppement web sous dautres langages de programmation et incapable de profiter de toute la puissance de ce modle. Dans ce contexte nous proposons une nouvelle approche que nous appellerons les dlgus des packages visant rduire la charge des concepteurs darchitecture web et leur donner la possibilit de crer des applications web plus rapidement et plus efficacement, suivant un modle gnrique qui constitue une sorte de design pattern. Cette approche fournit une dmarche pratique pour les programmeurs pour implmenter le modle MVC et exploiter sa modularit. Lapproche des dlgus des packages est un design architectural pour implmenter le modle MVC exploitant la nature fonctionnelle de ces trois composantes. Lapproche propose met en clair le passage de la thorie vers la pratique en donnant une dmarche mthodologique dinsertion de nouveaux modules dans les applications WEB. Structure du document Le document sorganise en cinq chapitres principaux, les trois premiers chapitres exposent les technologies utilises dans le cadre de ces travaux, et traitent leurs particularits dun angle de vue thorique et pratique. Ainsi le premier chapitre prsente les applications web, un domaine qui ne cesse dvoluer. Devant cette expansion, le dveloppement web se voit invitablement- adopter des processus logiciels limage des applications classiques, processus capables de supporter la taille et la rigueur imposes par la complexit de la nouvelle gnration des applications web. Dans le deuxime chapitre nous parlons du XML, technologie qui fait rver les informaticiens, utilise largement dans notre diteur des contenus (voir chapitre 5). Ce chapitre traite le sujet XML en dtail : Dfinitions, Standards, XML et bases de donnes, domaines dapplications, XML en pratique, DTD Nous verrons lutilit de cette technologie et ce quelle apporte pour le dveloppement web. Le troisime chapitre prsente le langage de modlisation UML, un langage largement adopt dans la communaut des dveloppeurs informatiques, grce sa simplicit et son utilit reprsenter des systmes robustes sous une sries de diagrammes graphiques, reprsentant chacun une vue diffrente du systme. UML fournit, la fois aux concepteurs et aux dveloppeurs de systmes informatiques, une puissante abstraction de haut niveau, permettant un meilleur suivi durant toutes les phases de ralisation et de dploiement de ces systmes. Le quatrime chapitre dbute par une prsentation du modle MVC et ses diffrentes variantes, puis dans une deuxime partie, nous proposons lapproche des dlgus des packages base sur ce modle. Cette approche peut tre considre comme un design pattern ou un modle darchitecture type, diffrenciant clairement les trois composantes classiques dun modle MVC savoir Vue, Contrle et Modle. Cette approche facilite visiblement le dploiement de ce modle sous un langage de programmation orient objet. Le cinquime chapitre est consacr pour la prsentation de deux projets que nous avons raliss, le premier intitul MERLIN, pour le compte de la socits ECS
Schindler spcialise dans la fabrication et la commercialisation dascenseurs et descaliers mcaniques, le projet est une implmentation effective de lapproche des dlgus des packages dcrite dans le quatrime chapitre, la ralisation de ce projet nous donne loccasion dillustrer et de clarifier son processus de dploiement et de sa mise en application. Aprs avoir prsent la problmatique, nous dcrirons en dtail le modle conceptuel de larchitecture de notre systme. Le second projet consiste en la ralisation dun site web de lAFP ( Association pour la Formation du Personnel ) intgrant un diteur des contenus destin amliorer et faciliter la cration et ldition des sites web. Enfin nous concluons sur nos travaux avant de dgager des perspectives dvolutions inspires dautres technologies. A la fin de ce mmoire on trouvera des annexes, dtaillant des sujets non toffs dans les chapitres principaux. Ainsi lutilisateur intress peut les consulter pour de plus amples informations.
1
Les applications WEB
1.1 Introduction Le dveloppement des applications WEB prsente certaines particularits, au niveau technique et ergonomique. Cette spcificit nous oblige, au moment de la conception, prconiser des mthodes de conception et des mthodes de travail ddies ce genre dapplications. Ce chapitre met en claire cette particularit des applications WEB en mettant laccent sur leurs caractristiques. 1.2 Dfinition dune application WEB Une application Web est un ensemble de pages qui interagissent avec les utilisateurs, les unes avec les autres, ainsi quavec les diffrentes ressources dun serveur Web, notamment les bases de donnes. Une application Web est un site Web qui contient des pages et dont le contenu est partiellement ou totalement indtermin. Le contenu final dune page est dtermin uniquement lorsque lutilisateur requiert une page depuis le serveur Web. Le contenu final dune page variant dune requte une autre en fonction des actions de lutilisateur, ce type de page est appel page dynamique. Les applications Web sont construites de manire rpondre diffrents types de dfis et de problmes.[Microsoft] 1.3 Sites ou applications web? Les applications web reposent sur des technologies sous-jacentes qui rendent leur contenu dynamique et qui permettent l'utilisateur de modifier l'tat applicatif sur le serveur. La distinction entre sites web et applications web est subtile, puisqu'elle rside dans le dernier cas en la possibilit d'affecter l'tat applicatif sur le serveur via un navigateur. Sans cela, il est inappropri de parler d'application web. Seuls les systmes qui offrent cette possibilit, et les serveurs d'application qui utilisent un serveur web pour l'interaction utilisateur, peuvent tre considrs comme des applications web. Pour toutes les applications web, aussi simples soient-elles, l'utilisateur doit transmettre plus que de simples requtes de navigation ; en
gnral, il peut saisir du texte simple, slectionner des boutons d'options, voire donner des informations binaires ou de fichier. La distinction devient encore plus subtile dans le cas des moteurs de recherche, pour lesquels des critres de recherche relativement sophistiqus sont saisis. Les sites web que sont les moteurs de recherche ne font qu'accepter ces critres, qu'ils emploient dans une espce de requte sur une base de donnes afin de renvoyer des rsultats. Quand l'utilisateur en a termin avec le systme, il n'y a pas de diffrence notable dans l'tat du moteur de recherche, except, bien sr, dans les fichiers journaux et les compteurs d'accs. Il en va tout autrement pour les applications web qui, par exemple, acceptent en ligne des informations d'inscription. Ainsi l'tat d'un site web dans lequel un utilisateur s'inscrit une formation sera-t-il modifi quand ce dernier en aura fini avec l'application. L'architecture d'un site web est tout ce qu'il y a de simple. Elle contient trois composants principaux : un serveur web, une connexion rseau et des navigateurs clients. Les applications web contiennent, en outre, un serveur d'application qui rend possible le traitement d'une logique et d'un tat applicatif. 1.4 Utilisations courantes des applications Web Les applications Web peuvent tre utilises de diverses faons par les visiteurs dun site et les dveloppeurs, notamment pour : Permettre aux utilisateurs de trouver rapidement et facilement des informations sur un site Web riche en contenu. Ce type dapplications Web permet aux visiteurs du site de rechercher, dorganiser et de parcourir le contenu leur convenance. Collecter, enregistrer et analyser des donnes fournies par les visiteurs du site. Auparavant, les donnes saisies dans des formulaires HTML taient envoyes sous forme de courriel aux employs ou sous forme dapplications CGI pour le traitement. Une application Web peut enregistrer les donnes dun formulaire directement dans une base de donnes et crer des rapports Web pour lanalyse. Les exemples incluent des pages de banques en ligne, de contrle des stocks, des sondages et des formulaires de commentaires. Mettre jour des sites Web dont le contenu change souvent. Une application Web vite au crateur davoir mettre frquemment jour le code HTML du site. Les fournisseurs de contenu tels que les rdacteurs en chef alimentent lapplication Web et celle-ci met automatiquement le site jour. 1.5 Le processus de dveloppement On ne dveloppe pas une application comme on suit une recette. Les comptences et les aptitudes des acteurs impliqus sont pleinement sollicites. Cela ne diminue en rien l'importance de la dfinition du projet. Mais si les efforts consentis par une quipe de dveloppement peuvent suffire pour mener un projet terme, ils seront mieux encore rtribus si ds l'abord le processus a t convenablement dfini. Un processus de dveloppement assure quatre fonctions [Booch96] : Dterminer l'ordre des activits d'une quipe, Spcifier les artefacts dvelopper, Guider la tche des dveloppeurs et de l'quipe dans son ensemble,
Offrir des critres pour le contrle et l'valuation des produits et des activits du projet.
Un processus de dveloppement logiciel peut prendre la forme d'un ensemble de documents ou de fichiers hypertexte. Le processus dfinit les chanes de processus mtier (workflows), les activits, les artefacts et les rles des acteurs impliqus dans le processus de dveloppement. Un acteur, dans ce sens, est un rle jou par un individu au cours du processus. Dans beaucoup d'quipes, des individus assurent les rles de plusieurs acteurs. Un workflow est un ensemble d'activits qui produit terme un rsultat concret et observable. Ainsi, la dtermination des besoins, la modlisation par cas d'utilisation, l'analyse, la conception. Un workflow dfinit un ensemble d'activits dans lesquelles des acteurs s'investissent. Les activits reprsentent que font les acteurs pour produire les artefacts de sortie du workflow. Un artefact dsigne tout lment d'information qui est produit par les acteurs du processus. Les artefacts peuvent tre du code, graphique, schmas de base de donnes, documents texte, diagrammes, modles, etc. Ils ont une proprit importante : ils peuvent tre soumis un contrle de versions car ils voluent souvent tout au long du processus ; un historique prcis de ces suites de modifications est en effet critique. Le processus dcrit ici est bas sur le processus unifi de Rational (RUP) pour Rational Unified Process [Krachten00] et le ICONIX Unified Process [Rosenberg99]. Tous deux dcoulent de processus et de mthodologies orients objet fonds sur les travaux de Grady Booch, Ivar Jacobson et Jim Rumbaugh [Booch99]. Ces deux processus ne sont pas les seuls processus formels utiliss aujourd'hui, il existe bien dautres processus. Comme d'autres, ces deux processus sont itratifs (voir figure 1.1). Cela veut dire que chaque phase du processus, analyse des besoins, analyse et conception, implmentation, test et valuation, est rpte et raffine jusqu' ce que le processus rponde aux besoins et quil puisse tre dploy. C'est une orientation toute diffrente du processus traditionnel de cycle de vie en cascade, dans lequel chaque phase du projet tait acheve avant que l'quipe ne passe la suivante. Les processus itratifs proviennent de cette constatation que, bien souvent, le dveloppement de logiciels ne se droule pas ainsi. Figure 1.1 Un processus itratif [Kruchten00]
Alors que les processus dcrits dans les manuels sont abstraits, la ralisation mme d'un processus de dveloppement est un processus en soi. Or, on ne saurait imposer une mthodologie une quipe tout en esprant qu'elle se conforme une
organisation, sans qu'un effort d'adaptation soit entrepris. Jim Conallen [Conallen00] dfini un certain nombre de particularits qui peuvent influencer la qualit dun processus de dveloppement logiciel : 1. Constitution de l'entreprise et organisation : Les grandes entreprises avec en leur sein des groupes consquents de talents spcialiss seront plus efficaces en suivant un processus rigoureux. Dans de telles organisations, les membres de l'quipe ne jouent qu'un rle et ne ralisent qu'un ensemble restreint d'activits bien en accord avec leur comptence et leur exprience. Le nombre important de personnes impliques renforce la ncessit de communications formelles entre les membres de l'quipe, ce qui se traduira par des artefacts dtaills et complets. 2. Les petites quipes, quant elles, pourront prfrer un processus moins contraignant. Ainsi, des quipes dont les membres ont dj collabor avec succs sur d'autres projets et dans lesquelles une dynamique de groupe a instaur une qualit de communication satisfaisante n'auront peut-tre pas besoin de toute la rigueur d'un processus surcharg d'artefacts. Que ces types de structures reposent sur des comptences prouves ne fera nanmoins pas l'conomie d'un processus bien dfini. Simplement, certains aspects du processus, tels que les runions officielles, n'auront pas la mme importance. 3. Nature de l'application. Le domaine de l'application peut influencer considrablement la structure du processus de dveloppement. Ainsi le contrle de qualit deviendra-t-il une priorit dans des secteurs qui engagent la vie humaine, tels que les appareillages mdicaux, les engins spatiaux ou les contrles de centrales nuclaires. Dans tous ces cas, le rythme des itrations sera avant tout dfini par la ralisation des objectifs fixs par l'assurance qualit. 4. Les comptences de l'quipe de dveloppement. Le processus doit tre adapt afin de tenir compte de la comptence de l'quipe. Des quipes peu exprimentes pourront tirer profit d'un processus plus encadr o les revues de groupe seront essentielles. Pour ce genre d'quipe, le processus de dveloppement doit aussi devenir un processus d'apprentissage. 5. Les priorits relatives entre les fonctionnalits, le dlai de livraison, le taux de dfauts acceptable, etc. C'est l'importance relative de tout ce qui caractrise la livraison du systme final qui dtermine les lments importants du processus de dveloppement. Par exemple, dans le cas o le but prioritaire du projet est d'tre le premier sur le march, les tests qualit pourront tre allgs, au profit de la capacit s'adapter de nouveaux besoins qui sera dterminante - quitte ne rpondre qu' un minimum de besoins dans la premire version. Le processus ainsi adapt rpondra au mieux la priorit accorde aux dlais. 1.5.1 Le modle La communication est essentielle dans le processus; c'est prcisment une des attributions du modle du systme que de servir de mcanisme de communication. Le modle est une reprsentation abstraite du systme dvelopper, du systme en dveloppement et du systme dvelopp. Le modle volue donc avec le systme en jouant un rle majeur dans chaque phase du projet. Le modle est un ensemble d'artefacts reprsentant chacun une vue du systme. Il est utilis par presque tous les membres de l'quipe, depuis les commanditaires dont les conditions de travail seront amliores par le systme, jusqu'aux dveloppeurs responsables de l'implmentation de ses composants. Chaque participant dans le processus de dveloppement utilise ou enrichit le modle diffremment (voir figure 1.2) La communication est facilite parce que tous les membres sont partie prenante
l'laboration du mme modle, mme si chaque participant en a une vision particulire.
Figure 1.2 Le modle, un artefact Central du processus De dveloppement
Comme les systmes deviennent de plus en plus complexes, leur comprhension dpasse les capacits d'un seul individu. La construction d'un modle abstrait permet d'y remdier. Un bon modle pourra ainsi servir dterminer quels composants sont associs quels cas d'utilisation et en quelle qualit. Le modle pourra aussi aider prdire les consquences que des modifications de besoins pourraient avoir sur le systme. Le modle prsente notamment l'atout de faciliter la traabilit du systme, savoir la possibilit de partir d'un de ses lments et de suivre ses interactions et liens avec d'autres parties du modle. Par exemple, les cas d'utilisation dans le modle sont associs aux ralisations de cas d'utilisation et aux diagrammes de squence (scnario), qui leur tour sont associs aux classes de base et aux collaborations qui implmentent le scnario. La traabilit permet ainsi aux chefs de projet de naviguer dans le modle pour trouver les solutions aux problmes rencontrs pendant le processus de dveloppement. 1.5.2 Le workflows Les principaux workflows du processus de dveloppement logiciel sont les suivants : la direction de projet, les besoins, l'analyse, la conception, l'implmentation, les tests, le dploiement, la configuration et la gestion des changements. [Conallen00]
10
la direction de projet Le workflow de direction de projet est responsable de la gestion globale de l'application, incluant la gestion des ressources et des budgets, et assume aussi le rle de porte-parole du projet. Le workflow de direction de projet produit les artefacts suivants : 6. Planning du projet, 7. Planning des itrations, 8. Gestion du risque, 9. Contrle de l'avancement. Le principal acteur du workflow de direction de projet est le chef de projet, responsable du bon droulement du processus. La collecte des besoins On appelle besoin un nonc de ce que le systme devrait faire. L'ensemble des besoins est dfini dans la spcification des besoins. Dfinir les besoins pour un systme ne va pas de soi : mme en partant d'une vision commune, les reprsentations mentales d'un systme diffrent d'un individu l'autre. Pire encore, les divergences de conception peuvent aussi se manifester parmi les dveloppeurs. L'expression des besoins doit donc proposer ce que le systme non pas comment, mais quoi. Ce sont l'analyse et la conception question du comment Les cas d'utilisation sont un outil clairement les besoins tous les individus concerns et pour comprendre d'une manire univoque. Lanalyse L'analyse et la conception sont souvent fortement associes ; nous prfrons les sparer dans deux workflows distincts. En effet, bien que, dans la majorit des cas, les mmes individus participent aux deux workflows, les activits et les objectifs sont trs diffrents. L'analyse est le processus qui, en partant de l'examen des besoins, produit un modle conceptuel du systme dvelopper. Les artefacts de l'analyse incluent les classes et les collaborations dtailles, les diagrammes de squence, les diagrammes d'tats et les diagrammes d'activits. La conception opre sur les mmes artefacts, mais seulement aprs que l'architecture y a t intgre. Au moment de l'analyse, ces artefacts peuvent encore tre discuts avec des experts du domaine et des reprsentants des utilisateurs, alors qu'une fois l'architecture applique au moment de la conception, ils deviennent le plus souvent trop techniques pour eux. La conception Le workflow de conception traite les artefacts produits durant l'analyse en leur appliquant l'architecture. Le but principal de la conception est de rendre le modle de l'analyse ralisable sous forme de logiciel. C'est alors la premire fois que les concepts abstraits du mtier sont confronts au monde logiciel. Dans certains cas, l'introduction d'une architecture affecte tant le modle que deux modles spars du systme sont maintenus : un modle d'analyse et un modle de conception. Ces modles ne sont que deux vues diffrentes du mme systme. Dans le cas o deux devrait accomplir qui rpondront la cl pour exprimer qu'ils puissent les
11
modles doivent coexister, le workflow de gestion de configuration et des changements a une nouvelle responsabilit : assurer la cohrence des deux modles. Limplmentation Bien que l'criture et la compilation du code ne soient pas les seules tches affrentes l'implmentation d'un systme logiciel, elles en reprsentent une grande part. L'implmentation applique des outils de dveloppement logiciel aux artefacts de la conception. En plus des diteurs et compilateurs courants, des environnements de dveloppement intgrs peuvent gnrer du code partir d'lments du modle ; cependant, la gnration de code avec les environnements intgrs se limite pour l'essentiel des lments structuraux, laissant totalement la charge du dveloppeur le codage de la dynamique de l'application. L'implmentation d'applications web implique souvent la matrise simultane de nombreuses technologies. Pour le dveloppement ct client, les langages et les techniques sont principalement HTML, JavaScript, Java, ActiveX et d'ventuelles technologies objet distribues. Sur le serveur, les langages et les technologies sont plus varis avec des langages de troisime gnration et des langages orients objet (C/C++, Java, Smalltalk, Ada, Eiffel, PHP), mais aussi des technologies base de composants (JavaBeans, COM), et enfin des technologies traditionnelles de bases de donnes. On retrouve ainsi sur le serveur toutes les technologies d'un systme clientserveur classique. Les tests Le workflow des tests consiste pour l'essentiel valuer les artefacts excutables du systme. Les tests sont dissocis de l'assurance qualit, laquelle affecte toutes les parties du systme et non pas uniquement les excutables. De nombreux tests diffrents sont effectus sur le systme; chacun d'entre eux essaie de dterminer une proprit du systme. Un test de performance value la capacit du systme fonctionner rapidement sous la pression d'une forte charge. Un test de charge soumet le systme une utilisation intense pour tablir son point de rupture ou simplement sa courbe de performance relative. Les tests fonctionnels vrifient que des fonctions particulires ont bien t implmentes telles qu'elles sont dfinies dans les spcifications des besoins. Les tests fonctionnels dcoulent souvent directement des cas d'utilisation. Outre les tests d'valuation de proprits du systme, d'autres tests permettent de valider certaines tapes du processus : 10. Test unitaire : il est effectu par le dveloppeur sur une partie limite du systme qu'il a dvelopp. Bien souvent, un test unitaire ne porte que sur un seul composant ou sur une petite collaboration de composants. Chaque dveloppeur est cens effectuer les tests unitaires qui concernent son propre travail. 11. Test d'intgration : il valide la compatibilit des diffrentes interfaces des composants. Il est effectu aprs l'interconnexion de certaines parties du systme mais avant l'assemblage de l'ensemble du systme. 12. Test systme : il vrifie que l'ensemble des besoins est satisfait. Ce test est effectu une fois tous les composants du systme assembls afin de valider le systme dans son ensemble.
12
13. Test d'acceptation : c'est le test officiel par lequel la communaut des utilisateurs valide le systme. Si le systme est accept, il est prt tre dploy. Paralllement aux tests de validation de certaines tapes, les tests de non-rgression prennent une importance plus sensible dans un processus de dveloppement itratif. Ce sont les tests de non-rgression qui contrlent nouveau un systme qui a potentiellement chang. Bien que la traabilit dans le modle facilite la dtermination des cas d'utilisation affects par une modification du code, la possibilit qu'un changement effectu sur une partie du systme en affecte une autre, apparemment indpendante, n'est jamais exclue. L'application systmatique de tests de non-rgression limite ce risque. Si un lest de non-rgression dtecte un dysfonctionnement, cela peut rvler une dpendance inconnue, qu'il convient de clarifier dans le modle. Les tests d'une application web se droulent peu prs de la mme manire que pour un autre systme. L'quipe de test procde souvent avec l'application comme s'il s'agissait d'une bote noire : seul le comportement extrieur du systme compte. La nature de l'application web pourra amener effectuer les tests sur un grand nombre de configurations de plates-formes et de navigateur client. Les applications destines l'Internet doivent considrer toutes les varits de navigateurs qui pourraient tre employes, ainsi que les plates-formes sur lesquelles ils fonctionnent. Pour les applications Internet, cela reprsente une lourde contrainte qui elle seule peut limiter leur interface leur plus simple expression. Le dploiement Selon les cas, le dploiement d'une application web peut s'avrer trs facile ou au contraire trs complexe. Ainsi, le dploiement d'une application intranet simple qui fonctionne sur un serveur et bnficie d'un rseau existant pourra tre trs ais. Seul le serveur doit tre configur car les clients possdent probablement des navigateurs adapts. Si l'application est conue pour n'utiliser que les possibilits de base du client, il n'y a rien de plus faire. Mais si l'application doit grer des aspects de scurit et de gros volumes d'accs sur l'Internet, un investissement consquent en termes de planification du dploiement est ncessaire. Les applications Internet doivent aussi soigneusement planifier la disponibilit des ressources et des accs rseau. La plupart des grosses applications Internet possdent des connexions Internet redondantes et des systmes de sauvegarde hors site. Le dploiement de telles applications exige une planification et une gestion rigoureuses. La gestion de configuration et des changement Si la gestion de configuration et des changements est un workflow en soi, c'est parce que son rle est vital dans un processus itratif. La raison en est que la possibilit d'incorporer des changements dans le processus en cours, d'une faon contrle, est la condition mme du succs de la convergence des itrations. Chaque changement est un petit ajustement par rapport l'orientation fixe au projet. Le contrle des changements fournit au chef de projet des informations utiles qui lui permettent de valider la qualit des parties du projet. Des changements frquents et non prvus dans certains secteurs indiqueraient probablement que ce sont l des secteurs haut risque, qui n'ont pas fait l'objet d'une analyse suffisante en amont.
13
1.5.3 Les risques Le processus de dveloppement vise avant tout cerner au plus tt tout risque qu'encourt un projet. Le risque, c'est l'inconnu ; et ce, aussi bien dans les secteurs de l'application qui reposent sur des technologies non prouves que dans des domaines o l'quipe de dveloppement manque d'exprience. C'est le plus tt possible dans le processus que le chef de projet, l'architecte et les membres cls de l'quipe doivent examiner l'ensemble des artefacts de l'analyse des besoins, incluant les cas d'utilisation, la recherche de sources de risques. La mise en uvre du processus permet d'anticiper sur les risques potentiels du systme et de dlimiter ses zones risque en les implmentant en premier. Le mcanisme consiste laisser les cas d'utilisation jouer leur rle central, qui est de conduire le processus. En effet, les cas d'utilisation sont une ressource pour presque toutes les activits du processus et chaque collaborateur se rfre aux cas d'utilisation pour valider les dcisions prises durant les activits de dveloppement. Cette approche centre sur les cas d'utilisation favorise l'claircissement des risques en insistant sur le dveloppement. 1.5.4 Les itrations La planification des itrations est essentielle dans la russite du processus. Aucune place ne doit tre laisse l'improvisation. Une fois que les secteurs risque ont t dtermins, le chef de projet dresse, avec l'architecte et les membres cls de l'quipe, le plan d'itration initial. Ce plan dtaille les objectifs court terme de chaque membre de l'quipe et dfinit les dates de livraison des artefacts. La premire itration permet en grande partie de dfinir la vision du projet. Elle aboutit principalement deux artefacts, l'nonc de la vision du projet et son cas d'utilisation. Cette premire itration peut galement inclure la mise en place de procdures pour la gestion de configuration et des changements, ainsi que l'analyse de l'environnement. Elle peut en outre contenir une modlisation prliminaire de cas d'utilisation ou la dfinition des paquetages des cas d'utilisation de haut niveau. Dans certains cas, le choix d'une architecture d'application web est vident. Par exemple, l'entreprise qui souhaite vendre sur l'Internet des produits doit opter pour un systme de commerce lectronique bas sur le Web. Si la majorit des applications web de la premire gnration ont pu tre dveloppes hors de tout vrai processus sans trop de difficults, c'est parce qu'elles taient les produits de petites quipes (voire d'une seule personne) et qu'elles ne possdaient qu'une fonctionnalit limite. Les applications web actuelles, qui deviennent de plus en plus complexes et qui jouent des rles critiques en faisant appel des quipes trs toffes, en nombre et en spcialistes, ne peuvent se soustraire, sous peine de drive incontrle, un processus fortement structur. 1.6 Contenu des sites web 1.6.1 Page dynamique et page statique Un site Web est un ensemble de pages statiques et dynamiques. Une page statique nest pas modifie lorsquun visiteur la consulte : le serveur Web transmet la page au navigateur qui la sollicite sans la modifier. A linverse, une page Web dynamique est modifie (construite) par le serveur avant dtre transmise au navigateur qui la sollicite. Cest pourquoi cette page est dite dynamique.
14
Vous pouvez par exemple crer une page pour afficher les rsultats du programme de mise en forme et faire en sorte que certaines informations (telles le nom et les rsultats de lemploy) soient dtermines lorsquune page est sollicite par un employ donn. 1.6.2 Traitement des pages Web statiques Un site Web statique comprend un jeu de pages et de fichiers HTML associs hbergs sur un ordinateur excutant un serveur Web. Un serveur Web est un logiciel qui fournit des pages Web en rponse des requtes de navigateurs Web. Une requte de page est gnre lorsquun utilisateur clique sur un lien dune page Web ou saisit une URL dans le champ Adresse du navigateur. Le contenu final dune page Web statique est dtermin par le crateur de la page et nest pas modifi lorsquun utilisateur la sollicite. Exemple : Chaque ligne du code HTML de la page est rdige par le crateur avant que la page ne soit place sur le serveur. Ce code HTML ntant pas modifi une fois la page sur le serveur, cette page est dite statique. <html> <head> <title>Informations relatives la page</title> </head> <body> <h1>A propos de cette page</h1> <p>Cette page est une simple page HTML.</p> </body> </html>
Remarque : Lorsquun serveur Web reoit une requte de page statique, il lit la requte, localise la page et la transmet au navigateur qui la sollicite, tel quindiqu dans la figure 1.3 ci-dessous :
Figure 1.3 Traitement d'une page statique

Etape 1 Le navigateur sollicite unEtape 7 Le serveur Web envoie la page Navigateur Web Demande Rponse
Etape 2 Le serveur Web localise la page
Serveur Web <HTML> <p> </HTML> Page statique
Etape 3 Le serveur Web envoi la page au navigateur requrant
15
Dans le cas des applications Web, certaines lignes de code ne sont pas dtermines au moment o lutilisateur sollicite la page. Ces lignes doivent tre dtermines via un mcanisme avant que la page ne soit transmise au navigateur. Ce mcanisme est prsent dans la section suivante. 1.6.3 Traitement des pages dynamiques Lorsquun serveur Web reoit une requte de page Web statique, il transmet simplement cette page au navigateur requrant. En revanche, lorsque le serveur Web reoit une requte de page dynamique, il ragit de manire diffrente : il transmet cette page une extension logicielle spciale charge dachever la page. Ce logiciel spcial est appel serveur dapplication. Le serveur dapplication lit le code de la page, termine cette page en fonction des instructions figurant dans le code, puis en retire le code. Il en rsulte une page statique que le serveur dapplication renvoie au serveur Web, lequel transmet alors cette page au navigateur requrant. Le navigateur reoit uniquement du code HTML pur lorsque la page lui est transmise. La figure 1.4 affiche un aperu du processus : Figure 1.4 Traitement des pages dynamiques
Etape 1 Le navigateur sollicite une page dynamique Navigateur Web Demande Rponse
Etape 2 Le serveur Web localise la page et la transmet au serveur dapplication Etape 3 Le serveur dapplication analyse la page la recherche dinstructions et la termine.
Serveur web <HTML> <code> </HTML> <HTML> <p> </HTML>
Etape 5 Le serveur Web envoie la page acheve au navigateur requrant
Serveur dapplication
Etape 4 Le serveur dapplication transmet la page acheve au serveur Web.
1.6.4 Accs une base de donnes Un serveur dapplication vous permet de travailler avec des ressources ct serveur telles que les bases de donnes. Une page dynamique peut, par exemple, ordonner au serveur dapplication dextraire des donnes de la base de donnes et de les insrer dans le code HTML de la page. Linstruction dextraction des donnes de la base est nomme requte de base de donnes. Une requte est compose de critres de recherche rdigs dans un langage de base de donnes appel SQL (Structured Query Language) La requte SQL est rdige dans les scripts ou les balises ct serveur de la page. Un serveur dapplication ne peut pas communiquer directement avec une base de donnes car le format propritaire de cette dernire rend les donnes
16
indchiffrables, de la mme manire quun document Microsoft Word ouvert dans Bloc-notes ou dans BBEdit est indchiffrable. Le pilote de base de donnes constitue lunique moyen de communication entre le serveur dapplication et la base de donnes : ce logiciel agit comme un interprte entre le serveur dapplication et la base de donnes. Une fois que le pilote a tabli la communication, la requte est excute par rapport la base de donnes et un jeu denregistrements est cr. Un jeu denregistrements est un ensemble de donnes extraites dune ou de plusieurs tables de base de donnes. Le jeu denregistrements est renvoy au serveur dapplication et les donnes sont utilises pour complter la page dynamique. Voici un exemple simple de requte de base de donnes rdige en SQL :
SELECT nom, prenom, Email FROM Employees [retourne le nom et le prnom et lemail de tous les employs contenus dans la table Employees]
Et en voici une autre plus complexe :
SELECT nom, prenom, Email, adressEntreprise FROM Employees a , Entreprise b Where a.idEnreprise = b. idEnreprise And a.email like %@monDomaine.com [retourne le nom et le prnom, email et ladresse de lentreprise de tous les employs dont le-mail contient la chane @monDomaine.com en dernire position]
Le mot cl SELECT regroupe tout un langage dinterrogation de base de donnes, avec sa propre grammaire il constitue un outil trs puissant de slection et de filtrage des donnes. Dun diteur de base de donnes un autre, la syntaxe diffre, mais il existe un standard SQL/92 qui offre la plupart des fonctionnalits de base dinterrogation et de manipulation des donnes. Les SGBD actuellement sur le march fournissent de nombreux outils requteurs permettant de construire des requtes graphiquement sans ncessiter des connaissances du langage SQL. Le but est de se rapprocher dune large tranche dutilisateurs, qui dans leurs majorit ne sont pas des spcialistes du domaine
17
La figure 1.5 est une illustration du processus dinterrogation de la base de donnes via des requtes et de la transmission des donnes au navigateur Figure 1.5 Accs une base de donnes
Etape 1 Le navigateur sollicite une page dynamique
Navigateur Web Demande Rponse
Etape 2 Le serveur Web localise la page et la transmet au serveur dapplication Etape 3 Le serveur dapplication analyse la page la recherche dinstructions et la termine.
Serveur web <HTML> <code> </HTML> <HTML> <p> </HTML>
Etape 7 Le serveur Web envoie la page acheve au navigateur requrant Etape 6 Le serveur dapplication insre les donnes dans la page, puis transmet la page acheve au serveur Web. Etape 5 Le SGBD renvoie un jeu denregistrements au serveur dapplication.
Serveur dapplication
Etape 4 Le serveur dapplication envoie une requette au SGBD
Base de donnes
A partir du moment o les pilotes de base de donnes requis sont installs sur le serveur, vous pouvez utiliser pratiquement toutes les bases de donnes avec votre application Web. Si vous prvoyez de crer de petites applications peu onreuses, vous pouvez utiliser une base de donnes fichier, cre par exemple sous Microsoft Access. Si vous prvoyez de crer des applications stratgiques robustes, vous pouvez utiliser une base de donnes client/serveur, cre par exemple avec Microsoft SQL Server, Oracle 9i ou MySQL. Si votre base de donnes rside sur un systme autre que votre serveur Web, assurez-vous quil existe une connexion rapide entre les deux systmes pour un fonctionnement efficace et rapide de votre application Web. 1.6.5 Cration de pages dynamiques La cration dune page dynamique consiste crire dabord le code HTML, puis ajouter les scripts et les balises ct serveur au code HTML pour rendre la page dynamique. Lorsque vous visualisez le code obtenu, le langage apparat incorpor dans le code HTML de la page. Par consquent, ces langages sont appels langages de programmation HTML intgrs. Lexemple de base ci-dessous utilise le code PHP :
18
<html> <head> <title>Une Simple page dynamique avec PHP </title> </head> <body> <h3>Ceci est un exemple de page dynamique</h3> <p>Cette page a t cre le :<b>  <?php $date = Date("l F d, Y"); echo($date); ?>  </b></p> <h3>Fin de la page</h3> </body> </html>
Les instructions incorpores dans cette page excutent les actions suivantes : Cration dune variable appele date et assignation de la date courante cette variable. Insertion de la valeur de la variable, date , dans le code HTML.
Le serveur dapplication renvoie la page suivante au serveur Web :
<html> <head> <title>Une Simple page dynamique avec PHP </title> </head> <body> <h3>Ceci est un exemple de page dynamique</h3> <p>Cette page a t cre le :<b>  Samedi 10 Mars 2006  </b></p> <h3>Fin de la page</h3> </body> </html>
Le serveur Web transmet la page au navigateur requrant, lequel laffiche de la manire suivante :
19
Le langage de script ou de balise utiliser dpend de la technologie de serveur disponible sur votre serveur. Voici une liste des langages les plus utiliss pour les cinq technologies de serveur : Tableau 1.1 Langages de script
Technologie de serveur ColdFusion ASP.NET Pages ASP (Active Server Pages) JSP (JavaServer Pages) PHP
Langage CFML (ColdFusion Markup Language) Visual Basic C# VBScript JavaScript Java PHP
1.6.6 Choix dune technologie de serveur Le choix de la technologie de serveur dpend galement du serveur dapplication que vous souhaitez utiliser pour votre application Web. Un serveur dapplication est un logiciel qui aide un serveur Web traiter des pages Web contenant des scripts ou des balises ct serveur. Par exemple, si vous disposez de ColdFusion MX Server, vous pouvez choisir ColdFusion comme technologie de serveur. Si vous avez accs au serveur Microsoft Internet Information Server 5 (IIS) avec la plate-forme .NET, vous pouvez choisir ASP.NET. Faites appel PHP si vous avez accs un serveur Web avec un serveur dapplication PHP. Pour en savoir plus sur ASP.NET, visitez le site Web Microsoft ladresse suivante : www.asp.net/ (en anglais). Pour en savoir plus sur ASP, visitez le site Web Microsoft ladresse suivante : msdn.microsoft.com/library/psdk/iisref/aspguide.htm. Pour en savoir plus sur JSP, visitez le site Web de Sun Microsystems ladresse suivante : http://java.sun.com/products/jsp. Pour en savoir plus sur PHP, visitez le site Web de PHP ladresse suivante : www.php.net/.
1.7 Patterns architecturaux pour les applications WEB Un pattern architectural est l'expression d'un schma fondamental d'organisation pour des systmes logiciels. Il inclut un ensemble de sous-systmes prdfinis, prcisent leurs responsabilits et prescrit des rgles et des conseils pour organiser leurs relations Les trois patterns les plus courants sont les suivants : Le pattern du client web lger (Thin Web Client), employ surtout pour les applications destines l'Internet pour lesquelles la configuration du client n'est pas contrle. Le client ne ncessite qu'un navigateur web standard compatible avec les formulaires. La logique mtier est intgralement excute sur le serveur. Le pattern du client web lourd (Thick Web Client), permettant une partie significative de la logique mtier d'tre excute sur le poste client. En gnral, le client met en uvre HTML dynamique, des applets Java ou des
20
contrles ActiveX pour excuter la logique mtier. Les communications avec le serveur passent toujours par HTTP. Le pattern livraison web (Web Delivery), pour lequel, en plus de l'emploi de HTTP pour la communication client-serveur, d'autres protocoles, tels IIOP ou DCOM, peuvent tre mis en uvre dans un systme d'objets distribus. Le navigateur web agit principalement comme un conteneur et comme un priphrique de livraison dans le systme d'objets distribus.
1.8 Scurit des application web 1.8.1 Introduction Lorsqu'il est question de scurit des applications Web, on pense immdiatement ces pirates qui endommagent les sites Web, volent des numros de cartes de crdit et bombardent les sites d'attaques de refus de service. Il est frquent aussi de penser aux virus, aux chevaux de Troie et aux vers. Ce sont l les types de problmes le plus largement voqus car ils reprsentent quelques-unes des menaces les plus importantes auxquelles sont confrontes les applications Web actuelles. Mais ils ne sont pas les seuls. D'autres problmes essentiels sont frquemment sous-estims. Les menaces internes dues des administrateurs malfaisants, des employs hostiles et des utilisateurs occasionnels qui tombent par erreur sur des donnes sensibles reprsentent un risque non ngligeable. Le plus gros problme est peut-tre l'ignorance. La solution pour assurer la scurit d'une application Web dpasse la technologie. Elle suppose un processus progressif d'implication des personnes et de recours certaines pratiques. Pour construire une application Web scurise, une architecture et une conception adaptes sont indispensables. Le cot et les efforts d'adaptation de la scurit aprs le dveloppement sont trop levs. L'examen de l'architecture et de la conception vous aide valider les fonctions de conception de votre application lies la scurit, avant le dmarrage de la phase de dveloppement. Ceci vous permet d'identifier et de corriger les vulnrabilits avant qu'elles ne soient exploites, et avant que la correction ne require des efforts inconsidrs de ringnierie. Quel sens donner au mot scurit ? La scurit est essentiellement destine protger les ressources. Celles-ci peuvent tre des lments tangibles, comme une page Web ou votre base de donnes de clients ou plus abstraits, tels que la rputation dune socit. La scurit n'est pas une destination, elle est un chemin parcourir. mesure que vous analysez votre infrastructure et vos applications, vous identifiez des menaces potentielles et vous ralisez alors que chacune d'elles prsente un degr de risque. La scurit consiste grer le risque et mettre en uvre des contre-mesures efficaces. 1.8.2 Principes fondamentaux de la scurit La scurit s'appuie sur les lments suivants :
21
Authentification L'authentification pose la question : qui tes-vous ? Il s'agit du processus visant identifier de faon unique les clients de vos applications et services, qui peuvent tre des utilisateurs finals, d'autres services, des processus ou des ordinateurs. En termes de scurit, les clients authentifis sont appels entits. Autorisation L'autorisation pose la question : que pouvez-vous faire ? Il s'agit de dterminer les ressources et les oprations que le client authentifi est autoris consulter ou effectuer. Les ressources englobent des fichiers, des bases de donnes, des tables, des lignes, etc., ainsi que des ressources dites systme telles que des cls de registre et des donnes de configuration. Les oprations incluent l'excution de transactions telles que l'achat d'un produit, le transfert d'argent d'un compte un autre ou l'augmentation du taux de crdit d'un client. Confidentialit La confidentialit permet de s'assurer que les donnes restent prives et confidentielles et qu'elles ne peuvent pas tre vues ou dtournes par des utilisateurs non autoriss ou des indiscrets qui surveillent le flux du trafic sur un rseau. Le cryptage est souvent employ pour renforcer la confidentialit. Les listes de contrle d'accs (ACL) sont un autre moyen d'imposer la confidentialit. Intgrit L'intgrit garantit que les donnes sont protges contre toute modification accidentelle ou dlibre (malveillante) Comme la confidentialit, l'intgrit est une proccupation majeure, notamment pour les donnes transmises sur des rseaux. L'intgrit des donnes en transit est gnralement assure par des techniques de hachage et des codes d'authentification des messages. Disponibilit En termes de scurit, on entend par disponibilit la capacit pour des systmes de rester disponibles pour les utilisateurs lgitimes. Le but de nombreux auteurs d'attaques par refus de service est de dtriorer une application ou de crer une saturation telle que les utilisateurs ne puissent plus y accder. 1.8.3 Menaces, vulnrabilits et attaques : dfinitions Une menace est un vnement potentiel, malveillant ou autre, qui pourrait nuire une ressource. En d'autres termes, toute opration prjudiciable vos ressources est une menace. Une vulnrabilit est une faiblesse qui rend possible une menace. Cette possibilit peut tre due une mauvaise conception, des erreurs de configuration ou des techniques de codage inappropries et non fiables. Une validation de la saisie insuffisante est un exemple de vulnrabilit de la couche application susceptible d'aboutir des attaques au niveau des entres.
22
Une attaque est une action qui exploite une vulnrabilit ou excute une menace. Il s'agit par exemple d'envoyer des donnes d'entre malveillantes une application ou de saturer un rseau en vue d'entraner un refus de service. Pour rsumer, une menace est un vnement potentiel qui peut avoir un impact ngatif sur une ressource, tandis qu'une attaque russie exploite les vulnrabilits de votre systme. 1.8.4 Comment crer une application Web scurise ? Il n'est pas possible de concevoir et de crer une application Web scurise tant que vous ignorez les menaces. Un processus toujours plus important qu'il est conseill d'intgrer dans la phase de conception de votre application est la modlisation de la menace. Son objectif est d'analyser l'architecture et la conception de l'application et d'identifier les domaines potentiellement vulnrables qui permettraient un utilisateur, mme par erreur ou un pirate mal intentionn, de compromettre la scurit de votre systme. Une fois que vous connaissez les menaces, gardez l'esprit, lors de la phase de conception, l'objectif de scurit en appliquant des principes prouvs de longue date. En tant que dveloppeur, vous devez appliquer des techniques de codage sres afin d'laborer des solutions scurises, robustes et rsistantes aux attaques. La conception et le dveloppement de la partie logicielle de la couche application doivent tre tays par une configuration fiabilise du rseau, de l'hte et de l'application sur les serveurs o le logiciel sera dploy. 1.8.5 Aspects architecturaux pour la conception des applications Web Dans le monde des entreprises, la scurit est un lment cl dans la mise en place des rseaux informatiques, larchitecture doit rpondre rigoureusement des normes de qualit et daudit pour assurer le niveau de protection le plus lev possible. Certaines entreprises, par crainte de divulguer leurs secrets professionnels prfrent sisoler dans des rseaux Intranet garantissant la protection contre les requtes malveillantes des tiers. Mais louverture du march mondial pousse les socits se doter invitablement- douvertures sur le monde extrieur, via des applications Web de plus en plus nombreuses. Les concepteurs et dveloppeurs des applications Web doivent faire face un grand nombre de difficults. Au pralable, l'application doit tre capable d'identifier l'utilisateur en faisant appel une forme ou une autre d'authentification. Sachant que toutes les dcisions d'autorisation ultrieures sont bases sur l'identit de l'utilisateur, il est essentiel que le processus d'authentification soit scuris et que le mcanisme de gestion de session utilis pour suivre les utilisateurs authentifis bnficie du mme niveau de protection. La conception de mcanismes d'authentification et de gestion de session ne constitue qu'une partie des difficults auxquelles les concepteurs et dveloppeurs des applications Web sont confronts. D'autres difficults apparaissent du fait que les donnes d'entre et de sortie sont transmises sur des rseaux publics. La prvention de la manipulation des paramtres et la divulgation des donnes sensibles constituent d'autres problmes majeurs. [Microsoft]
23
Certains des principaux problmes devant tre rsolus en ayant recours des pratiques de conception scurise sont illustrs dans la figure 1.6. Figure 1.6 Problmes de conception des applications Web
Le tableau 1.2 numre les catgories de vulnrabilit, et pour chacune d'entre elle, met en vidence les problmes potentiels pouvant dcouler d'une mauvaise conception. Tableau 1.2 Vulnrabilits des applications Web et problmes potentiels dus une conception mdiocre Catgorie de Problme potentiel d une conception mdiocre vulnrabilit Validation entres des Attaques ralises en insrant des chanes malveillantes dans des chanes de requte, des champs de formulaires, des cookies et des en-ttes HTTP. Il peut s'agir d'attaques d'excution de commande, de script inter-site (XSS), d'injection SQL et de dpassement de la capacit de la mmoire tampon.
Authentification Usurpation d'identit, dcodage de mot de passe, lvation des privilges et accs non autoris. Autorisation Accs des donnes confidentielles ou restreintes, falsification et excution d'oprations non autorises.
Gestion de la Accs non autoris aux interfaces d'administration, capacit configuration mettre jour les donnes de configuration et accs non autoris aux comptes utilisateurs et aux profils de compte. Donnes sensibles Divulgation d'informations confidentielles et falsification des donnes.
24
Catgorie de Problme potentiel d une conception mdiocre vulnrabilit Gestion sessions des Capture des identificateurs de session se traduisant par le piratage de session et l'usurpation d'identit. Accs des donnes confidentielles ou des informations d'identification de compte ou les deux.
Cryptographie
Manipulation Attaques de pntration de rpertoire, excution de des paramtres commande et contournement des mcanismes de contrle d'accs (entre autres), se traduisant par la divulgation d'informations, l'lvation des privilges et le refus de service. Gestion des Refus de service et divulgation d'informations sensibles de exceptions niveau systme. Audit et Absence de dtection des signes d'intrusion, incapacit journalisation authentifier les actions d'un utilisateur et difficults diagnostiquer les problmes. Validation des entres La validation des entres est un problme dlicat et la responsabilit principale de sa solution repose sur les paules des dveloppeurs d'applications. Nanmoins, une validation correcte des entres est l'une des meilleures mesures de dfense contre les attaques actuelles visant les applications. Elle constitue une contre-mesure efficace pour empcher ses attaques. La validation des entres est dlicate du fait qu'il n'existe pas de rponse unique vis--vis de ce qui constitue une saisie valide travers des applications, voir au sein d'une mme application. De mme, il n'existe pas de dfinition unique de ce qu'est une entre malveillante. Pour ne rien simplifier, l'utilisation que fait votre application de ces entres influe sur le risque li au dtournement. Par exemple, stockez-vous des donnes l'intention d'autres applications ou votre application consomme-t-elle les entres provenant de sources de donnes cres par d'autres applications ? Les pratiques suivantes visent amliorer la validation des entres de vos applications Web : Partir du principe que toute entre de donnes est malveillante. Centraliser votre approche. Ne pas faire confiance la validation ct client. Contraindre, rejeter et assainir vos entres
Partir du principe que toute entre de donnes est malveillante La validation des entres repose sur la supposition fondamentale que toute entre est malveillante jusqu' preuve du contraire. Que les entres manent d'un service, d'un partage de fichier, d'un utilisateur ou d'une base de donnes, validez-les si la source se trouve hors de votre frontire de scurit. Par exemple, si vous appelez un service Web externe qui retourne des chanes, comment pouvez-vous savoir si des commandes malveillantes ne s'y trouvent pas ? De plus, si plusieurs
25
applications crivent dans une base de donnes partage, lorsque vous lisez les donnes, comment savoir si elles sont saines ? Centraliser votre approche Faites de votre stratgie de validation de saisie un lment central de votre conception d'application. Envisagez une approche de validation centralise, par exemple en utilisant un code commun de validation et de filtrage dans des bibliothques partages. Ceci garantit que les rgles de validation sont appliques en permanence. Ceci rduit en outre les efforts de dveloppement et favorise la maintenance future. Imaginez un modle o lensemble des cas dutilisation de votre application implmentent un unique package de validation et de contrle. Cette approche est illustre dans la figure 1.7.
Figure 1.7 Une approche centralise de la validation des entres
Ne pas faire confiance la validation ct client Le code ct serveur doit effectuer sa propre validation. Que se passe-t-il si un attaquant contourne votre client ou neutralise vos routines de script ct client, par exemple, en dsactivant JavaScript ? Utilisez la validation ct client pour aider rduire le nombre de boucles vers le serveur mais ne vous basez pas dessus pour la scurit. Ceci est un exemple de dfense renforce. Forcer, bloquer et purifier la saisie L'approche de prdilection en matire de validation des entres consiste limiter ce que vous autorisez ds le dbut. Il est beaucoup plus facile de valider des donnes pr-filtres que de valider des donnes en recherchant des caractres rputs incorrects. Lorsque vous concevez votre application, vous savez ce qu'elle attend. La plage de donnes valides est gnralement un ensemble fini d'lments, dans lequel une entre potentiellement malveillante n'a pas sa place. Nanmoins, pour assurer une dfense renforce, vous pouvez galement rejeter les entres connues comme incorrectes, puis assainir la saisie. Cette approche ncessite la mise en
26
place de plans de test permettant de vrifier tous les cas de figure possibles et de prvoir des procds appropris chaque cas. La stratgie recommande est illustre dans la figure 1.8.
Figure 1.8 Stratgie de validation des entres : contraignez, rejetez et assainissez la saisie de la validation des entres
1.9 Critres ergonomiques pour lvaluation des interfaces Web Les critres ergonomiques, qu'on les voit comme des rgles ou des guides, sont la base un des meilleurs outils que l'on puisse utiliser pour voir, comprendre et expliquer des problmes ergonomiques. Ils permettent aussi d'orienter des choix de conception vers des pistes ergonomiquement solides, sans pour autant sacrifier l'aspect esthtique d'un site. Ils contribuent viter les piges de la subjectivit et des gots personnels en donnant un cadre de travail neutre et efficace. Tel que soulign dans larticle de Scapin et Bastien [Bastin93], les critres ergonomiques ont trois caractristiques qui les distinguent d'autres activits ergonomiques et en font un outil de choix: 1. Ils sont bass sur une analyse de l'interface, activit plus rapide et moins dispendieuse que les tests d'utilisabilit; 2. Ils sont utilisables par des non-spcialistes du domaine de l'utilisabilit; 3. Ils sont suffisamment explicites pour permettre des mesures prcises, puis suffisamment standardiss pour donner des rsultats reproductibles. Voir le document original des auteurs publi chez lINRIA [Bastin93] 1.9.1Guidage Dfinition : Le Guidage est l'ensemble des moyens mis en uvre pour conseiller, orienter, informer, et conduire l'utilisateur lors de ses interactions avec l'ordinateur (messages, alarmes, labels, etc.), y compris dans ses aspects lexicaux. Quatre sous-critres participent au Guidage : Incitation, Groupement/Distinction entre Items, Feedback Immdiat et Lisibilit.
27
Lobjectif du guidage est de faciliter lutilisation du systme et son apprentissage. [Nogier01]
Justification : Un bon guidage facilite l'apprentissage et l'utilisation du systme en permettant l'utilisateur : de savoir, tout moment, o il se trouve dans une squence d'interactions, ou dans l'accomplissement d'une tche ; de connatre les actions permises ainsi que leurs consquences ; et d'obtenir de l'information supplmentaire (ventuellement sur demande). La facilit d'apprentissage et d'utilisation qui s'ensuivent conduisent de meilleures performances et occasionnent moins d'erreurs 1.9.2 Charge de travail Dfinition : Le critre Charge de Travail concerne l'ensemble des lments de l'interface qui ont un rle dans la rduction de la charge perceptive ou mnsique des utilisateurs et dans l'augmentation de l'efficacit du dialogue. Deux sous-critres participent au critre Charge de Travail : Brivet (qui inclut les critres Concision et Actions Minimales), et Densit Informationnelle. Justification : Plus la charge de travail est leve, plus grands sont les risques d'erreurs. De mme, moins l'utilisateur sera distrait par des informations non pertinentes, plus il pourra effectuer sa tche efficacement. Par ailleurs, plus les actions requises seront courtes, plus rapides seront les interactions. 1.9.3 contrle explicite Dfinition : Le critre Contrle Explicite concerne la fois la prise en compte par le systme des actions explicites des utilisateurs et le contrle qu'ont les utilisateurs sur le traitement de leurs actions. Deux sous-critres participent au Contrle Explicite : Actions Explicites et Contrle Utilisateur. Justification : Quand les entres des utilisateurs sont explicitement dfinies par eux-mmes et sous leur contrle, les ambiguts et les erreurs sont limites. De plus, le contrle qu'ont les utilisateurs sur le dialogue est un facteur d'acceptation du systme.
28
1.9.4 Adaptabilit Dfinition : L'adaptabilit d'un systme concerne sa capacit ragir selon le contexte, et selon les besoins et prfrences des utilisateurs. Deux sous-critres participent au critre Adaptabilit : Flexibilit et Prise en Compte de l'Exprience de l'Utilisateur. Justification : Plus les faons d'effectuer une mme tche sont diverses, plus les chances que l'utilisateur puisse choisir et matriser l'une d'entre elles, au cours de ses apprentissages, sont importantes. Il faut donc fournir l'utilisateur des procdures, options, et commandes diffrentes leur permettant d'atteindre un mme objectif. Par ailleurs, une interface ne peut convenir la fois tous ses utilisateurs potentiels. Pour qu'elle n'ait pas d'effets ngatifs sur l'utilisateur, cette interface doit, selon les contextes, s'adapter l'utilisateur. 1.9.5 Gestion des erreurs Dfinition : Le critre Gestion des Erreurs concerne tous les moyens permettant d'une part d'viter ou de rduire les erreurs, et d'autre part de les corriger lorsqu'elles surviennent. Les erreurs sont ici considres comme des saisies de donnes incorrectes, des saisies dans des formats inadquats, des saisies de commandes avec une syntaxe incorrecte, etc. Justification : Les interruptions provoques par les erreurs ont des consquences ngatives sur l'activit des utilisateurs. De manire gnrale, elles rallongent les transactions et perturbent la planification. Plus les erreurs sont limites, moins il y a d'interruptions au cours de la ralisation d'une tche et meilleure est la performance. 1.9.6 Homognit/Cohrence Dfinition : Le critre Homognit/Cohrence se rfre la faon avec laquelle les choix de conception de l'interface (codes, dnominations, formats, procdures, etc.) sont conservs pour des contextes identiques, et sont diffrents pour des contextes diffrents. Justification : Les procdures, labels, commandes, etc., sont d'autant mieux reconnus, localiss et utiliss, que leur format, localisation, ou syntaxe sont stables d'un cran l'autre, d'une session l'autre. Dans ces conditions le systme est davantage prvisible et les apprentissages plus gnralisables; les erreurs sont rduites. Le manque d'homognit peut augmenter considrablement le temps de recherche.
29
Le manque d'homognit est aussi une raison importante du refus d'utilisation. 1.9.7 Signifiance des codes et dnominations Dfinition : Le critre Signifiance des Codes et Dnominations concerne l'adquation entre l'objet ou l'information affiche ou entre, et son rfrent. Des codes et dnominations "signifiants" disposent d'une relation smantique forte avec leur rfrent. Justification : Lorsque le codage est signifiant, le rappel et la reconnaissance sont meilleurs. De plus, des codes et dnominations non significatifs pour les utilisateurs peuvent leur suggrer des oprations inappropries et ainsi conduire des erreurs. 1.9.8 Compatibilit Dfinition : Le critre Compatibilit se rfre l'accord pouvant exister entre les caractristiques des utilisateurs (mmoire, perceptions, habitudes, comptences, ge, attentes, etc.) et des tches, d'une part, et l'organisation des sorties, des entres et du dialogue d'une application donne, d'autre part. De plus, la Compatibilit concerne galement le degr de similitude entre divers environnements ou applications. Justification : Le transfert d'information d'un contexte un autre est d'autant plus rapide et efficace que le volume d'information recoder par l'utilisateur est rduit. L'efficacit est accrue lorsque : les procdures ncessaires l'accomplissement de la tche sont compatibles avec les caractristiques psychologiques des utilisateurs ; les procdures et les tches sont organises de manire respecter les attentes ou les habitudes des utilisateurs ; les traductions, les transpositions, les interprtations ou rfrences la documentation sont minimises. Conclusion Le dveloppement web constitue un domaine en expansion, les entreprises, les particuliers tout le monde est concern. En parallle, les technologies voluent vers des modles facilitant visiblement la tche des dveloppeurs web, des solutions dintgration et de conception darchitectures web sont proposes pour acclrer le processus de dveloppement. Ce chapitre nous a prsent quelques aspects de ce domaine. Nous nous sommes focaliss sur le cot fonctionnel pour permettre une appropriation avec le thme de ce mmoire savoir le rapprochement des mthodes de conception des applications web afin de proposer des solutions fonctionnellement exploitables.
30
2
Technologie XML
2.1 Introduction XML (Extensible Markup Language ou Langage Extensible de Balisage) drive d'un langage dvelopp dans les annes 80, le SGML (Standard Generalized Markup Language) Ce langage tait complexe apprendre et utiliser quotidiennement, En particulier, il tait inadapt l'criture de documents pour Internet. En pratique XML tente de se servir des principes de simplicit du HTML et de la souplesse SGML. XML a t dvelopp par un groupe de travail (GT) XML (XML Working Group) (initialement connu sous le nom de comit d'examen ditorial SGML [SGML Editorial Review Board]) constitu sous les auspices du Consortium du World Wide Web (W3C) en 1996. Le GT tait prsid par Jon Bosak de Sun Microsystems avec la participation active d'un groupe d'intrt XML [XML Special Interest Group] (auparavant connu sous le nom de groupe de travail de SGML [SGML Working Group]) galement organis par le W3C.
XML est considr comme simplification du SGML, car il ne prsente que 35 pages de spcification, dans sa 1re version, contre 155 pages pour SGML.
Formellement, on peut dire que XML est un sous-ensemble du SGML(ISO 8879). Qui dit sous-ensemble dit ncessairement moins de fonctionnalits. [W3C]
HTML a permis la mise en place rapide du Web, le plus important systme d'information jamais conu.
31
La technologie XML, depuis son apparition, a connu un succs sans prcdent, ceci est d sa crdibilit et sa subordination au monde rel, effectivement XML rduit le foss entre la ralit et le support informatique. Chaque lment de la nature est englob dans un autre, en partant du plus grand jusquau plus petit, cest toujours le mme principe et chaque niveau se rserve le contrle de ses descendants et se distingue par certaines proprits. XML est tout simplement une manire, bien rflchie, de prsenter cette vue le lunivers. Une des caractristiques, les plus importantes, du XML est que la mise en forme du contenu est totalement spare des donnes. Cela permet de sparer compltement l'information (le contenu) de son apparence (prsentation), et donc de fournir plusieurs types de sortie pour un mme fichier de donnes, en fonction de l'utilisateur ou de l'application demandeuse (tableau, graphique, image, animation multimdia, fichier HTML, fichier PDF...) (figure 2.1)
Figure 2.1 Sparation des donnes et de la prsentation avec XML
Feuille XML --XML-----
Prsentation XSL/CSS
---Prsentation1 ---
Rsultat PDF
DTD
------
+ +
---Prsentation2 ---
Rsultat HTML
la diffrence d'HTML, mais comme SGML, XML n'a pas de balise prdfinies : celles-ci sont fixes par l'application. Les balises sont donc extensibles, c'est--dire que l'on peut toujours ajouter des balises; elles doivent tre correctement enchanes, avec une balise de dbut et une balise de fin, comme des parenthses. En rsum, les balises permettent de composer les lments des documents. Les lments peuvent tre imbriqus autant qu'on le veut. Un document est simplement une suite d'lments correctement imbriqus prcde d'une ligne d'en-tte. XML s'appuie donc sur un modle d'change par lments baliss. Un document XML est fondamentalement de type texte, par opposition d'autres structures informatiques qui peuvent tre de type binaire (programmes excutables, base de donnes) Un simple diteur de texte est donc capable de crer, d'ouvrir ou de modifier un document XML stock sur disque. Mais un document XML n'existe pas uniquement sous forme de fichier. Il peut exister aussi temporairement en mmoire comme format de transfert de donnes entre deux programmes ou comme requte html POST. 2.2 Pourquoi utiliser XML ? Beaucoup de dveloppements tournent aujourd'hui autour du web, des assistants de poche, des WAP et autres, il devenait ncessaire de dfinir une norme universelle de description des donnes, quelque soit la plate-forme cible. XML
32
rpond cette exigence, en thorie du moins, car le phnomne a encore du chemin parcourir sur la voie de la standardisation. L'intrt d'XML rside dans l'existence de bibliothques qui implmentent les API standards d'XML (DOM, SAX etc.) et ce sur de nombreuses plateformes. Mme une technologie propritaire comme Flash (de Macromdia) embarque un parseur XML. Du coup, il devient rellement intressant de concevoir ses paquets de donnes au format XML, lorsqu'elles doivent tre communiques un autre service ou systme. Les objectifs de conception de XML sont les suivants : XML devrait pouvoir tre utilis sans difficult sur Internet. XML devrait soutenir une grande varit d'applications. XML devra tre compatible avec SGML. Il devrait tre facile d'crire des programmes traitant les documents XML. Le nombre d'options dans XML doit tre rduit au minimum, idalement aucune. 6. Les documents XML devraient tre lisibles par l'homme et raisonnablement clairs. 7. La conception de XML devrait tre prpare rapidement. 8. La conception de XML sera formelle et concise. 9. Il devrait tre facile de crer des documents XML. 10. La concision dans le balisage de XML est de peu d'importance. 2.3 Structure dun document XML Chaque document XML a une structure logique et une structure physique. Physiquement, le document se compose d'units appeles entits. Une entit peut appeler d'autres entits pour causer leur inclusion dans le document. Un document commence la racine ou entit document. Logiquement, le document se compose de dclarations, d'lments, de commentaires, d'appels de caractre et d'instructions de traitement, qui sont indiqus dans le document par du balisage explicite. Les structures logiques et physiques doivent s'imbriquer correctement, tel que prcis dans les spcifications [SpecXML] 2.3.1 Les composantes des documents XML On peut distinguer trois parties dans un document XML bien form :
1. Le prologue : permet d'indiquer la version de la norme XML utilise pour
1. 2. 3. 4. 5.
crer le document (cette indication est obligatoire partir de la version XML 1.1) ainsi que le jeu de caractres (encoding) utilis dans le document (lment facultatif) Exemple de prologue : <?xml version="1.0" encoding="ISO-8859-1"?>
2. La dclaration de type de document XML : contient ou dsigne des
dclarations de balisage qui fournissent la grammaire d'une classe de document. Cette grammaire est connue sous le nom de dfinition de type de document (DTD). La dclaration de type de document peut pointer vers un sous-ensemble externe (un type d'entit externe particulier), contenant des dclarations de balisage ou peut contenir directement les dclarations de balisage dans un sous-ensemble interne ou encore les deux. Le DTD d'un document consiste en la runion des deux sous-ensembles.]
33
3. L'arbre des lments XML : est constitu d'une hirarchie de balises comportant ventuellement des attributs. Un attribut est une paire cl valeur crit sous la forme Cle="Valeur", ainsi une balise affecte d'un attribut aura la syntaxe suivante : <element Attrib0="valeurAttribut1"> ValeurElement</element > 2.3.2 Unicode Unicode est un standard dfinissant un jeu de caractres. Sans entrer dans les dtails, mentionnons que l'Unicode de base permet le codage des caractres sur 2 octets, soit plus de 65 000 caractres diffrents. En plus des techniques de codage, Unicode dfinit un jeu de caractres qui en compte plusieurs dizaines de milliers (la version actuelle d'Unicode est la 5.00 et elle dfinit prs de 99 000 caractres). Tous les caractres des langues vivantes s'y retrouvent, de mme que certaines langues mortes et des symboles. Unicode ne rgle pas tous les problmes de multilinguisme, mais il constitue la meilleure solution que l'on connaisse actuellement. L'incorporation d'Unicode dans les applications client-serveur, les applications distribues et les sites Internet permet une simplification de l'architecture et une rduction des cots par rapport l'utilisation des systmes de codage traditionnels. Grce Unicode, un seul logiciel ou site Internet peut satisfaire simultanment et sans modification les demandes de plusieurs plateformes, langues et pays. Unicode permet aussi des logiciels de provenance varie d'changer des caractres sans pertes de donnes. [Unicode] 2.3.3 Unicode et XML
Par dfaut, les documents XML sont des documents texte dont le jeu de caractres est l'Unicode. En quelque sorte, il y a un seul jeu de caractres standard pour l'XML, et ce jeu de caractres est le plus important que l'on connaisse. D'autres jeux de caractres (comme l'ISO Latin 1) peuvent tre utiliss, mais une application XML n'est pas oblige de les supporter, et donc de les traiter correctement. Cette intime association entre Unicode et XML fait en sorte que les systmes d'information bass sur XML peuvent grer (en thorie) des documents ou des informations de toutes les langues, y compris dans les mmes documents.
2.3.4 La question de l'encodage Il existe plusieurs faons d'encoder des caractres Unicode dans des fichiers informatiques : UTF-8 : consiste encoder les caractres ASCII sur un octet, puis les autres caractres sur 2, 3 ou 4 octets, sans ambigut. Il s'agit d'un encodage intressant pour le franais, car la plupart des caractres pourront s'crire sur un seul octet (les lettres non accentues), alors que les autres sont dfinis de telle sorte qu'en UTF-8 ils sont cods sur deux octets seulement. UTF-16 consiste reprsenter tous les caractres sur deux octets. Cet encodage est plus efficace pour des documents en langues asiatiques par exemple, mais inefficace pour des documents en langues europennes. Les deux encodages Unicode (UTF-8 et UTF-16) sont ainsi les seuls encodages que la recommandation XML 1.0 impose tous les parseurs XML.
34
2.4 XML oppos HTML Pour comparer XML et HTML, les points les plus importants considrer sont les suivants : XML ne remplace pas HTML ; il en serait plutt un complment. XML et HTML poursuivent diffrents objectifs : HTML est conu pour afficher des donnes et s'attache plutt leur aspect, tandis que XML est conu pour dcrire les donnes et s'attache plutt leur nature. l'instar de HTML, XML ne fait rien. En effet, les balises XML servent dcrire la structure d'un lment tel qu'un bon de commande ; toutefois, ce bon de commande ne contient pas de code permettant de l'envoyer, de le traiter et de garantir qu'il sera rempli. D'autres gens doivent crire du code pour que toutes ces oprations soient effectues sur vos donnes au format XML. la diffrence de HTML, les balises XML sont dfinies par l'auteur d'un schma ou d'un document et sont illimites. l'inverse, les balises HTML sont prdfinies ; il n'est possible d'utiliser que les balises prises en charge par la norme HTML en vigueur.
2.4.1 Exemple de HTML/XML : Pour comprendre la philosophie de XML, rien de mieux qu'un petit exemple. Prenons pour ce faire une page numrant la bibliographie en langue franaise sur XML ( rapprocher des dizaines d'ouvrages existant en anglais sur le mme sujet). Voici comment une telle page pourrait se prsenter (avant interprtation par le logiciel de navigation) si elle tait code selon le langage actuel du Web, HTML :
<H2>Bibliographie XML</H2> <UL> <LI> JeanChristophe Bernadac et Franois Knab, <I> Construire une application XML</I>, Paris, Eyrolles,1999 </LI> <LI> Alain Michard, <I> XML, Langage et Applications</I>, Paris, Eyrolles, 1998 </LI> </UL> Rsultat dans un navigateur web :
35
Nous constatons dans cet exemple que les balises HTML fournissent des indications qui vont permettre au butineur de mettre en page (ou en cran) le texte qu'elles encadrent : <H2> et </H2> signalent un titre de niveau 2, <UL> et </UL> une liste non numrote, <LI> et </LI> un lment de cette liste. Voici ce que donnerait la mme page si elle tait code en XML :
<?xml version="1.0" encoding="ISO-8859-1" ?> <BIBLIO SUBJECT="XML"> <BOOK ISBN="9782212090819" LANG="fr" SUBJECT="applications"> <AUTHOR> <FIRSTNAME>Jean-Christophe</FIRSTNAME> <LASTNAME>Bernadac</LASTNAME> </AUTHOR> <AUTHOR> <FIRSTNAME>Franois</FIRSTNAME> <LASTNAME>Knab</LASTNAME> </AUTHOR> <TITLE>Construire une application XML</TITLE> <PUBLISHER> <NAME>Eyrolles</NAME> <PLACE>Paris</PLACE> </PUBLISHER> <DATEPUB>1999</DATEPUB> </BOOK> <BOOK ISBN="9782212090529" LANG="fr" SUBJECT="gnral"> <AUTHOR> <FIRSTNAME>Alain</FIRSTNAME> <LASTNAME>Michard</LASTNAME> </AUTHOR> <TITLE>XML, Langage et Applications</TITLE> <PUBLISHER> <NAME>Eyrolles</NAME> <PLACE>Paris</PLACE> </PUBLISHER> <DATEPUB>1998</DATEPUB> </BOOK> </BIBLIO>
Ici aucune des balises ne dcrit la prsentation finale. On remarque, en revanche, que maintenant les balises ont un sens et une hirarchie. Par exemple, l'lment "author" comprend le prnom (balise "firstname") et le nom (balise "lastname") de l'auteur. On remarque aussi que des informations supplmentaires (langue, sujet, n ISBN), ont pu tre ajoutes sous forme d'"attributs" situs l'intrieur mme des balises.
2.5 Les DTD ( Document Type Dfinition/Dfinition de Type de Document) XML tant un mtalangage, la dfinition de la structure attendu est ncessaire afin de sassurer de la cohrence des donnes manipules. La DTD dun document dcrit
36
lensemble des lments admissibles au sein du document (< !ELEMENT), ainsi que les attributs possibles pour chaque lment (< !ATTLIST). (voir la figure 2.2) DTD permet d'utiliser un fichier afin de vrifier qu'un document XML est conforme une syntaxe donne. La norme XML dfinit ainsi une dfinition de document type appele DTD (Document Type Definition), c'est--dire une grammaire permettant de vrifier la conformit du document XML. La norme XML n'impose pas l'utilisation d'une DTD pour un document XML, mais elle impose par contre le respect exact des rgles de base de la norme XML. Ainsi on parlera de : document valide pour un document XML comportant une DTD document bien form pour un document XML ne comportant pas de DTD mais rpondant aux rgles de base du XML.
Une DTD peut tre dfinie de 2 faons :

sous forme interne, c'est--dire en incluant la grammaire au sein mme du document. sous forme externe, soit en appelant un fichier contenant la grammaire partir d'un fichier local ou bien en y accdant par son URL. (figure 2.2)
Figure 2.2 Exemple de fichier XML avec sa DTD
annuaire.xml
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE annuaire SYSTEM "annuaire.dtd"> <annuaire> <personne profession =" profession_1"> <nom>nom_1</nom> <prenom>prenom_1</prenom> <email>prenom_1.nom_1@domaine_1.ext_1</email> </personne> <personne type=" profession_1"> <nom>nom_2</nom> <prenom>prenom_2</prenom> <email>prenom_2.nom_2@domaine_2.ext_2</email> </personne> </annuaire>
annuaire.dtd ( fichier DTD associ)

<?xml version="1.0" encoding="ISO-8859-1"?> <!ELEMENT annnuaire (personne*)> <!ELEMENT personne (nom,prenom,email+)> <!ATTLIST personne profession(profession_1|profession_2) profession_1"> <!ELEMENT nom (#PCDATA)> <!ELEMENT prenom (#PCDATA)> <!ELEMENT email (#PCDATA)>
37
Remarques: Pour chacun des lments, on dfini sa composition par <!ELEMENT nom_element (structure)> Pour chacun des attributs, on dfini nom_element nom_attribut (structure)> sa composition par <!ATTLIST
L'attribut profession est, ici, dfini comme tant un choix impos entre "profession_1", " profession_2", par dfaut on met profession_1. personne* signifie que dans un lment annuaire on peut trouver de 0 ou plusieurs lments de type personne. nom,prenom,email+ signifie que dans un lment personne on doit trouver une lment nom, un lment prenom et un ou plusieurs lment(s) email dans cet ordre. nom, prenom et email sont des lments qui peuvent contenir du texte, les contenus #PCDATA sont dits contenus mixtes
2.6 Les schmas XML Les dfinitions de type de document (DTD) ont rapidement laisses apparatre des carences dans le domaine des contraintes de structures et de donnes. L'universalit du langage XML requiert la cration d'un ensemble d'applications verticales allant de la dfinition des documents (langage de schma), en passant par leur structuration et composition (langage XML) et jusqu' leur prsentation l'utilisateur final (langage XSL). L'adoption d'un langage de dfinition des documents bas sur XML, tait donc invitable afin de conserver une homognit dans la sphre XML dj fort bien pourvue. [Laltruiste]
XML Schema est un langage de description de format de document XML permettant de dfinir la structure d'un document XML. Un schma XML est lui-mme un fichier XML Une instance d'un XML Schema est un peu l'quivalent d'une DTD
Les schmas XML sont des documents qui servent dfinir et valider le contenu et la structure des donnes XML, comme le schma de base de donnes dfinit et valide les tables, les colonnes et les types de donnes constituant une base de donnes. Un schma XML dfinit et dcrit certains types de donnes XML l'aide du langage de dfinition de schma XML (XSD, XML Schema Definition). Les lments du schma XML (lments, attributs, types et groupes) servent dfinir une structure et un contenu de donnes valides ainsi que des relations entre certains types de donnes XML. Les schmas XML peuvent galement fournir des valeurs par dfaut pour les attributs et les lments. Vous pouvez utiliser un schma XML pour garantir la cohrence de certains types de donnes XML que se partagent plusieurs applications et organisations. Un schma XML peut tre utilis comme un contrat rgissant l'change des donnes entre deux applications. Les organisations peuvent publier des schmas dcrivant le format du code XML gnr et utilis par leurs applications. D'autres organisations et applications souhaitant changer des donnes peuvent alors gnrer leurs applications partir de ces schmas de sorte que leurs messages XML soient compris.
38
Par exemple, un bon de commande en XML peut tre valid l'aide d'un schma XML avant d'tre envoy de l'acheteur au vendeur. Cette validation vrifie que tous les lments de donnes existent, qu'ils sont ordonns selon la squence adquate et que leur type de donnes est correct. Elle garantit ainsi que le destinataire du bon de commande sera en mesure d'interprter correctement les donnes lors de leur rception.[MSDN] Les schmas XML (xsd) sont une volution des DTD pour la validation des documents XML. Ils sont standardiss sous forme de recommandation du W3C (XML Schema 1.0) depuis mai 2000. Malgr quelques critiques pointant surtout la complexit des schmas. Ils tendent aujourdhui remplacer les DTD car ils permettent de dfinir des modles beaucoup plus complets. La dfinition dun schma XML se ralise par l'intermdiaire de plusieurs lments chargs de reprsenter l'arborescence et les informations d'un document XML. L'extensibilit des dfinitions des documents apporte par les schmas XML, facilite l'change, la fusion ou la rutilisation de donnes provenant d'une ou plusieurs sources. Effectivement, l'instar des documents XML, les schmas XML pourront dsormais se combiner en se fusionnant compltement ou partiellement afin de crer un modle de contenu composite. D'ailleurs, plusieurs schmas peuvent tre rfrencs l'intrieur d'un unique document XML et donc valider la structure et le contenu de ce dernier. La gnration dynamique de documents XML et du modle de contenu associ, devient alors beaucoup plus commode. Evidemment, cela demande une certaine compatibilit entre les schmas susceptibles d'tre combins. Grce cette normalisation, des schmas XML provenant d'un fournisseur pourront tre fusionns sans peines avec ceux d'un distributeur dans le but de crer un modle de contenu spcifique destin la validation de documents XML gnrs la vole. 2.6.1 langages de schma
Les principaux langages de schma sont :
W3C XML Schema est le choix naturel pour publication dans les rpertoires de schmas et lorsque des informations de typage doivent tre communiques des applications. Relax NG est plus simple matriser (et donc gnrer). Il dispose d'un meilleur pouvoir expressif que W3C XML Schema et permet d'exprimer plus de contraintes. Pour des fonctions de validations, c'est donc un langage qui permettra de coller au plus prs aux documents dcrits. Schematron est l'outil de finition qui peut tester ce qui ne peut pas tre test avec les autres langages. Il est gnralement utilis en complment de W3C XML Schema ou Relax NG (on n'utilise pas un outil de finition pour faire le travail de dgrossissage!). Dans la mesure o Relax NG dcrit mieux les documents que W3C XML Schema, il y aura frquemment plus faire avec Schematron lorsqu'il est associ W3C XML Schema que lorsqu'il est associ Relax NG. Il ne faut pas oublier les DTDs qui sont un outil privilgi pour toute une gnration de logiciels.
A ct de ces principaux langages, il existe d'autres langages moins connus qui peuvent avoir leur rle jouer.
39
2.7 DTD ou XML-Schema ? Bob DuCharme crit : Beaucoup de dveloppeurs XML ne sont pas satisfaits de la syntaxe des dclarations de balises dcrites dans les spcifications, pour deux raisons. Premirement, ils pensent que si les documents XML sont si bons pour dcrire la structure des informations, alors la description d'une structure de type de document (ses schmas ) devrait tre dans un document XML et non crite avec sa propre syntaxe. En plus d'tre plus consistent, ceci permettrait plus facilement d'diter et manipuler le schma avec des outils habituels de manipulation de documents. Deuximement, ils pensent que la notation traditionnelle des DTD ne donne pas aux dfinisseurs de schmas la puissance ncessaire pour imposer assez de contrainte sur les donnes -- par exemple, la possibilit de dire qu'un certain type lment doit toujours avoir une valeur positive, qu'il ne peut pas tre vide ou qu'il peut faire partie d'une liste au choix. Ceci faciliterait le dveloppement de logiciels utilisant ces donnes car le dveloppeur aurait moins de code de dtection d'erreurs crire. [DUCHARME01] Un document XML se conforme sa DTD, certes, mais une DTD ne se conforme pas une DTD (puisque qu'une DTD dcrit du XML mais que la DTD n'est pas ellemme dcrite en XML). Du coup, impossible de passer la mta-DTD. Solution : le XML-Schema, il dcrit du XML et se dcrit lui mme en XML; la rflexion devient donc possible. On peu dsormais utiliser un mta-Schma. Le XML devient ainsi un espace technique au mme titre que les modles et les langages. Les schmas XML prsentent les avantages suivants par rapport au DTD : Ils utilisent la syntaxe XML ; vous n'avez donc pas besoin d'apprendre une nouvelle syntaxe pour dfinir la structure de vos donnes. Ils prennent en charge des types rutilisables et vous permettent de crer de nouveaux types par le biais de l'hritage. Ils vous permettent de grouper des lments en vue de contrler la rcurrence des lments et des attributs.
2.8 Feuilles de style Comme il a t dit, la philosophie d'XML consiste bien sparer les donnes/documents (le fichier XML proprement dit) des traitements/prsentations. Un document donn sera, lors de sa cration, balis uniquement en fonction de son contenu (sa smantique) intrinsque et indpendamment de sa restitution future (papier, cran, terminal Braille, synthse vocale ou autre) comme d'ailleurs de tout autre traitement automatique qui pourra lui tre appliqu. XML/XSL apporte laspect multi-reprsentation de document Cette indpendance par rapport aux applications qui vont le traiter en gnral, et par rapport celles charges de sa restitution en particulier, va lui confrer : Une trs grande interoprabilit : le mme document XML va pouvoir tre affich sur le Web et/ou produit en version papier, alimenter un SGBD, etc. Une grande durabilit/rutilisation : le document ne deviendra pas obsolte avec l'volution des techniques informatiques ; il pourra sans difficult tre incorpor, en tout ou partie, dans des documents de nature trs diffrente, tre trait par des applications non prvues.
40
2.8.1 XSL( Extensible stylesheet language ) XSL est le langage de description de feuilles de style du W3C associ XML. A partir de fichiers de donnes XML, arbitrairement structurs, les auteurs utilisent une feuille de style XSL pour dterminer la faon dont ce contenu structur devrait tre reprsent ; c'est--dire la faon dont le contenu source devrait tre styl, dispos et pagin pour un support de prsentation donn, comme par exemple dans une fentre de navigateur web, un appareil portatif ou un jeu de pages physiques dans un catalogue, un rapport. [SpecXMLT]. Une feuille de style XSL est un fichier XML qui dcrit comment doivent tre prsents (c'est--dire affichs, imprims, pels) les documents XML. La spcification est divise en trois parties : XSLT, le langage de transformation XPath, le langage de navigation dans un document XML XSL-FO, le vocabulaire XML de mise en forme
2.8.1.1 Le traitement d'une feuille de style la diffrence de HTML, les noms des lments en XML n'ont aucune signification de prsentation intrinsque. En l'absence d'une feuille de style, un processeur n'aurait aucun moyen sa disposition pour rendre le contenu d'un document XML, autrement que sous la forme d'une chane indiffrencie de caractres. XSL fournit un modle complet et un vocabulaire pour l'criture d'une telle feuille de style avec une syntaxe XML. XSL est bti sur un travail prcdent effectu sur les feuilles de style en cascade (CSS) et le langage de smantique et de spcification du style du document (DSSSL). Un processeur de feuille de style XSL reoit un document, ou des donnes, XML avec une feuille de style XSL et produit une prsentation de cette source XML de la manire voulue par l'auteur de la feuille de style. Ce procd de prsentation revt deux aspects : premirement, la construction d'un arbre labor partir de celui de la source XML et, deuximement, l'interprtation de cet arbre rsultant pour produire les sorties adaptes pour la reprsentation voulue. On appelle la premire opration transformation de l'arbre et la seconde mise en forme. L'opration de mise en forme est accomplie par un formateur. Ce formateur peut simplement tre le moteur de rendu d'un navigateur. La transformation de l'arbre autorise une diffrenciation significative de la structure de l'arbre rsultant par rapport celui de la source. Par exemple, on pourrait ajouter une table des matires qui agirait comme un filtre de slection sur un document source original ou on pourrait rarranger les donnes de la source en une prsentation tabulaire ordonne. Lors de l'laboration de l'arbre rsultant, l'opration de transformation de l'arbre inclut galement les instructions ncessaires pour la propre mise en forme de celui-ci. La mise en forme est active par l'incorporation d'une smantique de formatage dans l'arbre rsultant. Cette smantique de formatage s'expriment sous la forme d'un catalogue de classes d'objets de mise en forme. Les nuds de l'arbre rsultant sont des objets de mise en forme. Les classes d'objets de mise en forme
41
reprsentent des abstractions typographiques comme une page, un paragraphe, une table et ainsi de suite. Un contrle plus fin de la reprsentation de ces abstractions est ralis par un jeu de proprits de mise en forme, ainsi celles rgissant les indentations, les espacements entre les mots et les lettres. En XSL, les classes des objets de mise en forme et les proprits de mise en forme fournissent un vocabulaire pour exprimer une prsentation souhaite. Le modle de traitement XSL n'est que conceptuel. On ne requiert pas d'une implmentation qu'elle reproduise ces oprations de manire distincte. En outre, les implmentations sont libres de traiter un document source leur faon, pourvu que le rsultat de ce traitement soit le mme que celui qui aurait t obtenu selon le modle de traitement conceptuel de XSL. La figure 2.3 montre le modle conceptuel en dtails.
Figure 2.3 Transformation avec XSL
La transformation de l'arbre construit l'arbre rsultant. En XSL, on appelle ce dernier l'arbre des lments et des attributs, avec des objets principalement dans l'espace de nommage de l'objet de mise en forme . Dans cet arbre, un objet de mise en forme est reprsent comme un lment XML dont les proprits se prsentent sous la forme d'un jeu de paires XML attribut-valeur. Le contenu d'un objet de mise en forme est tout simplement le contenu de l'lment XML. La transformation de l'arbre est dfinie par la recommandation XSLT (figure 2.3) La mise en forme est une interprtation de l'arbre rsultant, dans sa forme d'arbre des objets de mise en forme, pour la production de la prsentation souhaite par l'auteur de la feuille de style, partir de laquelle l'arbre des lments et des attributs XML dans l'espace de nommage fo a t construit. XSL a t dvelopp pour donner aux auteurs un contrle des fonctions ncessaires autant pour des documents pagins que pour fournir une structure quivalente aux cadres pour la navigation sur le web. Pour obtenir ce contrle, XSL a tendu le jeu des objets et des proprits de mise en forme. De plus, la slection des composants d'une source XML, ceux pouvant recevoir un style (lments, attributs, nuds de texte, commentaires et instructions de traitement), se base sur XSLT et XPath, ce qui offre l'utilisateur un mcanisme de slection trs puissant.
42
Une feuille de style XSL est appele partir d'un document XML par une "processing instruction" (PI) selon l'exemple suivant :
<?xml-stylesheet href="biblio.xsl" type="text/xsl" ?>
2.8.1 CSS feuilles de style en cascade CSS est un Langage utilis pour dcrire la prsentation d'un document structur crit en HTML ou en XML. CSS est utilis pour dfinir les couleurs, les polices, et d'autres caractristiques lies la prsentation d'un document. L'objectif est de bien sparer la structure et la prsentation du document. CSS t originellement dfinit, et optimis, pour tre utilis avec le langage HTML. Les travaux les plus rcents sur cette norme visent l'ouvrir tout document dont la structure est base sur un jeu d'lments quel qu'il soit (soit n'importe quelle application xml) A la diffrence de XSL, CSS est trs limit en terme de possibilits de traitement et de transformation sur les documents XML. Une feuille de style CSS est appele partir d'un document XML par une "processing instruction" (PI) selon l'exemple suivant :
<?xml-stylesheet href="biblio.css" type="text/css" ?>
2.9 Les rgles du jeu XML Les informations doivent tre : Soit encadres par des balises ouvrantes(ex. <LIVRE>) et fermantes (ex. </LIVRE>) contrairement HTML o ces dernires n'taient pas toujours obligatoires. On parle alors d'lments. Les lments doivent s'imbriquer proprement les uns dans les autres : aucun chevauchement n'est autoris. Les lments vides sont permis, selon le format <ELEMENTVIDE/>. Soit incluses l'intrieur mme des balises : on parle alors d'attributs. Exemple : <LIVRE SUJET="XML">. Ici l'attribut SUJET de l'lment LIVRE a la valeur "XML" . En XML, contrairement HTML, les valeurs des entits doivent toujours tre encadres par des guillemets (simples ou doubles). Soit encore dfinies sous forme d'entits. Les entits sont des abrviations. Par ex; si "Extensible Markup Language" est dclar comme une entit associe la notation "xml"; cette chane de caractres pourra tre abrge en "&xml;" dans tout le fichier XML. Une entit peut aussi reprsenter un fichier XML externe tout entier. Ainsi un mme fichier XML (par exemple notre bibliographie) pourra tre utilis par plusieurs pages XML diffrentes (par exemple une page spcifiquement consacre XSL pourra prsenter la fin la bibliographie spcifique d'XSL -quand elle existera- extraite automatiquement de notre bibliographie XML)
43
La DTD (Dfinition de Type de Document). La structure arborescente du document XML (intitul des balises, imbrications des balises, caractre obligatoire ou facultatif des balises et de leur ordre de succession) peut tre dclare formellement dans le corps du document XML ou dans un fichier part. Cette dclaration s'appelle une Dfinition de Type de Document (DTD). Elle s'effectue selon un formalisme particulier dfini luiaussi dans la spcification XML. En XML cette dclaration est facultative, ce qui donne une grande souplesse aux dveloppeurs. On n'crira donc une DTD que lorsqu'il y aura vraiment intrt le faire, par exemple pour contraindre la saisie/mise jour du document XML. Lorsqu'un document XML possde une DTD associe et la respecte, on dit qu'il est valide. Lorsqu'il respecte seulement les rgles de la grammaire XML (balises fermes, correctement imbriques) on dit qu'il est bien form.
La spcification XML se trouve sur le site du W3C [SpecXML]. 2.10 Les espaces de nommage (namespaces) Les namespaces, ou "espaces de nommage", sont un mcanisme destin lever les ambiguts ventuelles des intituls de balise. Par exemple "titre" peut aussi bien dsigner le titre d'un ouvrage que celui d'une personne. Pour lever ces ambiguts, le mcanisme des namespaces consiste utiliser des prfixes, par ex. "perso:titre" et "biblio:titre". Ces prfixes doivent tre dclars comme associs une URL qui peut tre fictive, mais qui le plus souvent fera rfrence l'organisme garant du vocabulaire en question. Les espaces de nommage XML visent viter les conflits de noms et les ambivalences dans des documents XML contenant des lments d'une ou de plusieurs dfinitions de type de document (DTD). En les rattachant une Uniform Resource Identifier (URI) des noms potentiellement ambivalents sont relis un espace de nommage et sont ainsi qualifis. Un espace de nommage n'est ni plus ni moins qu'une srie de noms de types d'lments et d'attributs pouvant tre identifis de faon univoque par le biais d'une URI. Les espaces de nommage utiliss dans un document doivent tre dclars dans le document XML. cette fin, l'URI de l'espace de nommage est affecte ce qu'on appelle un prfixe d'espace de nommage. Un lment ou attribut d'un espace de nommage est alors qualifi par le prfixe d'espace de nommage. Le prfixe d'espace de nommage fait alors office d'abrviation de l'URI. 2.10.1 Problmatique: espaces de nommage et validation L'URI de l'espace de nommage ne doit pas forcment pointer sur une adresse existant rellement sur la toile, en particulier sur une DTD affecte l'espace de nommage. La dclaration d'espace de nommage n'a pas la moindre fonction de lien et l'URI est en fin de compte un identificateur univoque formel pour l'espace de nommage. En dclarant l'espace de nommage, aucune liaison n'est tablie entre un espace de nommage et les dclarations pour les lments et les attributs de l'espace de nommage. Plus gnralement: Le concept d'espace de nommage et le concept de validation de XML sont bien distincts. Ce qui signifie concrtement qu'il faut veiller certaines choses pour crer des documents XML valides utilisant des espaces de nommage.
44
2.11 XML et les bases de donnes XML devient le standard d'change des systmes d'information ouverts au-dessus du protocole HTTP. Il devient donc ncessaire d'une part, de stocker les documents XML reus dans une base de donnes et d'autre part, de publier les donnes des bases en XML directement sur le Web. XML est issu de SGML, le langage de la gestion de documents. Il pourrait donc tre naturel d'utiliser un systme documentaire pour faire persister et interroger des documents XML. Mais les bases de donnes intgrent de plus en plus souvent des documents, par exemple sous forme de colonnes dans les systmes objet-relationnel. Les bases e donnes XML se situent donc la croise des chemins des systmes documentaires et des bases de donnes. Stocker des documents XML directement en bases de donnes ou produire des documents XML directement depuis des bases de donnes prsentent de nombreux avantages, outre celui de grer la persistance, le partage et la scurit des documents XML : Pouvoir saisir directement les donnes en base depuis des formulaires XML (XForms du W3C est prvu pour cela). Autoriser la publication directe des donnes sur le Web suite une requte produisant le document XML dsir, sans manipulation textuelle, simplement en ajoutant une feuille de style pour la prsentation des rsultats. Pouvoir changer des donnes avec des partenaires commerciaux, par exemple des commandes, des factures, etc., en suivant des DTD ou des schmas conventionnels , et ceci directement entre systmes d'information d'entreprises. Permettre le dveloppement de systme d'interrogation multi-bases, vritables moteurs de recherche de la mmoire de l'entreprise tendue.
Depuis 1998, l'ide de bases de donnes XML a merg. Deux approches se sont opposes : l'approche middleware consistant utiliser un SGBD relationnel ou objet et dcomposer le document XML en lments simples stocks dans des tables et l' approche native consistant garder le document entier en base et lui joindre des acclrateurs d'accs rapide (index). La premire approche prsente l'avantage de permettre une intgration douce de XML au cur du systme d'information existant par un mapping XML-relationnel appropri. Elle peut plus ou moins profiter des extensions objet des systmes relationnels. La seconde approche ncessite au minimum le dveloppement d'un nouveau type de donnes avec fonctions d'accs spcifiques et au plus d'un SGBD complet orient vers la description et la manipulation de documents XML. [Gardarin02] Ces deux approches, qui se subdivisent en de multiples sous-classes, ncessitent de toute manire de choisir un langage de description de donnes et langage de manipulation pour les donnes XML. La description s'appuie en gnral sur les schmas XML. La manipulation peut s'effectuer par des extensions de SQL3, la version objet-tionnel normalise en 1999, avec des fonctions pour XML; c'est ainsi construit le langage de requte SQL/XML, propos en particulier par Oracle. Cependant, SQL tant plutt orient vers les tables et quelque peu limit pour les donnes semi-structures, le W3C a lanc un groupe de travail afin de normaliser un langage de requtes pour XML. Celui-ci s'appelle Xquery. Aujourdhui arriv maturit.
45
2.11.1 XML est-il une base de donnes ? Un document XML peut tre considr comme une base de donns uniquement au sens le plus strict de lexpression. savoir, une collection de donnes. XML en cela nest gure diffrent des autres fichiers, car aprs tout, tous les fichiers contiennent dune certaine manire des donnes. En tant que format de "base de donnes", XML prsente cependant certains avantages. Il est par exemple auto-descriptif car les balises dcrivent la structure et le type des noms des donnes ; il est portable puisque cod en Unicode, et il peut dcrire les donnes sous la forme dun arbre ou dun graphe. Il prsente aussi quelques inconvnients. Il est verbeux par exemple, et laccs aux donnes est lent cause de lanalyse [parsing] et de la conversion du texte. Une question plus intressante consiste se demander si XML et les technologies qui lui sont associes constituent une "base de donnes" dans un sens plus large, cest--dire au sens dun systme de gestion de base de donnes (SGBD). La rponse cette question est : XML est une sorte de SGBD . Dans le sens dune rponse positive, XML fournit plusieurs des caractristiques que lon retrouve dans les bases de donnes : le stockage (les documents XML), les schmas (DTD, XML Schemas, RELAX NG, etc.), des langages de requte (XQuery, XPath, XQL, XML-QL, QUILT, etc.), des interfaces de programmation (SAX, DOM, JDOM), et ainsi de suite. Dans le sens dune rponse ngative, de nombreuses caractristiques prsentes dans les bases de donnes lui font dfaut : un stockage efficace, les index, la scurit, les transactions et lintgrit des donnes, laccs multiutilisateur, les dclencheurs [triggers], les requtes sur plusieurs documents, etc. Ainsi, bien quil soit possible dutiliser un ou plusieurs documents XML comme une base de donnes dans les environnements qui prsentent une faible quantit de donnes, qui comportent peu dutilisateurs, et qui se satisfont de performances modestes, cela chouera dans la plupart des environnements de production qui disposent de nombreux utilisateurs, requirent une stricte intgrit des donnes et ont besoin de bonnes performances. Un fichier .ini -- cest--dire un fichier contenant les informations de configuration dune application -- constitue un bon exemple de type de "base de donnes" pour lequel un document XML est appropri. Il est bien plus facile dinventer un petit langage XML et dcrire une application SAX permettant dinterprter ce langage que dcrire un analyseur de fichier au format texte dlimit par des virgules. De plus, XML permet dimbriquer les entres, ce quil est difficile de raliser avec des fichiers au format texte dlimit par des virgules. Il ne sagit pourtant pas vraiment dune base de donnes puisque le document XML est lu et crit linairement au dbut et la fin de lapplication. Il existe dautres exemples plus sophistiqus de collections de donnes pour lesquelles un document XML pourrait tre utilis en tant que base de donne: les listes de contacts personnels (noms, numros de tlphone, adresses, etc.), les liens favoris dans un navigateur Cependant, tant donn le cot rduit et la facilit dutilisation des bases de donnes telles que Access, il semble, mme pour les cas voqus, quil existe peu de raisons dutiliser un document XML en tant que base de donnes. Le seul vritable avantage dun document XML est sa portabilit, et dailleurs, cest un avantage moins crucial quil ny parat quand on considre le grand nombre doutils disponibles pour srialiser sous forme XML une base de donnes. [Bourret03]
46
2.12 Rsum Pour finir avec XML, ce rsum en 10 points prsente les concepts de base et donne un aperu global des importantes applications drives d'XML. 1. XML est une mthode pour structurer des donnes On entend par " donnes structures " des lments tels que des feuilles de calcul, des carnets d'adresses, des paramtres de configuration, des transactions financires, des dessins techniques, etc. XML est un ensemble de rgles, de lignes directrices, de conventions pour la conception de formats texte permettant de structurer des donnes. XML facilite la ralisation de fichiers qui ne soient pas ambigus, et qui vitent les piges courants, tels que la non-extensibilit, l'absence de prise en charge de l'internationalisation/localisation et la dpendance par rapport certaines plates-formes. 2. XML ressemble un peu HTML Comme HTML, XML utilise des balises (des mots encadrs par '<' et '>') et des attributs (de la forme non = valeur ). Mais alors que HTML dfinit la signification de chaque balise et de chaque attribut (et souvent la manire dont le texte qu'ils encadrent apparatra dans un navigateur), XML utilise les balises seulement pour dlimiter les lments de donnes et laisse l'entire interprtation des donnes l'application qui les lit. En d'autres termes, si vous voyez "<p>" dans un fichier XML, ne supposez pas qu'il s'agit d'un paragraphe. Selon le contexte, cela peut tre un prix, un paramtre, une personne, un p ... (d'ailleurs, qui a dit qu'il devait s'agir d'un mot commenant par "p" ?). 3. XML est du texte, mais il n'est pas destin tre lu Les programmes qui produisent de telles donnes les stockent souvent sur disque, dans un format binaire ou un format texte. Ce dernier format vous permet, si ncessaire, de consulter les donnes sans le programme qui les a produites. Les fichiers XML sont des fichiers texte, mais ils sont encore moins destins tre lus par des individus que les fichiers HTML. Ce sont des fichiers texte, car ils permettent des experts (tels que les programmeurs) de dboguer plus facilement des applications, et en cas d'urgence, d'utiliser un simple diteur de texte pour corriger un fichier XML endommag. Mais les rgles des fichiers XML sont beaucoup plus strictes que celles des fichiers HTML. Une balise oublie ou un attribut sans guillemets rendent le fichier inutilisable, alors qu'avec HTML, de telles pratiques sont souvent explicitement permises, ou au moins tolres. Les spcifications officielles de XML indiquent que les applications ne sont pas autorises essayer de deviner ce qu'a voulu faire le crateur d'un fichier XML endommag ; si le fichier est endommag, une application doit s'arrter immdiatement et mettre une erreur. 4. XML est bavard, mais ce n'est pas un problme Comme XML est un format texte et qu'il utilise des balises pour dlimiter les donnes, les fichiers XML sont presque toujours d'une taille plus importante que les formats binaires quivalents. Il s'agit l d'une dcision prise en toute conscience par les dveloppeurs de XML. Les avantages d'un format texte sont vidents (voir le point 3 ci-dessus), et ses inconvnients peuvent tre gnralement compenss un autre niveau. L'espace disque n'est plus aussi coteux qu'auparavant, et les programmes tels que winzip compressent trs bien et trs rapidement les fichiers.
47
De plus, les protocoles de communication tels que les protocoles de modem et HTTP/1.1 (le protocole de base du Web) peuvent compresser des donnes la vole, ce qui conomise de la bande passante aussi efficacement qu'un format binaire. 5. XML est une famille de technologies Il existe XML 1.0, la spcification qui dfinit ce que sont les "balises" et les "attributs", mais autour de cette spcification, un nombre de plus en plus important de modules facultatifs fournissant des ensembles de balises et d'attributs ou des lignes directrices pour des tches particulires ont t dfinis. C'est, par exemple, le cas de Xlink, qui dcrit une mthode standard pour ajouter des liens hypertextes un fichier XML. XPointer et XFragments sont des syntaxes pour pointer sur des parties d'un document XML. Un XPointer ressemble un URL, mais au lieu de pointer sur des documents du Web, il pointe sur des lments de donnes au sein d'un fichier XML. CSS, le langage des feuilles de style, s'applique XML de la mme faon qu' HTML. XSL est le langage volu pour la dfinition de feuilles de style. Il est bas sur XSLT, un langage de transformation utilis pour rorganiser, ajouter ou supprimer des balises et des attributs. Le DOM est un ensemble d'appels de fonctions standard pour manipuler des fichiers XML (et HTML) partir d'un langage de programmation. Les Schmas XML 1 et 2 aident les dveloppeurs dfinir prcisment leurs propres formats bass sur XML. Plusieurs autres modules et outils sont disponibles ou en cours de dveloppement. Consultez rgulirement la page des rapports techniques du W3C. 6. XML est nouveau, mais pas si nouveau que a Le dveloppement de XML a commenc en 1996, et XML est une norme du W3C depuis fvrier 1998, ce qui peut laisser supposer qu'il s'agit d'une technologie plutt immature. En fait, il ne s'agit pas d'une technologie trs nouvelle. Avant XML, il existait SGML, dvelopp au dbut des annes 80, devenu norme ISO depuis 1986 et largement utilis dans des projets de documentation de taille importante. Et il existait bien sr HTML, dont le dveloppement a commenc en 1990. Les concepteurs de XML ont simplement pris les meilleures parties de SGML, profit de l'exprience de HTML, et produit une technologie qui n'est pas moins puissante que SGML, mais infiniment plus rgulire et plus simple utiliser. Certaines volutions, cependant, peuvent tre assimiles des rvolutions... Il faut galement savoir que SGML est principalement utilis pour des documentations techniques et beaucoup moins pour d'autres types de donnes, alors que c'est exactement l'inverse avec XML. 7. XML conduit HTML XHTML Une application importante d'XML est le langage XHTML comme successeur de HTML. On retrouve dans XHTML beaucoup d'lments du langage HTML. La syntaxe a t lgrement modifie afin de se conformer aux rgles d'XML. Plus gnralement, un document fond sur XML hrite sa syntaxe d'XML modulo quelques exceptions : par exemple, XHTML autorise la balise "<p>" mais pas "<r>". XML ajoute aussi un sens cette syntaxe : par exemple, XHTML dit que "<p>" signifie "paragraphe" et non "prix" ou "personne" ou etc. 8. XML est modulaire XML permet de dfinir un nouveau format de document en associant et en rutilisant d'autres formats. Cependant, deux formats dvelopps indpendamment
48
peuvent avoir des lments ou attributs de mme nom. Il faut alors tre trs attentif ne pas confondre les noms : "<p>" signifie-t-il "paragraphe" ou "personne" ? Pour viter toute confusion lors de l'association de noms identiques, XML fournit un mcanisme d'espaces de nom. XSL et RDF sont de bons exemples de technologies fondes sur XML qui utilisent les espaces de nom. XML Schema a t conu pour rpercuter cette fonctionnalit modulaire pour la dfinition des structures XML, puisqu'il est facile de combiner deux schmas pour en produire un troisime qui sera associ au document fusionn. 9. XML est le fondement de RDF et du Web Smantique RDF, la norme du W3C pour les mtadonnes, est un texte au format XML qui autorise la description de ressources et les applications mtadonnes, tels que recueils de musiques, albums photos, et bibliographies. Par exemple, RDF pourrait vous laisser identifier des personnes dans un album photo sur le Web en utilisant des informations puises dans une liste de contacts ; puis, votre messagerie pourrait automatiquement envoyer un message prvenant les personnes que leurs photos sont sur le Web. Tout comme les lments HTML intgrs, comme les menus et formulaires, RDF intgre les applications et les agents en un Web Smantique. De la mme manire que les humains ont besoin de se mettre d'accord sur les mots qu'ils utilisent en communicant entre eux, les machines ont aussi besoin de mcanismes pour communiquer efficacement. Les descriptions formelles de terminologies dans un domaine particulier (la grande distribution ou l'industrie, par exemple) sont appeles ontologies, et sont une partie ncessaire du Web Smantique. RDF, ontologies, et la reprsentation des connaissances sont tous des sujets dcrits dans l'activit Web Smantique. 10. XML est libre de droits, indpendant des plates-formes et correctement pris en charge En choisissant XML pour un projet, vous bnficiez d'un ensemble important et sans cesse croissant d'outils. Opter pour XML, c'est un peu comme choisir SQL pour des bases de donnes : vous devez encore construire votre propre base de donnes et vos propres programmes ou procdures qui la manipulent, mais un grand nombre d'outils et d'individus peuvent vous y aider. Et comme XML est libre de droits, vous pouvez vous en servir pour construire votre propre logiciel sans avoir payer quoi que ce soit qui que ce soit. Conclusion XML tire sa popularit de sa puissance cerner une multitude de problmes de reprsentation smantique et syntaxique sous une bibliothque de vocabulaires riche et paramtrable la demande. XML constitue un moyen incontournable pour lchange des donnes formates. A travers ce chapitre nous avons pu aborder les diffrents aspects du XML, nous avons constat lavantage de faire recours cette technologie dans limplmentation dun outils ddition des contenus pour la sauvegarde des donnes et de leur smantique.(Chapitre 5). La plupart des langages de programmation volus intgre dsormais dans leurs bibliothques de subroutines des parseurs XML puissants et couvrant pratiquement lensemble des besoins de navigation et de manipulation des objets XML.
49
3
Modlisation UML
3.1 Introduction Lobjectif de ce chapitre est de donner une petite introduction UML (Unified Modeling Language) il ne traite pas en dtail tout les concepts dUML. Il existe toute une bibliothque de livre sur UML et les mthodes de son apprentissage ( voir la bibliographie ). UML est apparu comme la notation de facto pour la modlisation oriente objet. Il rsulte des travaux de Grady Booch et de Jim Rumbaugh qui, en 1994, ont combin les notation de leurs deux mthodes ; les mthodes Booch et OMT (Object Modeling Technique ). Rejoints plus tard par Ivar Jacobson, crateur de la mthode Objectory, il ont acquis leur notorit sous le nom des trois amigos. Bien que dautres auteurs ont contribu UML, en particulier Cris Kobryn, qui en a dvelopp les versions les plus fines [Larman2002].(figure 3.1)
50
Figure 3.1 Historique dUML
UML est un langage de spcification, de reprsentation graphique, de construction et de documentation des artefacts des systmes logiciels ainsi quun langage de modlisation mtier et de systmes non logiciels [OMG01]. UML est adapt la modlisation de systmes, depuis les systmes informatiques dentreprise jusquaux applications distribues bases sur le Web , en passant par les systmes temps rel embarqus. [BooRumJac02] UML unifie les notations ncessaire aux diffrentes activits dun processus de dveloppement et offre, par ce biais, le moyen dtablir le suivi des dcisions prises, depuis lexpression des besoins jusquau codage. Pourquoi la modlisation ? Le fait de connatre un langage de programmation orient objet comme Java est ncessaire mais insuffisant pour crer des systmes objets, il faut en outre savoir penser en objet [Larman02]
Les modles permettent de mieux comprendre le systme que lon dveloppe [BooRumJac02] Un diteur de solutions informatiques qui adopte des mthodes de travail fondes sur des techniques de conception solides rencontrera probablement du succs, car ses produits rpondrons au mieux aux attentes des utilisateurs et constituerons des versions stables, volutives et modulaires.
51
Les projets informatiques russissent prsentent tous raisons expliquent le succs modlisation est un lment
chouent chacun leur manire, mais ceux qui des caractristiques communes. Ainsi, de nombreuses de certains fabricants de logiciels, mais le recours la commun tous. [BooRumJac02]
Un modle est une simplification de la ralit [BooRumJac02] UML nest quun langage de modlisation, il ne constitue quune partie dune mthode de dveloppement logiciel. UML est indpendant des processus, mme si, idalement, il doit tre utilis dans le cadre dun processus fond sur les cas dutilisation, centr sur larchitecture, itratif et incrmental. [BooRumJac02] Le recours la modlisation est depuis longtemps une pratique indispensable au dveloppement logiciel, car un modle sert anticiper les rsultats du codage, il constitue une reprsentation abstraite dun systme qui permet den faciliter ltude et de le documenter. Chaque intervenant dans le processus de dveloppement contribue et enrichit le modle diffremment. La modlisation synthtise les systmes et facilite leur comprhension et permette la ralisation de projet volumineux sans perdre le contrle de leur gestion et volutivit. La modlisation permet entre autre de responsabilis clairement les entits du systme en reprsentant leurs relations avec les autres entits et leurs rles dans des contextes diffrents. A est un bon modle de B si A permet de rpondre de faon satisfaisante des questions prdfinies sur B ( daprs D.T.Ross). Un modle doit prsenter le contexte tudi, et non une vue plus globale qui, sans doute, va lencombrer. Prenez lexemple dune carte routire o il est inutile dutiliser la carte dun pay pour circuler dans une de ses villes, par contre cette utilit ce manifeste sil sagit de circuler au niveau national. A chaque voyage correspond une bonne carte
La modlisation permet de formuler au mieux notre perception du monde rel en employant des abstractions orientes entits-mtiers. Ainsi ces abstractions fusionnent toute notre connaissance du systme et reprsentent notre comprhension dune manire claire et exploitable. La modlisation peut tre bnfique pour nimporte quel projet, parce que tout les systmes utiles et intressants tendent devenir plus compliqus avec le temps et, mme sil semble inutile de les modliser aujourdhui, cette dcision pourra tre mise en cause et regrette demain quand ces systmes auront volu. La modlisation permet datteindre quarte objectifs : [BooRumJac02] Les modles aident visualiser un systme tel quil est ou tel que nous voudrions quil soit. Les modles permettent de prciser la structure ou le comportement dun systme. Les modles fournissent un canevas qui guide la construction dun systme. Les modles permettent de documenter les dcisions prises. Nous construisons des modles pour les systmes complexes parce que nous ne somme pas en mesure dapprhender de tels systmes dans leur intgralit. [BooRumJac02]
52
Grce la modlisation il est devenu possible denvisager la ralisation des systmes complexes sans autant perdre le contrle, ceci est du sa capacit de fractionner la complexit dans des entits lmentaires moins complexes et plus faciles cerner par les facults de comprhensions humaine. 3.2 Les principes de la modlisation L'histoire de la modlisation dans tous les domaines technologiques est riche et l'exprience acquise dicte quatre principes de base : [BooRumJac02] 1. Le choix des modles crer a une trs forte influence sur la manire d'aborder un problme et sur la nature de sa solution : En d'autres termes, les modles doivent tre choisis avec soin car, s'ils sont bons, ils feront ressortir les problmes de dveloppement les plus ardus et apporteront un claircissement inespr, alors que s'ils sont mauvais, ils dtourneront l'attention des dveloppeurs des questions fondamentales. 2. Tous les modles peuvent avoir diffrents niveaux de prcision : Dans certains cas, le modle excutable simple et rapide d'une interface utilisateur est exactement ce qui convient, dans d'autres, il faut descendre au niveau des niveaux beaucoup plus bas pour comprendre. Les meilleurs modles sont ceux qui laissent le choix du niveau de dtail, en fonction du point de vue envisag. Un analyste ou un utilisateur final se concentrera sur les fonctions, alors qu'un dveloppeur mettra l'accent sur leur ralisation. Tous veulent visualiser le systme avec une prcision variable et des phases de dveloppement diffrentes. 3. Les meilleurs modles ne perdent pas le sens de la ralit : Il est donc prfrable de disposer de modles qui restent en contact avec la ralit, un dcalage entre le modle analytique et le modle conceptuel d'un systme peut engendrer un dcalage fondamental entre la conception et la ralisation effective. 4. Parce quaucun modle n 'est suffisant lui seul, il est prfrable de dcomposer un systme important en un ensemble de petits modles presque indpendants :pour comprendre larchitecture dun systme, plusieurs perspectives complmentaires et imbriques sont ncessaires. 3.3 Pourquoi lapproche Objet ? En quoi lapproche objet est-elle tellement attractive ? A cette question, les adeptes de lobjet rpondent invariablement que les avantages de lapproche objet sont la stabilit de la modlisation par rapport aux entits du monde rel, la construction itrative facilite par le faible couplage entre composants et la possibilit de rutiliser les lments dun dveloppement un autre. Tous ces points sont parfaitement exacts, mais ils ne sont que la consquence de la fantastique capacit dintgration ( ou dunification) de lapproche objet. En informatique, la modlisation peut tre aborde sous plusieurs angles. Les deux principaux sont la perspective algorithmique et la perspective oriente objet. [BooRumJac02] La construction d'un logiciel est, par consquent, une suite d'itrations du genre division-runion ; il faut dcomposer - diviser - pour comprendre et il faut composer runir - pour construire. Cela conduit une situation paradoxale : il faut diviser pour runir.
53
Face ce paradoxe, le processus de dcomposition a t dirig traditionnellement par un critre fonctionnel. Les fonctions du systme sont identifies, puis dcomposes en sous-fonctions, et cela rcursivement jusqu' l'obtention d'lments simples, directement reprsentables dans les langages de programmation (par les fonctions et les procdures).
Figure 3.2 Dcomposition fonctionnelle
L'architecture logicielle est alors le reflet des fonctions du systme. Cne dmarche, dont les mcanismes intgrateurs sont la fonction et la hirarchie, apporte des rsultats satisfaisants lorsque les fonctions sont bien identifies et lorsqu'elles sont stables dans le temps. Toutefois, tant donn que la fonction induit la structure, les volutions fonctionnelles peuvent impliquer des modifications structurelles lourdes, du fait du couplage statique entre architecture et fonctions. L'approche objet repose la fois sur le rationalisme d'une dmarche cartsienne et sur une dmarche systmique qui considre un systme comme une totalit organise, dont les lments solidaires ne peuvent tre dfinis que les uns par rapport aux autres. Elle propose une mthode de dcomposition, non pas base uniquement sur ce que le systme fait, mais plutt sur l'intgration de ce que le systme est fait.
Figure 3.3 Dcomposition Objet
Initialement base sur lutilisation dobjets en tant quabstraction du monde rel, lapproche objet a pour but une modlisation des proprits statiques et dynamiques de lenvironnement dans le quel sont dfinis les besoins, appel le domaine du problme ou le champ dapplication. [MullerGaertner00]. Elle traduit notre perception du monde rel et met en perspective des solutions rapproches le plus possible de la logique qui dfinie la structure des objets et leurs relations entre eux mais aussi avec tout les intervenants. Lorsque le problme est compris et la conception de notre systme informatique est acheve, le passage limplmentation informatique de la solution (codage) devient facile et mcanique . La construction dun systme apparat donc comme une dmarche dintgration dun ensemble de composants
54
harmonieusement organiss sous une architecture progressivement complexe et qui reflte notre perception rapproch du monde rel. [MullerGaertner00] En informatique, l'approche oriente objet est largement adopte, tout simplement parce qu'elle a dmontr son efficacit lors de la construction de systmes dans les domaines mtier les plus divers et qu'elle englobe toutes les dimensions et tous les degrs de complexit. De plus, la plupart des langages, des systmes d'exploitation et des outils modernes sont au moins partiellement orients objet, ce qui incite d'autant plus voir les choses en termes d'objets. 3.4 Les objets Lobjet est une unit atomique forme de lunion dun tat et dun comportement. Il fournit une relation dencapsulation qui assure la fois une cohsion interne trs forte et un faible couplage entre le dit objet et lextrieur. Lobjet rvle son vrai rle et sa vraie responsabilit lorsque, par lintermdiaire de lenvoi de message, il sinsre dans un scnario de communication [MullerGaertner00] Objet = Etat + Comportement + Identit
L 'tat : regroupe les valeurs instantanes de tous les attributs dun objet, par exemple dans le cas d'un objet Moto, celui-ci pourrait tre caractris par les attributs suivants : la marque, la couleur, le poids, la puissance, la quantit d'essence... Le comportement d'un objet indique toutes les comptences de celui-ci et dcrit les actions et les ractions qu'il peut avoir. Chaque lment de base du comportement est appel opration. Les oprations d'un objet sont dclenches suite une stimulation externe de l'utilisateur qui appuie sur un bouton ou du programmeur qui appelle une opration. Il existe un lien trs troit entre le comportement d'un objet et son tat. Effectivement, l'tat d'un objet peut tre modifi par l'appel d'une opration et les actions effectues par une opration dpendent de l'tat de l'objet. Reprenons notre exemple de l'objet Moto. Nous pourrions dfinir les oprations Dmarrer, Rouler, Stopper. L'opration Dmarrer n'a de sens que si l'information "moteur teint" est vrifie. De mme, l'opration Stopper n'aura d'effet que si les oprations Dmarrer et Rouler ont dj t excutes modifiant ainsi l'tat de l'objet moto de "moto stoppe" "moto en dplacement". L 'identit : En plus de son tat et de son comportement, un objet possde une identit qui caractrise son existence propre. L'identit permet de distinguer tout objet de faon non ambigu, et cela indpendamment de son tat. Cela permet, entre autres, de distinguer deux objets dont toutes les valeurs d'attributs sont identiques. L'identit est souvent construite partir d'un identifiant issu naturellement du domaine du problme. Ainsi une moto est identifie par son numro de srie, un compte en banque par son numro de compte. [MullerGaertner00]
Les objets communiquent travers les messages, un message est le support dune relation de communication qui relie, de faon dynamique, les objets qui ont t spars par le processus de dcomposition. Il permet linteraction de manire flexible et cest lui qui assure la dlgation des tches et garantit le respect des contraintes.
55
Figure 3.4 Communication des objets par des messages
3.5 Les diagrammes UML Un diagramme donne lutilisateur un moyen de visualiser et de manipuler des lments de modlisation. UML sarticule autour de plusieurs types de diagrammes, chacun deux tant ddi la reprsentation des concepts particuliers dun systme logiciel. UML modlise le systme suivant trois mode de reprsentation, la figure 3.5 montre ces trois vues de modlisation. [Roques02]
Figure 3.5 Les diagrammes UML par axe de modlisation
Figure 3.6 Hritage des diagrammes UML
56
3.5.1 Vue fonctionnelle : Dcrit les services et les fonctionnalits assures par le systme, elle est reprsente par le diagramme de cas dutilisation : o Diagramme de cas d'utilisation : reprsentation des fonctions du systme du point de vue de l'utilisateur, il est utilis dans phase danalyse des besoins, les cas dutilisation servent saisir le comportement attendu d'un systme en cours de dveloppement sans avoir prciser la faon dont ce comportement est ralis. Les cas dutilisation permettent aux dveloppeurs datteindre une comprhension commune avec les utilisateurs finaux du systme et les experts du domaine. Les cas dutilisations bien structurs reprsentent uniquement le contexte tudi il ne doivent pas tre trop gnraux, ni trop spcifiques. Le diagramme des cas dutilisation constitue l'apport original de la mthode OOSE (I.Jacobson, 1992) la notation UML.
3.5.2 Vue statique : Diagramme de classes : est le diagramme le plus utilis dans la modlisation orient objet et reprsente le point centrale dans un dveloppement orient objet. Il dcrit la structure des entits manipules par les utilisateurs. Il reprsente un ensemble de classes, dinterfaces et de collaborations ainsi que leurs relations. Le diagramme de classes est important non seulement pour visualiser, construire, spcifier et documenter des modles structurels, mais galement pour construire des systmes excutable grce au reverse engineering. [BooRumJac02]
Figure 3.7 Extrait du mtamodle. Caractristiques de la classe
Diagramme dobjets : ou diagramme dinstance, montre des objets et des liens. Un diagramme dobjet est une instance dun diagramme de classes qui montre ltat du systme modlis un instant donn. La notation retenue
57
pour les diagrammes dobjets est ainsi drive de celle des diagrammes de classes. Diagramme de composants : un diagramme de composants dcrit les composants et leurs dpendances dans lenvironnement de ralisation. En pratique, les diagrammes de composant ne sont utiliss que pour des architectures complexes. Un composant est une partie physique remplaable dun systme qui fournit la ralisation dun ensemble dinterfaces et sy conforme.[BooRumJac02]
Diagramme de dploiement : Les diagrammes de dploiement montrent la disposition physique des matriels qui composent le systme et la rpartition des composants sur ces matriels. Les ressources matrielles sont reprsentes sous forme de nuds. Les diagrammes de dploiement peuvent montrer des instances de nuds (un matriel prcis), ou des classes de nuds. Un nud (node) est un objet physique correspondant une ressource de traitement (mmoire et processeur). Il sagit dordinateurs, de ressources humaines, de traitements mcaniques. Un diagramme de dploiement est un diagramme qui montre la configuration de nuds de traitement en phase dexcution ainsi que les composants qui se trouvent sur ces nuds. [BooRumJac02] Pour certains types de systmes, le diagrammes de dploiement ne sont pas ncessaire. Si lon dveloppe un logiciel qui se trouve sur une seule machine et nest en interface quavec des priphriques standards dj grs par le systme dexploitation hte ( exp : clavier, modem ) on peut se passer des diagrammes de dploiement. En revanche, si lon dveloppe un logiciel en interaction avec des priphriques que le systme dexploitation de lhte ne gre pas habituellement ou qui est rparti physiquement sur plusieurs processeurs, lutilisation de diagrammes de dploiement permet alors de rflchir au mapping entre le logiciel et le matriel du systme. [BooRumJac02]
3.5.3 Vue dynamique : La phase danalyse dynamique intervient aprs la phase danalyse statique, elle sappuie sur les objets dcrits dans la vue statique, ainsi que sur les vnements provenant de lextrieur du systme dcrits dans la vue fonctionnelle, La modlisation dynamique est plus difficile mettre en uvre que la modlisation statique car elle ncessite une relle comprhension du fonctionnement global du systme. o Diagramme d'tats-transitions : est un automate tats finis, compos d'tats, de transitions, d'vnements et d'activits. Ils prsente la vue dynamique d'un systme, particulirement important dans la modlisation du comportement d'une interface, d'une classe ou d'une collaboration et met l'accent sur le comportement d'un objet ordonnanc par les vnements, ce qui est particulirement utile dans la modlisation des systmes ractifs.
58
Le diagramme d'tats-transitions reprsente le cycle de vie commun aux objets dune mme classe. Ce diagramme permet de complter la connaissance des classes en analyse et en conception. Figure 3.8 Un ou plusieurs automates peuvent tre associs chaque classe du modle. o Diagramme dactivits : est une variante des diagrammes d'tatstransitions qui dcrit la succession des activits au sein d'un systme. Ils prsentent la vue dynamique d'un systme ; ils sont particulirement importants dans la modlisation de la fonction d'un systme et mettent l'accent sur le flot de contrle entre les objets. Dans un diagramme d'tats-transitions, les tats et les transitions sont mis en avant alors que dans un diagramme dactivits, ce sont les activits et les transitions qui sont mises en avant. Les diagrammes d'activits utilisent beaucoup d'lments du mtamodle dfinis pour les diagrammes d'tats-transitions. Un diagramme d'activits reprsente l'tat de l'excution d'un mcanisme, sous la forme d'un droulement d'tapes regroupes squentiellement dans des branches parallles de flot de contrle. Le dbut et la fin (si elle existe) d'un mcanisme sont dfinis respectivement par un tat initial et un tat final. [MullerGaertner00] Diagramme de squence et Diagramme de collaboration : sont deux types de diagrammes d'interaction. Les diagrammes d'interaction reprsentent une interaction, c'est--dire un ensemble d'objets et leurs relations, y compris les messages qu'ils peuvent s'changer. Ils prsentent la vue dynamique d'un systme. Les diagrammes de squence sont des diagrammes d'interaction qui mettent l'accent sur le classement chronologique des messages alors que les diagrammes de collaboration sont des diagrammes d'interaction qui mettent l'accent sur l'organisation structurelle des objets qui envoient et reoivent des messages. Les diagrammes de squence et les diagrammes de collaboration sont isomorphes, c'est-dire que l'un peut tre transform en l'autre.
3.6 Nouveaut de UML 2.0 Avec la nouvelle version dUML ( UML 2.0 ) 4 nouveaux diagrammes viennent complter la collection des diagrammes UML, ces diagrammes sont : Diagramme de packages : permet de reprsenter la hirarchie des modules du projet, leur organisation et leurs interdpendances. Cela simplifie les diagrammes, et les rend donc plus simple comprendre Diagramme de structure composite : permet de dcrire la structure interne d'un objet complexe lors de son excution (au run-time - dcrire l'excution du programme), dont ses points d'interaction avec le reste du systme. Diagramme global d'interaction : permet d'associer les notations du diagramme de squence celle du diagramme d'activit, ce qui permet de dcrire une mthode complexe. C'est une variante du diagramme d'activit.
59
Diagramme de temps : permet de modliser les contraintes d'interaction entre plusieurs objets, comme le changement d'tat en rponse un vnement extrieur.
3.7 UML est un langage pour communiquer Souvent dans le jargon des programmeurs on entends lexpression telle personne parle bien UML cest parce que UML est un moyen de communication trs efficace et utilis grande chelle dans la communaut des dveloppeurs informatiques. Il substitue largement au langage naturel ( parl ) ceci est du sa simplicit, sa capacit prsenter des systmes assez complexes sur des schmas expressifs. Dailleurs les fondateurs dUML le qualifie comme un langage pour visualiser [BooRumJac02]. UML comporte un riche vocabulaire et une arsenal de rgles rgissant la manire de concevoir et de comprendre des modles correctement structurs. UML est bien plus quun simple ensemble de symboles graphiques, en fait chaque symbole vhicule une smantique stricte. Cette rigueur permet entre autre de : Rendre son modle universel : la matrise dUML permet de lire nimporte quel modle respectant les rgles dfinies dans le standards OMG. Lutilisation des outils de gnration automatique du code natif depuis les schma UML. Reverse engineering
3.8 Etude base sur les cas dutilisation Le principe des cas dutilisation a t introduit en 1986 par Ivar Jacobson [Jacobson92] il permet de dcrire des besoins fonctionnels, cette technique a rapidement trouve sa place dans le milieu des concepteurs dapplications et mme devenue une cole, ceci et du sa simplicit et surtout son utilit [Larman2002]. Parmi tout les travaux raliss dans ce domaine, on trouve luvre de Alistair Cockburn, qui constitue une rfrence dans la matire avec son exhaustivit Rdiger des cas dutilisation efficaces [Cokburn01] Un cas dutilisation tablit, entre les diffrents intervenants, un contrat rgissant le comportement dun systme. Il dcrit ce comportement sous diverses conditions [Cokburn01] cette dfinition ne laisse penser que les cas dutilisation est la premire tapes du processus danalyse, elle doit permettre de voir notre futur systme sous plusieurs angles, mais tous centrs sur lutilisateur final, ce dernier doit assister la rdaction des cas dutilisation car sa contribution est essentielle. Ce qui diffrencie ltude base sur les cas dutilisation et une autre qualifie fonctionnelle cest la manire daborder le problme pour arriver au rsultat. Les cas dutilisation visent les objectifs (utilisation effective du systme) cependant ltude fonctionnelle traite plus le processus ramenant au rsultat, le modle des cas dutilisation permet daboutir des rponses novatrices et optimises aux besoins et non pas au processus, en plus concevoir une solution fonctionnelle nous pousse, sans conscience, reproduire des systmes existants ce qui prsente une lacune majeure pour le profit de lutilisateur final. La dtermination et la comprhension des besoins sont souvent difficiles car les intervenants sont noys sous de grandes quantits d'information. Les besoins sont souvent exprims de manire non structure, sans forte. Les cas dutilisation est une
60
perception de haut niveau du systme, ils dcrivent la relation de notre systme avec le monde extrieur, sans se proccuper des dtails ou se laisser distraire par les contraintes technologiques. Les cas d'utilisation recentrent l'expression des besoins sur les utilisateurs, en partant du principe qu'un systme est avant tout construit pour ses utilisateurs. [BooRumJac02] Pour un systme, il existe trois aspects importants : la fonction, linterface et limplmentation (cest le cas dun objet). La fonction justifie le pourquoi du projet, linterface reprsente les voies de communication avec le systme depuis lextrieur pour exploiter ces services, tandis que limplmentation est lexistence technique du systme. Une tude base sur lutilisateur focalise leffort sur les deux premiers aspects c d la fonction et linterface car elle prsente le seul intrt pour lutilisateur final. En plus le faite de les bien dfinir, permet de cerner le contexte et le champ dapplication de notre systme. Tracer un diagramme des cas dutilisation est une tche souvent difficile et quivoque et pleine de piges, pourquoi ? Les analystes et les utilisateurs nont pas forcment les mmes dfinitions, ceci est d au faite que chacun dentre eux vise un objectif diffrent, mais il reste dire que cest le rle de lanalyste de trouver un compromis et de piloter les discutions pour aboutir des informations exploitables. Dcrire un cas dutilisation par un petit schma conventionnel est trs utile mais il reste insuffisant pour comprendre lemplacement du cas dutilisation dans le systme et surtout dans le workflow. Ceci revient dfinir certains lments qui sont communs dans la plupart des cas dutilisation [Cokburn01] Tableau 3.1 Description textuelle dun Cas dUtilisation Prsupposs Ltat dans le quel le systme doit tre avant dappeler le cas dutilisation, c d tous les prsupposs sont vrifis. Les prsupposs, la diffrence des pr-conditions, doivent tre vrifier par dautres cas dutilisation. Ltat dans lequel le systme doit tre avant dutiliser le cas dutilisation. Mais contrairement aux prsupposs, les pr-conditions sont vrifier par le cas dutilisation, si les conditions ne sont pas remplies, lacteur se voit refuser lusage du cas. O et quand le cas dmarrera ? Trouver les dclencheurs du cas est important pour laspect de rutilisation, chaque utilisation est particulirement distingue par une manire de dclencher le cas. La description de la communication entre le cas dutilisation et son utilisateur (acteur, cas dutilisation) depuis la demande jusqu un point darrt du cas. Souvent le cas dutilisation dispose de plusieurs signaux darrt, lister toute les possibilits pour viter doublier le traitement des exceptions et des erreurs.
Prconditions
Dmarrage
Processus ou dialogue Arrt
61
Postcondition
Ltat dans lequel le systme doit se retrouver aprs la fin du cas dutilisation. Ceci permet de vrifier la stabilit du systme aprs lachvement de lexcution du cas (normale ou anormale exp : Erreur).
Notez bien, que cette description textuelle dun cas dutilisation ne fait pas partie du standard UML, en effet il sagit plus dune mthodologie de travail. 3.9 Le choix dun outil de modlisation Il existe de nombreux outils de modlisation graphique UML allant du plus simple jusquaux ateliers de gnie logiciel. Mais lOMG ne prconise aucun outil de modlisation UML, lorganisation prcise que la plupart des outils du march ont t conus pour mettre en uvre certaines mthodologies(langages), du fait ce nest pas judicieux dutiliser un outil et essayer ensuite de ladapter une mthodologie la quelle il ne sadhre pas [URL_OMG] car ceci peut constituer un grand handicape pour le processus de dveloppement. Cependant il existe des outils qui intgrent plusieurs mthodologies (langages de programmation) il y a mme dautres qui permettent le passage dune mthodologie une autre. LOMG pris cette position neutre pour viter de crer une concurrence polmique non souhaite entre diteurs de solution software car elle va orienter la recherche en dpit de linnovation. Nanmoins, Lutilisation des outils de modlisation montr quun certain nombre de critre sont trs important dans lvaluation dun outil de modlisation UML : Gnration automatique du code : permet de rduire visiblement la charge du dveloppeur en crant automatiquement depuis des modles UML des squelettes de code dans un langage prcis. Reverse engineering : cest lopration inverse de la gnratrice du code, elle consiste crer des modles UML partir du code. Beaucoup doutils proposent cette fonctionnalit mais peu sont ceux qui atteignent un niveau de succs acceptable. Le Reverse engineering est trs utile aussi bien pour transformer le code dans un modle quand aucun modle n'a exist prcdemment, que pour synchroniser de nouveau un modle avec le code la fin d'une itration. Gnration de la documentation ( format HTML ou autre ) avec des images du modle. Compatibilit avec les versions UML : avant de commencer utiliser UML, il faut choisir une version ( 1.1, 1.3, 2.0 ) ce critre va dterminer le choix de loutil de modlisation car tout les outils ne supportent pas toutes les versions dUML. Ou faire linverse c d choisir loutil suivant dautres critres que la version dUML et saligner ensuite la version dUML utilise par cette outil. Les Donnes d'Intgration du Modle : L'outil de modlisation d'objet doit permettre l'intgration avec des fonctionnalits de modlisation des donnes. Il y a beaucoup de faons de fournir ces fonctionnalits. L'une des possibilits est que l'outil UML comprenne une fonction qui permet au modle d'objet d'tre transform en DDL. DDL est le SQL ncessaire la cration de tables pour les classes. L' outil UML peut galement exporter les mta-data vers l'outil de modlisation des donnes qui peut les importer et les utiliser comme base d'un modle de donnes. Un ensemble d'outils
62
intgr avanc doit permettre la synchronisation des modles de donnes et des modles d'objet aprs chaque itration du dessin. Gestion des versions : permettre la sauvegarde de plusieurs version du modle et la possibilit de naviguer entre ces versions. Ergonomie conviviale et interface intuitive. Plate-forme : Afin d'optimiser votre investissement dans un outil de modlisation, considrez attentivement les plates-formes sur lesquelles s'excutera cet outil. Allez-vous dvelopper des produits pour Windows, pour Unix ou pour les deux ? Sur quelle plate-forme dvelopperez-vous ? Exportation vers le format XMI : XMI standard de lOMG est l'un des dveloppements rcents les plus passionnant pour la communaut des dveloppeurs de l'UML. XMI est un format d'change qui a la capacit d'autoriser le partage en continu des modles entre les outils de dveloppement les meilleurs de la nouvelle gnration. Par exemple, plutt que d'crire les scripts dans un outil de modlisation UML pour crer des rapports, un utilisateur pourrait exporter le modle en cours de conception en utilisant XMI et simplement importer le modle dans un outil spcialis en criture de rapports.
Pour finir voici une liste, non exhaustive, doutils de modlisation : Tableau 3.2 Outils de modlisation UML Produit Rational Rose Socit :Rational software Corporation
URL : http://www.rational.com
Description Rational Rose est une des leaders mondiaux des outils de modlisation UML. La socit Rose a dans ces membres les pres des mthodes objet : Rumbaugh, Jacobson, Booch. Rose est orient programmation Version d'valuation 1 mois. Outil professionnel trs puissant et trs complet de modlisation de donnes jouissant d'une trs bonne rputation. Support de multiples modles(OO), modle conceptuel, modle physique, traduction de modle, reverse engineering de base de donnes et de programme. UML partir de la version 7. Prix (approx.) : 5000 .
PowerDesigner (PowerAMC version franaise) Socit :Sybase

URL :http://www.sybase.com/
Visio Socit : Microsoft

URL :http://www.microsoft.com/office/visio
Gamme de produit qui va du simple diagramme (Standard) un vritable outil de modlisation de base de donnes et pour la conception de programmes (entreprise). Fournit un environnement de dveloppement Visual Basic pour application ce qui permet de le personnaliser facilement. Support du reverseengineering, gnration de rapports. Supporte tous les diagrammes UML
63
Produit
Description Outil de modlisation UML, gnration de code java, export XMI, interface agrable et intuitive, version CE gratuite, supporte les 9 diagrammes de la norme UML. Nanmoins, les diagrammes d'objets, de composants et de dploiement sont tous rassembls dans un seul diteur ("Deployment diagram") car les lments de notation graphique sont similaires Outil trs complet de dveloppement. Support du formalisme UML. La version complte permet de couvrir tous les besoins de modlisation de base de donnes, programmation. Ncessite Visio (sauf la version Java). Simple, gratuit et trs complet. Outil spcifiquement dvelopp pour la modlisation de donnes gographiques. Dveloppement possible avec Visual Basic pour Application ou d'autres langages. Code disponible. Outil gratuit. Gnration de dictionnaire de donnes. Gnration de rapport compatible ISO TC211. Diagramme de classe UML
PoseidonPE Socit : gentleware

URL :http://www.gentleware.com
Oracle Designer 2000 Socit : Oracle

URL : http://www.oracle.com/
Perceptory Socit : Universit Laval

URL :http://sirs.scg.ulaval.ca/perceptory
ArgoUML Socit : Tigris

URL :http://www.tigris.org
Outil de modlisation UML programm en Java. Il s'agit d'un produit Open Source.
MyUML Socit : Softwarefarm

URL : http://www.swfm.com
Outil de modlisation UML en Java. Version gratuite disponible. Utilisation de XMI pour import et export. Support de Java JDK versions 1.1.x et 1.2.x.
Objecteering Socit : Softeam

URL :http://www.objecteering.com
Atelier de modlisation UML, un outil puissant Outil de modlisation UML, ainsi que dautre fonction de prsentation graphique. Loriginalit de cet outil cest lexistence dune bibliothque ddie la modlisation WEB Outil de modlisation UML trs puissant et trs complet.
SmartDraw Socit : Hemera Technologies Inc

URL :http://www.smartDraw.com
Enterprise Architect Socit : Sparx Systems

URL :http://www.sparxsystems.com
64
Produit
Description ModelMaker est maintenant directement intgr dans Borland Delphi Entreprise, exclusivement conu pour la modlisation UML pour Delphi, synchronisation bidirectionnelle entre le modle UML et le code Delphi, Reverse engineering. Environnement de conception agile et intgr, Synchroniser le modle et le code source du projet, Gnrer la documentation de l'application, S'interfacer avec tous les EDI majeurs du march (C++BuilderX, Eclipse, JBuilder, ect) Atelier de gnie logiciel, riche en fonctionnalits et cest aussi un outil de conception UML facile utiliser qui dispose dexcellentes possibilits dinteroprabilit avec dautres applications. Son environnement de dveloppement intelligent (SDE) est disponible dans de nombreuses versions, chacune tant conue pour sintgrer aisment un EDI. La version d'valuation contient la version Community Edition qui est gratuite.
ModelMaker
URL :http://www.modelmakertools.com
Borland Together Borland

URL : http://www.borland.com/fr/products/together
Visual Paradigm
http://www.visual-paradigm.com/
3.10 UML et la Mta-modlisation Le dveloppement dirige par les modles, est une approche de conception qui vise garder les modles comme point de rfrence tout au long du processus de dveloppement logiciel. LOMG cherche apporter de nouvelles fonctionnalits aux diffrents modles qui sont utiliss pour concevoir des applications, faciliter la cration de nouveaux espaces de modlisation plus adapts aux besoins de leurs utilisateurs, et faciliter les diffrentes tapes de modlisation ncessaires llaboration dun produit fini. Un des points cls dans cette approche est la possibilit de transformer les modles, dun espace de modlisation ou dun niveau dabstraction vers un autre. En effet, la gestion manuelle des modles savre aujourdhui coteuse et les modles sont en consquence bien souvent laisss de ct. Il devient donc ncessaire de proposer des outils flexibles de gestion automatique des modles, permettant, tout au long de leur cycle de vie, de les porter aisment sous des formes dans lesquelles ils rpondront mieux aux attentes de leurs utilisateurs un moment donn. Cette partie du chapitre tente dtablir un tat de lart sur les outils de transformations de modles, en analysant en particulier les possibilits qui ont dj t mises en uvre lheure actuelle. 3.10.1 Les besoins lis aux modles : Depuis longtemps, divers langages et techniques de modlisation sont utiliss lors des phases danalyse et de conception, entre autres en dveloppement logiciel. Se situant un niveau intermdiaire entre lexpression des besoins et le code dvelopp pour rpondre ces besoins, ils permettent une meilleure
65
communication entre informaticien et client. Du point de vue du dveloppeur, ils permettent de garder tout au long du cycle de vie du logiciel une vision globale sur le systme traiter, en offrant plusieurs niveaux dabstraction. De ce point de vue, le langage UML offre une gamme doutils tendue, permettant de reprsenter sous forme graphique divers aspects dun systme traiter, notamment lorganisation des donnes, les flots de contrle, les interactions entre plusieurs modules, lorganisation des applications rparties. Pourtant, ce standard souffre actuellement de nombreuses critiques : orient vers un dveloppement objet, bas sur un formalisme relch, il ne permettrait pas de tenir compte de la diversit des plates-formes logicielles, ni dexprimer certains points cl de la dfinition dun systme. En effet, les diffrentes phases du cycle de vie du logiciel sont ponctues de prises de dcisions, et il apparat ncessaire que les modles fournissent une aide efficace dans ces dcisions. Il sagit notamment des questions lies au choix dune plateforme, de validation des choix de dveloppement en amont de limplmentation, de llaboration de donnes de tests, de vrification de composants. Pour rpondre ces besoins et offrir une relle assistance dans ces phases de dcision, il est ncessaire quun modle puisse tre trait automatiquement. Cela permettrait notamment lanimation dun modle, la gnration de donnes de tests, ou encore la simulation dajout de nouveaux composants, offrant ainsi un rel gain en temps et en moyens. Les besoins tant trs divers en matire de modlisation, il apparat lheure actuelle impossible de dfinir un langage de modlisation permettant de rpondre tous ces besoins de manire quitable. En ralit, des outils et espaces de modlisation varis sont utiliss et continueront ltre en fonction des besoins qui interviennent lors du cycle de dveloppement, et du domaine mtier concern. De mme, les phases de modlisation passent par divers niveaux dabstraction, et le retour sur les choix pris un niveau prcis est trs coteux : de nombreuses amliorations pourraient tre apportes de ce point de vue. En consquence, pour rendre la dmarche de modlisation productive, il est ncessaire de fournir des outils de transformation permettant de passer dun espace de modlisation ou dun niveau dabstraction un autre. [TATIBOUET06] Tout comme un programme, un modle destin tre trait par une machine ne doit pas permettre dambiguts dinterprtation, et doit tre exprim en respectant des rgles bien dfinies. Il sagit l de lobjet de la dmarche de mta-modlisation, qui sattache dfinir des formalismes pour les langages de modlisation. Une fois le formalisme dfini, on peut garantir que tout modle conforme ce formalisme pourra tre trait correctement. Il sagit ici de bien distinguer les diffrents niveaux dabstraction lis au concept de mta-modlisation, qui sont rsums dans le tableau figure 3.9.
66
Figure 3.9 Niveaux dabstraction de la mta-modlisation
Mta-mta-modle Mta-modle Modle Systme
Abstraction
Au premier niveau, se trouve le systme tudier : il peut sagir selon le cas du systme dinformation dune entreprise, ou des tches que lon souhaite automatiser. Au second niveau, se trouve le modle qui dcrit certains aspects du premier niveau que lon veut tudier : il peut sagir dun diagramme de classes UML, dun modle conceptuel de traitement MERISE, dune machine B, ou de tout schma qui reprsente une vue abstraite des objets modliss. Au troisime niveau se trouve le langage de modlisation ou mta-modle : par exemple les dfinitions dun MCD MERISE dun diagramme dobjet UML ou le langage B. Cest ce langage qui doit faire lobjet dune spcification formelle. Au quatrime niveau se trouve le mta-mta-modle : il sagit dun langage qui doit tre assez gnrique pour dfinir les diffrents langages de modlisation existants, et assez prcis pour exprimer les rgles que chaque langage doit respecter pour pouvoir tre trait automatiquement.
Dans larchitecture propose par lOMG, UML se situe au troisime niveau, et un langage gnrique de description des modles est propos : le MOF (Meta Object Facility), que nous dcrivons dans les pages qui suivent. Dans le formalisme XML, on pourrait situer le langage des DTD ou des schmas au quatrime niveau, puisquil sagit de langages servant dcrire un format de document. Une DTD ou un schma particulier se placerait alors au niveau 3, dcrivant le format que doit respecter un certain type de document. Un document particulier se situerait alors au niveau 2, conforme au prcdent et reprsentant certaines donnes dun domaine particulier. Comme nous lavons vu dans le chapitre 2, XML tant lui-mme utilis en tant que langage de description de modle, ces niveaux peuvent varier suivant lutilisation quon en fait. Ltablissement dun mta-modle est une condition ncessaire au traitement automatis. Le mta-modle doit dfinir une syntaxe qui permettra un programme non seulement de vrifier quun modle est dcrit correctement, mais surtout didentifier les diffrents lments de ce modle afin de leur appliquer un certain traitement. [TATIBOUET06] Cest notamment sur un mta-modle que sappuiera la dfinition de transformations. Par exemple, si on dsire obtenir partir dun modle objet son quivalent dans le formalisme relationnel, le programme qui ralise la transformation doit tre capable didentifier chaque lment du modle source pour gnrer son quivalent dans le modle cible. Il est donc ncessaire dexprimer
67
formellement les langages de dfinition des deux modles source et cible, afin quils soient reconnus par notre programme. lOMG a propos trois standards qui sont respectivement le MOF (langage permettant de dcrire des mtamodles), le format XMI (XML Metadata Interchange) et QVT (Query / View / Transform). 3.10.2 MOF Le MOF (Meta Object Facility) est une extension du modle objet, qui permet celui-ci de reprsenter non plus des entits du monde rel, mais des entits de description de modles. La figure 3.10 extraite des spcifications MOF 2.0 prsente la partie du mta-modle sur laquelle sappuient les procds de transformation. On retrouve le concept de classe, qui reprsente ici un lment du mta-modle dcrit. Les relations entre ces lments sont exprimes par la rfrence opposite de la classe Property : pour dire quil existe une relation bidirectionnelle entre une classe A et une classe B, la reprsentation de chaque classe possdera une proprit dont lattribut opposite fera rfrence lautre classe. Si lon veut par exemple reprsenter une partie du mta-modle UML en MOF, les concepts de classe ou dattribut seront chacun reprsents par une classe du MOF, sachant quils reprsentent une entit de description de modles. Une association entre une classe et les attributs quelle possde sera reprsente dans la classe Class par une proprit dont lattribut opposite fera rfrence la classe Attribute. Le MOF est donc un langage de description des langages de modlisation (ou mtamodles). En utilisant des lments du MOF, on peut dcrire un langage tel que UML, le langage de description des bases de donnes relationnelles, XML ou encore le MOF lui-mme. Ce langage permet dabord de faire une reprsentation graphique dun langage de modlisation particulier. Mais surtout il dfinit une grammaire selon laquelle un programme peut reconnatre et traiter des lments dun modle dcrit dans le langage spcifi. Figure 3.10 Package EMOF (MOF 2.0)
68
3.10.3 XMI Le MOF restant avant tout une reprsentation graphique, il est ncessaire de disposer dun format de stockage des mta-modle MOF ou des modles dcrits avec un outil de modlisation quelconque, afin que ces modles puissent tre rcuprs et traits par un programme. Le standard XMI (XML Metadata Interchange) a t mis en place en 2000 pour permettre la srialisation des modles, afin de rendre possible lchange de modles entre diffrents logiciels (de modlisation, de dveloppement). Le standard XMI, est actuellement utilis, sous de nombreuses variantes par des plates-formes de modlisation et de dveloppement logiciel, notamment Rational Rose ,PowerAMC et Posedon pour permettre la transmission de modles entre ces plateformes. Lintrt du format idal ceux-ci, qui transformer, logiciels. standard XMI dans les outils de modlisation est quil propose un pour dcrire la fois les mta-modles et les modles conformes vont permettre loutil de traiter automatiquement les modles et de fournir en sortie un modle directement exploitable par dautres
3.10.4 QVT : Les standards MOF et XMI tant largement utiliss dans le cadre de la mtamodlisation, ils ne suffisent toutefois pas dfinir le procd de transformation qui permet de passer dun modle un autre sur la base des mta-modles de dpart et darrive. En effet, des APIs ont t dfinies pour passer dun formalisme lautre, mais lenjeu des outils de transformation est de pouvoir transformer plusieurs classes de modles, dfinies suivant plusieurs mta-modles diffrents. Lidentification ces dernires annes de nouveaux besoins en matire de modlisation donne lieu une recherche active dans le domaine de la mtamodlisation. En effet, cette dmarche offre la perspective de pouvoir oprer des traitements informatiques avancs sur les modles, amenant ainsi une gestion plus efficace des ceux-ci, leur permettant doccuper une place plus importante dans les procds de dveloppement logiciel. La possibilit de transformer des modles est au centre des proccupations de ceux qui traitent de mta-modlisation. Une partie importante des recherches qui se font sur ce thme est centre sur lappel propositions QVT de lOMG. 3.11 Les Design Patterns Les design patterns sont apparus dans les annes 1990. Les travaux de la bande des 4 ' [Gamma 95] en ont produit le document fondateur. Cet ouvrage ainsi que des publications ultrieures constituent depuis des catalogues de rfrence pour les concepteurs objet.
69
3.11.1 Dfinition Plusieurs dfinitions nous aideront comprendre ce concept : En gnie informatique, un motif de conception (Design pattern en anglais) est un concept issu de la programmation oriente objet, destin rsoudre les problmes rcurrents Solution rcurrente dcrivant et rsolvant un problme gnral dans un contexte particulier . une solution de conception commune un problme | rcurrent dans un contexte donn [UML-UG 98] . , un Design Pattern dcrit un problme rcurrent dans un environnement donn puis dcrit une solution ce problme de telle manire que cette solution soit rutilisable chaque fois qu'on rencontre le problme sans cependant qu'elle soit deux fois exactement la mme. Le principal intrt des patterns est de permettre la manipulation d'artefacts plus labors que les objets et les classes. Ils accroissent la force d'expression des langages de modlisation. Le concepteur d'un pattern propose une solution gnrique pour un problme, plutt de dtail, qui est souvent rencontr dans divers dveloppements. Cette solution est prsente sous une forme indpendante d'un langage de programmation particulier L'usage des design patterns apporte donc volutivit, lisibilit et efficacit aux dveloppements. C'est pourquoi leur emploi amliore sensiblement le respect des prescriptions d'architecture [Bushmann 96]. Par ailleurs, ils offrent un transfert de comptence rapide en conception oriente objet, dans la mesure o ils reprsentent pour les dbutants un catalogue des meilleures pratiques adopter. Un design pattern est gnralement form de quatre parties essentielles, savoir : Le nom du pattern, point d'accroch qui permettra de facilement retrouver le problme et sa solution. Ce nom doit donc tre choisi avec soin. Le problme lui-mme, qui dcrit le plus synthtiquement possible le contexte dans lequel s'applique ce design pattern. La solution, qui dcrit l'ensemble des lments en jeu, leurs relations et leurs responsabilits. La solution est exprime d'une faon gnrique et ne repose sur aucun cas concret pour tre facilement transposable. La solution doit tre abstraite pour mieux tre concrtise, un peu comme une classe abstraite permet de crer par hritages des classes concrtes. Les consquences qu'entran l'application de la solution. En matire de dveloppement, cela peut concerner la mmoire utilise, le temps de calcul, les contraintes particulires que le langage choisi, pour mettre en uvre la solution, doit pouvoir respecter.
Les deux points centraux (description du problme trait et solution apporte) justifient en gnral l'utilisation de UML pour illustrer le propos et le rendre plus universel.
70
Les diagrammes les plus souvent utiliss en la matire sont les cas d'utilisation, les diagrammes de classes, les diagrammes de squences et de collaboration ainsi que les diagrammes d'tats de transitions. Les design patterns sont l'antithse de la rinvention de la roue. Et comme finalement le monde est partout le mme, et que les problmes proviennent de souvent de causes similaires, de situations classiques , il est raisonnable de vouloir rutiliser les solutions qui ont fait leurs preuves face des problmes finalement identiques ou proches dans leur nature. C'est ce que permettent de faire les design patterns. Lorsqu'elles sont appliques au dveloppement, elles permettent la fois de gagner du temps et de s'assurer qu'on utilise une bonne solution qui ne causera pas ultrieurement plus de problmes qu'elle n'en rglait. La POO a introduit la notion de rutilisation du code en crant des acteurs autonomes que sont les objets, les design patterns inventent la rutilisation des ides. Aprs avoir rsolu un problme original on peut gnraliser cette solution en crant un design pattern. 3.11.2 Exemple de design Patterns 3.11.2.1 Le design pattern singleton Le singleton [Gamma 95] est l'une des techniques les plus utilises en conception oriente objet. Il permet de rfrencer l'instance d'une classe devant tre unique par construction. Certains objets techniques prennent en effet une responsabilit particulire dans la gestion logique d'une application. C'est par exemple le cas d'objets comme le contrleur des objets chargs en mmoire ou le superviseur des vues , qui sont les seuls et uniques reprsentants de leur classe. Ces objets sont le plus souvent publiquement accessibles. De tels cas de figure sont frquents en conception, le singleton est requis pour les concevoir. Le singleton permet de s'assurer qu'une seule instance d'une classe sera instancie pendant toute la dure dexcution dune application.
Implmentation Pour s'assurer de l'unicit de l'instance dune classe, il faut mettre les constructeurs de la classe en accessibilit limite (prive). Cette mesure va garantir quaucun objet externe la classe en question peut appeler directement le constructeur. Du moment que fournir un point getInstance() qui lappelant. (figure les constructeurs sont inaccessibles depuis lextrieur, il faut dappel accessible par tous les objets, une mthode static va vrifier si une instance existe dj avant de la retourn 3.11)
71
Figure 3.11 Le design pattern Singleton
3.11.2.2 Le design pattern Decorator Ce pattern permet d'attacher des responsabilits supplmentaires un objet de faon dynamique. Avec ce pattern on dispose d'un moyen efficace pour accrocher de nouvelles fonctions un objet dynamiquement lors de l'excution. Cela ressemble la fois un peu aux interfaces et l'hritage mais c'est une troisime voie offrant des avantages diffrents. Les nouvelles fonctionnalits sont contenues dans des objets, l'objet parent tant dynamiquement mis en relation avec ces derniers pour en utiliser les capacits.
Figure 3.12 Le design pattern Decorator
3.11.2.3 Le design pattern Observer La design pattern observer (observateur) dfinit une relation un--plusieurs entre des objets, de telle sorte que lorsque l'objet observ est modifi, tous les observateurs de ce dernier en soit notifis De nombreux exemples illustrent ce besoin, l 'u n des plus classiques est celui d'une information qui se trouve visualise sous diverses formes. Supposons une gestion de stock offrant diverses vues sur chaque article : des graphiques, des fiches textuelles... Si lutilisateur affiche plusieurs de ces fentres, ainsi que celle qui permet de modifier la fiche article, nous pouvons dsirer que ds qu'une saisie modifie la fiche article, cela soit reflt immdiatement par toutes les fentres ouvertes affichant des informations relatives l'article en question
72
Figure 3.13 Le design pattern Observer
3.11.2.4 Autres exemples Le tableau suivant illustre une liste des design patterns les plus connus classs par catgorie, notez que cette liste nest pas exhaustive, en effet il existe beaucoup dautre, dailleurs vous pouvez vous-mme en inventer des nouveaux. Tableau 3.3 Liste de Design Patterns
Catgorie cration Structure Comportement
Design patterns Abstract Factory, Builder, Method, Prototype, Singleton Factory
Adapter, Bridge, Composite, Decorator, Faade, Flyweight, Proxy Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor
Comme le prcise la dfinition dun design pattern, lapplication dun design pattern dpend fortement de la nature du problme. Avec lexprience, les dveloppeurs cumulent une sorte de bibliothque mentale, qui les aides slectionner rapidement le design pattern adquat leur problmatique. Il est trs utile davoir un aperu sur un grand nombre de design pattern et leur utilisation pour sen souvenir le moment venu.
73
4
Approche des dlgus des packages
4.1 Le Modle MVC 4.1.1 Introduction L'objectif de la majorit des systmes informatiques est de rcuprer les donnes depuis un entrept de donnes et de les prsenter l'utilisateur. Une fois que l'utilisateur a modifi les donnes, le systme stocke les mises jour dans lentrept. Comme le principal flux d'informations s'effectue entre le lentrept de donnes et l'interface utilisateur, vous pourriez tre tent de lier ces deux lments afin de rduire le volume de code et amliorer les performances de l'application. Cette approche qui peut vous paratre naturelle n'est pas sans prsenter certains problmes non ngligeables. L'un d'eux est que l'interface utilisateur a tendance changer plus frquemment que le systme de stockage des donnes. Autre problme du couplage des donnes avec les lments d'interface utilisateur, les applications mtier tendent intgrer une logique mtier qui va bien au-del de la transmission de donnes. L'architecture MVC (Modle Vue Contrleur) est un design pattern (motif de conception) pour le dveloppement d'applications logicielles qui spare le modle de donnes, l'interface utilisateur et la logique de contrle. Ce motif a t mis au point en 1979 par Trygve Reenskaug [Reenskaug], qui travaillait alors sur Smalltalk dans les laboratoires de recherche Xerox PARC. [wikipedia]
74
4.1.2 Problmatique Comment normaliser l'interface utilisateur d'une application Web de sorte que chaque partie puisse tre aisment modifie individuellement ? 4.1.3 Facteurs prendre en compte Les facteurs suivants agissent sur le systme dans le contexte prsent et doivent tre pris en compte dans la recherche de la solution au problme : La logique d'interface utilisateur est modifie plus frquemment que la logique mtier, particulirement dans les applications Web. Il est possible, par exemple, d'ajouter de nouvelles pages d'interface ou de rorganiser les pages existantes. Aprs tout, l'un des avantages d'une application cliente lgre Web rside bien dans le fait que vous pouvez modifier l'interface utilisateur tout moment sans avoir redistribuer l'application. Si le code de prsentation et la logique mtier sont associs dans un seul et mme objet, vous devrez modifier l'objet contenant la logique mtier chaque fois que vous souhaiterez changer l'interface utilisateur. Cette dmarche risque d'introduire des erreurs et ncessite chaque modification de l'interface, mme minime, de tester de nouveau l'ensemble de la logique mtier. Dans certains cas, l'application affiche les mmes donnes sous plusieurs formes. Par exemple, un analyste prfrera visualiser les donnes dans une feuille de calcul alors que ses managers choisiront les graphiques secteur pour afficher les mmes donnes. Certaines interfaces utilisateur clientes riches prsentent simultanment plusieurs vues des mme donnes. Si l'utilisateur modifie les donnes dans une vue, le systme doit mettre jour automatiquement toutes les autres vues des donnes. La conception de pages HTML visuellement efficaces et attirantes ncessite gnralement des comptences autres que celles requises pour le dveloppement d'une logique mtier complexe. Et il est bien rare qu'une mme personne prsente cette double comptence. Il est donc prfrable de sparer l'effort de dveloppement de ces deux parties. L'activit de l'interface utilisateur se compose gnralement de deux lments : la prsentation et la mise jour. La partie prsentation rcupre les donnes depuis un entrept de donnes et les met en forme avant de les afficher. Lorsque l'utilisateur effectue une action sur les donnes, la partie mise jour passe la main la logique mtier pour mettre jour les donnes. Dans les applications Web, une simple requte de page combine le traitement de l'action associe au lien que l'utilisateur a slectionn et le rendu de la page cible. Il n'est pas rare que la page cible ne soit pas directement lie l'action. Imaginez, par exemple, une simple application Web qui prsente une liste d'articles. L'utilisateur revient la page de liste principale aprs avoir ajout un article la liste ou supprim un article de la liste. L'application doit donc rendre la mme page (la liste) aprs excution de deux commandes plutt diffrentes (ajout ou suppression) le tout dans le cadre de la mme requte HTTP. Le code de l'interface utilisateur dpend gnralement plus de la machine que la logique mtier. Si vous souhaitez faire migrer l'application d'une application sur navigateur une application sur assistant personnel ou sur tlphone mobile compatible Web, vous devez rcrire une bonne partie du code de l'interface utilisateur alors que la logique mtier pourra rester inchange. Une sparation
75
claire de ces deux lments permet d'acclrer la migration et de rduire le risque d'introduction d'erreurs dans la logique mtier. La cration de tests automatiss pour les interfaces utilisateur est gnralement plus longue et difficile que les mmes tests pour la logique mtier. On comprend donc que rduire le volume de code directement li l'interface utilisateur permet d'amliorer les capacits d'valuation de l'application. 4.1.4.Solution Le modle Model-View-Controller (MVC) spare la modlisation du domaine, la prsentation et les actions reposant sur l'entre utilisateur en trois classes distinctes [Burbeck92] : Modle. Le modle gre le comportement et les donnes du domaine d'application, rpond aux demandes d'informations sur son tat (souvent issues de la vue) ainsi qu'aux instructions de changement d'tat (souvent issues du contrleur). Vue. La vue gre l'affichage des informations. Contrleur. Le contrleur interprte les entres clavier et souris de l'utilisateur et informe le modle et/ou la vue des changements ncessaires.
La figure 4.1 prsente les relations structurelles entre les trois objets.
Figure 4.1 Structure de classe MVC
Il est important de noter que la vue et le contrleur dpendent tous deux du modle. En revanche, le modle ne dpend ni de la vue ni du contrleur. C'est l'un des principaux avantages de la sparation. Cette sparation des tches permet de crer et de tester le modle indpendamment de la reprsentation visuelle. La sparation entre la vue et le contrleur est secondaire dans la plupart des applications clientes riches et, en effet, de nombreuses infrastructures d'interface utilisateur implmentent les rles comme un seul objet. Dans les applications Web, par contre, la sparation entre la vue (le navigateur) et le contrleur (les composants ct serveur grant les requtes HTTP) est clairement dfinie.
76
Le modle Model-View-Controller est un modle de conception fondamental en matire de sparation de la logique de l'interface utilisateur et de la logique mtier. Malheureusement, la popularit de ce modle a eu pour consquence un certain nombre de descriptions errones. En particulier, le terme contrleur a t utilis pour signifier diffrentes choses dans diffrents contextes. Fort heureusement, l'avnement des applications Web a permis de rsoudre certaines ambiguts, tant la sparation entre la vue et le contrleur est vidente. 4.1.5 Variations Dans son livre, Application Programming in Smalltalk-80: How to use Model-ViewController (MVC) [Burbeck92] (Programmation d'applications Smalltalk80: utilisation du modle Model-View-Controller (MVC)), Steve Burbeck dcrit deux variantes du MVC : un modle passif et un modle actif. Le modle passif s'utilise lorsqu'un contrleur manipule le modle exclusivement. Le contrleur modifie le modle, puis informe la vue que le modle a chang et doit tre actualis (voir figure 4.2). Dans ce scnario, le modle est entirement indpendant de la vue et du contrleur, ce qui signifie que le modle n'a aucun moyen de rapporter ses changements d'tat. Le protocole HTTP constitue un exemple de ce mode de fonctionnement. Le navigateur ne dispose pas de moyen simple pour obtenir des mises jour asynchrones du serveur. Il affiche la vue et rpond l'entre utilisateur mais il ne dtecte pas les modifications apportes aux donnes sur le serveur. Le navigateur interroge le serveur sur les modifications uniquement lorsque l'utilisateur demande explicitement une actualisation. Figure 4.2 Comportement du modle passif
4.1.6 Comportement du modle actif Le modle actif est utilis lorsque le modle change d'tat sans impliquer le contrleur. Ceci se produit lorsque d'autres sources modifient les donnes et que les modifications doivent tre prises en compte dans les affichages. Considrons l'affichage d'un march boursier. Vous recevez des informations sur les actions d'une source externe et vous souhaitez mettre jour les vues (par exemple un tlscripteur et une fentre d'alerte) lorsque les donnes sur les actions changent.
77
Comme le modle est le seul dtecter les modifications de son tat interne lorsqu'elles se produisent, il doit indiquer aux vues d'actualiser l'affichage. Toutefois, l'une des raisons qui motivent l'utilisation du modle MVC est de conserver un modle indpendant des vues. Si le modle devait notifier les changements aux vues, vous rintroduiriez la dpendance que vous cherchiez viter. Heureusement, le modle Observer [Gamma95] fournit un mcanisme pour alerter les autres objets des changements d'tat sans pour autant introduire de dpendances entre eux. Chaque vue implmente l'interface Observer et s'enregistre auprs du modle. Le modle tient jour la liste de tous les observateurs qui s'abonnent aux changements. Lorsqu'un modle change, il effectue une itration sur tous les observateurs enregistrs et les notifie du changement. Cette approche est gnralement appele diter-s'abonner . Le modle ne ncessite jamais d'informations spcifiques sur les vues. En fait, dans les scnarios o le contrleur doit tre inform des changements de modle (pour activer ou dsactiver des options de menu, par exemple), les seules tches du contrleur consistent implmenter l'interface Observer et s'abonner aux changements du modle. Lorsqu'il y a plusieurs vues, il peut s'avrer utile de dfinir plusieurs sujets, chacun d'entre eux dcrivant un type spcifique de changement de modle. Chaque vue peut ensuite s'abonner uniquement aux types de modifications pertinents pour la vue. La figure 4.3 illustre la structure du MVC actif utilisant l'observateur. Elle prsente en outre la faon dont l'observateur isole le modle afin d'viter qu'il ne fasse directement rfrence aux vues.
Figure 4.3 Utilisation de l'observateur pour dissocier le modle de la vue dans le modle actif
La figure 4.4 illustre la faon dont l'observateur signale aux vues les modifications du modle. Malheureusement, il n'est pas vident de dmontrer la sparation du modle et de la vue dans un diagramme de squences UML car le diagramme reprsente des instances d'objets au lieu de classes et d'interfaces.
78
Figure 4.4 Comportement du modle actif
4.1.7 Considrations relatives au test La capacit de test est fortement amliore lorsqu'on utilise un modle Model-ViewController. Le test des composants se complique lorsque ceux-ci sont interdpendants et particulirement lorsqu'il s'agit de composants d'interface. En effet, ce type de composant ncessite souvent une configuration complexe pour tester une simple fonction. Pire, lorsqu'une erreur se produit, il est difficile d'isoler le problme sur un composant spcifique. C'est la raison pour laquelle la sparation des problmes revt une telle importance du point de vue architectural. MVC spare le problme de stockage, d'affichage et de mise jour des donnes entre trois composants pouvant tres tests individuellement. Outre les problmes poss par les interdpendances, les infrastructures d'interface utilisateur s'avrent intrinsquement difficiles tester. Le test des interfaces utilisateur ncessite soit un test manuel, fastidieux (et sujet aux erreurs), soit des scripts qui simulent les actions de l'utilisateur. Le dveloppement de ces scripts est gnralement long et dlicat. Le modle MVC n'vite pas d'avoir tester l'interface utilisateur mais, du fait que la logique de prsentation est spare du modle, ce dernier peut tre test en toute indpendance par rapport la prsentation, ce qui rduit le nombre des combinaisons de test de l'interface utilisateur. Contexte final L'organisation architecturale de la couche prsentation autour du modle MVC fait apparatre les avantages et les inconvnients suivants : Avantages Prise en charge de plusieurs vues. Comme la vue est spare du modle et qu'il n'y a pas de dpendance directe entre eux, l'interface utilisateur peut afficher simultanment plusieurs vues des mme donnes. Ainsi, plusieurs pages d'une application Web peuvent utiliser les mmes objets de modle. L'application Web permettant l'utilisateur de modifier l'apparence des pages constitue un autre exemple des avantages de cette sparation. Ces pages affichent les mmes
79
donnes partir du modle partag mais ces donnes s'affichent de diffrentes manires. Adaptation aux changements. Les exigences en matire d'interface utilisateur ont tendance changer beaucoup plus rapidement que les rgles mtiers. Les utilisateurs peuvent prfrer utiliser diffrentes couleurs, polices, disposition l'cran et plusieurs niveaux de prise en charge des nouveaux priphriques tels que les tlphones mobiles ou les assistants personnels. Comme le modle ne dpend pas des vues, l'ajout de nouveaux types de vues au systme ne l'affecte gnralement pas. En consquence, le changement porte uniquement sur la vue. Inconvnients Complexit. Le modle MVC introduit de nouveaux stades d'indirection et augmente de ce fait lgrement la complexit de la solution. Il accrot galement la nature vnementielle du code de l'interface utilisateur qui peut alors tre plus difficile dboguer. Cot des mises jour frquentes. Dissocier le modle de la vue ne signifie pas que les dveloppeurs du modle peuvent ignorer la nature des vues. Par exemple, si le modle subit des modifications frquentes, il peut inonder les vues de demandes de mise jour. Certaines vues, telles que les affichages graphiques, peuvent prendre du temps s'afficher et la vue peut alors tre dcale par rapport aux demandes de mise jour. Il est donc important de penser la vue lors du codage du modle. Le modle pourra, par exemple, regrouper plusieurs requtes en une seule notification la vue.
80
4.2. Approche des dlgus des packages 4.2.1 Introduction : Nous avons vu dans la premire partie de ce chapitre, lutilit de ce modle et ce quil apporte comme avantages tout au long du processus du dveloppement logiciel. Cependant il reste un grand travail la charge des concepteurs, pour implmenter rellement cette architecture. Ltude faite dans cette partie vise rduire cette charge et proposer une architecture fidle au MVC ainsi facile implmenter pour la plupart des applications WEB. Cette approche se base sur le principe des dlgus des packages et la programmation oriente objet, qui consiste centraliser les connaissances dun package MVC dans une seule classe constituant linterface du package et le moyen unique pour le pntrer. 4.2.2 Approche des dlgus des packages : Supposons que vous tes chargs dentreprendre une ngociation avec un prestataire de service. A priori vous savez ce que cette entreprise peut vous fournir comme produit, mais vous ne savez pas qui en particulier se chargera rellement de la ralisation du travail demand. La question est : qui devez vous vous adresser ? Dans ce genre de situation, les responsables de lentreprise sont les plus qualifis pour vous rpondre. En effet, car ils ont la connaissance sur lorganisation de lentreprise et les fonctions du personnel. Vous allez, naturellement entamer les ngociations avec eux et ils se chargeront ensuite de demander aux personnes concernes de raliser le travail demand. Lapproche des dlgus des packages sinspire fortement de cet exemple. Le terme package fait rfrence aux trois units qui constituent le modle MVC [Modle Vus Contrle]. Jai choisi le mot dlgu pour cette approche car toutes les connaissances dun package sont centralises dans une seule classe de dlgation. Cette classe soccupe du dispatching des vnements en provenance de diffrentes sources vers les classes internes du package. On peut rsumer le principe de cette approche dans les points suivant : 1. Pour chaque package on cre une classe de dlgation. 2. La communication avec les autres classes du package passe exclusivement par lintermdiaire de cette classe de dlgation. 3. Les classes de dlgation disposent dune connaissance exacte sur les autres classes du mme package. 4. A la rception dun vnement (demande dexcution dune
mthode) par une classe de dlgation. Cette dernire peut dterminer la cible de lvnement au sein de son package puis lui rediriger automatiquement cette demande dexcution.
81
4.2.3. Amlioration du faible couplage M-V-C La figure 4.5 ci-dessous montre larchitecture globale du modle MVC amlior suivant lapproche des dlgus des packages. Figure 4.5 Modle MVC avec les dlgus des Packages
Les classes commenant avec le prfixe Main savoir MainControle, MainView et MainModele correspondent respectivement aux dlgus des packages Modele, Vue, Contrle. Les classes commenant par le prfixe Base, reprsentent des classes abstraites additionnelles. Elles regroupent toutes les fonctionnalits communes aux classes de chaque package, on peut imaginer une architecture plus complexe avec une hirarchie plusieurs niveaux, suivant les besoins de chaque projet et application WEB. Les classes commenant par le prfixe page donnent un exemple sur ce que peut contenir effectivement lapplication WEB. Je prconise avec cette approche, de crer une classe de contrle et une classe de vue ainsi qune classe de modle pour chaque page de lapplication, susceptible de contenir des donnes dynamiques.
82
Il reste la charge de chaque dveloppeur de dfinir le contenu fonctionnel (proprits, mthodes ...) des classes suivant ses besoins. Nanmoins, il est important de noter que les classes du modle reprsentent linterface de lapplication cot base de donnes. Il est donc inutile de crer et dassocier de telles classes des pages qui ne demandent pas des donnes de la base de donnes. Lexemple caractristique, est celui des pages contenu driv calcul avec des scripts chargs sur le poste du client. 4.2.4 Avantages de Approche des dlgus des packages 1. Modularit : cette approche se base sur le principe dclatement des applications WEB en composants autonomes. Le modle MVC propose dj dans sa version standard trois modules (modle, vue, contrle). Cette approche amliore cette version en dcrivant une meilleure manire de procder pour arriver une implmentation simple et claire. 2. Faible couplage entre modules: nous avons vu que les trois packages disposent dune seule interface de communication avec lextrieur, ce qui permet davoir une dpendance mene au minimum entre eux. 3. Rduire la charge des concepteurs : souvent la conception des applications (web et classiques), demande un effort considrable et des comptences en terme danalyse et de mta modlisation. Si vous avez particip la ralisation dun projet informatique (srement), vous avez pu constater quune erreur de conception a souvent des implications, plus ou moins, importantes au moment du passage au codage. En effet, une fois impliqu dans le processus de codage, vous risquez de faire une erreur si vous essayer de modifier une dcision dj prise dans la phase de conception de lapplication. Pourquoi ? Parce que le codage consiste traduire ce qui a t conu en un programme qui tourne sur un support informatique. Or la conception possde lavantage de visualiser la solution depuis un niveau dabstraction plus lev. Lintrt de lapproche des dlgus des packages est de permettre de faire ce retour en arrire, car il y a peu de chose modifier dans les concepts, mis part lattribution des rles des classes spcifiques, la cration de nouvelles classes dans les diffrents packages et den informer les dlgus. 4. Evolution rapide : supposez que vous travaillez sur une application WEB conue suivant cette approche et que lon vous demande dajouter dautres modules lapplication (ex. : ajouter de nouvelles rubriques ou de nouvelles pages) La dmarche est simple, aprs avoir dfini linformation afficher et la source de cette information, limplmentation devient automatique en respectant les rgles dfinies. 5. Scurit : rediriger les vnements vers une seule cible permet une meilleure scurit, ainsi le contrle didentification et des droits daccs est centralis, ce qui loigne le risque doubli (ex. : oublier de scuriser le point dentrer dun nouveau module). 6. Maintenance aise : travailler sur des modules fonctionnellement spars permet de raliser des tests prcis et facilite la dtection des sources derreurs. Sil sagit dun problme daffichage vous savez pertinemment que cest dans la vue quil faut chercher.
83
7. Gnration automatique du code natif : la gnration automatique du code natif depuis des schmas de modlisations UML est devenue dsormais une pratique courante dans la plupart des outils de modlisation. Cependant, il nest pas courant de trouver de tels outils pour les langages de dveloppement WEB (PHP, ASP, ) mais on sy dirige petit petit car il y a une forte tendance vers POO. Le langage PHP implmente dans la version 5 les concepts de la programmation oriente objet. Dautres outils commencent intgrer ces techniques, tel que CodeCharge3, Dreamweaver. 8. Distribuer les responsabilits suivant les comptences : cet avantage hrit du modle MVC, comme il sagit de travailler sur 3 aspects fondamentalement diffrents (Modle, Vue, Contrle) il permet de diviser lquipe de travaille en trois grands groupes ; chacun se voyant affecter la charge dun module. En outre, il est rare de trouver des comptences du codage et dinterface runies chez une mme personne.
4.2.5 Inconvnients Approche des dlgus des packages 1. Demande des comptences de POO : jai voqu ce point en tant quinconvnient, bien que lon puisse le considrer comme un avantage. En effet, le dveloppement WEB est ouvert le plus souvent, des concepteurs non confirms. Le dveloppement objet reste prsent rserv aux professionnels du mtier. 2. Rigoureuse au moment de la conception : le modle MVC est un moyen thorique pour mieux organiser larchitecture des applications afin damliorer la productivit. Cette approche perfectionne ce modle et ajoute de la clart son implmentation technique. Mais elle exige une bonne conception cest dire son adaptation aux besoins de chaque application WEB. Notes : Cette approche est valable pour la plupart des applications WEB. Par contre il est inutile dy faire recours dans deux cas : 1. 2. Quand il sagit de site web contenu statique. Applications dynamiques de petites taille et non volutives : dailleurs cest le cas du MVC. Lobjectif est de rduire la charge du concepteur et non pas de compliquer sa tche. Mlanger tous les aspects (logique mtier et application) rvle un intrt crucial quand le contenu de lapplication est restreints.
4.2.6 Exemple dimplmentation de lapproche des dlgus des packages Ce chapitre tait loccasion pour prsenter notre approche des dlgus des packages, qui vise optimiser et simplifier larchitecture conceptuelle des applications orientes objet en gnral et les en particulier les application web. Nous avons pu raliser tout un projet suivant cette approche. Cest le projet Merlin dcrit dans le chapitre 5 suivant, o larchitecture de lapplication a t soigneusement ralise pour respecter les concepts dfinis dans ce chapitre.
84
Conclusion Le modle MVC a fait preuve defficacit il y a bien longtemps. Lapproche des dlgus des packages vise renfoncer la segmentation de diffrentes composantes dun systme informatique, et de fournir une mthode dimplmentation pratique. Lavantage de faire recours cette approche, est de pouvoir suivre laspect dynamique dune application. En effet, dlguer la communication dune composante architecturale une seule classe, garantie la centralisation des messages entrants/sortants et offre ainsi une meilleurs traabilit des trames changes. Le chapitre suivant est consacr limplmentation de cette approche dans un projet dinformatique dcisionnelle.
85
5
Application & Implmentation
5.1 Introduction Nous avons pu concrtiser les concepts tudis dans ce mmoire dans plusieurs projets informatiques de grandes ampleurs, il sagit prcisment dun site web et dune srie dapplications Intranet implmentes dans un environnement industriel pour grer le systme dinformation dune entreprise. Nous allons nous contenter dexposer deux projets qui ont ts dvelopps respectivement pour le compte des socits ECS-Schindler1 et AFP2. Le premier projet, est une implmentation effective de lapproche des dlgus des packages pour une solution de linformatique dcisionnelle avec un Data Warehouse. Le deuxime est un site web (www.afp-lemans.fr) intgrant un diteur des contenus destin amliorer la cration et ldition des sites web. 5.2 Le projet MERLIN 5.2.1 Contexte Ce projet sinscrit dans la volont de lentreprise ECS-Schindler1 renforcer son systme dcisionnel, afin de permettre aux dcideurs de disposer dinformations et de rponses des questions cruciales, pour la prise de dcision et la planification dune stratgie marketing cible.
1 : ECS-Schindler (Elevator Car System) : est une unit de production rattache au groupe multinational Suisse Schindler spcialis dans la fabrication et la commercialisation dascenseurs et descaliers mcaniques. Leader mondial des escaliers mcaniques et leader europen des ascenseurs, le groupe Schindler est implant dans plus de 140 pays. ECS est une usine de production de cabine dascenseur Schindler situe la ville de Mulhouse en France. Elle reoit ses commandes travers un systme de gestion intgr ERP/SAP en provenance des autres entits Schindler lchelle mondiale. Ds rception un systme dimport automatique rcupre le dtail de ces commandes dans une base interne oracle pour raliser des traitements spcifiques, Chaque commande suit un flux de production et en parallle un circuit informatique de validation trs strict avant dtre expdie au client. 2 : AFP (Association pour la Formation du Personnel) est spcialise dans l'audit conseil en ressources humaines et la formation du personnel : Management, Communication, Technique, Productique, Mcanique, Maintenance, Production. Elle prpare aussi les jeunes aux diffrents diplmes professionnels. Les demandeurs d'emploi aussi peuvent acqurir des comptences au sein de lAFP.
86
5.2.2 Dnomination du projet Pour simplifier le rfrencement de ce projet, nous nommerons MERLIN lensemble des entits de celui-ci. [Ainsi ce mot dsigne le projet en question. Ce choix a t pris seulement dans le seul but de simplification.] 5.2.3 Problmatique Lentreprise dECS-Schindler dispose dun nombre important de sources de donnes (ERP/SAP, Notes/GSM, Base oracle, Base Access, fichiers Excel). Avant la mise en place de ce projet il nexistait pas de moyens pour fusionner toutes ces sources de donnes afin den extraire de linformation. Souvent la dimension dune rponse fait appel plusieurs sources de donnes, il nest pas impossible de rechercher dans ces sources pour trouver la rponse mais il est rare de disposer du temps ncessaire pour le faire. Il faut pouvoir donner une rponse immdiate lors dun appel tlphonique dun client ou dun responsable hirarchique. Lambition de lentreprise est darriver viter des erreurs de dcision dues au manque dinformations aux moments opportuns. 5.2.4 Solution Avant darriver laborer une solution une problmatique il faut faire un effort considrable afin de comprendre le besoin et faire le point sur ltat de lart des technologies et des solutions existantes. Dans notre cas, il est question dun traitement de grande masse de donnes en provenance de plusieurs sources de donnes non homognes. Typiquement la solution cette problmatique est la mise en place dun data warehouse (Annexe A) (entrept de donnes). Il sagit dune solution de linformatique dcisionnelle qui exploite les donnes des entreprises dans le but de faciliter la prise de dcision (par les dcideurs). A ce titre, le Data Warehouse doit tre rapproch de tous les concepts visant tablir une synergie entre le systme dinformation et sa stratgie.
Objectifs de MERLIN : 14. Permettre une prise de dcision rapide. 15. Tableaux de bord disponible de manire dynamique. 16. Accs direct par lutilisateur final via un navigateur Web. 17. Un seul systme interrog assurant performance et cohrence. 18. Mettre en valeur les connaissances et le savoir-faire de l'entreprise. 19. Archivage et accessibilit des donnes. 20. Croiser les donnes des diffrentes sources pour en extraire linformation.
de
Ce projet tait loccasion pour implmenter lapproche des dlgus des packages expose dans le chapitre 4. Nous avons respect larchitecture de cette approche ; chaque page de notre systme est reprsent par les trois composantes MVC et
87
toutes les transactions des vnements transitent via les dlgus des packages pour saligner aux principes de lapproche. 5.2.5 Technologies employes Plusieurs technologies ont t utilises : DELPHI pour limportation des donnes et le paramtrage de ETL. Serveur dapplication : PHP 4.3.10 pour la consultation web. Serveur http : Apache. C /Labwindow : pour lapplication des bancs de test : lutilisation de cet environnement tait secondaire, PL/SQL : pour les dclencheurs et les procdures stockes. SGBD : o Oracle : comme source et cible de donnes. o Access : source de donne o Notes : utilisation de SQLNotes avec ODBC o SAP : utilisation de lActiveX
Pour des contraintes de performances et budgtaires lies la politique de la socit, le choix dOracle apparat le plus vidant, en effet, la masse dinformations traites ncessite un SGBD client/Serveur robuste, en plus lentreprise dispose dune licence Oracle ce qui vite un investissement assez important. En plus oracle a lavantage de faciliter limplmentation de plusieurs profils de connexion pour assurer une scurit renforce (voir type de requte plus loin dans ce chapitre 5.2.12.3). 5.2.6 Notion dindicateur Un indicateur est un ensemble dinformations structures qui permet un dcideur de prendre des dcisions ou de prvoir des mesures mettre en place pour assurer un niveau de qualit prvu dans la politique dune organisation . La dtermination des indicateurs pertinents est une tape cl dans la russite de nimporte quel systme dcisionnel. Elle dtermine son ventuelle frquence dutilisation ainsi sa valeur rajoute au sein dune organisation. Souvent cette tape slabore par plusieurs runions de travail, avec les dcideurs et les potentiels utilisateurs du futur systme, pour accueillir un maximum dinformations sur le fonctionnement du processus dcisionnel de lorganisation et cela tout au long du projet. Pour lutilisateur final le rsultat doit tre instantan et exploitable pour la prise de dcision, ce qui implique une prsentation intuitive et la possibilit de visualiser les rsultats suivant plusieurs faons dont la plus utilise est la notion de tableaux de bord. Les objectifs de tous les systmes dcisionnels tournent autour du principe des indicateurs ; meilleurs sont les indicateurs implments, meilleurs sont les rponses fournies et en dpend la position stratgique de ces systmes au sein de lentreprise.
88
5.2.6.1 Indicateurs ECS-Schindler Chaque entreprise dispose de ses propres indicateurs, il est vrai que certains dentre eux peuvent tre communs plusieurs entreprises, mais souvent le pige invisible, cest dessayer de calquer ou de projeter les indicateurs dune entreprise sur une autre sans aucune tude fonctionnelle auprs des utilisateurs concerns. Cette dmarche engendre une fuite en masse de ces potentiels utilisateurs, et la solution demeure obsolte car elle ne rpond plus leurs attentes. Aprs plusieurs runions de travail avec les futurs utilisateur du systme, nous avons pu dfinir un certain nombre dindicateurs importants pour lentreprise, en voici une liste non exhaustive : Suivi des commandes : chaque fois savoir le nombre de commande suivant son statut : o Statut lancement : Entre, Traite, Bloque o Statut production : En production, En quarantaine, Produite o Statut expdition : Expdie, Non Expdie. Suivi chiffre daffaires : Permet de connatre le chiffre daffaires ralis avec un client (ou lensemble des clients) par produit dans une priode donne. Suivi des retards : Permet de connatre la liste des commandes en retard par type de produit. Paramtre commande : Permet de consulter les paramtres techniques dune commande.
5.2.7 Alimentation du Data Warehouse Comme nous lavons annonc dans la problmatique, les sources de donnes sont multiples. La prsence des donnes ncessaires pour la prise dune dcision dans ces multiples sources en mme temps implique des recherches fastidieuses et des temps de traitement trs importants, ce qui complique la tche des dcideurs.
Pour prendre la dcision daugmenter le chiffre daffaire avec un client il faut connatre : Type des commandes : base de production Ponctuation du payement des redevances : base comptabilit Solvabilit : donne juridique . Cest l o interviens les ETL. ETL (Extract-Transform-Load ou extraction-transformation-chargement) ? A lorigine les donnes peuvent tre de diffrentes sources de donne de lentreprise, ce stade elles se prsentent de manire brute. Afin quelles soient exploitables, une tape de filtrage et de prtraitement est ncessaire (rle des ETL). LETL est un logiciel programm pour tourner priodiquement (ex. Une fois chaque nuit) en se connectant aux diffrentes sources, rcuprer les donnes et effectuer les traitements ncessaires avant dalimenter le Data Warehouse.
89
La figure 5.1 montre une vision globale de larchitecture du projet MERLIN. Figure 5.1 Sources de donnes MERLIN
5.2.8 Diagramme des cas dutilisation Pour simplifier le diagramme des cas dutilisation nous prsenterons un seul niveau dhritage. (figure 5.2)
90
Figure 5.2 Diagramme des cas dutilisations
Il nest pas lieu ici de dtailler toute limplmentation technique de notre systme, nous nous contentons de prsenter un seul cas dutilisation parmi les plus importants et les plus complets savoir commandeVente. Pour dcrire notre cas dutilisation nous utilisons la description textuelle expose dans le chapitre 3. Description textuelle du cas dutilisation CommandeVente Figure 5.3 Dtail du cas dutilisation : CommandeVente
CU Commande vente
Description Permet un commercial de connatre le nombre de commandes entres, traites ou bloques par type de produit dans une priode donne. (figure 5.3)
91
Fiche descriptive Fonctionnalit Type Nom Numro squentiel Acteurs concerns Prsupposition Pr-conditions Dmarrage Arrt Description Cas dutilisation Commande vente CU002 COOMERCIAL Utilisateur identifi avec succs Saisir une priode valide ou rien A la demande Informations affiches Echec de connexion la base de donnes Lutilisateur annule sa demande Le dlai dattente est coul Informations affiches
Post-condition
5.2.9 Diagramme de squence : Comportement dynamique du systme Le diagramme de squence de la figure 5.4 constitue une vue dynamique associe au cas dutilisation commandeVente. Figure 5.4 Prsentation dynamique avec le diagramme de squence
92
Le diagramme de la figure 5.4 implmente le cas dutilisation commandeVente, cependant, comme nous lavons expliqu dans le chapitre 4, lapproche des dlgus des packages utilise dans ce projet impose dutiliser le mme scnario dexcution pour lensemble des pages, ce qui change ce sont les implmentations des mthodes mtiers et lutilisation des classes utilitaires. Ce qui suit est une description textuelle dun diagramme de squence valable tous les flux respectant lapproche des dlgus des packages. Utilisateur : Demande dune page View : 1. Cration dune instance de la classe mainView. 2. Excution de la mthode viewDispatch qui rcupre les paramtres utilisateurs. 3. Cration de la classe view pour la page sollicite par lutilisateur. Contrle : 4. Cration dune instance de la classe mainControle. 5. Evaluation des paramtres dentre par la mthode dispachControle 6. Cration de la classe contrle pour la page sollicite par lutilisateur Modle : 7. Cration dune instance de la classe mainModele. 8. Evaluation des paramtres dentres par la mthode dispachModele 9. Cration de la classe modle pour la page sollicite par lutilisateur 10. Excution de requtes SQL pour interroger la base de donnes 11. Transmettre les donnes la classe de contrle. Contrle : 12. Traitement des donnes avec les processus mtiers implmentes dans les classes de contrles. 13. Envoyer le rsultat des traitements la classe view view : 14. Formatage des donnes reues de la classe de contrle. 15. Affichage des donnes dans linterface utilisateur.
93
5.2.10 Diagramme des packages Figure 5.5 Diagramme des packages MERLIN
5.2.11 Utilisation de lapproche des dlgus des packages Limplmentation de lapproche des dlgus des packages dans ce projet tait simple, chaque indicateur se voit attribuer un tripl de classe MVC, et chaque classe de chaque package implmente la mthode principale de la classe de base savoir veritableExecuteAction et la mthode dabonnement auprs de la classe main (voir chapitre 5). 5.2.11.1 Diagramme de classe Figure 5.6 Diagramme de classe partiel du package CONTROLE (MVC avec les dlgus des packages)
Classe CTR_MainControler : Classe dlgue du package CONTROLE. La mthode controleDispatch() dispatche les vnements en provenance des vues vers les diffrentes classes du package CONTROLE pour implmenter des traitements mtiers.
94
La classe CTR_BaseControler est une classe de rfrence pour lensemble des classes du package, elle implmente des mthodes communes plusieurs classes du package. De la mme manire les deux autres packages implmentent les mmes classes.
Figure 5.7 Diagramme de classe partiel du package MODELE (MVC avec les dlgus des packages)
Classe CTR_MainModele : Classe dlgue du package MODELE. La mthode modeleDispatch()dispatche les vnements en provenance des classes externes vers les diffrentes classes du package MODELE pour raliser des oprations sur la base de donnes. Figure 5.8 Diagramme de classe partiel du package VUE (MVC avec les dlgus des packages)
Classe CTR_MainView : Classe dlgue du package VIEW. La mthode viewDispatch() dispatche les vnements en provenance des classes externes vers les diffrentes classes du package VIEW pour essayer de comprendre les actions de lutilisateur et prparer laffichage des donnes retournes par le package CONTROLE.
95
Les classes de dlgation sont : 1. VUE.VW_MainVIEW 2. CONTROLE.CTR_MainControler 3. MODELE.MD_MainModele 5.2.11.2 Principe dabonnement des classes dun package : Les classes de dlgation reoivent tous les vnements en direction dun package, lexcution de la mthode dispatche permet de connatre le destinataire de lvnement externe. Une fois que le destinataire est connu, la mthode cre une instance de la classe dsigne par lvnement externe et lui transmet le contrle pour raliser le traitement demand. Le constructeur de la classe de contrle doit sabonner auprs du dlgu du package pour que ce dernier accepte le rsultat du traitement achev. Ce principe est optionnel, nanmoins, il permet de mieux contrler et de suivre les instances des classes cres, son utilit se manifeste clairement dans le dbogage du systme. Une classe abonne : est une classe dont le dlgu garde un pointeur (vers) sur son adresse mmoire. Labonnement des classes permet de sassurer : Un meilleur dboguage du systme Une meilleure gestion de la mmoire (garbage Collector )
5.2.12 Modle de donnes : Pour pouvoir exploiter facilement les donnes, nous avons implment une modlisation par sujet fonctionnel plutt que par application. Malgr que pour linstant il nexiste quune seule application utilisant ce modle cette solution saligne sur lambition de lentreprise pour gnraliser cette application pour dautres services. Ainsi lintgrit des donnes est garantie et laccs est ralis plus efficacement aux donnes. Cette solution est commune aux data warehouse car leurs objectifs est de rpondre des questions stratgiques orientes sujet. Et cest bien ce qui les diffrencient des bases de donnes ordinaires ( figue 5.9)
96
Figure 5.9 Base de donnes classiques et Data Warehouse Personnel Donnes produit
Comptabilit
Donnes client
Production
Data Warehouse
5.2.12.1 Modle physique de donnes MPD La figure 5.10 montre lutilisation du modle en toile, qui consiste centraliser linformation dans une table centrale (MR_COMMANDEVENTE) appele table de fait et la relier des tables secondaires appeles table de dimensions. Le modle montre la simplicit de la solution adopte pour implmenter la consistance des donnes. Remarquez quil existe une table "gigantesque" MR_COMMANDE, en fait, nous aurions pu clater cette relation sur plusieurs relations suivant le modle relationnel pour respecter les formes normales canoniques (exemple crer une entit lot) cependant, nous avons considr dautres facteurs dans notre choix que la normalisation : 1. La simplicit des requtes 2. La frquence des requtes sur les attributs dune entit : exemple : il est inutile de crer une entit pour les lots sil nexiste pas des demandes de consultation des dtails des lots. 3. Respecter le modle en toile qui rpond au mieux aux besoins des applications Data warehouse. Le modle en toile est optimis pour les requtes d'analyse et souvent considr, tort, comme un modle dnormalis, parce que ses objectifs sont plus spcifiques et plus pointus que ceux des bases de donnes ordinaires.
97
Figure 5.10 Modle physique de donne Modle en toile
98
La figure 5.11 montre la deuxime partie du modle physique de donnes, consacre lETL (Extract-Transform-Load) Figure 5.11 Modle physique de donne Modle en flocon "neige"
99
5.2.12.2 Evolution du modle Comme nous lavons mentionn prcdemment cette application est fortement sollicite pour voluer et prendre forme afin dinclure dautres services et couvrir un secteur plus vaste des donnes de lentreprise, ce titre il est indispensable de revoir notre modle de donne afin de supporter ces ventuelles volutions. Le modle en toile vise rduire au maximum le nombre des tables de fait, cependant linsertion dune table de fait savre invitable lorsque lon se retrouve devant des entits fonctionnement distinctes. Figure 5.12 Plusieurs tables de fait dans un modle en toile
La figure 5.12 montre lutilisation de plusieurs tables de fait pour modliser des vues fonctionnelles diffrentes de notre modle et de regrouper les entits suivant les modles danalyses tablis dans les perspectives du Data warehouse pour rpondre au mieux aux attentes des utilisateurs. La fusion ou lclatement des tables de fait dpend, en premier, du regroupement des indicateurs par liste dattribues intervenant dans lexcution des requtes SQL. Ceci revient essayer de regrouper dans chaque table de fait les attributs cls correspondants des indicateurs fonctionnellement lis. La figure 5.13 montre cette interdpendance entre groupes dindicateurs et les attributs des tables de fait.
100
Figure 5.13 Eclatement des tables de fait

Table de fait
Indicateurs de comptabilit Indicateur 1 : Suivi des commande Indicateur 2 : Suivi de payement Indicateur 3 : Chiffre d'affaire ... ... ...
Attr Attr Attr Attr Attr Attr Attr Attr ... ... ...
Eclatement de la table de fait
0 1 2 3 4 5 6 7
Indicateurs de Production Indicateur 4 : Suivi de production Indicateur 5 : Suivi d'expdition ... ... ... ...
Table de fait
Indicateurs de comptabilit Indicateur 1 : Suivi des commande Indicateur 2 : Suivi de payement Indicateur 3 : Chiffre d'affaire ... ... ...
Attr Attr Attr Attr
0 1 2 3
Table de fait
Attr Attr Attr Attr
4 5 6 7
Indicateurs de Production Indicateur 4 : Suivi de production Indicateur 5 : Suivi d'expdition ... ... ... ...
Table de fait
... ... ... Ce modle amliore nettement lefficacit de notre base de donnes en terme de temps dexcution pour la plupart des requtes. Mais cette amlioration souvent est ralise en dpit de dautres indicateurs (indicateur 3 de la figure 5.13) qui se voient compliquer les requtes de slection, dans ce genre de situation, il faut arriver trouver un compromis de juste milieu, de manire isoler les indicateurs secondaires et favoriser lefficacit des requtes pour les principaux indicateurs. A noter que la valeur dun indicateur se traduit par sa frquence dutilisation et sa valeur stratgique dans lentreprise. 5.2.12.3 Type des requtes
Une des principales caractristiques des Data warehouse, est que les donnes sont
non volatiles et leur enregistrement est dfinitif. En pratique, il est strictement interdit dexcuter des requtes de mise jours ou de suppression sur les donnes du data warehouse par lutilisateur, mis part les requtes de slection qui sont autorises. Pour remdier ce problme nous avons utilis une technique ORACLE
101
en crant plusieurs profils utilisateurs spcialiss, la figure 5.14 montre lutilisation de ces profils Figure 5.14 Profils daccs la base de donnes
www.merlin :8080 ( Php )
Application ETL
ORACLE
Donnes MERLIN MerlinAdmin

Read/ Write
Read
MerlinRead Base de configuration

Read/ Write
MerlinStatistque
Trois profils sont implments pour moduler les droits daccs suivant le besoin et suivant lapplication hte : MerlinAdmin : dispose dun contrle total sur la base de donnes, utilis par lapplication ETL pour alimenter la base de donnes de diffrentes sources et pour modifier la configuration de la base de lETL. MerlinRead : dispose dun droit de lecture sur la base Merlin contenant les donnes de notre Data warehouse. Accder la base travers ce profil nouvre le droit qu des requtes de slection. Ce profil est utilis par lapplication de consultation via un navigateur web. MerlinStatistique : Dispose dun contrle total sur la base de configuration de lETL qui contient des statistiques de consultation (nombre de connexion, rpartition des tches, frquence dutilisation des indicateurs) Pourquoi ce profil ? On aurait pu utiliser le profil MerlinAdmin pour accder cette base de donnes, mais cette application est accessible de lextrieur par des utilisateurs multiples ce qui augmente le risque dune utilisation malveillante. Cette technique a lavantage de dlguer lassurance de la scurit des donnes de notre systme lSGBD ORACLE qui constitue une rfrence en la matire.
102
5.2.13 Interface (Ecrans) Linterface graphique reprsente aux yeux des utilisateurs un lment dvaluation trs prsent, ainsi un systme bien labor au sens du mtier, mais qui nglige sa prsentation, est soumis invitablement lchec. Nous avons essay de respecter les critres ergonomiques exposs dans le premier chapitre travers un processus de validation des maquettes auprs des utilisateurs et nous avons tabli aussi un questionnaire type pour vrifier lapplication de ces critres. Comme lapplication est destine un usage purement professionnel, nous avons adopt une interface sobre caractre professionnel visant mettre en avant les attentes des utilisateurs. Le moteur de recherche change de critre dune page lautre pour rpondre des recherches personnalises. Etant donn que le rsultat de lensemble des indicateurs sont des chiffres calculs base des donnes de lentreprise, nous avons intgr une fonctionnalit dexport vers Excel pour raliser des ventuels traitements sur ces rsultats. Un seul menu de navigation, permet datteindre nimporte quelle page des indicateurs, et depuis ces pages lutilisateur peut accder au rsultat de ces recherches.
103
La figure 5.15 affiche un certain nombre dindicateurs (Statut lancement : Entres, traites, bloques). Les indicateurs sont calculs sur des priodes paramtrables par lutilisateur. Figure 5.15 Ecran : Affichage de plusieurs indicateurs
Cet cran est un aperu de la capacit de notre systme agrger de grande quantit de donnes en provenance de plusieurs sources de donnes pour prsenter le rsultat sous forme dinformations trs utiles la prise de dcision.
104
Dans le mme esprit de sobrit et de professionnalisme lcran suivant (figure 5.16) reprsente un masque de recherche des commandes entres et le dtail dune recherche.
Figure 5.16 Ecran : Dtail dun indicateur
5.2.13.1 Module des statistiques Comme nous lavons mentionn dans le modle de donne, il existe une base de donnes ddie ladministration du site et la sauvegarde des statistiques sur la frquence dutilisation du site par les utilisateurs. Ici aussi, on retrouve le principe des indicateurs pour prsenter cette information (La figure 5.17) Le principal objectif de garder ces statistiques est de promouvoir les indicateurs peu consults en sapprochant des utilisateurs pour comprendre et couter leurs propositions damliorations.
105
Figure 5.17 Ecran : Statistiques de consultation
5.2.14 Avantages constats avec lutilisation de lapproche des dlgus des packages Comme nous lavons mentionn dans le chapitre 4 lapproche des dlgus des packages est rigoureusement exigeante dans la phase de conception, chose qui consomme beaucoup de temps alors que le planning de ce projet t trs serr. Le seul argument qui a fait pencher la balance en faveur de cette approche est la perspective dvolution de ce projet pour inclure dautres services de lentreprise. Effectivement, avec cette approche - purement oriente objet linsertion dun nouvel indicateur devient (aprs sa validation au sens mtier) presque une tape techniquement mcanique, il suffit de respecter les recommandations techniques de lapproche, do la perspective de concevoir un EDI ddi qui permettrait lencapsulation de la mise en place dune architecture MVC respectant lapproche des dlgus des packages.
106
5.3 Site WEB AFPLemans 5.3.1 Prface Le deuxime projet que nous prsentons dans ce chapitre est un site Web ralis pour le compte de lentreprise AFP Le Mans. Vous trouverez dans cette partie une brve description de la structure du site et plus en dtail le fonctionnement de lditeur des contenus intgr dans le site pour faciliter la mise jour du contenu du site. Nous ne nous concentrerons pas sur le contenu du site mais surtout sur le cot technique au sens informatique, cest dire les technologies utilises et limplmentation dun diteur des contenus qui sera lobjet principal de cette partie. 5.3.2 Contexte LAFP mene par le souci de donner une nouvelle image, qui reflte les changements structurels au sein de son organisation et un nouveau moyen ses clients de bnficier des opportunits de communication sur le Web. Les clients de lAFP, sont des demandeurs demplois, des employs dentreprises, des tudiants ayant diffrents niveaux dtudes dsirant acqurir une formation professionnelle ; le dfi est de rpondre aux besoins de toute cette varit de clients potentiels. Le site devra prsenter linstitution mais surtout rpondre aux attentes des internautes cherchant une solution leur problmatique de formation. Lobjectif fondamental du site de lAFP, est daugmenter son efficacit en permettant aux diverses catgories de clients de trouver rapidement les formations qui rpondent le mieux leurs attentes et de pouvoir tlcharger des formulaires dinscriptions ces formations. Le site est destin tre actualis frquemment pour mettre jour la liste des formations et le contenu informationnel, cependant, les personnes charges de cet entretien et volution continue du site, ne sont pas forcment des informaticiens cest pourquoi on doit leur fournir un moyen facile et intuitif ne ncessitant aucune intervention au niveau du code. 5.3.3 Technologies utilises Nous avons utilis plusieurs technologies pour mettre en place ce site : PHP : pour les scripts de cration et de navigation dans les fichiers XML. Flash : avec son langage de programmation propritaire orient objet ActionScript driv du langage C ddie pour la manipulation et le contrle des animations Flash. Flash constitue le principal support daffichage du site, le noyau de lditeur des contenus est dvelopp sous FLASH. XML : pour enregistrer les contenus dynamiques du site dits par lditeur des contenus. MySQL : la quantit des donnes traites dans le cadre de ce projet en prenant en compte les ventuelles volutions prvues est relativement modeste, dans cette perspective nous avons choisi dutiliser MySQL car il est gratuit et assez puissant pour grer une telle quantit de donnes et de frquence dutilisation.
107
5.3.4 Choix de la technologie XML Effectivement le choix dXML ntait pas un hasard, comme nous lavons vu dans le chapitre 2 qui lui a t consacr, le langage XML offre une palette de nouveauts efficacement exploites et testes pour raliser diverses applications robustes et de grandes ampleurs. Notre exprience avec XML avait dbut avec des applications classiques sous le langage Java (qui ne sont pas lobjet de ce thme), elle nous a permis de dcouvrir sa puissance et son utilit. Nous avons su aprs ltude des besoins quXML rpondra au mieux limplmentation des attentes des utilisateurs envers leur futur site web. 5.3.5 Structure du site Nous avons repris un classique de structuration des applications contenus dynamiques, savoir, les deux modules Back Office et Front office : Back Office (le module dadministration) : regroupe toutes les fonctionnalits dadministration du site et de la base de donnes. Cette partie du site est destine tre utilise en interne pour la mise jour du site, elle est protge par une tape didentification. La mise en place de cette partie tait la plus longue dans les phases de ralisation de ce projet. Front office : constitue le site proprement dit aux yeux des internautes, cest linterface WEB du site sans restriction daccs.
Ce choix se justifie par lexistence - bien clair - de ces deux catgories de fonctionnalits dans notre site web, cette sparation entre les deux parties est lorigine de limplmentation de lditeur des contenus pour la partie back office. 5.3.6 Intgration des moyens de modification dynamique Nous dtaillerons dans cette partie quelques principes en relation avec le sujet de ce mmoire savoir lintgration des moyens de modification dynamique. En quoi consiste un moyen de modification dynamique ? Il nexiste aucune dfinition formelle cette expression, cependant, on peut classer dans cette catgorie tous les moyens et techniques utilises en vue de faciliter et damliorer la modification et la mise jour des sites web. Plusieurs firmes de software concentrent des efforts importants pour innover de nouvelles approches visant augmenter le potentiel du web. Exemples de moyens de modification dynamique : Structuration conventionnelle de site Normalisation des interfaces utilisateurs. Suppression ou diminution du recours la modification du code pour la mise jour de la structure ou du contenu des sites web Gnration automatique des scripts de modifications. .
Le march des outils destins au dveloppement web constitue un des plus grands marchs en terme du nombre dutilisateurs et il est en constante volution en gagnant chaque jour un nouveau public. Cette constatation saffirme devant le
108
nombre colossal des sites web dvelopps travers le monde. Plusieurs explications peuvent tre donnes pour cette tendance, mais la plus pertinente est celle qui met la lumire sur leffort ralis par les concepteurs de ces outils pour sapprocher de leurs utilisateurs les plus modestes au sens technique, en leurs offrants des environnements intgrs allant jusquaux ateliers du gnie logiciel intgrant des outils de conceptions graphiques encapsulant la complexit des langages de programmation. Lutilisateur (dveloppeur web) se voit dgager de leffort dapprendre la syntaxe et la smantique des langages de programmation, ainsi il concentrera son effort sur les rgles du mtier et la matire de son site web. Cette productivit encourage les utilisateurs continuer et attirer de nouveaux utilisateurs. Il existe un autre point trs important pour la survie des sites web. Un contenu peut devenir trs vite dsuet, en effet, le contenu et la prsentation dun site web sont souvent sujettes des modifications pour assurer leur pertinence et cohrence. Cette tape et trs lassante et coteuse si lon doit (fouiller) dans les piles de code. Les dveloppeurs des sites prconisent des outils de dveloppement intgrant la possibilit de modifier le site dynamiquement, sans passer par des transferts FTP. Ce que nous proposons dans le site dvelopp est dintgrer directement sur le serveur un diteur permettant la modification en ligne du contenu sans passer par des transferts FTP. 5.3.7 Exemple doutils facilitant ldition des contenus : Macromedia Dreamweaver, Macromedia Fireworks, SUN Java Studio Creator, CodeCharge, WebEdit. Tous ces outils fournissent beaucoup de facilit pour la cration et la mise jours des sites web. 5.3.8 Editeur des contenus intgr Dans la premire version, nous avons propos de sparer ladministration du site dans une application part, mais avec lavancement de la phase de conception nous nous sommes aperus que les modules de modifications se chevauchent fortement avec les modules de lecture, cest pourquoi nous avons commenc penser autrement do la naissance de lide de fusionner les deux modules (Administration et Affichage) en une seule et unique application. Cest quoi lditeur intgr des contenus ? Lditeur des contenus est un programme informatique, pour la gnration dynamique des sites web. Sa spcificit est son intgration avec le site web, cest dire physiquement, le programme est transfr sur le serveur hte du site, ainsi pas besoin de faire des transferts FTP pour apporter des modifications au contenu du site. Accessible directement avec un navigateur web et scuris par un mot de passe il permet dadministrer le site web et la base de donne, utilise la technologie XML pour sauvegarder les donnes et la description de linterface du site. La puissance de lditeur des contenus : Sa capacit traiter plusieurs formes de fichier (animation, image, texte)
109
Bas sur la technologie XML, avec toute son ouverture sur plusieurs langages de programmation. La cration rapide des sites web Possibilit de raliser facilement des modles de sites gnriques, destins tres paramtrs par les utilisateurs pour crer leurs propres sites web. Faciliter lentretien des sites web. Permettre interoprabilit avec dautres systmes de gestion de sites web en dfinissant et respectant un protocole dchange avec les schmas XML. Archivage facile des versions, il suffit de garder une copie des fichiers XML gnrs.
Inconvnient Lditeur, avec sa version actuelle nest pas riche en terme de fonctionnalit, cependant, la perspective denrichir la bibliothque utilitaire par de nouvelles fonctionnalits et louverture sur dautres formats de fichier met en valeur lide de cet diteur. La mise en place de nouvelles fonctionnalits est trs lourde et demande beaucoup de temps pour prendre en compte les varits des langages de programmation et des normes du dveloppement web.
5.3.8.1 Ce qui est possible avec lditeur des contenus Modifier trois types de contenu : Les zones de texte : avec lditeur des contenus, il est possible de crer/modifier autant de zones de texte que lon veut. Changer leur position sur les pages du site. Les animations : possibilit de changer la position, le contraste et la transparence. Les images : possibilit de changer la position, le contraste et la transparence.
5.3.8.2 Fonctionnement de lditeur des contenus Lditeur est accessible dans le mode administration du site (Back office) protg par mot de passe. Ce mode reprend la mme interface de visualisation du site, ainsi ladministrateur peut visualiser un aperu de ses modifications avant de les valider.
110
5.3.8.3 Architecture gnrale Figure 5.18 Architecture gnrale
Interface utilisateur
FichierXML
XMLLoader
Interface Consultation
XMLGenerator
Interface Administration
Figure 5.19 Une partie du diagramme de classe de l diteur des contenus
5.3.8.4 Description des principales classes package org.merlin.xmlManager Classe XMLFile Classe mre des classes des traitements lis aux fichiers XML. Classe XMLLoader Cette classe a pour rle de charger les fichiers XML associs aux pages du site, le chargement du fichier XML consiste parcourir tous les nuds et de les charger en mmoire. Classe XMLGenerator
111
Utilis par lditeur des contenus pour gnrer de nouveaux fichiers XML ou de modifier des existants Classe Contenu. Classe mre des types de contenus que lditeur des contenus peut manipuler. Toute insertion de nouveaux types doit hriter de cette classe. Classe Action Classe mre des actions (lecture, dplacement, suppression ) que peuvent raliser les objets de type contenu. Remarque : Pour la modlisation de cette application nous avons utilis PowerMAc de Sysbase. 5.3.9 Le fichier XML Lditeur des contenus doit sa flexibilit lutilisation du langage XML pour enregistrer la description de notre site web. Pour assurer un ventuel traitement conventionnel des donnes des pages du site, tous les fichiers XML respectent le schma de la figure 5.20. Ainsi la figure 5.21 donne un aperu de ce que peut tre une partie de notre fichier XML. (voir le chapitre 2 et annexe B pour plus dinformations sur les schmas XML )
Figure 5.20 Aperu du schma XML des fichiers XML gnrs par lditeur des contenus
112
Figure 5.21 Exemple dun fichier XML gnrs par lditeur des contenus
<accueil> ------------------------------------------------------------------ Racine du document <zoneTexte> ---------------------------------------------------------- Englobe les lments zone de texte <zone> ------------------------------------------------------------Nouvelle zone <textValue>Page D'accueil</textValue> ---Contenu textuelle/ <textFormat> -----------------------------------------------Format du texte <size>24</size> --------------------------------------Taille <color>3284170</color> ---------------------------Couleur du texte <fonte>Times New Roman</fonte> -------------Style de la police <format>false</format> -----------------------------Type gras </textFormat> -----------------------------------------------Fin de la balise Format <emplacement> --------------------------------------------Emplacement de la zone du texte <x>116.8</x> ------------------------------------------Position X de la zone du texte <y>16.2</y> --------------------------------------------Position Y de la zone du texte </emplacement> --------------------------------------------Fin de la balise emplacement <BackGround>> --------------------------------------------Background de la zone de texte <arrPlan>false</arrPlan> ----------------------------existe il un arrire plan <scrollBar>false</scrollBar> ------------------------existe il un une scrolbare </BackGround> ----------------------------------------------Fin de la balise background <liens> ---------------------------------------------------------Possibilit de mettre le texte comme hyper lien <exist>false</exist> -----------------------------------nous sommes ou non en prsence dun lien <valeur/> ------------------------------------------------si oui le quel </liens> --------------------------------------------------------Fin de la balise lien </zone> -------------------------------------------------------------Fin de la balise zone </zoneTexte> -----------------------------------------------------------Fin de la balise </accueil> --------------------------------------------------------------------- Fin du document
5.3.10 Interface de lditeur des contenus Figure 5.22 Ecran : Lditeur des contenus
La figure 5.22 montre larchitecture globale du site pour la partie Front office. Le cur de tout le systme est lanimation principale, qui gre toutes les transactions en faisant appel des scripts de configuration *.as (ActionScript) et des scripts PHP, pour linterrogation de la base de donnes.
113
Cette structure constitue un privilge pour la cration dynamique des contenus. Le faite de fractionner les lments sur des modules spars fournis un moyen de contrle slectif. Selon le besoin et la position des requtes, des chargements partiels se dclenchent. Les fichiers XML, chargs la demande, contiennent les donnes et les informations ncessaires laffichage des contenus, utiliss pour la cration des zones de textes au moment du chargement.
114
Conclusion
Dans ces travaux, nous nous sommes intresss au domaine de conception et de dveloppement des applications web, pour rpondre la problmatique expose dans lintroduction : rduire la distance entre la thorie et la pratique dans les modles de conception. Nous avons introduit deux concepts, savoir lapproche des dlgus des packages et lditeur des contenus, deux propositions qui salignent sur la tendance essentielle de linformatique faciliter lutilisation de loutil informatique et daccrotre le potentiel des utilisateurs, en leur offrant des solutions logiciels rpondant au mieux leurs besoins et garantissant, en mme temps, fiabilit et professionnalisme. Depuis le dbut de cette thse, un nombre important de projets ont vu le jour, lancs par des diteurs de logiciels notamment Microsoft avec le framework .Net, SUN avec la nouvelle technologie JSF (JavaServer Faces successeur de STRUTS et JSP) CodeCharge de Yes Software, chaque solution visant rpondre certaines exigences techniques. Tous ces produits implmentent des mthodes diffrentes ddition dynamique des contenus. Le contexte industriel pratique dans lequel les projets ont t raliss bnficie de lapprobation et des critiques des utilisateurs, ainsi que de leurs propositions damlioration et dvolution. Coupler recherche et application rapporte des rsultats exploitables et rapproche la thorie des applications du terrain, ce qui instaure une motivation soutenue et une contribution complmentaire. Le contact continu avec les utilisateurs potentiels des solutions proposes, permet de les impliquer dans les projets et dviter des spirales inutiles dans le processus de dveloppement et assure une validation progressive des tapes de ralisation. Nous avons pu constater lutilit de limplmentation de lapproche des dlgus des packages travers la mise en place dun Data Warehouse. Ds la premire version du systme, nous tions amens apporter des modifications, fonctionnellement spares. La clart et lhomognit de larchitecture de notre systme, nous permis de cibler rapidement les zones concernes par les modifications, contribuant ainsi la maintenance et lvolution du systme. A travers ce modeste travail men sur plusieurs annes de recherche et dapplication dans diffrent domaine, lapproche ddition dynamique a donn un rsultat trs satisfaisant dans deux projets de grande ampleur ; le premier avec lutilisation dun diteur de contenu intgr avec la technologie XML, et le second avec lutilisation intgrale de lapproche des dlgus des packages. Nous avons constat lutilit de cette approche dans la facilit des volutions des premires versions. Perspectives Ce projet souvre sur des perspectives prometteuses ; jusqu prsent les applications dveloppes ont t ralises sous des diteurs non ddis comme PHPEdit, Dreamweaver, codeCharge, nous esprons mettre en place un EDI avec un framework intgrant lapproche des dlgus des packages pour faciliter et acclrer la gnration du code natif. Une autre perspective consiste proposer des modles prdfinis partir de cette approche pour servir de point de dpart des solutions logiciels complexes dans diffrents domaines ( Systme dinformation, workflow, data warehouse ...)
115
Nous esprons mener une tude plus approfondie des designs patterns existants afin de dgager leurs points forts et de les mettre profit dans larchitecture de notre approche des dlgus des packages. Lditeur des contenus dans sa version actuelle ne contient pas beaucoup de fonctionnalits et ne supporte que quelques formats de fichiers. Lobjectif est dessayer denrichir cette bibliothque en gardant toujours le principe ddition dynamique.
116
Annexe A : Data warehouse

Prsentation Data Warehouse (DW) ou entrept de donnes, est un concept spcifique de l'informatique dcisionnelle, issu du constat suivant : les donnes de l'informatique de production (galement appele informatique transactionnelle ), notamment les progiciels de gestion intgrs (ou ERP, Enterprise Resource Planning) ne se prtent pas une exploitation dans un cadre d'analyse dcisionnelle. Les systmes de production sont en effet construits dans le but de traiter des oprations individuelles qui peuvent impliquer diffrents mtiers de l'entreprise et surtout, ne se proccupent pas de leur compilation ou historisation dans le temps. l'inverse, les systmes dcisionnels doivent permettre l'analyse par mtiers ou par sujets et le suivi dans le temps d'indicateurs calculs ou agrgs. Il est donc souvent indispensable de sparer ces deux mondes et de repenser les schmas de donnes, ce qui implique l'unification des diffrents gisements de donnes de l'entreprise en un entrept de donnes global (data warehouse) ou ddi un sujet/mtiers (datamart). Le Data WareHouse est une collection de donnes orientes sujet, intgres, non volatiles et historises, organises pour le support d'un processus d'aide la dcision. [WH.Inmon96]
Un datamart est un magasin de donnes. Comme le data warehouse c'est un entrept de donnes, mais spcialis pour un mtier ou un sujet donn. En rgle gnrale, il se situe en aval d'un data warehouse plus global et est aliment partir de ce data warehouse, dont il constitue en quelque sorte un extrait. Le datamart est un point de vue spcifique, dtermin par des critres fonctionnels mtier. Le datamart est conu d'aprs un besoin d'affaire identifi et pour une porte clairement dfinie. Ainsi plusieurs datamarts pourront tre conus pour rpondre chacun un besoin diffrent. Le datamart est une base de donnes dcisionnelle structure et formate en fonction d'un mtier prcis ou d'un usage particulier (datamart commercial, datamart financier, ...). L'information y est prpare pour tre consomme telle quelle : c'est une structure plus spcifique qu'un data warehouse qui reste, lui, vocation plus gnrale et plus transversale au regard des diffrents mtiers de l'entreprise. [wikipedia] Le datamart sert au reporting et l'analyse dcisionnelle, en bout de la chane de l'informatique dcisionnelle. L'entrept de donnes de type datamart a une structure de donnes : Soit multidimensionnelle stocke dans un cube ou hypercube : M-OLAP, ROLAP ... (notamment lorsqu'il s'agit de donnes agrges) Soit reprsente par un modle de donnes en toile ou en flocon dans un SGBD relationnel (notamment lorsqu'il s'agit de donnes lmentaires ou unitaires non agrges).
Exemples dinformations dcisionnelles : Chiffre daffaire par client Progression des ventes dans un intervalle de temps
117
Evolution de la part du march dun produit particulier Evolution de la part du march par rgion Taux dabsentisme des employs par secteur de production
Un data warehouse ne s'achte pas, il se construit. [WH.Inmon96] Un DW est une structure informatique dans laquelle est centralis un volume important de donnes consolides partir des diffrentes sources de renseignements d'une entreprise (notamment les bases de donnes internes) et qui est conue de manire que les personnes intresses aient accs rapidement l'information stratgique dont elles ont besoin. Si, dans le pass, l'entrept de donnes servait davantage l'archivage, aujourd'hui il est devenu une pice matresse de l'informatique dcisionnelle (ou informatique d'aide la dcision). Il reprsente l'un des lments essentiels d'un ensemble matriel et logiciel dynamique de recherche d'informations. Dans un entrept de donnes, les donnes sont : slectionnes et prpares (pour rpondre aux questions vitales de l'entreprise), intgres ( partir des diffrentes sources de renseignements) et dates (elles gardent la trace de leur origine). Le terme entrept de donnes, employ trs frquemment, semble vouloir supplanter ses concurrents dpt de donnes et centrale de donnes. Bien que le terme magasin de donnes soit utilis comme quivalent de data warehouse par certains auteurs, il convient mieux au concept d' operational data store . D'aprs les renseignements inscrits dans la base de donnes IBMOT d'IBM, Information Warehouse est une marque de commerce d'International Business Machines Corp. Le terme lui-mme est pourtant rpertori comme nom commun dans plus d'un dictionnaire unilingue anglais spcialis. Cette dfinition est tire de celle de Bill Inmon (William H. Inmon ) que l'on nomme le pre des entrepts de donnes et l'inventeur de ce qu'on appelle EDW pour Entreprise Data warehouse ou CIF pour Corporate Information Factory . [GrdDiction] Le but dun DW est de transformer des donnes avec vacation de production en un ensemble dinformations dcisionnelles alimentant la source de donnes dun systme dinformations dcisionnels. Les principes Un Data Warehouse est un entrept de donnes (une base de donnes) qui se caractrise par des donnes : Orientes mtier ou business (par exemple, pour une entreprise de production, les commandes clients sont traites diffremment entre le service de comptabilit et le service des achats) Prsentes selon diffrents axes d'analyse ou dimensions (par exemple : le temps, les types ou segments de clientle, les diffrentes gammes de produits, les diffrents secteurs rgionaux ou commerciaux, etc.)
Figure A.1 Vue Multidimensionnelle des Data Warehouse
118
Non volatiles : stables, en lecture seule, non modifiables, Intgres en provenance de sources htrognes ou d'origines diverses (y compris des fichiers externes de cotation ou de string) Archives et donc dates : avec une conservation de l'historique et de son volution pour permettre les analyses comparatives (par exemple, d'une anne sur l'autre, etc.).
Critres dvaluation des Data Warehouse

Les temps de rponse. Facilit dutilisation. Visualisation multidimensionnelle des donnes.
Architecture d'un Data Warehouse Un entrept de donnes est gnralement construit selon une architecture en 3 niveaux, tel quindiqu dans la figure A.3 ci-dessous : d'un serveur d'entrept (serveur de donnes) d'un serveur OLAP (de type HOLAP/MOLAP ou ROLAP) d'un client o outil pour l'excution des requtes o outil pour l'analyse des donnes
Figure A.2 Architecture dun Data warehouse
Alimentation L'alimentation des donnes partir des bases de production est une phase primordiale d'un Data Warehouse. Des outils logiciels sont alors ncessaires pour
119
intgrer les donnes dans le data warehouse. On parle d'ELT (Extract, Transform, Load). Les phases de l'alimentation d'un data warehouse sont les suivantes : Dcouverte des donnes : Il s'agit d'identifier dans les systmes sources les donnes importer dans le data warehouse. Il faut prendre les donnes les plus judicieuses. Un mauvais choix peut considrablement compliquer les phases suivantes de l'alimentation. Extraction des donnes : Il s'agit de collecter les donnes utiles dans les systmes de production. Il faut identifier les donnes ayant t modifies afin d'importer le minimum de donnes dans le data warehouse. Transformation des donnes : Il faut rendre les donnes cohrentes avec la structure du data warehouse. On applique alors des filtres sur les donnes. Il peut tre ncessaire de convertir le format des donnes (EBCDIC vers ASCII par exemple) ou d'harmoniser les formats de dates (jj/mm/aaaa). Il faut galement associer les champs source avec les champs cibles. Un champ source adresse pourra ainsi par exemple tre dcompos en numro , rue , code postal , ville ou l'inverse. Enfin des donnes des systmes de production doivent tre agrges ou calcules avant leur chargement.
OLAP
Les data warehouses eux reposent sur le systme OLAP (On Line Analytical Processing). Ce systme travail en lecture seulement. Les programmes consultent d'importantes quantits de donnes pour procder des analyses. Les objectifs principaux sont regrouper, organiser des informations provenant de sources diverses, les intgrer et les stocker pour donner lutilisateur une vue oriente mtier, retrouver et analyser linformation facilement et rapidement. Cela ncessite de consulter des versions historiques de la base et peut se permettre d'ignorer temporairement les dernires mises jour. Ces bases sont souvent d'un ordre de grandeur nettement suprieur celle des bases OLTP, du fait de la conservation de l'historique. Comparaison : Voici un tableau rcapitulatif des diffrences entre OLTP et OLAP : Tableau A.1 Comparaison OLTP/OLAP Caractristiques Utilisation Opration typique Type d'accs Niveau d'analyse Quantit d'information changes Orientation Taille BD OLTP SGBD (base de production) Mise jour Lecture criture Elmentaire Faible Ligne Faible (max qq GB) OLAP Data Warehouse Analyse Lecture Global Importante Multidimension Importante (pouvant aller plusieurs TB).
L'objectif des bases OLTP est de pouvoir rpondre rapidement des rponses simples, exemple : les ventes du produit X. Les bases OLAP permettent des requtes plus complexes : les ventes du produit X par vendeur, rgion et par mois.
120
Annexe B : Tutorial RELAX NG [CLARK01]

Cette annexe est une copie intgrale dune partie dun trs bon tutorial [CLARK01] traitant les schmas XML avec le langage RELAX NG. Nous vous conseillons de le consulter pour dcouvrir toutes les fonctionnalits de ce puissant langage. RELAX NG est un langage de schma pour XML, bas sur RELAX et TREX. Un schma RELAX NG spcifie des motifs qui dcrivent la structure et le contenu d'un document XML. Un tel schma RELAX NG identifie une classe de documents XML qui correspond aux documents qui se conforment cet ensemble de motifs. Un schma RELAX NG est en soit un document XML. 1. Premiers pas Considrons une lectroniques : reprsentation XML basique d'un rpertoire d'adresses
<rpertoire> <carte> <nom>John Smith</nom> <courriel>js@exemple.com</courriel> </carte> <carte> <nom>Fred Bloggs</nom> <courriel>fb@exemple.net</courriel> </carte> </rpertoire>
La DTD en serait la suivante : <!DOCTYPE <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT ]> rpertoire [ rpertoire (carte*)> carte (nom, courriel)> nom (#PCDATA)> courriel (#PCDATA)>
Un motif RELAX NG correspondant pourrait tre rdig ainsi : <element name="rpertoire" xmlns="http://relaxng.org/ns/structure/1.0"> <zeroOrMore> <element name="carte"> <element name="nom"> <text/> </element> <element name="courriel"> <text/> </element> </element> </zeroOrMore> </element> Figure A.3 Reprsentation graphique dun RELAX NG
121
Si
rpertoire
ne doit pas tre vide, alors on utilise (NdT : zro ou plus):
oneOrMore
(NdT : un ou plus) au
lieu de
zeroOrMore
<element name="rpertoire" xmlns="http://relaxng.org/ns/structure/1.0"> <oneOrMore> <element name="carte"> <element name="nom"> <text/> </element> <element name="courriel"> <text/> </element> </element> </oneOrMore> </element> Changeons maintenant ce motif pour permettre chaque lment
note carte
de contenir un
optionnel : name="rpertoire"
<element xmlns="http://relaxng.org/ns/structure/1.0"> <zeroOrMore> <element name="carte"> <element name="nom"> <text/> </element> <element name="courriel"> <text/> </element> <optional> <element name="note"> <text/> </element> </optional> </element> </zeroOrMore> </element>
Notez que le motif text correspond n'importe quel texte, y compris un texte vide. Notez aussi qu'un espace sparant des balises est ignor quand ces dernires sont compares un motif. Tous les lments dfinissant un motif doivent appartenir un espace de noms identifi par l'URI : http://relaxng.org/ns/structure/1.0 L'exemple ci-dessus utilise la dclaration d'espace de noms par dfaut xmlns="http://relaxng.org/ns/structure/1.0". Il est galement autoris d'associer un prfixe un espace de noms : <rng:element name="rpertoire" xmlns:rng="http://relaxng.org/ns/structure/1.0"> <rng:zeroOrMore> <rng:element name="carte"> <rng:element name="nom"> <rng:text/> </rng:element> <rng:element name="courriel"> <rng:text/> </rng:element> </rng:element> </rng:zeroOrMore> </rng:element>
122
2. Choix Supposons maintenant que nous voulions permettre, comme alternative distinction entre un
prnom nom
, une
et un
nom-de-famille
, selon un rpertoire suivant :
<rpertoire> <carte> <prnom>John</prnom> <nom-de-famille>Smith</nom-de-famille> <courriel>js@exemple.com</courriel> </carte> <carte> <nom>Fred Bloggs</nom> <courriel>fb@exemple.net</courriel> </carte> </rpertoire>
On peut utiliser le motif suivant :
<element name="courriel"> <text/> </element> <optional> <element name="note"> <text/> </element> </optional> </element> </zeroOrMore> </element>
<element name="courriel"> <text/> </element> <optional> <element name="note"> <text/> </element> </optional> </element> </zeroOrMore> </element>
123
Cela correspond la DTD suivante :
<!DOCTYPE <!ELEMENT <!ELEMENT note?)> <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT ]>
rpertoire [ rpertoire (carte*)> carte ((nom | (prnom, nom-de-famille)), courriel, nom (#PCDATA)> courriel (#PCDATA)> prnom (#PCDATA)> nom-de-famille (#PCDATA)> note (#PCDATA)>
3.Typage de donnes RELAX NG permet aux motifs de faire rfrence des types de donnes conformes des dfinitions externes, comme celles dfinies par [W3C XML Schema Datatypes]. Les implmentations RELAX NG peuvent diffrer dans les types de donnes qu'elles supportent. Vous devez utiliser les types de donnes qui sont supports par l'implmentation que vous souhaitez utiliser. Le motif data valide une chane de caractres qui reprsente la valeur d'un type de donnes dsign. L'attribut datatypeLibrary prend pour valeur l'URI identifiant la librairie de types de donnes utilise. La librairie de types de donnes de [W3C XML Schema Datatypes] doit tre identifie par l'URI http://www.w3.org/2001/XMLSchema-datatypes. L'attribut type spcifie le nom d'un type de donnes de la libraire identifie par l'attribut datatypeLibrary. Par exemple, si une implmentation RELAX NG supportait les types de donnes de [W3C XML Schema Datatypes], vous pourriez utiliser : <element name="nombre"> <data type="integer" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"/> </element> Il ne serait pas commode de devoir spcifier systmatiquement un attribut datatypeLibrary pour chaque lment data, c'est pourquoi RELAX NG permet ses lments d'hriter de la valeur de l'attribut datatypeLibrary. L'attribut datatypeLibrary peut-tre spcifi pour n'importe quel lment RELAX NG. Si un lment data n'a pas d'attribut datatypeLibrary, la valeur de l'attribut datatypeLibrary de l'lment parent le plus direct sera utilise. Typiquement, l'attribut datatypeLibrary dans l'lment racine d'un schma RELAX NG. Par exemple :
<element name="point" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> <element name="x"> <data type="double"/> </element> <element name="y"> <data type="double"/> </element> </element>
124
Si le fils d'un lment ou attribut se conforme un motif data, alors tout le contenu de cet lment ou attribut doit se conformer ce motif data. Un motif ne peut pas permettre une partie de son contenu de se conformer un motif data donn tout en permettant une autre partie de se conformer un autre. Par exemple, le motif suivant n'est pas autoris : <element name="incorrect"> <data type="int"/> <element name="note"> <text/> </element> </element>
Cependant, celui-ci serait correct :
<element name="correct"> <data type="int"/> <attribute name="note"> <text/> </attribute> </element>
Notez que ces restrictions ne s'appliquent pas au motif text. Les types de donnes peuvent avoir des paramtres. Par exemple, une chane de caractres d'un type de donnes peut avoir un paramtre contrlant sa longueur. Les paramtres applicables des types de donnes particuliers sont dtermins par le vocabulaire de typage des donnes. Les paramtres sont spcifis en insrant un ou plusieurs lments param comme lments fils d'un lment data. L'exemple suivant limite la chane de caractres contenue dans un lment courriel une longueur maximum de 127 caractres :
<element name="courriel"> <data type="string"> <param name="maxLength">127</param> </data> </element> Comparaison avec les DTD XML RELAX NG propose des fonctionnalits qui dpassent le cadre des DTD pour XML. En particulier, RELAX NG : utilise une syntaxe XML pour reprsenter des schmas ; supporte le typage des donnes ; intgre les attributs dans les modles de contenu ; supporte les espaces de noms XML ; supporte les contenus non ordonns ; supporte la dpendance au contexte des modles de contenu.
125
Syntaxe du schma XML [MSDN] <?xml version="1.0" encoding="utf-8"?> <xs:schema targetNamespace="http://tempuri.org/XMLSchema1.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:complexType name="addressType"> <xs:sequence> <xs:element name="street1" type="xs:string"/> <xs:element name="street2" type="xs:string"/> <xs:element name="city" type="xs:string"/> <xs:element name="state" type="xs:string"/> <xs:element name="zip" type="xs:integer"/> </xs:sequence> </xs:complexType> <xs:element name="purchaseOrder"> <xs:complexType> <xs:sequence> <xs:element name="shipTo" type="addressType" /> <xs:element name="billTo" type="addressType" /> <xs:element name="shipDate" type="xs:date" /> <xs:element name="item" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
Exemple dun schma XML L'exemple de schma XML ci-dessus contient les lments suivants : La premire instruction, <?xml version="1.0" encoding="utf-8"?>, spcifie quelle version de XML est utilise. La seconde instruction se compose de plusieurs parties : o La dclaration xs:schema indique qu'il s'agit d'un schma et que le prfixe xs: sera plac devant ses lments. o La dclaration xmlns:xs="http://www.w3.org/2001/XMLSchema" indique que toutes les balises de ce schma doivent tre interprtes en fonction de l'espace de noms par dfaut du consortium W3C (World Wide Web Consortium), fond en 2001. o La dclaration targetnamespace attribue au schma le nom XMLSchema1.xsd et indique sa position par dfaut, laquelle se trouvera dans un URI (Universal Resource Identifier) de votre serveur de dveloppement appel tempuri.org. Un type complexe sans nom appel addressType est dfini ; il contient cinq lments de types de donnes divers. Notez que chacun de ces lments est un type nomm simple. Un lment complexe appel purchaseOrder est dfini. Il contient des lments utilisant le type addressType prcdemment dfini. Une relation imbrique est ainsi cre entre l'lment purchaseOrder et ces lments. L'lment final de purchaseOrder, Item, contient une facette appele maxOccurs. Les facettes servent limiter le type de contenu qu'un type simple peut contenir. maxOccurs est utilis pour limiter le nombre d'occurrences d'un mme lment dans les documents crs l'aide de ce schma. Par dfaut, il est gal un. Dans ce cas, la valeur unbounded dfinie pour maxOccurs indique qu'il peut exister autant d'occurrences de l'lment Item que ncessaire. Annexe.
126
Annexe C : Glossaire de vocabulaire

A/COO : Analyse et Conception Orientes Objet. CWM :Common Warehouse Metamodel, Une interface servant faciliter les changes de mtadonnes entre outils, plates-formes et bibliothques de mtadonnes dans un environnement htrogne. CODEC : Coding decoding, Codage-decodage, algorithmes de compression et dcompression Cookie : Petit fichier envoy du serveur vers le client et utilis comme marqueur pour suivre l'utilisateur et enregistrer des paramtres son sujet CSS / feuille de style : Cascading Style Sheet, est un concept qui a t dvelopp pour HTML et contient les proprits attaches un lment (les styles). Les styles dfinissent comment visualiser une page HTML (police de caractre, taille de police, etc.) Consortium Unicode : est une organisation sans but lucratif, ayant pour mission de dvelopper, d'tendre et de promouvoir Unicode. Les membres du consortium sont issus d'un large ventail d'entreprises et d'organisations dans le domaine de l'informatique et des technologies de l'information. Le consortium est financ uniquement par les cotisations de ses membres. L'adhsion au consortium Unicode est ouverte toutes les organisations et individus qui soutiennent le standard Unicode et souhaitent favoriser son extension et son utilisation. [Unicode] DTD : Document Type Dfinition, Dfinition de Type de Document Data Mining : Dans le cadre de leurs activits, les organisations (prives ou publiques) constituent de nombreuses bases de donnes. Le data mining consiste extraire et analyser certaines de ces donnes, notamment dans le cadre du marketing. Par exemple, lors d'un achat sur un magasin en ligne, on recommande un produit au consommateur en fonction de l'analyse de ses habitudes d'achat Data warehouse : entrept de donnes, est une sorte de base de donnes de bases de donnes! Structure de manire spcifique, elle permet l'analyse de toutes les donnes stockes par une organisation et offre ainsi aux responsables des outils stratgiques d'aides la dcision DNS : Domain Name Server, nom de domaine EDI : Environnement de Dveloppement Intgr : est un programme regroupant un diteur de texte, un compilateur, des outils automatiques de fabrication, et souvent un dbogueur. Bien que des EDI pour plusieurs langages existent, bien souvent (surtout dans les produits commerciaux) un EDI est ddi un seul langage de programmation. On peut galement trouver dans un EDI un systme de gestion de versions et diffrents outils pour faciliter la cration de l'interface graphique ERP : Enterprise Resource Planning, selon le grand dictionnaire terminologique [GDT], un Progiciel qui permet de grer l'ensemble des processus d'une entreprise, en intgrant l'ensemble des fonctions de cette dernire comme la gestion des ressources humaines, la gestion comptable et financire, l'aide la
127
dcision, mais aussi la vente, la distribution, l'approvisionnement et le commerce lectronique. ETL : Extract-Transform-Load / datapumping, Il s'agit d'une technologie informatique middleware permettant d'effectuer des synchronisations massives d'information d'une banque de donnes vers une autre. Selon le contexte, on traduira par alimentation , extraction , transformation , constitution ou conversion , souvent combins. Elle est base sur des connecteurs servant exporter ou importer les donnes dans les applications (Ex : connecteur Oracle ou SAP...), des transformateurs qui manipulent les donnes (agrgations, filtres, conversions...), et des mises en correspondance (mappages). Le but est l'intgration de l'entreprise par ses donnes. GDT : est un dictionnaire terminologique de l'Office qubcois de la langue franaise contenant plus de 3 millions de termes franais, anglais et latin dans 200 domaines d'activit. http://www.granddictionnaire.com. ISO : International Organization for Standardization,Organisation internationale de normalisation. IIS : Internet Information Services, est un ensemble de services TCP/IP ddis l'Internet, Il comprend les serveurs suivants : Web, FTP, Gopher, SMTP, NNTP et les outils d'administration associs. JSF :JavaServer Faces. JSF est un framework Java, ou en franais cadre de travail, pour les dveloppeurs d'interface Web, utilisant l'architecture J2EE. JSF a t mis au point par Craig McClanahan, le pre de Struts et de Catalina le conteneur de servlet de Tomcat. La premire version a vu le jour en 2003. Le but de JSF est de fournir au dveloppeur d'applications de type Web, une interface de programmation lui permettant de manipuler l'interface Web dans un environnement J2EE sans avoir recourir du code HTML ou JavaScript. JSF est implment sous lEDI SUN Java Studio Creator. LAN : Local Area Network, Rseau local d'ordinateurs qui partagent des ressources (serveur, imprimantes, scanners, ...). Typiquement le btiment d'une entreprise. Le serveur hberge des applications et partage l'espace de stockage de donnes pour les utilisateurs. LDAP : Lightweight Directory Access Protocol, Protocole d'accs normalis aux services d'un annuaire (base de donnes avec une structure spcifique arborescente). LDAP est aujourd'hui trs largement utilis par les applications visant offrir un accs un ou des annuaire(s), par exemple dans un rseau local ou sur Internet. NTIC / TIC : Nouvelles Technologies de l'Information et de la Communication Middleware : En informatique, dsigne les logiciels servant d'intermdiaire entre d'autres logiciels. On utilise gnralement du middleware comme intermdiaire de communication entre des applications complexes, distribues sur un rseau informatique. Metamodeling : mta-modlisation, modlisation partir deux-mmes. Modlisation Rcursive des Elments de
128
MVC : Modle Vue Contrleur : est un design pattern (motif de conception) pour le dveloppement d'applications logicielles qui spare le modle de donnes, l'interface utilisateur et la logique de contrle. Ce motif a t mis au point en 1979 par Trygve Reenskaug, qui travaillait alors sur Smalltalk. Les lments permettant la ralisation classique d'un systme en architecture trois tiers sont les suivants: systme de base de donne relationnel (SGBDR) pour le stockage des donnes. serveur applicatif pour la logique applicative. navigateur web pour la prsentation
MOF : Meta Object Facility, http://www.omg.org/, est un standard de l'OMG adressant la reprsentation des mtamodles et leur manipulation. Le langage MOF s'auto-dfinit. OMT : Object Modeling Technique, Technique de modlisation Objet OMG : Object Management Group, est un groupe dindustriels cr en 1989 dont l'objectif est de standardiser et promouvoir le modle objet sous toutes ses formes. lOMG comprend actuellement plus de 800 membres, dont les principaux acteurs de lindustrie informatique ( SUN, IBM, Microsoft, ) [Roques02] OCL : Object Constraint Language, langage dvelopp lorigine pour exprimer des contraintes sur des lments de diagrammes UML, il offre un ensemble de fonctions efficaces pour naviguer entre les lments dun modle UML ou MOF et rcuprer les informations lies ces lments. ODBC : Open DataBase Connectivity, Interface d'accs aux bases de donnes dveloppe par Microsoft pour en savoir plus: www.microsoft.com/data/ RDF : Ressource Description Framework RELAX : REgular LAnguage description for XML. RELAX NG : est un langage de schma pour XML, bas sur [RELAX] et TREX]. Un schma RELAX NG spcifie des motifs qui dcrivent la structure et le contenu d'un document XML. Un tel schma RELAX NG identifie une classe de documents XML qui correspond aux documents qui se conforment cet ensemble de motifs. Un schma RELAX NG est en soit un document XML. RUP : Rational Unified Process, est un processus de dveloppement logiciel labor et commercialis par la socit Rational Software gr actuellement par IBM. Il se prsente sous forme d'un guide mthodologique au format HTML, coupl une base de connaissances et capable de s'interfacer avec divers outils d'expression des besoins, de modlisation UML, d'automatisation des tests, de gestion de configuration, de production de documents, de gestion de projet, etc. SAX : Simple API for XML. Interface standard pour les parseurs XML. SAX est une API base sur un modle vnementiel, cela signifie que SAX permet de dclencher des vnements au cours de l'analyse du document XML.
129
SMTP : Simple Mail Transfer Protocol, Protocole utilis pour l'envoi de messages lectroniques sur Internet SGML : Standard Generalized Markup Language, Langage normalis ( anctre du langage XML ) permettant de dcrire les relations entre le contenu d'un document informatique et sa structure Shareware / Partagiciel : Logiciel sans copyright. On en trouve des milliers sur le Net . On peut le tlcharger gratuitement et l'utiliser un certain temps pour l'valuer. Si l'on est satisfait, il suffit de contacter l'auteur pour payer et recevoir une version complte et sans limite d'utilisation dans le temps SGBD : Systme de gestion de bases de donnes. SGBDR : Systme de gestion de bases de donnes relationnelles (exemple: Oracle, Informix, Sybase, SQLServer, etc) TREX : Tree Regular Expressions for XML TCP/IP : Transmission Control Protocol/Internet Protocol URI : Universal Resource Identifier URL : Unified Resource Locator UWE : UML-based Web Engineering, approche de conception orient objet propose par N.Koch [Koch00]. Elle peut tre classe comme une extension de la notation UML pour le dveloppement WEB. Web services : Services Web, Dvelopps sur base d'XML et des standards UDDI, WSDL et SOAP, les services Web permettent la mise disposition d'applications prtes l'emploi via le Web, sans contrainte de plate-forme de dveloppement. Ils permettent la communication entre applications et entreprises sur le Web W3C : World Wide Web Consortium, Organisation internationale cre en 1994 et dont l'objectif est de permettre au Web d'atteindre son meilleur potentiel par le dveloppement de protocoles communs et universels. www.w3c.org XSL : eXtensible Style Language, Langage normalis par W3C dfinissant l'utilisation de feuilles de styles pour transformer des documents XML en documents XML, HTML, XHTML, texte, etc XSL-FO : XSL Formatting Objects XML : eXtensible Markup Language Langage de description et d'change des documents structurs dfini par le Consortium W3C en 1998. XML est en passe de devenir le format standard de stockage et d'change de donnes, notamment pour les applications d'e-business pour en savoir plus: www.xml.org. XMI : XML Metadata Interchange, http://www.omg.org/.
130
Annexe E Liste des Logiciels utiliss : Les logiciels mentionns dans cet annexe ont t utiliss dans le cadre des travaux pratiques lies au thme de ce mmoire et dautres figurent titre dinformation. 1 NOM DU LOGICIEL Entreprise Licence Version Description DBDesigner 4 Libres GNU GPL 4.0.5.6 BETA Modliser les base de donnes Synchroniser avec BD [test avec MySql, avec oracle il faut passer un ODBC ] Reverse ingenering : Gnr le modle physique de la base de donnes, et possibilit dexportation des scripts SQL Interface agrable et facile utiliser. http://www.fabforce.net/ TOAD QUEST SOFTWARE Payant 8.6.1 Grer des base de donnes Oracle Requteur Administration de base de donnes Gestion des tables, des vues, des Triggers, des procdures stockes Export/import des donnes. Import/export Et bien dautres fonctionnalits trs pratique Compatible seulement avec Oracle Ergonomiquement bien conu Multi connexion Rapide Trs pratique pour le teste des de requtes ( limage de SQL+) Je le conseil vivement. www.quest.com PowerAMC Sybase Payant [version dessai 30 jours] 10.0 Modlisation UML Modliser les base de donnes Gnration du code natif pour application JAVA Gnration des donnes de teste Reverse ingenering. Ergonomiquement bien conu Un produit complet et stable
Remarque Source WEB 2 NOM DU LOGICIEL Entreprise Licence Version Description
Remarque
Source WEB 3 NOM DU LOGICIEL Entreprise Licence Version Description
Remarque
131
Multi connexion Cote trs cher www.sysbase.com Poseidon for UML Gentleware Version Standard gratuite Version Professionnel payante 1.3 Modlisation UML Gnration de la documentation HTML des classes et des diagrammes UML Gnration du code natif JAVA Interface basique. La version payante semble intressante. http://www.gentleware.com Dreamweaver MX 2004 Macromedia Payant (Version dessai gratuite) MX 2004 Cration de site WEB Usage de modle prdfinie Fonctionnalits avances pour la cration de page HTML Dbogueur PHP Connexion une base de donnes Un logiciel Complet et stable Ergonomiquement bien conu La mme ergonomie des logiciels STUDIO MX de Macromedia www.macromedia.com Flash MX 2004 Macromedia Payant (Version dessai gratuite) MX 2004 Cration danimation Ouvert sur plusieurs langages de technologie Internet (JAVA, HTML, PHP, JSP, JavaScript, XML ) Langage objet propritaire (ActionScript ) pour la cration et le contrle danimations et du droulement de scnarios. Site Web interactifs Intgre des fonctionnalits avances pour la manipulation des objets XML Animation base de dessins vectoriels www.macromedia.com Fireworks MX 2004
Remarque
Remarque
Source WEB 7 NOM DU LOGICIEL
132
Entreprise Licence Version Description
Macromedia Payant (Version dessai gratuite) MX 2004 Traitement dimages Dessin vectoriel Fusion des images Exportation des images vers plusieurs formats Cration des images Interactives avec possibilit de gnration du code HTML intgrant les vnement dinteraction en JavaScript plein de fonctionnalits deffets de traitement dimages Pratique pour la gnration des squelettes des pages HTML www.macromedia.com PHPEDit Waterproof Software Payant de puis la version 1.0.3 2.8 Editeur de script PHP Gnration de la documentation depuis les commentaire Dbogage Des centaines de raccourcis Possibilit de cration des modles de templates avec des raccourcis pour la gnration des squelettes de code (exemple Class avec constructeur, fonction, variable) Facilite la programmation oriente objet Interface agrable et facile utilise indispensable pour un dveloppeur PHP je le conseil vivement http://www.waterproof.fr/ CodeCharge Studio Yessoftware Payant ( version dessai gratuite ) 3.1 Environnement de programmation graphique de multiples langage de programmation WEB Gnration automatique de modle de sites web partir de base de donne Supporte plusieurs langages de programmation web ( PHP4/PHP5, ASP, ASP.Net, CFML,JSP, PERL) Programmation vnementielle Permet de raliser des sites web rapidement je le conseil vivement Loriginalit de ce logiciel cest la Programmation vnementielle dans du dveloppement web.
Remarque
Remarque
Remarque
133
www.yessoftware.com MySQL to Oracle Intelligent Converters software Payant (Version dessai gratuite) 2.3 Migration des bases de donnes MySQL vers Oracle (Schma + donnes) Exige un serveur MySQL install et un serveur Oracle Pratique pour la migration dune base MySQL vers une base Oracle Lentreprise prsente un grand nombre de logiciels de conversion pour dautres SGBD http://www.convert-in.com/ ModelMaker 6.2 Payant, version dessai fournie avec le cd Delphi Modlisation graphique des Objets pour DELPHI Synchronis le code avec lenvironnement de dveloppement DELPHI Ncessite des connaissances avances sur la programmation Objet sous Delphi Trs pratique pour les projets de taille, et surtout dans la phase de maintenance. http://www.modelmakertools.com
Remarque
Remarque
ECLIPSE
Eclipse Open source, gratuit 3.2 Un puissant outil pour raliser des applications orientes sous Java Intgre depuis la version 2.0 le langage de programmation PHP www.eclipse.org
Java Studio Creator

SUN Gratuit 2004 Programmation java .Net Technologie JSF (Java Server Face ) Permet de faire de la programmation Web visuel www.sun.com
Remarque Source WEB
134
Rfrences bibliographies
Ouvrages
[Conallen00] [Larman02] [Lopez98] [Cokburn01] [Roques02] [Jacobson02] Concevoir des applications WEB avec UML. J.Conallen. Eyrolles UML et les Design Patterns. C.Larman CampusPress Intgrer UML dans vos projets. N.Lopez, J.Migueis, E.Pichon Eyrolles Rdiger des cas dutilisation efficaces. A.Cockburn Eyrolles UML Modliser un site e-commerce. P.Roques. Eyrolles. 2000 2002 1998 2001 2002
Le guide de lutilisateur UML. G.Booch, J.Rumbaugh, I.Jacobson. 2002 Eyrolles. 2000
[MullerGaertne Modlisation objet avec UML. P-A.Muller, N.Gaertner. Eyrolles. r00] [Gamma 95]
Design Patterns : Elements of reusable Object-Oriented Software. 1995 E.Gamme, et R. Helm, Ralph Johnson, J.Vlissides. Addison-Wesley The Unified Modeling Language Reference Manual. 1999. G.Booch, 1998 J.Rumbaugh, I.Jacobson. Addison-Wesley
[UML-UG 98]
[Bushmann96] Pattern-Oriented Software Architecture : A System of Patterns. 1996 . F.Bushmann R.Meunier, H.Rohnert, P.Sommerlad, M.Stal. Wiley. [Bordage06] [Booch96] [Kruchten00] [Monnier02] [Booch99] Conduite de projet Web. 2006 S.Bordage. Eyrolles 2006
Object Solutions - Managing the Object-Oriented Project. G.Booch. 1996 Pearson Education Introduction au Rational Unified Process, Ph.Krachten . Eyrolles Flash MX : animation, interactivit, ActionScript. G.Monnier. Dunod 2000 2002
The Unified Software Development Process. G.Booch, J.Rumbaugh, 1999 I.Jacobson. Addison-Wesley
[Rosenberg99] Use Case Driven Object Modeling with UML. D.Rosenberg, K.Scott. 1999 Wesley Longman [Penner03] [Sehan02] [Goldfarb03] Creative Studio programmation Falsh MX. R.Penner. First interactive Flash MX et ActionScript. J-F.Sehan, B.Underdahl. First interactive, The XML Handbook, 5the Hall PTR 2003 2002
edition, C-F.Goldfarb, P.Prescod. Prentice 2003
[Gardarin02]
XML : Des bases de donnes aux services WEB. G. Gardarin. Dunod
2002
135
[Harold2000]
XML Le guide de lutilisateur.Elliotte Rusty Harold (Adap fr G.Picarde). 2000 Eyrolles
[DUCHARME01 Xslt Quickly: A Tutorial and Concise User's Guide. B.Ducharme. 2001 ] Manning Publications [Franco00] [Nogier01] Piloter l'entreprise grce au data Warehouse. J-M.Franco .Eyrolles, De l'ergonomie du logiciel au design des sites web : J.F. Nogier. 2001 Dunod Ergonomie du logiciel et design Web : Le manuel des interfaces 2005 utilisateur J.F. Nogier. Dunod. Concevoir et dployer un data warehouse Guide de conduite de 2000 projet : R.Kimball, L.Reeves. Eyrolles. 1996
[Nogier05]
[Kimball00]
[WH.Inmon96] Building the Data Warehouse : W.H.Inmon. John Wiley & Sons [Kimbel03] Entrepts de donnes. Guide pratique dimensionnelle. R.Kimball, M.Ross. Vuibert. de
modlisation 2003
Articles
[Koch01] The Authoring Process of the UML-based Web Engineering Approach. International : 2001, Institute of Computer Science, LudwigMaximilians University of Munich, http://www.pst.informatik.unimuenchen.de/publications/uwe_iwwost01.pdf Software Engineering for Adaptive Hypermedia Applications : PhD. Thesis. Ergonomic Criteria for the Evaluation of Human-Computer interfaces 1993 : Ch.Scapin, L.Bastien. INRIA Model-Driven Architecture, Technologies : John D. Poole Vision, Standards And Emerging 2001
[Koch00]. [Bastien93]
[Poo01]
[Tatibouet06] [Burbeck92]
Etude et comparaison doutils de transformation de modles : 2006 B.Tatibout. LIFC How to use Model-View-Controller. Steve Burbeck. Comment choisir les contenus de votre site web ? La mthode "Actions-Dclencheurs" de veblog. http://www.veblog.com/fr/2001/0513-determiner-contenus.html 1992
Internet
[W3C] [Bourret03] http://www.w3.org http://www.campusxml.org : XML and Databases, Traduction franaise P.Peccatte. R.Bourret. 2003
136
[CLARK01]
http://xmlfr.org/ : RELAX NG Tutorial. J.CLARK, M.Makoto. Oasis. 2001 Traduction franaise A.Arcouteil. http://www.laltruiste.com/ : Ressources de plusieurs langages de programmation http://msdn.microsoft.com/ : Divers Ressource informatique http://www.microsoft.com/ : Site officiel de lentreprise Microsoft
[Laltruiste]
[MSDN] [Microsoft]
[Unicode]
http://www.unicode.org/ : Le site Web du consortium Unicode, o vous trouverez les tableaux de caractres et beaucoup d'informations techniques sur la norme http://www.w3.org/TR/2004/REC-xml11-20040204/ ou http://www.w3.org/TR/REC-xml. La recommandation XML 1.1 du w3c http://www.w3.org/TR/2001/REC-xsl-20011015/ La recommandation XML 1.0 du w3c http://fr.sun.com Site officiel de lentreprise SUN Microsystems http://www.adobe.com site officiel de Adobe Macromedia fait dsormais partie de Adobe puisqu'elle a t rachete en avril 2005 http://fr.wikipedia.org : encyclopdie librement distribuable http://heim.ifi.uio.no/~trygver/ Page web personnelle de Trygve M. H. Reenskaug inventeur du modle MVC http://www.granddictionnaire.com/ e grand dictionnaire une excellente rfrence qui nous donne accs prs de 3 millions de termes franais et anglais du vocabulaire industriel, scientifique et commercial, dans 200 domaines d'activit http://xmlfr.org/ Ressource XML en franais http://www.uml.org, http://uml.free.fr http://www.omg.org/ http://www.cyberzoide.net/java/javastyle/ Guide francophone des conventions de codage pour la programmation en langage Java http://directory.google.com/ Rpertoire de liens vers des references informatqiues classes par thme http://www.valtech.fr/fr/index/hot/agile_methodology.html : La mthode Agile pour le dveloppement informatique
[SpecXML]
[SpecXMLT]
[SUN] [Adobe]
[wikipedia] [Reenskaug] [GrdDiction]
[XMLFR] [UML] [OMG]
137

Sce Samir Adouane

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sce Samir Adouane

Uploaded by

Copyright:

Available Formats

Rpublique Algrienne Dmocratique et Populaire

Option : Informatique industrielle

Intgration des moyens de modification dynamique des contenus sur le WEB

PARMENTIER, Fabrice TOMACITE et en gnrale tout le personnel dECS-Shindler Mulhouse.

Intgration des moyens de modification dynamique

des contenus sur le WEB

Liste des Figures

111 112 113 113 118 119 121

Liste des Tableaux

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

l'laboration du mme modle, mme si chaque participant en a une vision particulire.

Figure 1.2 Le modle, un artefact Central du processus De dveloppement

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Figure 1.3 Traitement d'une page statique

Etape 2 Le serveur Web localise la page

Serveur Web <HTML> <p> </HTML> Page statique

Etape 3 Le serveur Web envoi la page au navigateur requrant

Intgration des moyens de modification dynamique des contenus sur le WEB

Serveur web <HTML> <code> </HTML> <HTML> <p> </HTML>

Etape 5 Le serveur Web envoie la page acheve au navigateur requrant

Etape 4 Le serveur dapplication transmet la page acheve au serveur Web.

Intgration des moyens de modification dynamique des contenus sur le WEB

Et en voici une autre plus complexe :

Intgration des moyens de modification dynamique des contenus sur le WEB

Etape 1 Le navigateur sollicite une page dynamique

Navigateur Web Demande Rponse

Serveur web <HTML> <code> </HTML> <HTML> <p> </HTML>

Etape 4 Le serveur dapplication envoie une requette au SGBD

Intgration des moyens de modification dynamique des contenus sur le WEB

Le serveur dapplication renvoie la page suivante au serveur Web :

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Figure 1.7 Une approche centralise de la validation des entres

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Lobjectif du guidage est de faciliter lutilisation du systme et son apprentissage. [Nogier01]

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Figure 2.1 Sparation des donnes et de la prsentation avec XML

Feuille XML --XML-----

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB

Intgration des moyens de modification dynamique des contenus sur le WEB