torkmen_karim

Cycle de formation des ingnieurs en TlcommunicationsOption :

Services et Communication pour les Rseaux Multimdia

Rapport de Projet de fin dtudesThme :

Conception et ralisation d'un service de tlcommunications forte valeur ajoute base d'un systme Web-Vocal pour la gestion des gardes des pharmaciesRalis par :

Karim TORKMANE

Encadrant (s) :

M. Riadh ABDELFATTAH M. Riadh TEBOURBI

Travail propos et ralis en collaboration avec

Anne universitaire : 2005/2006

DdicacesA mes chers parents, Que nulle ddicace ne puisse exprimer ce que je leurs dois, pour leur bienveillance, leur affection et leur soutien Trsors de bont, de gnrosit et de tendresse, en tmoignage de mon profond amour et ma grande reconnaissance Que Dieu vous garde . A mes chers frres et soeur, En tmoignage de mes sincres reconnaissances pour les efforts quils ont consenti pour laccomplissement de mes tudes. Je leur ddie ce modeste travail en tmoignage de mon grand amour et ma gratitude infinie. A mon oncle Mustapha, Qui a t et est toujours un pre pour moi, aucune expression ne pourra exprimer ma gratitude envers lui pour m'avoir considr comme le fils qu'il n'a jamais eu. A tous mes amis, Pour leur aide et leur soutien moral durant llaboration du travail de fin dtude. A toute ma Famille A tous mes amis A tout ceux qui m'aiment

PFE-Sup'com 2006

Rsum

RsumGrce la fusion de l'informatique et des tlcommunications, de nouveaux services appels services de tlcommunications valeur ajoute sont apparus, constituant actuellement un march potentiel pour les socits de service. Dans le cadre de ce projet de fin d'tude, l'effort a t port sur la mise en place d'un service de tlcommunications valeur ajoute qui organise les gardes des pharmacies en France et permet un accs facile pour le grand public aux informations qui les concernent. Il s'agit de concevoir et raliser un systme intgrant une application Web pour grer les gardes des pharmacies et un serveur vocal pour accder aux informations sur ces gardes. Mots cls : services de tlcommunications valeur ajoute, voiceXML, Web, serveur vocal interactif, garde des pharmacies, systme centralis.

Confidentiel

i

PFE-Sup'com 2006

Abstract

AbstractThanks to the merging of informatics and telecommunications, new services known as value added telecommunication services appeared, constituting nowadays a potential market for the services companies. Within the framework of this PFE, the effort was carried on putting in a value added telecommunication service that organizes the duty of pharmacies in France and allows an easy access for the general public to their concerned information. It's about the design and the creation of a system integrating a Web application to manage the duty of the pharmacies and an interactive voice response to access to the information on these duties. Keywords : added value telecommunication services, voiceXML, Web, interactive voice response, duty of pharmacies, centralized system.

Confidentiel

ii

PFE-Sup'com 2006

Avant propos

Avant Propos

Ce projet de fin d'tudes s'inscrit dans le cadre de l'obtention du diplme d'ingnieurs en tlcommunications. Il a t ralis la socit PROXYM-IT et a pour objectif la conception et la ralisation d'un service de tlcommunications forte valeur ajoute base d'un systme Web-Vocal pour la gestion des gardes des pharmacies en France. Au terme de ce travail je tiens remercier Mr. Wassel Berrayana et Mr Hakim Harzallah directeurs associs de PROXYM-IT qui mont donn la possibilit deffectuer mon projet de fin d'tudes au sein de leur socit. J'adresse aussi mes vifs remerciements Mr. Riadh Abdelfattah Tebourbi de Sup'com pour leur aide prcieuse et leur clairvoyance. Je tiens aussi exprimer lhonneur qui mest fait par les membres du jury en acceptant de juger mon travail. et Mr Riadh

Confidentiel

iii

PFE-Sup'com 2006

Table des matires

Table des matiresINTRODUCTION GENERALE.............................................................................................1 CHAPITRE 1 : CONTEXTE GENERAL DU PROJET ......................................................3 I. LES SERVICES DE TELECOMMUNICATIONS A VALEUR AJOUTEE .............................................4 I.1. Prsentation des services de tlcommunications valeur ajoute..............................4 I.1.1. L'audiotex..............................................................................................................4 I.1.2. .La tlconfrence .................................................................................................4 I.1.3. .La sauvegarde en ligne des donnes ....................................................................5 I.2. Les atouts pour la ralisation des services valeur ajoute ........................................5 I.2.1. Le Web ..................................................................................................................5 I.2.1.1 .Internet en bref ...............................................................................................5 I.2.1.2 .Les applications Web de premire gnration ...............................................5 I.2.1.3 .Les applications Web de deuxime gnration ..............................................6 I.2.1.4 .Un Web trois niveaux..................................................................................6 I.2.2. Le VoiceXML .......................................................................................................7 I.2.2.1 .Prsentation du VoiceXML............................................................................7 I.2.2.2 .Modle architectural du VoiceXML ..............................................................8 II. CADRE ET CONTEXTE DU PROJET .........................................................................................9 II.1. Organisme d'accueil....................................................................................................9 II.2. Travail demand .........................................................................................................9 II.3. Problmatique ...........................................................................................................10 CHAPITRE 2 : CONCEPTION DU SYSTEME POUR LE SERVICE A VALEUR AJOUTEE ...............................................................................................................................12 I. LA MISE EN OEUVRE DU PROJET ..........................................................................................13 I.1. La dmarche de la ralisation du projet .....................................................................13 Confidentiel iv

PFE-Sup'com 2006

Table des matires

I.2. Le langage UML pour la modlisation du systme....................................................14 II. SPECIFICATION DES BESOINS DE LA GESTION DES GARDES DES PHARMACIES.....................15 II.1. Description des besoins.............................................................................................15 II.2. Modlisation des besoins ..........................................................................................16 II.2.1. Identification des acteurs ...................................................................................16 II.2.2. Diagramme des cas d'utilisation ........................................................................16 III. ARCHITECTURE DU SYSTEME ...........................................................................................21 III.1. Architecture matrielle du systme .........................................................................21 III.2. Conception de la base de donnes ...........................................................................23 III.2.1. La mthode Merise pour la conception de la base de donnes.........................23 III.2.2. Modle conceptuel de donnes.........................................................................25 III.2.3. Modle logique de donnes ..............................................................................28

III.3. Conception du SVI ..................................................................................................29 III.3.1. Choix du VoiceXML pour le dveloppement du SVI......................................29 III.3.2. Choix de la solution de l'intgration du SVI ....................................................30 III.4. Conception de l'application Web.............................................................................33 III.4.1. Le choix du motif de conception MVC pour l'application Web ....................33 III.4.2. Diagramme des composants .............................................................................34 III.4.3. Prsentation du sous-systme "InfoGarde" ......................................................36 III.4.3.1 .La chane de gnration d'un flux de donnes...........................................36 III.4.3.2 .Diagramme des classes du sous-systme "InfoGarde"..............................37 III.4.3.3 .Reprsentation du scnario de la gnration d'un flux VoiceXML...........39 CHAPITRE 3 : REALISATION DU SYSTEME POUR LE SERVICE A VALEUR AJOUTEE ...............................................................................................................................40 I. LES CHOIX TECHNIQUES POUR LA REALISATION DU SYSTEME .............................................41 I.1. Choix du langage de programmation .........................................................................41 I.2. Choix de l'API de traitement du XML .......................................................................42 I.3. Choix du SGBD .........................................................................................................43 II. ENVIRONNEMENT DE TRAVAIL ..........................................................................................44 II.1. Environnement matriel............................................................................................44 II.2. Environnement logiciel.............................................................................................44 III. PRESENTATION DU SYSTEME REALISE ..............................................................................45

Confidentiel

v

PFE-Sup'com 2006

Table des matires

CONCLUSION GENERALE................................................................................................53 ANNEXE : LA FAMILLE XML ..........................................................................................55 BIBLIOGRAPHIE .................................................................................................................58

Confidentiel

vi

PFE-Sup'com 2006

Liste des abrviations

Liste des abrviationsAPI ASP ASR AT&T CETE CHU CTI DOM DTMF HTML HTTP HTTPS IBM IHM IIS IP MCD MLD MVC NFS NFS OMG OMT OOD Application Programming Interface Active Server Pages Automatic Speech Recognition American telephone and telegraph Centre d' Etudes Techniques de l' Equipement Centre Hospitalier Universitaire Centre Technique d'Informatique Document Object Model Dual Tone Multi Frequency HyperText Markup Language Hypertext Transfer Protocol Secured HTTP International Business Machines Corporation Interface Homme/Machine Internet Information Services Internet Protocol Modle Conceptuel des Donnes Modle Logique des Donnes Modle Vue Contrleur Network File System Network File System Object Management Group Object Modeling Technique Object-Oriented Design

Confidentiel

vii

PFE-Sup'com 2006

Liste des abrviations

OOSE OSS PC PHP RTSP SAX SGBD SpeechML SQL SVI SVI TCP TTS UML VoiceXML VoxML W3C WWW XML XSLT

Object Oriented Software Engineering Operating Sub-System Personal Computer Hypertext Preprocessor Real Time Streaming Protocole Simple API for XML Systme de Gestion des Bases de Donnes Speech Markup Langauage Structured Query Language Serveur Vocal Interactif Serveur Vocal Interactif Transmission Control Protocol Text To Speech Unified Modeling Language Voice eXtensible Markup Language Voice Markup Language World Wide Web Consortium World Wide Web eXtensible Markup Language eXtensible StyleScheet Langauge Transformation

Confidentiel

viii

PFE-Sup'com 2006

Listes des figures et tableaux

Liste des figures et tableauxFiguresFIGURE 1.1 : ARCHITECTURE WEB A TROIS NIVEAUX. .................................................................7 FIGURE 1.2 : MODELE ARCHITECTURAL DU VOICEXML. ............................................................8 FIGURE 2.1 : CYCLE DE REALISATION DU PROJET.......................................................................13 FIGURE 2.2 : ORGANISATION EN PACKAGES DES CAS D'UTILISATION. ........................................17 FIGURE 2.3 : CAS D'UTILISATION DU PACKAGE "RECHERCHE"...................................................17 FIGURE 2.4 : SCENARIO DU CAS D'UTILISATION "RECHERCHERPHARMACIE"............................18

FIGURE 2.5 : CAS D'UTILISATION DU PACKAGE "SECURITE".......................................................18 FIGURE 2.6 : CAS D'UTILISATION DU PACKAGE "GESTION DES DISTRICTS". ...............................19 FIGURE 2.7 : CAS D'UTILISATION DU PACKAGE "ADMINISTRATION". .........................................19 FIGURE 2.8 : CAS D'UTILISATION DU PACKAGE "GESTION DES GARDES"....................................20 FIGURE 2.9 : CAS D'UTILISATION DU PACKAGE "GESTION DES PHARMACIES". ...........................21 FIGURE 2.10 : CAS D'UTILISATION DU PACKAGE "INFOGARDE". ................................................21 FIGURE 2.11 : DIAGRAMME DE DEPLOIEMENT. ..........................................................................22 FIGURE 2.12 : LE MODELE CONCEPTUEL DE DONNEES. ..............................................................26 FIGURE 2.13 : LE MODELE LOGIQUE DES DONNEES. ...................................................................28 FIGURE 2.14 : ARCHITECTURE D'UNE APPLICATION INTEGRANT VOICEXML. ...........................29 FIGURE 2.15 : SCHEMA SYNOPTIQUE DE L'INTEGRATION DU SVI PAR GENERATION DU XML....30 FIGURE 2.16 : SCHEMA SYNOPTIQUE DE L'INTEGRATION DU SVI PAR GENERATION DIRECTE DU VOICEXML. ........................................................................................................31 FIGURE 2.17 : INTEGRATION DU SVIPAR TRANSFORMATION DES PAGES HTML VERS DES PAGES

VOICEXML .............................................................................................................................. 32 FIGURE 2.18 : ARCHITECTURE MVC ........................................................................................34

Confidentiel

ix

PFE-Sup'com 2006

Listes des figures et tableaux

FIGURE 2.19 : LE DIAGRAMME DES COMPOSANTS......................................................................35 FIGURE 2.20 : CHAINE DE GENERATION D'UN FLUX DE DONNEES. ..............................................36 FIGURE 2.21 : DIAGRAMME DES CLASSES DU SOUS SYSTEME"INFOGARDE". .............................37 FIGURE 2.22 : SCENARIO DE GENERATION D'UN FLUX VOICEXML............................................39 FIGURE 3.1 : PAGE D' ATHENTIFICATON. ....................................................................................45 FIGURE 3.2 : MENU PRINCIPAL DE LA GESTION DES GARDES. .....................................................46 FIGURE 3.3 : AJOUT DE DISTRICT. ..............................................................................................46 FIGURE 3.4 : AJOUT DE PHARMACIE...........................................................................................47 FIGURE 3.5 : CONSULTATION DES GARDES PAR LE GRAND PUBLIC.............................................48 FIGURE 3.6 : RECHERCHE D'UNE PHARMACIE.............................................................................49 FIGURE 3.7 : GESTION DES GARDES. ..........................................................................................51 FIGURE 3.8 : GESTION DES PROFESSIONNELS. ............................................................................52

TableauxTABLEAU 2.1: LES DIFFERENTS NIVEAUX ET MODELES DE MERISE............................................24 TABLEAU 2.2: DICTIONNAIRE DES DONNEES..............................................................................27 TABLEAU 3.1: COMPARAISON SAX/DOM. ...............................................................................43

Confidentiel

x

PFE-Sup'com 2006

Introduction gnrale

Introduction gnraleRgulirement nous est annonc une nouvelle rvolution qui, telle que linvention de limprimerie ou de llectricit, marquerait le dbut dune nouvelle re. Ainsi en est-il aujourdhui des nouvelles technologies de linformation et de la communication. Cette rvolution n'aurait pu avoir lieu sans la fusion de deux domaines prcdemment considrs comme totalement spars : l'informatique et les tlcommunications. Cette fusion a conduit l'apparition de ce qu'on appelle les services de tlcommunications valeur ajoute, un domaine qui vise crer de nouveaux services en tirant profit des rvolutions technologiques. La valeur d'un tel service est d'autant plus grande si son existence se justifie, non seulement court terme mais si elle fait preuve d'une durabilit. Ceci est intimement li son usage et aux besoins auxquels il doit satisfaire. En effet, un service dvelopp pour supporter le fonctionnement de certaines composantes et mme remdier leurs dfaillances peut garantir sa prennit et donner un avantage concurrentiel la socit qui le propose. C'est le cas d'une banque qui propose ses clients la consultation de leurs comptes en ligne ou partir du tlphone, d'une compagnie d'assurance qui propose l'ouverture d'un sinistre d'assurance au moyen d'une interface vocale permettant ainsi un gain de temps, d'un Etat qui met en place un systme comblant les dfauts rgissant l'organisation des gardes des pharmacies. Ce projet de fin d'tudes a t ralis la socit PROXYM-IT, une socit de dveloppement de services de tlcommunications et d'informatiques. Il a pour objectif de dvelopper un service de tlcommunications forte valeur ajoute pour la gestion des gardes des pharmacies et la diffusion des informations qui leurs concernent. En effet, l'absence d'un systme centralis qui s'occupe de la gestion des gardes a cr une complexit accomplir Confidentiel 1

PFE-Sup'com 2006

Introduction gnrale

cette tche qui ncessite jusqu' prsent la collaboration de plusieurs acteurs tel que la prfecture, les pharmaciens, etc. En plus, les moyens permettant de connatre les pharmacies qui sont de garde tels que les journaux, les affichages sur les portes des pharmacies, etc. ne montrent pas une grande efficacit surtout si on est dans un cas d'urgence; d'ou l'ide de concevoir et raliser un systme qui rsout cette problmatique. Ce systme sera compos d'un serveur vocal interactif oprant l'chelle nationale Franaise qui permet de connatre les pharmacies qui sont de garde, et d'un outil Web pour la gestion des gardes des pharmacies. Il s'agit aussi de trouver une solution pour lier ces deux composantes. Le prsent rapport, comporte les trois chapitres suivants : - Le premier chapitre, "Contexte gnral du projet", met le projet dans son contexte par une prsentation des services de tlcommunications valeur ajoute, des technologies utilises pour construire le systme, de l'organisme d'accueil, du travail demand et de la problmatique rsoudre. - Le deuxime chapitre "Conception du systme pour le service valeur ajoute", prsente la mthodologie suivie pour raliser le projet, la spcification des besoins et des fonctionnalits du systme, les choix pour lesquels nous avons opt pour concevoir notre systme ainsi que l'architecture logicielle et matrielle que nous avons mis en place. - Le troisime chapitre "Ralisation du systme pour le service valeur ajoute", prsente les choix techniques faits, les environnements matriel et logiciel dont on a dispos pour la ralisation du systme ainsi qu'une description du systme obtenu.

Confidentiel

2

PFE-Sup'com 2006

Contexte gnral du projet

Chapitre 1 : Contexte gnral du projet

Ce chapitre reprsente une mise dans le contexte du projet de fin d'tude intitul conception et ralisation d'un service de tlcommunications forte valeur ajoute base d'un systme Web-Vocal pour la gestion des gardes des pharmacies. La premire partie prsente les services de tlcommunications valeur ajoute et les technologies qui seront utiles pour laborer notre systme. La deuxime partie se focalise sur le cadre du projet travers une prsentation de l'organisme d'accueil, une dfinition du travail demand et de la problmatique qu'il doit rsoudre.

Confidentiel

3

PFE-Sup'com 2006


I.Les services de tlcommunications valeur ajouteCette sous-section comporte une dfinition des services de tlcommunications valeur ajoute travers quelques exemples et une prsentation des atouts technologiques qui nous ont permis de dvelopper notre systme.

I.1.Prsentation des services de tlcommunications valeur ajouteA la diffrence des services de tlcommunications traditionnels appels services de tlcommunications de base tel que la tlphonie, le tlex, le fax, etc. dont le but est le juste acheminement des informations fournies par les clients; les services de tlcommunications valeur ajoute visent ajouter de la valeur aux informations en amliorant leur forme ou leur contenu ou en prvoyant leur stockage et leur recherche. A titre d'exemple nous citons les services de tlcommunications valeur ajoute suivants :

I.1.1.L'audiotexAppel galement audiotel est un service de communication, vocal, utilisant la voix numrise et permettant d'accder, partir d'un tlphone, des sources de donnes vocales. La base de donnes vocales est structure sous forme d'arborescence dont les branches sont slectionnables par l'appelant l'aide des touches de son clavier tlphonique. L'intrt de ce systme est de pouvoir accder 24 heures sur 24 et travers le tlphone des bases de donnes distantes. Les renseignements ainsi accessibles peuvent porter sur les heures d'ouverture, la mto, les offres spciales...

I.1.2..La tlconfrenceC'est l'change de l'information, en direct, entre plusieurs personnes loignes les unes des autres mais lies par un systme de tlcommunications. Cet change d'information peut tre sous forme audio ou vido ou une combinaison des deux.

Confidentiel

4

PFE-Sup'com 2006


I.1.3..La sauvegarde en ligne des donnesC'est la mise l'abri des donnes critiques d'une entreprise, via Internet ou une autre liaison. Elle reprsente une alternative aux solutions classiques, puisque le client ne s'occupe plus de la scurit de ses donnes mais il confie cette tche un spcialiste de la matire.

I.2.Les atouts pour la ralisation des services valeur ajoute I.2.1.Le Web I.2.1.1.Internet en brefC'est un rseau dcentralis dans lequel, chaque noeud devait se voir affect la mme importance et ne devait pas gner le fonctionnement global du systme en cas de dfaillance. Lors de la mise hors service d'un noeud, ce rseau devait tre capable de s'adapter automatiquement et de trouver un chemin alternatif pour assurer l'acheminement de l'information vers sa destination. Un groupe de protocoles de communications appels TCP/IP a t adopt, permettant une multitude de services de fonctionner simultanment sur le rseau (tels que les transferts de fichiers, les forums et messageries lectronique...). Depuis, l'Internet s'est dvelopp un rythme exponentiel grce l'augmentation du nombre de systmes informatiss sur le rseau et des services valeur ajoute qui l'adoptent pour acheminer les informations.

I.2.1.2.Les applications Web de premire gnrationAvec l'expansion de l'Internet, de nouveaux vocabulaires sont apparus. A titre d'exemple, on parle de "page Web" qui signifie la page cran qui sera visualise par les navigateurs Web. Au dbut, ces pages Web taient statiques. En effet, elles taient figes en un fichier ".htm/.html", d'aspect plutt austre et dpourvu de la plupart des possibilits d'interaction auxquelles l'utilisateur est dsormais habitu avec les logiciels pour PC usuels. De plus, la premire gnration de navigateurs Web ne reconnat que le texte et les donnes multimdia simple comme les images et le son.

Confidentiel

5

PFE-Sup'com 2006


I.2.1.3.Les applications Web de deuxime gnrationLa deuxime gnration d'applications Web a mis un terme l'aspect des pages Web. Ce sont les navigateurs Web de la nouvelle gnration qui ont permis cette volution. Ils peuvent : - Tlcharger des composants logiciels qui peuvent tre dvelopps dans un langage de haut niveau. Ces composants rendent le Web plus dynamique et plus flexible utiliser et maintenir. - Reconnatre les langages de script qui peuvent tre inclus dans un document HTML. De tels langages ont permis au poste client d'tre intelligent, du fait qu'ils peuvent contrler un champ de saisie par exemple, et d'avoir un comportement vnementiel. Un script peut notamment tre utilis pour dtecter un vnement dclench par un click sur un bouton et invoquer une mthode pour effectuer le traitement ncessaire.

I.2.1.4.Un Web trois niveauxLa forte demande de contenu dynamique a transform le Web en une variante d'architectures multi niveau, particulirement souples et indpendantes du nombre d'utilisateurs sur le rseau. Il en rsulte des applications plus faciles maintenir et supporter, tout en minimisant l'impact des modifications ncessaires apporter ces applications. L'architecture Web trois niveaux (Figure 1.1) prsente le grand avantage de rsoudre plusieurs problmes inhrents aux systmes client-serveur traditionnels, il devient possible de dvelopper une application unique et universelle pouvant tre dploye sur diffrents types de plates formes. Tout le traitement ct client est administr de faon centralise et dploy dynamiquement, ce qui signifie que toute mise jour est applique automatiquement lorsque l'utilisateur dmarre l'application. Ceci vite une installation manuelle sur chaque poste client. Cette architecture est compose de :

Confidentiel

6

PFE-Sup'com 2006


Figure 1.1 : Architecture Web trois niveaux.

- L'application cliente est reprsente par le navigateur. Elle est responsable de la logique de prsentation dfinie par le document HTML, lequel peut inclure des scripts ou autres composants logiciels. - Le serveur Web correspond au niveau intermdiaire. Il est utilis pour distribuer les donnes des clients et de grer les traitements mtiers. - Le serveur de donnes s'occupe de la gestion de l'accs aux donnes.

I.2.2.Le VoiceXML I.2.2.1.Prsentation du VoiceXMLVoiceXML est un langage utilis pour la cration des services vocaux interactifs. Normalis par le W3C, il est conu pour utiliser les principes et les technologies du Web (rseau Internet, XML, serveur Web, serveur dapplication, etc.). Son objectif initial est de permettre aux personnes disposant dun simple tlphone daccder sous forme vocale aux contenus et services du Web ainsi quaux systmes dinformations des entreprises. Les principales fonctionnalits de ce langage sont : - La diffusion de fichiers audio. - La diffusion de la parole synthtise (synthse vocale). - La dtection de codes DTMF gnrs par les touches du clavier du tlphone. Confidentiel 7

PFE-Sup'com 2006


- La dtection de mots ou expressions prononcs par l'utilisateur (reconnaissance vocale). - Lenregistrement de la parole de lutilisateur. - Le contrle de lappel tlphonique (transfert de lappel, dconnexion de lappel).

I.2.2.2.Modle architectural du VoiceXMLLe modle architectural du VoiceXML (Figure 1.2) dfini par le W3C est compos de :

Figure 1.2 : Modle architectural du VoiceXML. [6]

Un serveur de document (document server) qui peut tre un serveur Web par exemple, il a pour rle de gnrer du code VocieXML.

Un interprteur de contexte VoiceXML (VoiceXML interpreter contetxt) appel aussi gateway qui reprsente la porte d'entre au service des serveurs vocaux. Il englobe le VoiceXML Interpreter (plus connu sous le nom VoiceXML browser) qui a pour rle l'interprtation du code VocieXML.

Une plate-forme d'implmentation (implementation platform) qui regroupe les autres composantes supportant le navigateur VoiceXML interprter le code VoiceXML, tel que le serveur TTS.

Confidentiel

8

PFE-Sup'com 2006


II.Cadre et contexte du projetCette sous-section met le projet dans son cadre et contexte travers une prsentation de l'organisme d'accueil, une description du travail demand et une exhibition de la problmatique rsoudre.

II.1.Organisme d'accueilCe projet de fin d'tudes s'est droul PROXYM-IT. Cette socit a t cre le 4 janvier 2006 et possde deux siges, l'un la technople de Sousse constituant le centre de dveloppement de ses produits, et l'autre Lyon constituant une antenne commerciale. Elle s'intresse aux nouvelles technologies de l'information et de la communication et a pour activits : - Consulting : conseils sur la mise en place des systmes d'informations. - Dveloppement : essentiellement deux axes : les sites e-commerce et les services de tlcommunications valeur ajoute, entre autres les serveurs vocaux interactifs. - Formation : les technologies JAVA, XML et Linux.

II.2.Travail demandCe projet de fin d'tudes constitue une solution demande par la prfecture du dpartement de l'Isre au sud-est de la France pour la gestion des gardes des pharmacies et de la diffusion des informations les concernant. Il s'agit en premier lieu de construire un serveur vocal interactif accessible par un numro qui sera connu l'chelle nationale franaise, tel que le numro de la police de secours par exemple. Ceci va permettre au grand public de consulter la liste des pharmacies qui sont de garde. En deuxime lieu, il s'agit de raliser une application Web qui offre toutes les fonctionnalits ncessaires pour la gestion des gardes des pharmacies. Cette application doit aussi permettre de configurer le serveur vocal, et lui fournir les donnes dont il a besoin d'une faon dynamique.

Confidentiel

9

PFE-Sup'com 2006


II.3.ProblmatiqueEn France, la garantie de laccessibilit aux mdicaments 24h/24h dbute par un

compromis entre les pharmaciens qui s'organisent entre eux pour fixer leurs dates de gardes pour toute une anne. Aprs son tablissement, le planning doit tre envoy la prfecture pour tre approuv et publi. L'information issue de ce planning est disponible sur des journaux locaux, des sites Internet, par affichage sur les portes de toutes les pharmacies, les commissariats de police, les casernes des pompiers et parfois, sur un serveur vocal propritaire oprant sur un plan local (par exemple le serveur vocal du CHU de Grenoble propose chaque jour la liste des pharmacies qui sont de garde). Cependant, aucun serveur vocal oprant l'chelle nationale franaise n'a t mis en place. En plus, si une pharmacie se voit dans l'obligation de changer sa date de garde elle doit notifier ce changement au moins quatre jours avant son occurrence. Ce mode de fonctionnement rigide ne met pas en uvre un systme permettant la centralisation de la gestion des gardes des pharmacies et l'accs facile aux informations sur ces gardes, ce qui permet de remarquer les dfaillances suivantes : - Cette tche qui peut tre facile grer se transforme en un travail fastidieux ncessitant beaucoup de temps. - L'accs l'information sur les gardes n'est pas vident en cas d'urgence vu que les sources cites prcdemment sont inflexibles, surtout pour une personne trangre ayant des connaissances limites sur l'endroit o elle se trouve. - Certains acteurs se voient tre impliqus dans un processus ne faisant pas partie de leur logique mtier. Par exemple, si une pharmacie se voit oblige de changer sa date de garde, elle doit faire le parcours du combattant alors que logiquement ce n'est gure la charge du pharmacien de se proccuper de la circulation de l'information sur les gardes. Notons aussi qu'elle est oblige de coordonner avec les autres pharmacies pour tablir le planning des gardes alors qu'elle se serait dbarrasse de cette tche s'il y avait un systme qui le permettait. - Le risque que l'information sur les gardes soit obsolte est grand, puisque les diffrentes sources d'information peuvent ne pas communiquer entre elles, vu qu'il n' y a pas un systme centralis qui s'en occupe. Ce risque est d'autant plus lev si un cas d'urgence qui Confidentiel 10

PFE-Sup'com 2006


ne permet pas au pharmacien d'avoir les quatre jours pour notifier son changement de la date de garde arrive. Vu ces dfaillances, il s'avre ncessaire de dvelopper un systme permettant d'organiser cette composante du secteur de la sant. Ce systme doit permettre de centraliser la tche de la gestion des gardes des pharmacies et de l'accs aux informations sur ces gardes afin de remdier aux problmes cits prcdemment.

ConclusionDans ce chapitre nous avons prsent les technologies qui seront utilises pour mettre en place notre solution et nous avons situ le projet dans son cadre. Dans le chapitre suivant, nous passons l'tude du systme qu'on va raliser. .

Confidentiel

11

PFE-Sup'com 2006

Conception du systme pour le service valeur ajoute

Chapitre 2 :Conception du systme pour le service valeur ajoute

Nous exposons dans ce chapitre notre conception du systme raliser et qui a pour but de rendre flexible la tche de la gestion des gardes des pharmacies en France. En premier lieu, nous prsentons la dmarche suivie pour entreprendre ce projet. En deuxime lieu, nous dlimitons les fonctionnalits du systme raliser travers une tude et spcification des besoins. En troisime lieu, nous exposons l'architecture matrielle et logicielle du systme.

Confidentiel

12

PFE-Sup'com 2006


I.La mise en oeuvre du projetCette sous-section prsente la dmarche suivie pour raliser le projet, ainsi que le langage choisi pour modliser le systme construire.

I.1.La dmarche de la ralisation du projetLe choix d'une dmarche convenable pour entreprendre un projet est une tape cruciale qui conditionne sa russite. En effet, il n'existe pas de dmarche qui soit standard dans le sens o elle garantit la bonne conduite de n'importe quel travail mais son adoption doit tre en fonction des spcificits de chaque projet y compris les buts atteindre. En ce qui nous concerne, nous avons estim que le cycle en O (Figure 2.1) nous convient le mieux. A part qu'il permet une bonne dfinition des besoins, il est itratif et donc peut tre parcouru de multiples fois, en plus il offre la possibilit d'intgration de points de contrle tout au long du processus vu que l'valuation peut intervenir dans toutes les tapes. Ce cycle propose les phases suivantes pour raliser un projet :

Spcification des besoins

Conception du systme

Evaluation

Ralisation du systme

Figure 2.1 : Cycle de ralisation du projet.

Confidentiel

13

PFE-Sup'com 2006


1.

Spcification des besoins, consiste l'identification des besoins satisfaire et la dfinition des fonctionnalits du systme.

2.

Conception du systme, consiste dfinir l'architecture matrielle et logicielle du systme en se basant sur la phase de spcification des besoins.

3.

Ralisation du systme, consiste concrtiser le systme en ralisant et reliant ses diffrentes composantes.

4.

Evaluation, o le systme est soumis une utilisation relle pour s'assurer de son adaptation aux besoins exprims prcdemment.

I.2.Le langage UML pour la modlisation du systmePour modliser les fonctionnalits que doit offrir notre systme et reprsenter son architecture ainsi que les interactions entre ses diffrents composants, nous avons choisi le langage UML. C'est un langage standard conu pour l'criture des plans d'laboration des logiciels. Il dfinit neuf diagrammes qui servent visualiser un systme sous diffrentes perspectives : Le diagramme de classes : Il reprsente un ensemble de classes, d'interfaces et de collaboration ainsi que leurs relations. Les diagrammes de classes reprsentent la vue statique d'un systme. Le diagramme d'objets : Il reprsente un ensemble d'objets qui sont des instances des lments qui apparaissent dans le diagramme de classe. Le diagramme de cas d'utilisation : Il reprsente un ensemble de cas d'utilisations et d'acteurs et leurs relations. C'est en effet une vue statique de l'utilisation d'un systme. Le diagramme de squences et le diagramme de collaboration : Ils reprsentent un ensemble d'objets et leurs relations, donnant ainsi une vue dynamique sur le systme. Les diagrammes de squence mettent l'accent sur le classement chronologique des messages alors que les diagrammes de collaboration mettent l'accent sur l'organisation structurelle des objets qui envoient et reoivent des messages. Le diagramme d'tats-transitions : Il est compos d'tats, de transitions, d'vnements et d'activits. C'est une vue dynamique d'un systme. Confidentiel 14

PFE-Sup'com 2006


Le diagramme d'activits : C'est un type particulier de diagramme d'tats-transitions qui dcrit la succession des activits au sein d'un systme.

Le diagramme de composants : Il reprsente l'organisation et les dpendances au sein d'un systme de composants. Il prsente la vue d'implmentation statique d'un systme et est li au diagramme de classes.

Le diagramme de dploiement : Il est utilis pour la modlisation des aspects physiques d'un systme. Il montre la configuration des noeuds de traitement en phase d'excution ainsi que les composants qui se trouvent sur ces noeuds. Plusieurs raisons nous ont conduit adopter UML dans notre modlisation. En effet :

- Il a t normalis par l'OMG, qui est une organisation internationale se chargeant de la standardisation des technologies objets, c'est donc un langage standard comprhensible par tout le monde. - Malgr son volutivit, il est stable et facilite la comprhension du systme grce ses reprsentations simples. - Il permet d'utiliser les principes et les concepts objet pour enrichir la phase de la conception des systmes.

II.Spcification des besoins de la gestion des gardes des pharmaciesCette sous-section dcrit les besoins satisfaire par le dveloppement du systme et dtaille ses fonctionnalits travers une modlisation de ces besoins.

II.1.Description des besoinsLa tche de la gestion des gardes des pharmacies est fastidieuse, en plus l'accs aux informations qui concernent ces gardes par le grand public n'est pas flexible vu qu'il n'existe pas un systme centralis qui s'en occupe. Pour ce faire, on sera amen raliser un systme compos de : - Une application Web offrant toutes les fonctionnalits ncessaires pour grer les gardes, afin de supporter l'excution de cette tche auparavant pnible, tirant profit de la centralisation du traitement et de l'accs aux donnes offerte par le Web. Cette application, Confidentiel 15

PFE-Sup'com 2006


destine des gens qui sont dans la majorit des cas non familiariss avec l'informatique, doit offrir une interface conviviale et interactive. - Un serveur vocal interactif destin au grand public. Ce dernier doit fournir d'une faon fiable les informations ncessaires sur les gardes des pharmacies 24 heures/24 heures et 7 jours/7 jours.

II.2. Modlisation des besoins II.2.1.Identification des acteursUn acteur est une catgorie d'utilisateur, il reprsente un rle jou par une personne, un logiciel, un matriel, un automate qui exploite les donnes du systme et qui interagit avec [3]. Dans notre cas les acteurs sont : - Le professionnel : une personne qui a pour charge de grer la liste des pharmacies ainsi que la planification des gardes. - L'administrateur : c'est le responsable de l'octroi des droits d'accs l'application de la gestion des gardes. - L'utilisateur ordinaire : toute personne dsirant avoir des informations sur les pharmacies de garde.

II.2.2.Diagramme des cas d'utilisationUn cas d'utilisation modlise un service rendu par le systme. Il exprime les interactions acteurs/systme et apporte une valeur ajoute l'acteur concern, un cas d'utilisation est donc une abstraction d'une partie du comportement du systme [3]. Notons que pour faciliter la comprhension des cas d'utilisation nous les avons

partitionn en paquetages (Figure 2.2) qui sont des lments d'organisation des modles. Ils regroupent des lments de modlisation, selon des critres purement logiques. Il faut noter aussi que vu la ressemblance des scnarii des cas d'utilisation des diffrents paquetages, nous dtaillons le paquetage "Recherche" mais nous restreignons la description des autres la reprsentation de leurs diagrammes de cas d'utilisation.

Confidentiel

16

PFE-Sup'com 2006


Gestion des districts

InfoGarde Utilisateur ordinaire

Professionnel Gestion des pharmacies

Scurit

Gestion des gardes

Recherche

Administration

Administrateur

Figure 2.2 : Organisation en packages des cas d'utilisation.

a. Paquetage "Recherche"Recherche

Rechercher pharmacie par nom

Professionnel

Rechercher pharmacie par code postal ou numro de dpartement

Figure 2.3 : Cas d'utilisation du package "Recherche".

Confidentiel

17

PFE-Sup'com 2006


Ce paquetage (Figure 2.3) regroupe les fonctionnalits permettant de rechercher des informations sur les pharmacies. La description du scnario de recherche d'une pharmacie peut tre rsume par le diagramme de squences (Figure 2.4) suivant :

Systme Professionnel rechercheParNom ( ) ou rechercheParCodePostalOuNumroDeDpartement formulaire formulaireRempli ( )

rsultat de la recherche

Figure 2.4 : Scnario du cas d'utilisation "Rechercher pharmacie".

Le professionnel demande du systme la fonctionnalit de recherche d'une pharmacie. Ce dernier lui affiche un formulaire remplir. Selon le critre de recherche choisi par l'utilisateur et les informations qu'il a fournies, le systme lui affiche une liste de pharmacies.

b.

Paquetage "Scurit"Scurit

Administrateur Authentification

Professionnel

Figure 2.5 : Cas d'utilisation du package "Scurit".

Confidentiel

18

PFE-Sup'com 2006


Ce paquetage (Figure 2.5) comporte la fonctionnalit d'authentification pour l'accs certaines parties du systme.

c.

Paquetage "Gestion des districts"Gestion des districts

Ajouter district

Professionnel Supprimer district

Figure 2.6 : Cas d'utilisation du package "Gestion des districts".

Ce paquetage (Figure 2.6) regroupe les fonctionnalits que le systme doit offrir pour grer la liste des districts savoir l'ajout et la suppression d'un district.

d. Paquetage "Administration"Administration

Supprimer utilisateur

Administrateur

Ajouter utilisateur

Figure 2.7 : Cas d'utilisation du package "Administration".

Confidentiel

19

PFE-Sup'com 2006


Ce paquetage (Figure 2.7) regroupe les fonctionnalits qui permettent de contrler l'accs certaines parties du systme savoir l'octroi nouveau utilisateur les droits d'accs ou la privation d'un ancien utilisateur de ces droits.

e. Paquetage "Gestion des gardes"

Gestion des gardes Consulter garde partir de la zone militarise

Ajouter garde

Professionnel Supprimer garde

Figure 2.8 : Cas d'utilisation du package "Gestion des gardes".

Ce paquetage (Figure 2.8) regroupe les fonctionnalits que le systme doit offrir pour planifier les gardes des pharmacies. Ces fonctionnalits sont la consultation de la liste des pharmacies qui sont de garde, l'ajout ou la suppression d'une garde.

f. Paquetage "Gestion des pharmacies"Ce paquetage (Figure 2.9) regroupe les fonctionnalits que le systme doit offrir pour grer les fiches des pharmacies savoir la modification, l'ajout et la suppression d'une fiche de pharmacie.

Confidentiel

20

PFE-Sup'com 2006

Conception du systme pour le service valeur ajouteGestion des pharmacies

Modifier fiche pharmacie

Professionnel

Ajouter pharmacie

Supprimer pharmacie

Figure 2.9 : Cas d'utilisation du package "Gestion des pharmacies".

g. Paquetage "InfoGarde"InfoGarde

Consulter garde

Utilisateur ordinaire

Figure 2.10 : Cas d'utilisation du package "InfoGarde".

Ce paquetage (Figure 2.10) comporte la fonctionnalit de la consultation des gardes par le grand public.

III. Architecture du systmeCette sous-section prsente les choix que nous avons faits durant la phase de conception et dtaille la solution que nous avons conue pour raliser le systme.

III.1.Architecture matrielle du systmeConfidentiel 21

PFE-Sup'com 2006


Le diagramme de dploiement (Figure 2.11) reprsente l'organisation matrielle du systme. Il met en oeuvre les composants suivants :

Plate form Eloquent e

Serveur des fichiers audioH TTP R TSP H TTP

PCprofessionnel

H TTP

Serveur W eb

Serveur des applications vocales

N FS

Systm O e SS

H TTP

H TTPS

G M ou S TC

PCadm inistrateur

Tlphone fixe ou m obile

Figure 2.11 : Diagramme de dploiement.

- Serveur des applications vocales : se charge de la fourniture des flux VoiceXML au navigateur VoiceXML. - OSS : se charge du dpt des applications VoiceXML statiques dans la plateforme d'hbergement de ces applications. Notons qu'une application statique est une application dveloppe par manuellement, autrement dit celle qui ne soit pas fournie dynamiquement par un serveur. - Serveur de fichiers audio : se charge du dpt des flux audio qui seront utiliss par l'application vocale, et de leur fourniture en cas de besoin. Confidentiel 22

PFE-Sup'com 2006


- Serveur Web : il a pour fonction l'interprtation des scripts et la fourniture des flux VoiceXML au serveur vocal. - Tlphone fixe ou mobile : pour l'accs l'application vocale. - Deux ordinateurs : pour excuter les diffrentes tches informatiques relatives au systme. Ces composants communiquent entre eux par le biais des protocoles suivants : - RTSP : c'est un protocole de communication destin aux systmes de streaming media qui permettent de contrler un serveur de mdia distance, offrant des fonctionnalits typiques d'un lecteur vido tel que "lecture" et "pause", et permettant un accs en fonction de la position temporelle [17]. - NFS : c'est un protocole dvelopp par Sun Microsystems qui permet un ordinateur d'accder des fichiers via un rseau [17]. - HTTP : c'est un protocole de communication informatique client-serveur dvelopp pour le WWW. Il est utilis pour transfrer les documents (documents HTML, image, feuille de style, etc.) entre le serveur HTTP et le navigateur Web lorsqu'un visiteur consulte un site Web [17]. - HTTPS : c'est la variante de HTTP scurise avec les protocoles SSL ou TLS. Il permet au visiteur de vrifier l'identit du site auquel il accde grce un certificat d'authentification. Il permet galement de chiffrer la communication et est gnralement utilis pour les transactions financires en ligne : commerce lectronique, banque en ligne, courtage en ligne, etc. [17].

III.2.Conception de la base de donnes III.2.1.La mthode Merise pour la conception de la base de donnesMerise est une mthode de conception, de dveloppement et de ralisation des projets informatiques. Son but est la sparation des donnes et des traitements effectuer en plusieurs modles conceptuels et physiques. Elle date de 1978-1979, et est cre suite une consultation lance en 1977 par le ministre de l'industrie franais dans le but de choisir des socits de conseil en informatique afin de dfinir une mthode de conception de systmes

Confidentiel

23

PFE-Sup'com 2006


d'information. Les deux principales socits ayant mis au point cette mthode sont le CTI, charg de grer le projet, et le CETE [8]. Merise dcompose un systme dinformation en niveaux voluant de labstrait vers le concret. Ses diffrents niveaux et modles sont : - Le niveau conceptuel : dcrit la statique et la dynamique du systme dinformation en se proccupant uniquement du point de vue du gestionnaire. - Le niveau organisationnel : dcrit la nature des ressources qui sont utilises pour supporter la description statique et dynamique du systme dinformation. Ces ressources peuvent tre humaines et/ou matrielles et logicielles. - Le niveau oprationnel : dans lequel on choisit les techniques dimplantation du systme dinformation (donnes et traitements). - Le modle de communication : il formalise les changes dinformations en systmes dinformation. - Le modle de traitement : il formalise les traitements effectus par un systme fonctionnel. - Le modle de Donnes : il est la rfrence de lactivit de lentreprise, la manire dont elle peroit et mmorise son activit. Il formalise toutes les informations mmorises.

Tableau 2.1: Les diffrents niveaux et modles de Merise.

Niveau

Donnes Modle Conceptuel de Donne (MCD) Modle Logique de Donne (MLD, OU?) Modle Physique de Donne (MPD)

Traitement Modle Conceptuel de Traitement (MCT) Modle Organisationnel de Traitement (MOT, QUI, QUAND?) Modle Oprationnel de Traitement (MOPT)

Objectif

Conceptuel

Quoi ?

Organisationnel (Logique)

Qui, Ou, Quand ?

Oprationnel (Physique)

Comment ?

Confidentiel

24

PFE-Sup'com 2006


A part le fait qu'elle soit la mthode la plus utilise pour concevoir les bases de donnes relationnelles, notre choix s'est port sur elle vu qu'elle offre des modles qui sparent les donnes et les traitements. Ces modles permettent de structurer d'une faon claire les entits et les informations entre ces entits, afin que l'ensemble soit le plus efficace et volutif possible. Cependant, comme toute mthode, Merise n'est pas une fin en soi mais elle est un cadre d'action qu'il faut adapter en fonction du contexte. Partant de ce principe, on s'est limit dans au dveloppement des deux modles MCD et MLD qui sont suffisants pour dcrire notre base de donnes.

III.2.2.Modle conceptuel de donnesLe modle conceptuel de donnes est une reprsentation statique du systme dinformation de lentreprise qui met en vidence sa smantique. Il a pour but d'crire de faon formelle les donnes qui seront utilises par le systme d'information. Il s'agit donc d'une reprsentation des donnes facilement comprhensible. Le formalisme adopt par la mthode Merise pour raliser cette description est bas sur les concepts 'entit-association'. Dans ce contexte on dfinit : - Proprit : c'est une information lmentaire, cest--dire non dductible dautres informations, qui prsente un intrt pour le domaine tudi. - Entit : c'est la reprsentation d'un lment matriel ou immatriel ayant un rle dans le systme que l'on dsire dcrire. Chaque entit est compose de proprits permettant de la dcrire. - Association : c'est un lien smantique entre plusieurs entits. - Identifiant : c'est un ensemble de proprits (une ou plusieurs) permettant de dsigner une et une seule entit. - Cardinalits : c'est un couple de valeurs qui exprime le nombre minimal et maximal de fois qu'un lment d'entit peut exister dans les lments de l'association. Elles permettent de caractriser le lien qui existe entre une entit et la relation laquelle elle est relie. Le MCD (Figure 2.12) ralis avec l'outil PowerDesigner est compos des entits suivantes : Confidentiel 25

PFE-Sup'com 2006GARDE date D date 1,n pharmacie_garde


DEPARTEMENT iddep VA2 nomdep VA30 iddep 1,n

0,n PHARMACIE idphar desphar adrphar telphar urlphar idphar 1,n gere LI VA200 TXT LI TXT 1,1 possede CPOSTAL cpos SI cpos 0,n 1,1 appartient

se trouve

1,1 DISTRICT 1,n iddis I nomdis VA20 iddis

1,n UTILISATEUR idu nomu 1,n pnomu loginu mopasu 1,n role idu I VA50 VA50 VA20 VA20 ENUM('admin','pro')

est_gere

Figure 2.12 : Le modle conceptuel de donnes.

- GARDE : reprsente la date de garde d'une pharmacie. - PHARMACIE : regroupe les informations relatives une pharmacie.

Confidentiel

26

PFE-Sup'com 2006


- UTILISATEUR : regroupe les informations relatives aux personnes qui ont le droit d'accder certaines parties protges du systme. - CPOSTAL : reprsente le code postal d'une pharmacie. - DISTRICT : reprsente le district d'une pharmacie. - DEPARTEMENT : reprsente le dpartement d'une pharmacie. Le dictionnaire de donnes (Tableau 2.2) suivant, dcrit les proprits des entits.Tableau 2.2: Dictionnaire des donnes.

Nom du champ Date idphar desphar adrphar telphar urlphar Idu nomu pnomu loginu mopasu role cpos iddis nomdis iddep nomdep

Description Date de la garde. Identifiant d'une pharmacie. Description d'une pharmacie. Adresse d'une pharmacie. Tlphone d'une pharmacie. URL de l'annonce audio d'une pharmacie. Identifiant d'un utilisateur. Nom d'un utilisateur. Prnom d'un utilisateur. Login d'un utilisateur. Mot de passe d'un utilisateur. Type d'un utilisateur (administrateur, professionnel). Code postal. Identifiant d'un district. Nom d'un district. Identifiant d'un dpartement. Nom d'un dpartement.

Type Date Entier Caractre Texte Entier Texte Entier Caractre Caractre Caractre Caractre Enumration Entier Entier Caractre Caractre Caractre

Confidentiel

27

PFE-Sup'com 2006


III.2.3.Modle logique de donnes

GARDE date date FK_PHARMACI_PHARMACIE_GARDE

DEPARTEMENT pharmacie_garde idphar integer date date FK_PHARMACI_PHARMACIE_PHARMACI

iddep varchar(2) nomdep varchar(30)

FK_DISTRICT_SE_TROUVE_DEPARTEM

PHARMACIE idphar integer smallint cpos desphar varchar(200) adrphar long varchar telphar integer urlphar long varchar

FK_PHARMACI_POSSEDE_CPOSTAL

CPOSTAL FK_CPOSTAL_APPARTIEN_DISTRICT iddis cpos smallint iddep iddis integer nomdis

DISTRICT integer varchar(2) varchar(20)

FK_GERE_GERE_PHARMACI

gere idphar integer idu integer

FK_GERE_GERE2_UTILISAT

UTILISATEUR integer idu varchar(50) nomu pnomu varchar(50) loginu varchar(20) mopasu varchar(20) ENUM('admin','pro') role

FK_EST_GERE_EST_GERE_UTILISAT

FK_EST_GERE_EST_GERE2_UTILISAT

est_gere UTI_idu integer idu integer

Figure 2.13 : Le modle logique des donnes.

Le modle logique de donnes (Figure 2.13) donne une vue de la structure de la base de donnes et est obtenu partir du MCD en respectant les rgles suivantes : - Toute entit devient une relation, autrement dit elle devient une table de la base de donnes et l'identifiant de l'entit constitue la cl primaire de la table. Confidentiel 28

PFE-Sup'com 2006


- Une association 'un plusieurs' implique lintgration de la cl de la table relative la classe portant la cardinalit 'un ' dans la table relative la classe portant la cardinalit 'plusieurs'. - Une association 'plusieurs plusieurs' implique la cration dune nouvelle table ayant comme cl la concatnation des deux tables relatives aux classes associes. Il faut noter qu'avec les rgles de passage cites ci-dessus, il y a eu la gnration du MLD avec l'ajout par rapport au MCD des trois tables : pharmacie_garde, gere, est_gere.

III.3.Conception du SVI III.3.1.Choix du VoiceXML pour le dveloppement du SVINous avons opt pour le VoiceXML qui est une technologie standard recommande par le W3C suivants : pour dvelopper notre SVI. En effet, cette technologie prsente les avantages

Passerelle VoiceXML Donnes Serveur WebNavigateur Web

Figure 2.14 : Architecture d'une application intgrant VoiceXML.

Le dveloppement des applications VoiceXML est bas sur une rutilisation des composants logiciels des architectures Web (serveurs HTTP, serveurs d'applications etc.). La fiabilit de ces composants n'est plus dmontrer, ils ont bnfici de plusieurs annes d'utilisation intensive dans le monde des applications Web classiques.

Le VoiceXML est un langage simple qui permet facilement de dvelopper un service de tlcommunications. Cela rduit considrablement le temps et les cots de la mise en uvre de notre serveur vocal interactif.

Confidentiel

29

PFE-Sup'com 2006


Le VoiceXML garantit un accs centralis aux donnes du fait qu'il s'interface avec des applications Web, ce qui limine le risque que le SVI prsente des informations obsoltes.

III.3.2.Choix de la solution de l'intgration du SVIPour lier le SVI au serveur Web, nous avons eu choisir une des trois solutions suivantes : 1. Intgration du SVI par gnration du XML

Figure 2.15 : Schma synoptique de l'intgration du SVI par gnration du XML.

Cette solution consiste prsenter les informations gnrer dynamiquement sous format XML puis de les adapter selon le canal client en utilisant des standards de transformation du XML telle que le XSLT (Figure 2.15). Ses avantages rsident dans le fait qu'elle permet un ajout facile de nouveaux canaux de communication, do la facilit de

Confidentiel

30

PFE-Sup'com 2006


l'intgration du SVI. En plus, elle assure une bonne monte en charge puisque les flux changs sont de petite taille. Cependant sa mise en place est trs difficile voire impossible si on ne dispose pas d'une architecture qui spare la couche prsentation de la couche donne. 2. Intgration par gnration directe du VoiceXML

Figure 2.16 : Schma synoptique de l'Intgration du SVI par gnration directe du VoiceXML.

Cette solution consiste modifier une application Web pour retourner du VoiceXML en plus du HTML en rponse certaines requtes http (Figure 2.16). Cette solution se distingue par une mise en place rapide et comme la solution cite prcdemment, elle offre priori une bonne monte en charge puisque la taille des flux VoiceXML changs est trs faible.

Confidentiel

31

PFE-Sup'com 2006


Cependant, elle ne permet pas un ajout facile d'autres canaux de communication puisqu' chaque fois on sera amen modifier l'application Web. 3. Intgration par transformation des pages HTML vers des pages VoiceXML

Figure 2.17 : Intgration du SVI par transformation des pages HTML vers des pages VoiceXML

Cette solution consiste envoyer au serveur vocal des pages HTML et c'est lui de les transformer en pages VoiceXML (Figure 2.17). Cette solution n'est envisageable que si les changements ct Web ne sont pas possibles puisqu'elle a les dsavantages suivants : - Elle monte mal en charge vu la taille des pages HTML qui peut tre grande. - Le dlai de sa mise en place est plus important par rapport aux autres solutions puisqu'il faut dvelopper un module de traitement des pages HTML pour extraire les donnes pertinentes ce qui n'est pas facile raliser. - Le fonctionnement du serveur vocal sera impact par une modification des pages HTML retournes, puisqu' chaque fois que les pages HTML sont modifies il faudra effectuer des changements ct serveur vocal.

Confidentiel

32

PFE-Sup'com 2006

Conception du systme pour le service valeur ajoute solution

En ce qui concerne notre application, nous avons choisi la premire

"intgration du SVI par gnration du XML". En effet, cette solution permet l'volution du systme par intgration de nouveaux canaux de communication tel que le dveloppement d'un client "Pocket PC".

III.4.Conception de l'application Web III.4.1.Le choix du motif de conception MVC pour l'application WebDans le domaine de l'analyse et de la conception oriente objet, un motif de conception est une manire de dfinir la structure d'une classe. Plus gnralement, c'est un document qui dcrit une solution gnrale d'un problme qui revient souvent. Il est bas sur des expriences passes et est donc un ensemble de techniques permettant d'augmenter la productivit en adoptant certaines structures tablies et rutilisables. Le motif MVC est le plus utilis aujourd'hui. Il vient du monde de Smalltalk, l'un des premiers langages orients objet. Son ide de base est qu'un programme peut tre dcompos en trois parties :

Le Modle : reprsente le comportement de l'application tels que les traitements des donnes, les interactions avec la base de donnes, etc. Il dcrit les donnes manipules par l'application et dfinit les mthodes d'accs.

La Vue : correspond l'interface avec laquelle l'utilisateur interagit. Les rsultats renvoys par le modle sont dnus de toute prsentation mais sont prsents par les vues. Plusieurs vues peuvent afficher les informations d'un mme modle. Elles peuvent tre conues en HTML, ou tout autre langage de prsentation. La vue n'effectue aucun traitement, elle se contente d'afficher les rsultats des traitements effectus par le modle, et de permettre l'utilisateur d'interagir avec elles.

Le Contrleur : prend en charge la gestion des vnements de synchronisation pour mettre jour la vue ou le modle. Il ne modifie aucune donne, il analyse la requte du client et se contente d'appeler le modle adquat et de renvoyer la vue correspondante la demande. L'ide forte de ce motif est la sparation totale des donnes, de leur traitement et de leur reprsentation. Cela permet de modifier l'interface (ou d'en ajouter d'autres) facilement sans avoir toucher aux classes qui manipulent les donnes. Nous pouvons schmatiser une telle architecture de la faon suivante (Figure 2.18) : Confidentiel 33

PFE-Sup'com 2006


Figure 2.18 : Architecture MVC [12].

1. Le client fait une demande au contrleur. Ce contrleur passe toutes les demandes des clients; c'est la porte d'entre de l'application. C'est le C de MVC. 2. Le contrleur traite cette demande. Pour ce faire, il peut avoir besoin de la couche mtier. Cette dernire, son tour, peut faire appel la couche d'accs aux donnes. 3. Le contrleur reoit une rponse de la couche mtier. 4. Le contrleur choisit la vue envoyer au client. 5. La vue est envoye au client. C'est le V de MVC [12]. Notre choix pour le modle de conception MVC est justifi par l'architecture claire qu'il impose. Cela simplifierait les tches de maintenance et d'amlioration du systme. En plus, la solution pour laquelle on a opt pour lier le SVI au serveur Web exige la sparation des couches donnes; cette sparation est assure par le motif SVI.

III.4.2.Diagramme des composantsL'architecture logicielle de l'application Web reprsente par le diagramme des composants (Figure 2.19) met en oeuvre les huit sous systmes suivants :

Confidentiel

34

PFE-Sup'com 2006


Gestion des gardes

InfoGarde

Gestion des districts

Commun

Administration

Gestion des pharmacies

Scurit

Recherche

Figure 2.19 : Le diagramme des composants.

- Scurit : regroupe les modules de la gestion de l'accs au site, entre autres l'identification des utilisateurs et le chargement de leurs interfaces appropries. - Gestion des districts : regroupe les modules relatifs la gestion des InfoGarde : districts. -

regroupe les modules de la consultation des gardes par un

utilisateur ordinaire y compris les classes de la gnration des flux XML, HTML et VoiceXML. - Administration : regroupe les modules de la gestion des utilisateurs. - Gestion des gardes : regroupe les modules de la gestion des gardes. - Gestion des pharmacies : Il regroupe les modules de la gestion de la liste des pharmacies. - Recherche : regroupe les modules qui permettentt l'utilisateur de rechercher une pharmacie. - Commun : regroupe les modules qui sont accessibles par plusieurs sous systmes (par exemple le FrontController), ainsi que les classes qui reprsentent la base de donnes. Confidentiel 35

PFE-Sup'com 2006


III.4.3.Prsentation du sous-systme "InfoGarde"Pour ne pas surcharger ce rapport et vu la ressemblance des architectures des soussystmes prsents prcdemment, nous avons choisi de prsenter le sous-systme "InfoGarde". Pour prciser l'appartenance de chaque module aux diffrentes couches du MVC nous allons utiliser les symboles suivants :

Modle

Vue

Contrleur

III.4.3.1.La chane de gnration d'un flux de donnesVXSLT.xslt HXSLT.xslt

informations

gnrateur XML

flux XML

flux VoiceXML ou HTML adaptateur XML

Figure 2.20 : Chane de gnration d'un flux de donnes.

Les informations sur les gardes des pharmacies passent par un gnrateur de flux XML (XMLGenerator). Ce dernier va crer un flux XML puis le passe l'adaptateur XML (XMLAdaptator). Selon le canal de communication, l'adaptateur XML gnre le flux adquat l'aide des descriptions des feuilles de style XSLT (voir annexe B) aprs avoir vrifi la syntaxe du flux XML. Dans notre cas, nous avons prvu deux canaux de communications : le canal Web et le canal vocal. VXSLT dcrit la transformation du flux XML en flux VoiceXML. Quant HXSLT, il dcrit la transformation du flux XML en flux HTML. Confidentiel 36

PFE-Sup'com 2006


III.4.3.2.Diagramme des classes du sous-systme "InfoGarde"Le diagramme des classes (Figure 2.21) du sous-systme "InfoGarde" est compos des classes suivantes :

erreursInfoGarde

resultatInfoGarde

0..1 1 infoGarde 1 1 frontController 1

0..1

1 1 resultat 1 1 controlInfoGarde xmlAdaptator 1 1 1 1 xmlGenerator

1

1 ActionInfoGarde 1 1 infoGardeDAO 1 1 pharmacie_garde

Figure 2.21 : Diagramme des classes du sous systme"InfoGarde".

- infoGarde : elle reprsente l'interface de la consultation des gardes partir d'un code postal. - erreursInfoGarde : c'est l'interface qui s'affiche s'il y a eu une erreur d'excution ou de saisie.

Confidentiel

37

PFE-Sup'com 2006


- resultatInfoGarde : c'est l'interface qui prsente les rsultats de l'excution d'une requte du client. - frontController : c'est le module qui analyse les requtes de l'utilisateur, slectionne la vue et le contrleur local un sous systme donn. Notons que ce module appartient au sous systme "Commun". - resultat : une classe qui contient l'tat de l'excution d'une requte client. Suivant cet tat, le frontController slectionne la vue approprie. Cette classe fait partie du sous systme "Commun". - controlInfoGarde : c'est un contrleur relatif au sous systme "InfoGarde". - xmlAdaptator : regroupe les fonctions de vrification du flux XML gnr et de son adaptation selon le canal client. - xmlGenerator : s'occupe de la gnration du flux XML partir des informations fournies par les classes du modle. - actionInfoGarde : elle appartient la couche mtier et traduit l'action de la consultation des gardes. - infoGardeDAO : c'est la classe de manipulation des donnes. Elle implmente les requtes SQL pour la consultation des gardes. - pharmacie_garde : elle reprsente la table pharmacie_garde.

Confidentiel

38

PFE-Sup'com 2006


III.4.3.3.Reprsentation du scnario de la gnration d'un flux VoiceXML

InfoG arde

resultatInfoG arde

frontController

resultat

controlInfoG arde

XM LAdaptator

XM enerator LG

actionInfoG arde

infoG ardeD AO

choisirC odePostal () client = SVI choisirControleur() dem ande du flux VoiceXM L()

dem ande du flux XM L()

inform ations() dem ande des donnees inform ations donnees

flux xm l flux VoiceXM L construireResultat()

notifierConstructionR esultat() choisirVue()

Figure 2.22 : Scnario de gnration d'un flux VoiceXML.

Le diagramme des squences (Figure 2.22) dcrit dans le temps le scnario nominal de la gnration d'un flux VoiceXML. En effet, l'interface passe au FrontController le code postal et le type du canal de communication qui est dans ce cas le canal vocal. Le FrontController appelle le contrleur local controlInfoGarde qui son tour demande le flux VoiceXML du XMLAdaptator. Ce dernier demande l'XMLGenerator de lui fournir le flux XML. Le XML generator demande l'actionInfoGarde les informations sur les gardes. Ces informations seront construites aprs l'extraction des donnes stockes dans la base de donne, par l'infoGardeDAO.

ConclusionCe chapitre a t ddi l'tude du systme construire. Cette tude a commenc par une spcification des besoins raliser pour dterminer les fonctionnalits que le systme doit offrir. Ensuite, on a mis au point un modle pour ce systme. Dans le chapitre suivant, nous dcrirons le systme que nous avons ralis. Confidentiel 39

PFE-Sup'com 2006

Ralisation du systme pour le service valeur ajoute

Chapitre 3 : Ralisation du systme pour le service valeur ajoute

Aprs avoir dfini l'architecture de notre systme, prcis ses composants logiciels et matriels, il ne reste plus qu' le construire. Dans ce chapitre, nous commenons par une prsentation des diffrents choix technologiques faits pour dvelopper le systme. Ensuite, nous exposons l'environnement matriel et logiciel utilis pour raliser le systme. Enfin, nous dcrivons le systme obtenu.

Confidentiel

40

PFE-Sup'com 2006


I.Les choix techniques pour la ralisation du systme I.1.Choix du langage de programmation a. PHPPHP est un langage qui permet de dvelopper des applications Web dynamiques puissantes. Ses avantages rsident dans son indpendance de la plate forme. En effet, il existe pour les diffrentes versions de Windows, Unix et Linux. De plus, c'est un langage de script embarqu dans les pages HTML et trait par le serveur. PHP permet de construire dynamiquement des pages HTML contenant des rsultats de calcul ou de requtes SQL adresses un systme de gestion de bases de donnes.

b. ASPASP a t cr en 1996 par Microsoft. Cette technologie concurrenait le PHP. L'ASP fait maintenant place la plate-forme de dveloppement .NET sous le nom ASP .NET. Avec ce langage de programmation, les donnes utilises au sein des sites Web peuvent tre partages avec d'autres sites travers des services Web puisqu'il gre nativement ces nouveaux standards d'change.

c. Critiques et choix- La portabilit : ASP.net ne tourne que sur IIS et IIS ne peut tre install que sur un serveur Windows, alors que PHP s'installe sur Apache qui se distingue par le fait quil est multi plateforme et libre. - Le prix : ASP.net demande de nouveaux frais ds quil faut intgrer de nouveaux add-on, par contre PHP est totalement gratuit. - Lefficacit : ASP.net bnficie dun framework trs puissant lui permettant aisment de manipuler lhritage, le polymorphisme, et lencapsulation. Mais finalement, le code gnr souffre de temps dexcution pnalisants et dune utilisation mmoire trop importante. PHP est plus rapide sexcuter et bnficie de beaucoup de solutions comme "Zend Performance Suite" permettant de prcompiler les pages doptimiser les temps.

Confidentiel

41

PFE-Sup'com 2006


- Interaction : lintgration aux bases de donnes se fait laide des liens ODBC en ASP.net. PHP peut galement utiliser les liens ODBC mais il dispose de fonctions natives pour MySQL, Oracle et PostgreSQL. - Evolution : Le modle collaboratif du PHP permet de dtecter et corriger plus rapidement les bogues. Le niveau de qualit obtenu est donc amlior. Tandis quun bogue trouv sur ASP.net doit tre corrig, test, puis soumis validation et donc met beaucoup plus de temps tre mis en place. Autre point noir de lASP.net, le code source nest pas disponible alors que la philosophie de PHP incite au partage des sources. Ceci permet de rcuprer beaucoup de code utile et ainsi de dvelopper plus vite. Au final, le PHP se dmarque clairement de lASP, raison pour laquelle on a opt pour ce langage pour dvelopper notre application Web.

I.2.Choix de l'API de traitement du XMLL'analyseur, gnralement appel parseur, est un outil permettant de parcourir un document et d'en extraire des informations. Dans le cas de XML, on parle de parseur XML. Pour analyser un document, les parseurs utilisent actuellement deux types d'approches : - Les API bases sur un traitement hirarchique qui construisent une structure

hirarchique contenant des objets reprsentant les lments du document, et dont les mthodes permettent d'accder aux proprits. La principale API utilisant cette approche est DOM (Document Object Model). - Les API bases sur un mode vnementiel permettant de ragir des vnements (comme le dbut d'un lment, la fin d'un lment) et de renvoyer le rsultat l'application utilisant cette API. SAX (Simple API for XML) est la principale interface utilisant l'aspect vnementiel. Ainsi, on a tendance associer l'approche hirarchique avec DOM et l'approche vnementielle avec SAX. Les proprits de chaque API sont prsentes par le tableau suivant :

Confidentiel

42

PFE-Sup'com 2006


Tableau 3.1: Comparaison SAX/DOM.

DOM - Un processus qui utilise le DOM ne peut traiter l'arbre qu'aprs la lecture entire du document. - Accs alatoire. - Utilise beaucoup de mmoire. - Construction de l'arbre du document. - Les objets sont rutilisables.

SAX - Un analyseur SAX dlivre les donnes un processus au fur et mesure de la lecture du document. - Accs squentiel. - Utilise peu de mmoire. - Evnementiel. - Les objets ne sont pas stocks d'ou ils ne sont pas rutilisables. - Fonctionnalits rudimentaires. - Plus rapide car il examine les donnes au fur et mesure qu'elles arrivent.

- Richesse des fonctionnalits. - Moins rapide car il construit l'arbre du document.

Selon la comparaison ci-dessus. L'interface SAX est la plus adapte nos besoins. En effet, nous aurons besoin seulement du parseur pour vrifier la syntaxe du document XML puisque sa transformation s'effectue par des fichiers XSLT, d'o l'absence du besoin de stockage des objets en mmoire afin de les rutiliser. Par suite les fonctionnalits qu'il offre, rudimentaires qu'elles soient, sont suffisantes. En plus, elle est plus rapide, ce qui construit un apport pour notre systme qui a besoin de cette rapidit.

I.3.Choix du SGBDEn ce qui concerne la base de donnes, nous avons choisi le SGBD MySQL. En effet ce choix est justifi par le fait que : - C'est un serveur de base de donnes SQL. SQL est le langage des bases de donnes le plus populaire dans le monde. - Il est libre, gratuit et trs utilis aussi bien dans les projets libres que dans le milieu industriel vu son bon rapport qualit/prix.

Confidentiel

43

PFE-Sup'com 2006


- Il fonctionne sur beaucoup de plates formes par exemple Windows, Unix, Linux.

II.Environnement de travailCette sous-section dcrit l'environnement matriel et logiciel avec lequel nous avons ralise ce projet de fin d'tudes.

II.1.Environnement matrielL'application a t dveloppe l'aide d'un micro-ordinateur ayant les caractristiques suivantes : - Processeur Pentium IV 2.66 Ghz. - Disque dur de capacit 80 Go. - 512 Mo de RAM. - Ecran LCD 17.

II.2.Environnement logiciel- Microsoft Windows XP : systme d'exploitation. - EasyPHP : c'est une plateforme de dveloppement Web, permettant de faire fonctionner localement (sans se connecter un serveur externe) des scripts PHP. Il comprend deux serveurs (Apache et Mysql) et une administration SQL (PhpMyAdmin). - Skype : un logiciel de tlphonie IP. - Macromedia DreamWeaver : logiciel de conception des applications Web. - Pacestar UML diagrammer : logiciel de conception UML. - Sybase PowerDesigner : logiciel de conception des bases de donnes. -Plateforme Eloquent : plateforme franaise d'hbergement des serveurs

vocauxVoiceXML.

Confidentiel

44

PFE-Sup'com 2006


III. Prsentation du systme ralisL'IHM reprsente un lment cl dans l'utilisation de tout systme informatique et conditionne pour une large part son succs. En thorie, une interface doit tre naturelle, efficace, intelligente, fiable, de comprhension et d'utilisation facile. Autrement dit la plus proche possible des diffrents modes de perception et de communication humaine, que sont par exemple la parole et l'criture. Pour ce, nous avons compt sur l'expertise de certains membres de notre quipe afin que notre systme dispose d'une interface la fois efficace et conviviale. L'interface illustre par la figure 3.1 reprsente la page d'authentification pour l'accs aux fonctionnalits protges du systme selon la nature de l'utilisateur (administrateur ou professionnel).

Figure 3.1 : Page d' athentificaton.

La figure 3.2 reprsente le menu principal des diffrentes fonctionnalits pour grer les gardes des pharmacies. Ce menu comporte les liens suivants : - "Ajouter phamacie" permet la saisie d'une fiche de pharmacie.

Confidentiel

45

PFE-Sup'com 2006


- "Consulter garde" permet l'administration des gardes. - "Rechercher pharmacie" permet de rechercher une pharmacie. - "Grer district" permet la gestion de la liste des districts. - "Se dconnecter" permet de retourner vers la page d'authentification.

Figure 3.2 : Menu principal de la gestion des gardes.

Pour illustrer de faon claire les fonctionnalits offertes par le systme, on va les prsenter sous forme de scnarii. 1. Ajout/Suppression d'un district

Figure 3.3 : Ajout de district.

Confidentiel

46

PFE-Sup'com 2006


Ce scnario est ralis lorsque le professionnel dsire insrer un nouveau district. Ce dernier saisit les informations ncessaires et valide. Le systme lui affiche alors un message pour l'informer de l'tat de sa requte. Dans le cas de la Figure 3.3, le professionnel a voulu insrer un district qui existe dj. Comme rponse le systme lui a affich le message "District existant". 2. Ajout de pharmacie

Figure 3.4 : Ajout de pharmacie.

Confidentiel

47

PFE-Sup'com 2006


Ce scnario (Figure3.4) reprsente l'opration de l'insertion d'une nouvelle pharmacie. Aprs avoir saisi les informations ncessaires, le professionnel clique sur le bouton "Ajouter". Le systme l'avise du bon droulement de l'opration et affiche la page de l'insertion de l'annonce vocale relative la pharmacie. Cette annonce vocale va tre dpose sur le serveur des fichiers audio de la plateforme d'hbergement des applications VoiceXML. 3. Consultation des gardes par le grand public

Figure 3.5 : Consultation des gardes par le grand public.

La Figure 3.5 rsume l'opration de la consultation des gardes partir du SVI. En effet, cette interface Web a t dveloppe pour montrer la possibilit de la diffusion multi-canale de l'information, puisque les informations affiches ci-dessus sont les mmes transmises au serveur vocal interactif. Dans ce cas, l'utilisateur a tap le code postal 38100. Selon la date, le systme affiche la liste des pharmacies de garde pour ce code postal.

Confidentiel

48

PFE-Sup'com 2006 4.


Recherche d'une pharmacie

Figure 3.6 : Recherche d'une pharmacie.

Confidentiel

49

PFE-Sup'com 2006


Ce scnario (Figure 3.6) dcrit l'opration de recherche d'une pharmacie en se basant sur le numro de dpartement. Un click sur le bouton "Rechercher" affiche des liens vers les fiches des pharmacies qui appartiennent au dpartement n 38. Le professionnel peut alors consulter les informations dj saisies et les modifier, couter l'annonce vocale d'une pharmacie et la modifier. 5. Gestion des gardes Ce scnario reprsent par la Figure 3.7, illustre l'opration de la gestion des gardes. Le professionnel choisit le dpartement, le district et la date pour lesquels il veut connatre les pharmacies qui sont de garde. Le systme lui offre alors une vue du planning des gardes pour le mois choisi avec la possibilit de la navigation d'un mois un autre en cliquant sur les flches prsentes au dessus du tableau. Il lui offre aussi la possibilit de consulter les fiches des pharmacies par affichage de leurs noms sous forme de liens hypertexte. En ce qui concerne l'ajout de garde, deux faons sont proposes. La premire par un click sur le bouton (+), ce qui permet de planifier une garde en fournissant seulement le nom de la pharmacie. La deuxime par un click sur le lien "Ajouter garde" si le professionnel dsire planifier les gardes pour un autre district. Quant la suppression des gardes, le lien (-) prsent devant chaque nom de pharmacie permet de le faire.

Confidentiel

50

PFE-Sup'com 2006


Figure 3.7 : Gestion des gardes.

Confidentiel

51

PFE-Sup'com 2006 6. Gestion des professionnels


Figure 3.8 : Gestion des professionnels.

La Figure 3.8 reprsente les fonctionnalits d'ajout et de suppression des professionnels. Cette interface est accessible seulement par l'administrateur.

ConclusionCe chapitre, le dernier de ce rapport, a prsent les choix qui ont t faits pour laborer notre systme, les outils utiliss, ainsi que le rsultat de notre travail.

Confidentiel

52

PFE-Sup'com 2006

Conclusion gnrale

Conclusion gnraleLes rvolutions technologiques dans l'informatique et les tlcommunications ont rendu possible le dveloppement de nouveaux services qui fournissent une grande valeur ajoute par rapport certains services traditionnels. Dans ce cadre, le prsent projet de fin d'tudes avait pour but la mise en place d'un service de tlcommunications forte valeur ajoute base d'un systme Web-Vocal pour la rsolution de la problmatique de la gestion des gardes des pharmacies en France et l'accs du grand public aux informations qui les concernent par le grand public. En effet, l'absence d'un systme centralis a fait sentir ses effets, crant par exemple des inflexibilits pour la consultation de la liste des pharmacies de garde. Nous avons donc dvelopp un systme compos d'une application Web ddie la gestion des gardes des pharmacies et d'une application vocale base sur la technologie VoiceXML pour permettre un accs faciles aux informations sur les gardes. Nous avons aussi assur la liaison entre ces deux applications travers le dveloppement d'un module qui gnre du XML et l'adapte selon le canal de communication. De cette faon, il a t possible au serveur vocal de rcuprer les donnes dynamiquement du serveur Web qui assure leur mise jour. Ceci a permis la centralisation de la gestion des gardes des pharmacies et de l'accs aux informations qui les concernent. Ainsi, nous avons limin le risque de fournir des informations obsoltes et rendu plus flexible cette tche. En ce qui concerne la dmarche, nous avons en premier lieu effectu une phase bibliographique afin de dcouvrir les techniques existantes pour le dveloppement des systmes tel que le ntre. En deuxime lieu nous avons spcifi notre systme pour en discerner les fonctionnalits. En troisime lieu, nous avons procd sa conception ainsi qu'aux choix technologiques pour sa ralisation. Enfin, nous l'avons mis en uvre par le dveloppement et la liaison des deux sous systmes Web et vocal. Confidentiel 53

PFE-Sup'com 2006

Conclusion gnrale

Ce projet peut encore voluer en intgrant au systme d'autres canaux de communication comme le "Pocket PC". Il peut aussi intgrer une couche Web service, de cette faon les changes des informations entre ce systme et ses clients seront standardiss. Par ailleurs, la moindre des choses je dois dire est que ce projet de fin d'tudes ne m'avait t qu'une source de bnfices, tant au niveau technique qu'aux niveaux professionnel et relationnel. En effet, un aspect important dans mon exprience tait l'esprit d'quipe, ceci m'a appris qu'un problme ne peut tre rsolu sans la synergie des comptences. En plus, j'ai eu l'occasion de faire appel mes connaissances d'lve ingnieur qui a fait le choix de l'option services et communication pour les rseaux multimdia, une option qui m'a permis de dcouvrir le monde de dveloppement des services de tlcommunications et dont le but se concordait parfaitement avec le but de ce projet de fin d'tudes. J'ai eu aussi l'occasion de ctoyer une technologie qui est en train de rvolutionner le domaine des services des tlcommunications valeur ajoute, d'enrichir ma base de connaissance sur les technologies du Web et d'approfondir mes comptences en tant qu'ingnieur en tlcommunications.

Confidentiel

54

PFE-Sup'com 2006

Annexe : La famille XML


Confidentiel

55

PFE-Sup'com 2006


1. XMLXML (eXtensible Markup Language) est un langage de balisage des documents. Une recommandation du W3C du 10 fvrier 1998 le dfinit dans sa version 1.0. Un document XML est un arbre et par consquent, il est toujours compos d'un seul lment, l'lment racine qui est gnralement une collection de sous lments. Ses principales caractristiques sont : - Un ensemble extensible de balises. - Une sparation entre la reprsentation et les donnes. - Une bonne adaptation la diffusion Internet.

2. DTD et XSDOn dit quun document XML est bien form, sil ne comporte pas de caractres invalides, si les balises sont bien imbriques, si les balises ouvertes sont fermes, si la casse est respecte et sil ny a quun seul lment racine. On dit quun document XML est valide, sil est bien form et quil correspond un formalisme prdfinis. Ce dernier peut tre un document DTD ou XSD, et peut soit tre inclus dans le document soit tre rfrenc dans ce dernier. DTD (Document Type Definition) et XSD (XML Schema Description) sont donc des documents XML qui dcrivent de quelle manire en XML un objet ou une relation doit tre form. Cela permet de dcrire un schma relationnel.

3. Les feuilles de style : XSLT, XPATH, XSL-FO XSLLe XSL pour eXtensible Stylesheet Language ou "langage extensible de feuilles de style" est une recommandation du W3C datant de novembre 1999. C'est donc un standard dans le domaine de la publication sur le Web. Le XSL est en quelque sorte le langage de feuille de style du XML. Un fichier de feuilles de style reprend des donnes XML et produit

Confidentiel

56

PFE-Sup'com 2006


la prsentation ou l'affichage de ce contenu XML selon les souhaits du crateur de la page. Le XSL comporte en fait trois langages : - Le XSLT qui est un langage qui Transforme un document XML en un format, gnralement en Html, reconnu par un navigateur. - Le Xpath qui permet de dfinir et d'adresser des parties de document XML. - Le XML Formatter pour "formater" du XML de faon ce qu'il puisse tre rendu sur des "Pocket PC" ou des units de reconnaissance vocale.

XSLTCest le eXtensible Stylesheet Langage Transformations. Il permet la transformation dun fichier XML en un autre document XML ou en dautres formats comme HTML, XHTML, WML et mme des formats inattendus tel que du code source Java. XSLT est plus complexe et plus sophistiqu que HTML mais lest moins que Java.

XSL-FOLes feuilles de style XSL-FO permettent de crer des documents partir de fichiers XML. Cette norme est le plus souvent utilise pour gnrer des fichiers PDF. Il est ainsi possible, dans une feuille de style XSL-FO, de dfinir la mise en page que devra avoir le document final (en-tte, pied de page, etc.). Cette norme est complmentaire XSLT. Alors que XSLT est utilis pour afficher du contenu XML (dans un navigateur Web par exemple), XSL-FO permettra de transformer ce contenu en un document pouvant tre facilement tlcharg et imprim par l'utilisateur final. Il est ainsi tout fait possible de proposer sur un site Web le mme contenu sous diverses formes sans jamais avoir toucher au document XML i

torkmen_karim

Documents