Bien Suivi !!!
Transcript of Bien Suivi !!!
Cycle de formation des ingénieurs en Télécommunications Option :
Services et Communication pour les Réseaux Multimédia
Rapport de Projet de fin d’études
Thème :
Conception et réalisation d'un service de télécommunications à forte valeur ajoutée
à base d'un système Web-Vocal pour la gestion des gardes des pharmacies
Réalisé par :
Karim TORKMANE
Encadrant (s) :
M. Riadh ABDELFATTAH M. Riadh TEBOURBI
Travail proposé et réalisé en collaboration avec
Année universitaire : 2005/2006
Dédicaces
A mes chers parents,
Que nulle dédicace ne puisse exprimer ce que je leurs dois, pour leur bienveillance, leur
affection et leur soutien… Trésors de bonté, de générosité et de tendresse, en
témoignage de mon profond amour et ma grande reconnaissance « Que Dieu vous
garde ».
A mes chers frères et soeur,
En témoignage de mes sincères reconnaissances pour les efforts qu’ils ont consenti pour
l’accomplissement de mes études. Je leur dédie ce modeste travail en témoignage de
mon grand amour et ma gratitude infinie.
A mon oncle Mustapha,
Qui a été et est toujours un père pour moi, aucune expression ne pourra exprimer ma
gratitude envers lui pour m'avoir considéré comme le fils qu'il n'a jamais eu.
A tous mes amis,
Pour leur aide et leur soutien moral durant l’élaboration du travail de fin d’étude.
A toute ma Famille…
A tous mes amis…
A tout ceux qui m'aiment…
PFE-Sup'com 2006 Résumé
Confidentiel i
Résumé
Grâce à la fusion de l'informatique et des télécommunications, de nouveaux services
appelés services de télécommunications à valeur ajoutée sont apparus, constituant
actuellement un marché potentiel pour les sociétés 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 télécommunications à valeur ajoutée qui organise les gardes des pharmacies en
France et permet un accès facile pour le grand public aux informations qui les concernent. Il
s'agit de concevoir et réaliser un système intégrant une application Web pour gérer les gardes
des pharmacies et un serveur vocal pour accéder aux informations sur ces gardes.
Mots clés : services de télécommunications à valeur ajoutée, voiceXML, Web, serveur
vocal interactif, garde des pharmacies, système centralisé.
PFE-Sup'com 2006 Abstract
Confidentiel ii
Abstract
Thanks 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.
PFE-Sup'com 2006 Avant propos
Confidentiel iii
Avant Propos
Ce projet de fin d'études s'inscrit dans le cadre de l'obtention du diplôme d'ingénieurs en
télécommunications. Il a été réalisé à la société PROXYM-IT et a pour objectif la conception
et la réalisation d'un service de télécommunications à forte valeur ajoutée à base d'un système
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 associés de PROXYM-IT qui m’ont donné la possibilité d’effectuer
mon projet de fin d'études au sein de leur société.
J'adresse aussi mes vifs remerciements à Mr. Riadh Abdelfattah et Mr Riadh
Tebourbi de Sup'com pour leur aide précieuse et leur clairvoyance.
Je tiens aussi à exprimer l’honneur qui m’est fait par les membres du jury en acceptant
de juger mon travail.
PFE-Sup'com 2006 Table des matières
Confidentiel iv
Table des matières
INTRODUCTION GENERALE.............................................................................................1
CHAPITRE 1 : CONTEXTE GENERAL DU PROJET......................................................3
I. LES SERVICES DE TELECOMMUNICATIONS A VALEUR AJOUTEE.............................................4
I.1. Présentation des services de télécommunications à valeur ajoutée..............................4
I.1.1. L'audiotex..............................................................................................................4
I.1.2. .La téléconférence .................................................................................................4
I.1.3. .La sauvegarde en ligne des données ....................................................................5
I.2. Les atouts pour la réalisation des services à valeur ajoutée ........................................5
I.2.1. Le Web ..................................................................................................................5
I.2.1.1 .Internet en bref ...............................................................................................5
I.2.1.2 .Les applications Web de première génération ...............................................5
I.2.1.3 .Les applications Web de deuxième génération ..............................................6
I.2.1.4 .Un Web à trois niveaux..................................................................................6
I.2.2. Le VoiceXML .......................................................................................................7
I.2.2.1 .Présentation du VoiceXML............................................................................7
I.2.2.2 .Modèle architectural du VoiceXML ..............................................................8
II. CADRE ET CONTEXTE DU PROJET.........................................................................................9
II.1. Organisme d'accueil ....................................................................................................9
II.2. Travail demandé .........................................................................................................9
II.3. Problématique ...........................................................................................................10
CHAPITRE 2 : CONCEPTION DU SYSTEME POUR LE SERVICE A VALEUR
AJOUTEE ...............................................................................................................................12
I. LA MISE EN OEUVRE DU PROJET..........................................................................................13
I.1. La démarche de la réalisation du projet .....................................................................13
PFE-Sup'com 2006 Table des matières
Confidentiel v
I.2. Le langage UML pour la modélisation du système....................................................14
II. SPECIFICATION DES BESOINS DE LA GESTION DES GARDES DES PHARMACIES.....................15
II.1. Description des besoins.............................................................................................15
II.2. Modélisation 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 matérielle du système .........................................................................21
III.2. Conception de la base de données ...........................................................................23
III.2.1. La méthode Merise pour la conception de la base de données.........................23
III.2.2. Modèle conceptuel de données.........................................................................25
III.2.3. Modèle logique de données ..............................................................................28
III.3. Conception du SVI ..................................................................................................29
III.3.1. Choix du VoiceXML pour le développement du SVI......................................29
III.3.2. Choix de la solution de l'intégration 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. Présentation du sous-système "InfoGarde" ......................................................36
III.4.3.1 .La chaîne de génération d'un flux de données...........................................36
III.4.3.2 .Diagramme des classes du sous-système "InfoGarde"..............................37
III.4.3.3 .Représentation du scénario de la génération 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 matériel............................................................................................44
II.2. Environnement logiciel.............................................................................................44
III. PRESENTATION DU SYSTEME REALISE..............................................................................45
PFE-Sup'com 2006 Table des matières
Confidentiel vi
CONCLUSION GENERALE................................................................................................53
ANNEXE : LA FAMILLE XML ..........................................................................................55
BIBLIOGRAPHIE .................................................................................................................58
PFE-Sup'com 2006 Liste des abréviations
Confidentiel vii
Liste des abréviations
API Application Programming Interface
ASP Active Server Pages
ASR Automatic Speech Recognition
AT&T American telephone and telegraph
CETE Centre d' Etudes Techniques de l' Equipement
CHU Centre Hospitalier Universitaire
CTI Centre Technique d'Informatique
DOM Document Object Model
DTMF Dual Tone Multi Frequency
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
HTTPS Secured HTTP
IBM International Business Machines Corporation
IHM Interface Homme/Machine
IIS Internet Information Services
IP Internet Protocol
MCD Modèle Conceptuel des Données
MLD Modèle Logique des Données
MVC Modèle Vue Contrôleur
NFS Network File System
NFS Network File System
OMG Object Management Group
OMT Object Modeling Technique
OOD Object-Oriented Design
PFE-Sup'com 2006 Liste des abréviations
Confidentiel viii
OOSE Object Oriented Software Engineering
OSS Operating Sub-System
PC Personal Computer
PHP Hypertext Preprocessor
RTSP Real Time Streaming Protocole
SAX Simple API for XML
SGBD Système de Gestion des Bases de Données
SpeechML Speech Markup Langauage
SQL Structured Query Language
SVI Serveur Vocal Interactif
SVI Serveur Vocal Interactif
TCP Transmission Control Protocol
TTS Text To Speech
UML Unified Modeling Language
VoiceXML Voice eXtensible Markup Language
VoxML Voice Markup Language
W3C World Wide Web Consortium
WWW World Wide Web
XML eXtensible Markup Language
XSLT eXtensible StyleScheet Langauge Transformation
PFE-Sup'com 2006 Listes des figures et tableaux
Confidentiel ix
Liste des figures et
tableaux
Figures FIGURE 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 "RECHERCHER PHARMACIE"............................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 SVI PAR TRANSFORMATION DES PAGES HTML VERS DES PAGES
VOICEXML.............................................................................................................................. 32
FIGURE 2.18 : ARCHITECTURE MVC ........................................................................................34
PFE-Sup'com 2006 Listes des figures et tableaux
Confidentiel x
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
Tableaux
TABLEAU 2.1: LES DIFFERENTS NIVEAUX ET MODELES DE MERISE............................................24
TABLEAU 2.2: DICTIONNAIRE DES DONNEES..............................................................................27
TABLEAU 3.1: COMPARAISON SAX/DOM. ...............................................................................43
PFE-Sup'com 2006 Introduction générale
Confidentiel 1
Introduction générale
Régulièrement nous est annoncé une nouvelle révolution qui, telle que l’invention de
l’imprimerie ou de l’électricité, marquerait le début d’une nouvelle ère. Ainsi en est-il
aujourd’hui des nouvelles technologies de l’information et de la communication. Cette
révolution n'aurait pu avoir lieu sans la fusion de deux domaines précédemment considérés
comme totalement séparés : l'informatique et les télécommunications.
Cette fusion a conduit à l'apparition de ce qu'on appelle les services de
télécommunications à valeur ajoutée, un domaine qui vise à créer de nouveaux services en
tirant profit des révolutions 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 développé pour supporter
le fonctionnement de certaines composantes et même remédier à leurs défaillances peut
garantir sa pérennité et donner un avantage concurrentiel à la société qui le propose. C'est le
cas d'une banque qui propose à ses clients la consultation de leurs comptes en ligne ou à partir
du téléphone, 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
système comblant les défauts régissant l'organisation des gardes des pharmacies.
Ce projet de fin d'études a été réalisé à la société PROXYM-IT, une société de
développement de services de télécommunications et d'informatiques. Il a pour objectif de
développer un service de télécommunications à forte valeur ajoutée pour la gestion des gardes
des pharmacies et la diffusion des informations qui leurs concernent. En effet, l'absence d'un
système centralisé qui s'occupe de la gestion des gardes a créé une complexité à accomplir
PFE-Sup'com 2006 Introduction générale
Confidentiel 2
cette tâche qui nécessite jusqu'à présent la collaboration de plusieurs acteurs tel que la
préfecture, les pharmaciens, etc. En plus, les moyens permettant de connaître 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'idée de
concevoir et réaliser un système qui résout cette problématique. Ce système sera composé
d'un serveur vocal interactif opérant à l'échelle nationale Française qui permet de connaître 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 présent rapport, comporte les trois chapitres suivants :
- Le premier chapitre, "Contexte général du projet", met le projet dans son contexte par
une présentation des services de télécommunications à valeur ajoutée, des technologies
utilisées pour construire le système, de l'organisme d'accueil, du travail demandé et de la
problématique à résoudre.
- Le deuxième chapitre "Conception du système pour le service à valeur ajoutée",
présente la méthodologie suivie pour réaliser le projet, la spécification des besoins et des
fonctionnalités du système, les choix pour lesquels nous avons opté pour concevoir notre
système ainsi que l'architecture logicielle et matérielle que nous avons mis en place.
- Le troisième chapitre "Réalisation du système pour le service à valeur ajoutée",
présente les choix techniques faits, les environnements matériel et logiciel dont on a disposé
pour la réalisation du système ainsi qu'une description du système obtenu.
PFE-Sup'com 2006 Contexte général du projet
Confidentiel 3
Chapitre 1 : Contexte général du projet
Ce chapitre représente une mise dans le contexte du projet de fin d'étude intitulé
conception et réalisation d'un service de télécommunications à forte valeur ajoutée à base d'un
système Web-Vocal pour la gestion des gardes des pharmacies.
La première partie présente les services de télécommunications à valeur ajoutée et les
technologies qui seront utiles pour élaborer notre système.
La deuxième partie se focalise sur le cadre du projet à travers une présentation de
l'organisme d'accueil, une définition du travail demandé et de la problématique qu'il doit
résoudre.
PFE-Sup'com 2006 Contexte général du projet
Confidentiel 4
I.Les services de télécommunications à valeur ajoutée
Cette sous-section comporte une définition des services de télécommunications à valeur
ajoutée à travers quelques exemples et une présentation des atouts technologiques qui nous
ont permis de développer notre système.
I.1.Présentation des services de télécommunications à valeur ajoutée
A la différence des services de télécommunications traditionnels appelés services de
télécommunications de base tel que la téléphonie, le télex, le fax, etc. dont le but est le juste
acheminement des informations fournies par les clients; les services de télécommunications à
valeur ajoutée visent à ajouter de la valeur aux informations en améliorant leur forme ou leur
contenu ou en prévoyant leur stockage et leur recherche. A titre d'exemple nous citons les
services de télécommunications à valeur ajoutée suivants :
I.1.1.L'audiotex
Appelé également audiotel est un service de communication, vocal, utilisant la voix
numérisée et permettant d'accéder, à partir d'un téléphone, à des sources de données vocales.
La base de données vocales est structurée sous forme d'arborescence dont les branches sont
sélectionnables par l'appelant à l'aide des touches de son clavier téléphonique. L'intérêt de ce
système est de pouvoir accéder 24 heures sur 24 et à travers le téléphone à des bases de
données distantes. Les renseignements ainsi accessibles peuvent porter sur les heures
d'ouverture, la météo, les offres spéciales...
I.1.2..La téléconférence
C'est l'échange de l'information, en direct, entre plusieurs personnes éloignées les unes
des autres mais liées par un système de télécommunications. Cet échange d'information peut
être sous forme audio ou vidéo ou une combinaison des deux.
PFE-Sup'com 2006 Contexte général du projet
Confidentiel 5
I.1.3..La sauvegarde en ligne des données
C'est la mise à l'abri des données critiques d'une entreprise, via Internet ou une autre
liaison. Elle représente une alternative aux solutions classiques, puisque le client ne s'occupe
plus de la sécurité de ses données mais il confie cette tâche à un spécialiste de la matière.
I.2.Les atouts pour la réalisation des services à valeur ajoutée
I.2.1.Le Web
I.2.1.1.Internet en bref
C'est un réseau décentralisé dans lequel, chaque noeud devait se voir affecté la même
importance et ne devait pas gêner le fonctionnement global du système en cas de défaillance.
Lors de la mise hors service d'un noeud, ce réseau 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 appelés TCP/IP
a été adopté, permettant à une multitude de services de fonctionner simultanément sur le
réseau (tels que les transferts de fichiers, les forums et messageries électronique...). Depuis,
l'Internet s'est développé à un rythme exponentiel grâce à l'augmentation du nombre de
systèmes informatisés sur le réseau et des services à valeur ajoutée qui l'adoptent pour
acheminer les informations.
I.2.1.2.Les applications Web de première génération
Avec 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 visualisée par les
navigateurs Web. Au début, ces pages Web étaient statiques. En effet, elles étaient figées en
un fichier ".htm/.html", d'aspect plutôt austère et dépourvu de la plupart des possibilités
d'interaction auxquelles l'utilisateur est désormais habitué avec les logiciels pour PC usuels.
De plus, la première génération de navigateurs Web ne reconnaît que le texte et les données
multimédia simple comme les images et le son.
PFE-Sup'com 2006 Contexte général du projet
Confidentiel 6
I.2.1.3.Les applications Web de deuxième génération
La deuxième génération d'applications Web a mis un terme à l'aspect des pages Web.
Ce sont les navigateurs Web de la nouvelle génération qui ont permis cette évolution. Ils
peuvent :
- Télécharger des composants logiciels qui peuvent être développés dans un langage de
haut niveau. Ces composants rendent le Web plus dynamique et plus flexible à utiliser et à
maintenir.
- Reconnaître 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 contrôler un
champ de saisie par exemple, et d'avoir un comportement événementiel. Un script peut
notamment être utilisé pour détecter un événement déclenché par un click sur un bouton et
invoquer une méthode pour effectuer le traitement nécessaire.
I.2.1.4.Un Web à trois niveaux
La forte demande de contenu dynamique a transformé le Web en une variante
d'architectures multi niveau, particulièrement souples et indépendantes du nombre
d'utilisateurs sur le réseau. Il en résulte des applications plus faciles à maintenir et à supporter,
tout en minimisant l'impact des modifications nécessaires à apporter à ces applications.
L'architecture Web à trois niveaux (Figure 1.1) présente le grand avantage de résoudre
plusieurs problèmes inhérents aux systèmes client-serveur traditionnels, il devient possible de
développer une application unique et universelle pouvant être déployée sur différents types de
plates formes. Tout le traitement côté client est administré de façon centralisée et déployé
dynamiquement, ce qui signifie que toute mise à jour est appliquée automatiquement lorsque
l'utilisateur démarre l'application. Ceci évite une installation manuelle sur chaque poste client.
Cette architecture est composée de :
PFE-Sup'com 2006 Contexte général du projet
Confidentiel 7
Figure 1.1 : Architecture Web à trois niveaux.
- L'application cliente est représentée par le navigateur. Elle est responsable de la logique
de présentation définie par le document HTML, lequel peut inclure des scripts ou autres
composants logiciels.
- Le serveur Web correspond au niveau intermédiaire. Il est utilisé pour distribuer les
données des clients et de gérer les traitements métiers.
- Le serveur de données s'occupe de la gestion de l'accès aux données.
I.2.2.Le VoiceXML
I.2.2.1.Présentation du VoiceXML
VoiceXML est un langage utilisé pour la création des services vocaux interactifs.
Normalisé par le W3C, il est conçu pour utiliser les principes et les technologies du Web
(réseau Internet, XML, serveur Web, serveur d’application, etc.). Son objectif initial est de
permettre aux personnes disposant d’un simple téléphone d’accéder sous forme vocale aux
contenus et services du Web ainsi qu’aux systèmes d’informations des entreprises.
Les principales fonctionnalités de ce langage sont :
- La diffusion de fichiers audio.
- La diffusion de la parole synthétisée (synthèse vocale).
- La détection de codes DTMF générés par les touches du clavier du téléphone.
PFE-Sup'com 2006 Contexte général du projet
Confidentiel 8
- La détection de mots ou expressions prononcés par l'utilisateur (reconnaissance vocale).
- L’enregistrement de la parole de l’utilisateur.
- Le contrôle de l’appel téléphonique (transfert de l’appel, déconnexion de l’appel).
I.2.2.2.Modèle architectural du VoiceXML
Le modèle architectural du VoiceXML (Figure 1.2) défini par le W3C est composé de :
Figure 1.2 : Modèle architectural du VoiceXML. [6]
• Un serveur de document (document server) qui peut être un serveur Web par
exemple, il a pour rôle de générer du code VocieXML.
• Un interpréteur de contexte VoiceXML (VoiceXML interpreter contetxt) appelé
aussi gateway qui représente la porte d'entrée au service des serveurs vocaux. Il
englobe le VoiceXML Interpreter (plus connu sous le nom VoiceXML browser) qui a
pour rôle l'interprétation du code VocieXML.
• Une plate-forme d'implémentation (implementation platform) qui regroupe les
autres composantes supportant le navigateur VoiceXML à interpréter le code
VoiceXML, tel que le serveur TTS.
PFE-Sup'com 2006 Contexte général du projet
Confidentiel 9
II.Cadre et contexte du projet
Cette sous-section met le projet dans son cadre et contexte à travers une présentation de
l'organisme d'accueil, une description du travail demandé et une exhibition de la
problématique à résoudre.
II.1.Organisme d'accueil
Ce projet de fin d'études s'est déroulé à PROXYM-IT. Cette société a été créée le 4
janvier 2006 et possède deux sièges, l'un à la technopôle de Sousse constituant le centre de
développement de ses produits, et l'autre à Lyon constituant une antenne commerciale. Elle
s'intéresse aux nouvelles technologies de l'information et de la communication et a pour
activités :
- Consulting : conseils sur la mise en place des systèmes d'informations.
- Développement : essentiellement deux axes : les sites e-commerce et les services de
télécommunications à valeur ajoutée, entre autres les serveurs vocaux interactifs.
- Formation : les technologies JAVA, XML et Linux.
II.2.Travail demandé
Ce projet de fin d'études constitue une solution demandée par la préfecture du
département de l'Isère 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
numéro qui sera connu à l'échelle nationale française, tel que le numéro de la police de
secours par exemple. Ceci va permettre au grand public de consulter la liste des pharmacies
qui sont de garde.
En deuxième lieu, il s'agit de réaliser une application Web qui offre toutes les
fonctionnalités nécessaires pour la gestion des gardes des pharmacies. Cette application doit
aussi permettre de configurer le serveur vocal, et lui fournir les données dont il a besoin d'une
façon dynamique.
PFE-Sup'com 2006 Contexte général du projet
Confidentiel 10
II.3.Problématique
En France, la garantie de l’accessibilité aux médicaments 24h/24h débute par un
compromis entre les pharmaciens qui s'organisent entre eux pour fixer leurs dates de gardes
pour toute une année. Après son établissement, le planning doit être envoyé à la préfecture
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 propriétaire opérant 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 opérant à l'échelle nationale
française 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 système permettant la
centralisation de la gestion des gardes des pharmacies et l'accès facile aux informations sur
ces gardes, ce qui permet de remarquer les défaillances suivantes :
- Cette tâche qui peut être facile à gérer se transforme en un travail fastidieux nécessitant
beaucoup de temps.
- L'accès à l'information sur les gardes n'est pas évident en cas d'urgence vu que les
sources citées précédemment sont inflexibles, surtout pour une personne étrangère ayant
des connaissances limitées sur l'endroit où elle se trouve.
- Certains acteurs se voient être impliqués dans un processus ne faisant pas partie de leur
logique métier. Par exemple, si une pharmacie se voit obligée de changer sa date de garde,
elle doit faire le parcours du combattant alors que logiquement ce n'est guère à la charge du
pharmacien de se préoccuper de la circulation de l'information sur les gardes. Notons aussi
qu'elle est obligée de coordonner avec les autres pharmacies pour établir le planning des
gardes alors qu'elle se serait débarrassée de cette tâche s'il y avait un système qui le
permettait.
- Le risque que l'information sur les gardes soit obsolète est grand, puisque les différentes
sources d'information peuvent ne pas communiquer entre elles, vu qu'il n' y a pas un
système centralisé qui s'en occupe. Ce risque est d'autant plus élevé si un cas d'urgence qui
PFE-Sup'com 2006 Contexte général du projet
Confidentiel 11
ne permet pas au pharmacien d'avoir les quatre jours pour notifier son changement de la
date de garde arrive.
Vu ces défaillances, il s'avère nécessaire de développer un système permettant
d'organiser cette composante du secteur de la santé. Ce système doit permettre de centraliser
la tâche de la gestion des gardes des pharmacies et de l'accès aux informations sur ces gardes
afin de remédier aux problèmes cités précédemment.
Conclusion
Dans ce chapitre nous avons présenté les technologies qui seront utilisées pour mettre
en place notre solution et nous avons situé le projet dans son cadre. Dans le chapitre suivant,
nous passons à l'étude du système qu'on va réaliser.
.
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 12
Chapitre 2 :Conception du
système pour le service à valeur ajoutée
Nous exposons dans ce chapitre notre conception du système à réaliser et qui a pour but
de rendre flexible la tâche de la gestion des gardes des pharmacies en France.
En premier lieu, nous présentons la démarche suivie pour entreprendre ce projet. En
deuxième lieu, nous délimitons les fonctionnalités du système à réaliser à travers une étude et
spécification des besoins. En troisième lieu, nous exposons l'architecture matérielle et
logicielle du système.
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 13
I.La mise en oeuvre du projet
Cette sous-section présente la démarche suivie pour réaliser le projet, ainsi que le
langage choisi pour modéliser le système à construire.
I.1.La démarche de la réalisation du projet
Le choix d'une démarche convenable pour entreprendre un projet est une étape cruciale
qui conditionne sa réussite. En effet, il n'existe pas de démarche 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 spécificités 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 définition des besoins, il est itératif et donc peut être parcouru de
multiples fois, en plus il offre la possibilité d'intégration de points de contrôle tout au long du
processus vu que l'évaluation peut intervenir dans toutes les étapes. Ce cycle propose les
phases suivantes pour réaliser un projet :
Figure 2.1 : Cycle de réalisation du projet.
Spécification des besoins
Conception du système
Evaluation
Réalisation du système
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 14
1. Spécification des besoins, consiste à l'identification des besoins à satisfaire et à la
définition des fonctionnalités du système.
2. Conception du système, consiste à définir l'architecture matérielle et logicielle du
système en se basant sur la phase de spécification des besoins.
3. Réalisation du système, consiste à concrétiser le système en réalisant et reliant ses
différentes composantes.
4. Evaluation, où le système est soumis à une utilisation réelle pour s'assurer de son
adaptation aux besoins exprimés précédemment.
I.2.Le langage UML pour la modélisation du système
Pour modéliser les fonctionnalités que doit offrir notre système et représenter son
architecture ainsi que les interactions entre ses différents composants, nous avons choisi le
langage UML. C'est un langage standard conçu pour l'écriture des plans d'élaboration des
logiciels. Il définit neuf diagrammes qui servent à visualiser un système sous différentes
perspectives :
• Le diagramme de classes : Il représente un ensemble de classes, d'interfaces et de
collaboration ainsi que leurs relations. Les diagrammes de classes représentent la vue
statique d'un système.
• Le diagramme d'objets : Il représente un ensemble d'objets qui sont des instances
des éléments qui apparaissent dans le diagramme de classe.
• Le diagramme de cas d'utilisation : Il représente un ensemble de cas d'utilisations et
d'acteurs et leurs relations. C'est en effet une vue statique de l'utilisation d'un système.
• Le diagramme de séquences et le diagramme de collaboration : Ils représentent un
ensemble d'objets et leurs relations, donnant ainsi une vue dynamique sur le système.
Les diagrammes de séquence 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 reçoivent des messages.
• Le diagramme d'états-transitions : Il est composé d'états, de transitions,
d'évènements et d'activités. C'est une vue dynamique d'un système.
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 15
• Le diagramme d'activités : C'est un type particulier de diagramme d'états-transitions
qui décrit la succession des activités au sein d'un système.
• Le diagramme de composants : Il représente l'organisation et les dépendances au
sein d'un système de composants. Il présente la vue d'implémentation statique d'un
système et est lié au diagramme de classes.
• Le diagramme de déploiement : Il est utilisé pour la modélisation des aspects
physiques d'un système. Il montre la configuration des noeuds de traitement en phase
d'exécution ainsi que les composants qui se trouvent sur ces noeuds.
Plusieurs raisons nous ont conduit à adopter UML dans notre modélisation. 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 compréhensible par
tout le monde.
- Malgré son évolutivité, il est stable et facilite la compréhension du système grâce à ses
représentations simples.
- Il permet d'utiliser les principes et les concepts objet pour enrichir la phase de la
conception des systèmes.
II.Spécification des besoins de la gestion des gardes des pharmacies
Cette sous-section décrit les besoins à satisfaire par le développement du système et
détaille ses fonctionnalités à travers une modélisation de ces besoins.
II.1.Description des besoins
La tâche de la gestion des gardes des pharmacies est fastidieuse, en plus l'accès aux
informations qui concernent ces gardes par le grand public n'est pas flexible vu qu'il n'existe
pas un système centralisé qui s'en occupe. Pour ce faire, on sera amené à réaliser un système
composé de :
- Une application Web offrant toutes les fonctionnalités nécessaires pour gérer les gardes,
afin de supporter l'exécution de cette tâche auparavant pénible, tirant profit de la
centralisation du traitement et de l'accès aux données offerte par le Web. Cette application,
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 16
destinée à des gens qui sont dans la majorité des cas non familiarisés avec l'informatique,
doit offrir une interface conviviale et interactive.
- Un serveur vocal interactif destiné au grand public. Ce dernier doit fournir d'une façon
fiable les informations nécessaires sur les gardes des pharmacies 24 heures/24 heures et 7
jours/7 jours.
II.2. Modélisation des besoins
II.2.1.Identification des acteurs
Un acteur est une catégorie d'utilisateur, il représente un rôle joué par une personne, un
logiciel, un matériel, un automate qui exploite les données du système et qui interagit avec
[3]. Dans notre cas les acteurs sont :
- Le professionnel : une personne qui a pour charge de gérer la liste des pharmacies ainsi
que la planification des gardes.
- L'administrateur : c'est le responsable de l'octroi des droits d'accès à l'application de la
gestion des gardes.
- L'utilisateur ordinaire : toute personne désirant avoir des informations sur les
pharmacies de garde.
II.2.2.Diagramme des cas d'utilisation
Un cas d'utilisation modélise un service rendu par le système. Il exprime les interactions
acteurs/système et apporte une valeur ajoutée à l'acteur concerné, un cas d'utilisation est donc
une abstraction d'une partie du comportement du système [3].
Notons que pour faciliter la compréhension des cas d'utilisation nous les avons
partitionné en paquetages (Figure 2.2) qui sont des éléments d'organisation des modèles. Ils
regroupent des éléments de modélisation, selon des critères purement logiques. Il faut noter
aussi que vu la ressemblance des scénarii des cas d'utilisation des différents paquetages, nous
détaillons le paquetage "Recherche" mais nous restreignons la description des autres à la
représentation de leurs diagrammes de cas d'utilisation.
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 17
Gestion des pharmacies
Gestion des districts
Gestion des gardesSécurité
Recherche
Professionnel
Administrateur
Administration
InfoGarde
Utilisateurordinaire
Figure 2.2 : Organisation en packages des cas d'utilisation.
a. Paquetage "Recherche"
Rechercher pharmacie par nom
Rechercher pharmacie par code postal
ou numéro de départementProfessionnel
Recherche
Figure 2.3 : Cas d'utilisation du package "Recherche".
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 18
Ce paquetage (Figure 2.3) regroupe les fonctionnalités permettant de rechercher des
informations sur les pharmacies. La description du scénario de recherche d'une pharmacie
peut être résumée par le diagramme de séquences (Figure 2.4) suivant :
ProfessionnelrechercheParNom ( )
formulaire
formulaireRempli ( )
résultat de la recherche
Système
rechercheParCodePostalOuNuméroDeDépartementou
Figure 2.4 : Scénario du cas d'utilisation "Rechercher pharmacie".
Le professionnel demande du système la fonctionnalité de recherche d'une pharmacie.
Ce dernier lui affiche un formulaire à remplir. Selon le critère de recherche choisi par
l'utilisateur et les informations qu'il a fournies, le système lui affiche une liste de pharmacies.
b. Paquetage "Sécurité"
Authentification
Administrateur
Professionnel
Sécurité
Figure 2.5 : Cas d'utilisation du package "Sécurité".
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 19
Ce paquetage (Figure 2.5) comporte la fonctionnalité d'authentification pour l'accès à
certaines parties du système.
c. Paquetage "Gestion des districts"
Professionnel
Ajouter district
Supprimer district
Gestion des districts
Figure 2.6 : Cas d'utilisation du package "Gestion des districts".
Ce paquetage (Figure 2.6) regroupe les fonctionnalités que le système doit offrir pour
gérer la liste des districts à savoir l'ajout et la suppression d'un district.
d. Paquetage "Administration"
Ajouter utilisateur
Supprimer utilisateur
Administrateur
Administration
Figure 2.7 : Cas d'utilisation du package "Administration".
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 20
Ce paquetage (Figure 2.7) regroupe les fonctionnalités qui permettent de contrôler
l'accès à certaines parties du système à savoir l'octroi à nouveau utilisateur les droits d'accès
ou la privation d'un ancien utilisateur de ces droits.
e. Paquetage "Gestion des gardes"
Ajouter garde
Supprimer garde
Professionnel
Consulter gardeà partir de la zone
militarisée
Gestion des gardes
Figure 2.8 : Cas d'utilisation du package "Gestion des gardes".
Ce paquetage (Figure 2.8) regroupe les fonctionnalités que le système doit offrir pour
planifier les gardes des pharmacies. Ces fonctionnalités 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 fonctionnalités que le système doit offrir pour
gérer les fiches des pharmacies à savoir la modification, l'ajout et la suppression d'une fiche
de pharmacie.
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 21
Ajouter pharmacie
Supprimer pharmacie
Modifier fiche pharmacie
Professionnel
Gestion des pharmacies
Figure 2.9 : Cas d'utilisation du package "Gestion des pharmacies".
g. Paquetage "InfoGarde"
Utilisateur ordinaire
Consulter garde
InfoGarde
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 système
Cette sous-section présente les choix que nous avons faits durant la phase de conception
et détaille la solution que nous avons conçue pour réaliser le système.
III.1.Architecture matérielle du système
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 22
Le diagramme de déploiement (Figure 2.11) représente l'organisation matérielle du
système. Il met en oeuvre les composants suivants :
Serveur Web
Téléphone fixe ou mobile
«RTSP»
«HTTP»
«GSM» ou <<RTC>>
«NFS»
PC administrateur
«HTTPS»
Serveur des applications vocales
Serveur des fichiers audio
Plate forme Eloquent
Système OSS«HTTP»
«HTTP»PC professionnel
«HTTP»
Figure 2.11 : Diagramme de déploiement.
- Serveur des applications vocales : se charge de la fourniture des flux VoiceXML au
navigateur VoiceXML.
- OSS : se charge du dépôt des applications VoiceXML statiques dans la plateforme
d'hébergement de ces applications. Notons qu'une application statique est une application
développée par manuellement, autrement dit celle qui ne soit pas fournie dynamiquement
par un serveur.
- Serveur de fichiers audio : se charge du dépôt des flux audio qui seront utilisés par
l'application vocale, et de leur fourniture en cas de besoin.
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 23
- Serveur Web : il a pour fonction l'interprétation des scripts et la fourniture des flux
VoiceXML au serveur vocal.
- Téléphone fixe ou mobile : pour l'accès à l'application vocale.
- Deux ordinateurs : pour exécuter les différentes tâches informatiques relatives au
système.
Ces composants communiquent entre eux par le biais des protocoles suivants :
- RTSP : c'est un protocole de communication destiné aux systèmes de streaming media
qui permettent de contrôler un serveur de média à distance, offrant des fonctionnalités
typiques d'un lecteur vidéo tel que "lecture" et "pause", et permettant un accès en fonction
de la position temporelle [17].
- NFS : c'est un protocole développé par Sun Microsystems qui permet à un ordinateur
d'accéder à des fichiers via un réseau [17].
- HTTP : c'est un protocole de communication informatique client-serveur développé pour
le WWW. Il est utilisé pour transférer 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 sécurisée avec les protocoles SSL ou TLS. Il permet
au visiteur de vérifier l'identité du site auquel il accède grâce à un certificat
d'authentification. Il permet également de chiffrer la communication et est généralement
utilisé pour les transactions financières en ligne : commerce électronique, banque en ligne,
courtage en ligne, etc. [17].
III.2.Conception de la base de données
III.2.1.La méthode Merise pour la conception de la base de données
Merise est une méthode de conception, de développement et de réalisation des projets
informatiques. Son but est la séparation des données et des traitements à effectuer en plusieurs
modèles conceptuels et physiques. Elle date de 1978-1979, et est créée suite à une
consultation lancée en 1977 par le ministère de l'industrie français dans le but de choisir des
sociétés de conseil en informatique afin de définir une méthode de conception de systèmes
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 24
d'information. Les deux principales sociétés ayant mis au point cette méthode sont le CTI,
chargé de gérer le projet, et le CETE [8].
Merise décompose un système d’information en niveaux évoluant de l’abstrait vers le
concret. Ses différents niveaux et modèles sont :
- Le niveau conceptuel : décrit la statique et la dynamique du système d’information en se
préoccupant uniquement du point de vue du gestionnaire.
- Le niveau organisationnel : décrit la nature des ressources qui sont utilisées pour
supporter la description statique et dynamique du système d’information. Ces ressources
peuvent être humaines et/ou matérielles et logicielles.
- Le niveau opérationnel : dans lequel on choisit les techniques d’implantation du
système d’information (données et traitements).
- Le modèle de communication : il formalise les échanges d’informations en systèmes
d’information.
- Le modèle de traitement : il formalise les traitements effectués par un système
fonctionnel.
- Le modèle de Données : il est la référence de l’activité de l’entreprise, la manière dont
elle perçoit et mémorise son activité. Il formalise toutes les informations mémorisées.
Tableau 2.1: Les différents niveaux et modèles de Merise.
Niveau Données Traitement Objectif
Conceptuel Modèle
Conceptuel de Donnée (MCD)
Modèle Conceptuel de
Traitement (MCT)
Quoi ?
Organisationnel (Logique)
Modèle Logique de Donnée
(MLD, OU?)
Modèle Organisationnel de Traitement (MOT, QUI, QUAND?)
Qui, Ou, Quand ?
Opérationnel (Physique)
Modèle Physique de
Donnée (MPD)
Modèle Opérationnel de
Traitement (MOPT)
Comment ?
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 25
A part le fait qu'elle soit la méthode la plus utilisée pour concevoir les bases de
données relationnelles, notre choix s'est porté sur elle vu qu'elle offre des modèles qui
séparent les données et les traitements. Ces modèles permettent de structurer d'une façon
claire les entités et les informations entre ces entités, afin que l'ensemble soit le plus efficace
et évolutif possible.
Cependant, comme toute méthode, 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 développement des deux modèles MCD et MLD qui sont suffisants pour décrire notre base
de données.
III.2.2.Modèle conceptuel de données
Le modèle conceptuel de données est une représentation statique du système
d’information de l’entreprise qui met en évidence sa sémantique. Il a pour but d'écrire de
façon formelle les données qui seront utilisées par le système d'information. Il s'agit donc
d'une représentation des données facilement compréhensible. Le formalisme adopté par la
méthode Merise pour réaliser cette description est basé sur les concepts 'entité-association'.
Dans ce contexte on définit :
- Propriété : c'est une information élémentaire, c’est-à-dire non déductible d’autres
informations, qui présente un intérêt pour le domaine étudié.
- Entité : c'est la représentation d'un élément matériel ou immatériel ayant un rôle dans le
système que l'on désire décrire. Chaque entité est composée de propriétés permettant de la
décrire.
- Association : c'est un lien sémantique entre plusieurs entités.
- Identifiant : c'est un ensemble de propriétés (une ou plusieurs) permettant de désigner
une et une seule entité.
- Cardinalités : c'est un couple de valeurs qui exprime le nombre minimal et maximal de
fois qu'un élément d'entité peut exister dans les éléments de l'association. Elles permettent
de caractériser le lien qui existe entre une entité et la relation à laquelle elle est reliée.
Le MCD (Figure 2.12) réalisé avec l'outil PowerDesigner est composé des entités
suivantes :
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 26
1,10,n
1,n
1,n
1,n
1,n
1,n
1,1
1,n
1,1
0,n
1,n
PHARMACIEidphardespharadrphartelpharurlphar
<pi> LIVA200TXTLITXT
<M><M><M><M>
idphar <pi>DISTRICT
iddisnomdis
<pi> IVA20
<M><M>
iddis <pi>
DEPARTEMENTiddepnomdep
<pi> VA2VA30
<M><M>
iddep <pi>
CPOSTALcpos <pi> SI <M>cpos <pi>
UTILISATEURidunomupnomuloginumopasurole
<pi> IVA50VA50VA20VA20ENUM('admin','pro')
<M><M><M><M><M><M>
idu <pi>
possede
gere
est_gere
se trouve
appartient
GARDEdate <pi> D <M>date <pi>
pharmacie_garde
Figure 2.12 : Le modèle conceptuel de données.
- GARDE : représente la date de garde d'une pharmacie.
- PHARMACIE : regroupe les informations relatives à une pharmacie.
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 27
- UTILISATEUR : regroupe les informations relatives aux personnes qui ont le droit
d'accéder à certaines parties protégées du système.
- CPOSTAL : représente le code postal d'une pharmacie.
- DISTRICT : représente le district d'une pharmacie.
- DEPARTEMENT : représente le département d'une pharmacie.
Le dictionnaire de données (Tableau 2.2) suivant, décrit les propriétés des entités.
Tableau 2.2: Dictionnaire des données.
Nom du champ Description Type
Date Date de la garde. Date
idphar Identifiant d'une pharmacie. Entier
desphar Description d'une pharmacie. Caractère
adrphar Adresse d'une pharmacie. Texte
telphar Téléphone d'une pharmacie. Entier
urlphar URL de l'annonce audio d'une pharmacie. Texte
Idu Identifiant d'un utilisateur. Entier
nomu Nom d'un utilisateur. Caractère
pnomu Prénom d'un utilisateur. Caractère
loginu Login d'un utilisateur. Caractère
mopasu Mot de passe d'un utilisateur. Caractère
role Type d'un utilisateur (administrateur,
professionnel). Enumération
cpos Code postal. Entier
iddis Identifiant d'un district. Entier
nomdis Nom d'un district. Caractère
iddep Identifiant d'un département. Caractère
nomdep Nom d'un département. Caractère
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 28
III.2.3.Modèle logique de données
FK_PHARMACI_POSSEDE_CPOSTAL
FK_DISTRICT_SE_TROUVE_DEPARTEM
FK_CPOSTAL_APPARTIEN_DISTRICT
FK_GERE_GERE_PHARMACI
FK_GERE_GERE2_UTILISAT
FK_EST_GERE_EST_GERE_UTILISAT
FK_EST_GERE_EST_GERE2_UTILISAT
FK_PHARMACI_PHARMACIE_PHARMACI
FK_PHARMACI_PHARMACIE_GARDE
PHARMACIEidpharcposdespharadrphartelpharurlphar
integersmallintvarchar(200)long varcharintegerlong varchar
<pk><fk> DISTRICT
iddisiddepnomdis
integervarchar(2)varchar(20)
<pk><fk>
DEPARTEMENTiddepnomdep
varchar(2)varchar(30)
<pk>
CPOSTALcposiddis
smallintinteger
<pk><fk>
UTILISATEURidunomupnomuloginumopasurole
integervarchar(50)varchar(50)varchar(20)varchar(20)ENUM('admin','pro')
<pk>
gereidpharidu
integerinteger
<pk,fk1><pk,fk2>
est_gereUTI_iduidu
integerinteger
<pk,fk1><pk,fk2>
GARDEdate date <pk>
pharmacie_gardeidphardate
integerdate
<pk,fk1><pk,fk2>
Figure 2.13 : Le modèle logique des données.
Le modèle logique de données (Figure 2.13) donne une vue de la structure de la base de
données et est obtenu à partir du MCD en respectant les règles suivantes :
- Toute entité devient une relation, autrement dit elle devient une table de la base de
données et l'identifiant de l'entité constitue la clé primaire de la table.
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 29
- Une association 'un à plusieurs' implique l’intégration 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 création d’une nouvelle table ayant
comme clé la concaténation des deux tables relatives aux classes associées.
Il faut noter qu'avec les règles de passage citées ci-dessus, il y a eu la génération 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 développement du SVI
Nous avons opté pour le VoiceXML qui est une technologie standard recommandée par
le W3C pour développer notre SVI. En effet, cette technologie présente les avantages
suivants :
Figure 2.14 : Architecture d'une application intégrant VoiceXML.
• Le développement des applications VoiceXML est basé sur une réutilisation des
composants logiciels des architectures Web (serveurs HTTP, serveurs d'applications
etc.). La fiabilité de ces composants n'est plus à démontrer, ils ont bénéficié de
plusieurs années d'utilisation intensive dans le monde des applications Web classiques.
• Le VoiceXML est un langage simple qui permet facilement de développer un service
de télécommunications. Cela réduit considérablement le temps et les coûts de la mise
en œuvre de notre serveur vocal interactif.
Données
Navigateur Web
Serveur Web
Passerelle VoiceXML
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 30
• Le VoiceXML garantit un accès centralisé aux données du fait qu'il s'interface avec
des applications Web, ce qui élimine le risque que le SVI présente des informations
obsolètes.
III.3.2.Choix de la solution de l'intégration du SVI
Pour lier le SVI au serveur Web, nous avons eu à choisir une des trois solutions
suivantes :
1. Intégration du SVI par génération du XML
Figure 2.15 : Schéma synoptique de l'intégration du SVI par génération du XML.
Cette solution consiste à présenter les informations à générer 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 résident dans le fait
qu'elle permet un ajout facile de nouveaux canaux de communication, d’où la facilité de
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 31
l'intégration du SVI. En plus, elle assure une bonne montée en charge puisque les flux
échangés sont de petite taille.
Cependant sa mise en place est très difficile voire impossible si on ne dispose pas d'une
architecture qui sépare la couche présentation de la couche donnée.
2. Intégration par génération directe du VoiceXML
Figure 2.16 : Schéma synoptique de l'Intégration du SVI par génération directe du VoiceXML.
Cette solution consiste à modifier une application Web pour retourner du VoiceXML en
plus du HTML en réponse à certaines requêtes http (Figure 2.16). Cette solution se distingue
par une mise en place rapide et comme la solution citée précédemment, elle offre à priori une
bonne montée en charge puisque la taille des flux VoiceXML échangés est très faible.
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 32
Cependant, elle ne permet pas un ajout facile d'autres canaux de communication
puisqu'à chaque fois on sera amené à modifier l'application Web.
3. Intégration par transformation des pages HTML vers des pages VoiceXML
Figure 2.17 : Intégration 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 côté Web ne sont pas possibles puisqu'elle a les désavantages suivants :
- Elle monte mal en charge vu la taille des pages HTML qui peut être grande.
- Le délai de sa mise en place est plus important par rapport aux autres solutions puisqu'il
faut développer un module de traitement des pages HTML pour extraire les données
pertinentes ce qui n'est pas facile à réaliser.
- Le fonctionnement du serveur vocal sera impacté par une modification des pages HTML
retournées, puisqu' à chaque fois que les pages HTML sont modifiées il faudra effectuer
des changements côté serveur vocal.
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 33
En ce qui concerne notre application, nous avons choisi la première solution
"intégration du SVI par génération du XML". En effet, cette solution permet l'évolution du
système par intégration de nouveaux canaux de communication tel que le développement 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 Web
Dans le domaine de l'analyse et de la conception orientée objet, un motif de conception
est une manière de définir la structure d'une classe. Plus généralement, c'est un document qui
décrit une solution générale d'un problème qui revient souvent. Il est basé sur des expériences
passées et est donc un ensemble de techniques permettant d'augmenter la productivité en
adoptant certaines structures établies et réutilisables.
Le motif MVC est le plus utilisé aujourd'hui. Il vient du monde de Smalltalk, l'un des
premiers langages orientés objet. Son idée de base est qu'un programme peut être décomposé
en trois parties :
• Le Modèle : représente le comportement de l'application tels que les traitements des données,
les interactions avec la base de données, etc. Il décrit les données manipulées par l'application
et définit les méthodes d'accès.
• La Vue : correspond à l'interface avec laquelle l'utilisateur interagit. Les résultats renvoyés
par le modèle sont dénués de toute présentation mais sont présentés par les vues. Plusieurs
vues peuvent afficher les informations d'un même modèle. Elles peuvent être conçues en
HTML, ou tout autre langage de présentation. La vue n'effectue aucun traitement, elle se
contente d'afficher les résultats des traitements effectués par le modèle, et de permettre à
l'utilisateur d'interagir avec elles.
• Le Contrôleur : prend en charge la gestion des événements de synchronisation pour mettre à
jour la vue ou le modèle. Il ne modifie aucune donnée, il analyse la requête du client et se
contente d'appeler le modèle adéquat et de renvoyer la vue correspondante à la demande.
L'idée forte de ce motif est la séparation totale des données, de leur traitement et de leur
représentation. Cela permet de modifier l'interface (ou d'en ajouter d'autres) facilement sans
avoir à toucher aux classes qui manipulent les données. Nous pouvons schématiser une telle
architecture de la façon suivante (Figure 2.18) :
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 34
Figure 2.18 : Architecture MVC [12].
1. Le client fait une demande au contrôleur. Ce contrôleur passe toutes les demandes des
clients; c'est la porte d'entrée de l'application. C'est le C de MVC.
2. Le contrôleur traite cette demande. Pour ce faire, il peut avoir besoin de la couche
métier. Cette dernière, à son tour, peut faire appel à la couche d'accès aux données.
3. Le contrôleur reçoit une réponse de la couche métier.
4. Le contrôleur choisit la vue à envoyer au client.
5. La vue est envoyée au client. C'est le V de MVC [12].
Notre choix pour le modèle de conception MVC est justifié par l'architecture claire qu'il
impose. Cela simplifierait les tâches de maintenance et d'amélioration du système. En plus, la
solution pour laquelle on a opté pour lier le SVI au serveur Web exige la séparation des
couches données; cette séparation est assurée par le motif SVI.
III.4.2.Diagramme des composants
L'architecture logicielle de l'application Web représentée par le diagramme des
composants (Figure 2.19) met en oeuvre les huit sous systèmes suivants :
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 35
Gestion des districts
Gestion des gardes InfoGarde
Administration
Gestion des pharmacies
RechercheSécurité
Commun
Figure 2.19 : Le diagramme des composants.
- Sécurité : regroupe les modules de la gestion de l'accès au site, entre autres
l'identification des utilisateurs et le chargement de leurs interfaces appropriées.
- Gestion des districts : regroupe les modules relatifs à la gestion des districts. -
InfoGarde : regroupe les modules de la consultation des gardes par un
utilisateur ordinaire y compris les classes de la génération 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 systèmes (par
exemple le FrontController), ainsi que les classes qui représentent la base de données.
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 36
III.4.3.Présentation du sous-système "InfoGarde"
Pour ne pas surcharger ce rapport et vu la ressemblance des architectures des sous-
systèmes présentés précédemment, nous avons choisi de présenter le sous-système
"InfoGarde".
Pour préciser l'appartenance de chaque module aux différentes couches du MVC nous
allons utiliser les symboles suivants :
Modèle Vue Contrôleur
III.4.3.1.La chaîne de génération d'un flux de données
générateur XML adaptateur XML informations flux XML flux VoiceXML ou HTML
VXSLT.xslt HXSLT.xslt
Figure 2.20 : Chaîne de génération d'un flux de données.
Les informations sur les gardes des pharmacies passent par un générateur de flux XML
(XMLGenerator). Ce dernier va créer un flux XML puis le passe à l'adaptateur XML
(XMLAdaptator).
Selon le canal de communication, l'adaptateur XML génère le flux adéquat à l'aide des
descriptions des feuilles de style XSLT (voir annexe B) après avoir vérifié la syntaxe du flux
XML. Dans notre cas, nous avons prévu deux canaux de communications : le canal Web et le
canal vocal. VXSLT décrit la transformation du flux XML en flux VoiceXML. Quant à
HXSLT, il décrit la transformation du flux XML en flux HTML.
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 37
III.4.3.2.Diagramme des classes du sous-système "InfoGarde"
Le diagramme des classes (Figure 2.21) du sous-système "InfoGarde" est composé des
classes suivantes :
controlInfoGarderesultat
frontController
erreursInfoGarde resultatInfoGarde
pharmacie_garde
1 1
1
infoGarde1 1
0..1 0..1
1
1
xmlGeneratorxmlAdaptator
infoGardeDAO
1
1 1 1 1
1 1
1ActionInfoGarde
1 1
1
Figure 2.21 : Diagramme des classes du sous système"InfoGarde".
- infoGarde : elle représente 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'exécution ou de
saisie.
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 38
- resultatInfoGarde : c'est l'interface qui présente les résultats de l'exécution d'une requête
du client.
- frontController : c'est le module qui analyse les requêtes de l'utilisateur, sélectionne la
vue et le contrôleur local à un sous système donné. Notons que ce module appartient au
sous système "Commun".
- resultat : une classe qui contient l'état de l'exécution d'une requête client. Suivant cet
état, le frontController sélectionne la vue appropriée. Cette classe fait partie du sous
système "Commun".
- controlInfoGarde : c'est un contrôleur relatif au sous système "InfoGarde".
- xmlAdaptator : regroupe les fonctions de vérification du flux XML généré et de son
adaptation selon le canal client.
- xmlGenerator : s'occupe de la génération du flux XML à partir des informations
fournies par les classes du modèle.
- actionInfoGarde : elle appartient à la couche métier et traduit l'action de la consultation
des gardes.
- infoGardeDAO : c'est la classe de manipulation des données. Elle implémente les
requêtes SQL pour la consultation des gardes.
- pharmacie_garde : elle représente la table pharmacie_garde.
PFE-Sup'com 2006 Conception du système pour le service à valeur ajoutée
Confidentiel 39
III.4.3.3.Représentation du scénario de la génération d'un flux VoiceXML
InfoGarde frontController controlInfoGarde XMLAdaptator XMLGenerator actionInfoGarde infoGardeDAOresultatInfoGarde
choisirCodePostal ()client = SVI
choisirControleur()
demande du flux VoiceXML()
demande du flux XML()
informations()demande
des donnees
informations
flux xmlflux VoiceXML
construireResultat()
choisirVue()
donnees
notifierConstructionResultat()
resultat
Figure 2.22 : Scénario de génération d'un flux VoiceXML.
Le diagramme des séquences (Figure 2.22) décrit dans le temps le scénario nominal de
la génération 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 contrôleur 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 après l'extraction des données stockées dans la base de
donnée, par l'infoGardeDAO.
Conclusion
Ce chapitre a été dédié à l'étude du système à construire. Cette étude a commencé par
une spécification des besoins à réaliser pour déterminer les fonctionnalités que le système doit
offrir. Ensuite, on a mis au point un modèle pour ce système. Dans le chapitre suivant, nous
décrirons le système que nous avons réalisé.
PFE-Sup'com 2006 Réalisation du système pour le service à valeur ajoutée
Confidentiel 40
Chapitre 3 : Réalisation du système pour le service à
valeur ajoutée
Après avoir défini l'architecture de notre système, précisé ses composants logiciels et
matériels, il ne reste plus qu'à le construire.
Dans ce chapitre, nous commençons par une présentation des différents choix
technologiques faits pour développer le système. Ensuite, nous exposons l'environnement
matériel et logiciel utilisé pour réaliser le système. Enfin, nous décrivons le système obtenu.
PFE-Sup'com 2006 Réalisation du système pour le service à valeur ajoutée
Confidentiel 41
I.Les choix techniques pour la réalisation du système
I.1.Choix du langage de programmation
a. PHP
PHP est un langage qui permet de développer des applications Web dynamiques
puissantes. Ses avantages résident dans son indépendance de la plate forme. En effet, il existe
pour les différentes 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 résultats de calcul ou de requêtes SQL
adressées à un système de gestion de bases de données.
b. ASP
ASP a été créé en 1996 par Microsoft. Cette technologie concurrençait le PHP. L'ASP
fait maintenant place à la plate-forme de développement .NET sous le nom ASP .NET. Avec
ce langage de programmation, les données utilisées au sein des sites Web peuvent être
partagées avec d'autres sites à travers des services Web puisqu'il gère 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 qu’il est
multi plateforme et libre.
- Le prix : ASP.net demande de nouveaux frais dès qu’il faut intégrer de nouveaux add-on,
par contre PHP est totalement gratuit.
- L’efficacité : ASP.net bénéficie d’un framework très puissant lui permettant aisément de
manipuler l’héritage, le polymorphisme, et l’encapsulation. Mais finalement, le code
généré souffre de temps d’exécution pénalisants et d’une utilisation mémoire trop
importante. PHP est plus rapide à s’exécuter et bénéficie de beaucoup de solutions comme
"Zend Performance Suite" permettant de précompiler les pages d’optimiser les temps.
PFE-Sup'com 2006 Réalisation du système pour le service à valeur ajoutée
Confidentiel 42
- Interaction : l’intégration aux bases de données se fait à l’aide 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 modèle collaboratif du PHP permet de détecter et corriger plus
rapidement les bogues. Le niveau de qualité obtenu est donc amélioré. Tandis qu’un 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 l’ASP.net, le code source n’est pas
disponible alors que la philosophie de PHP incite au partage des sources. Ceci permet de
récupérer beaucoup de code utile et ainsi de développer plus vite.
Au final, le PHP se démarque clairement de l’ASP, raison pour laquelle on a opté pour
ce langage pour développer notre application Web.
I.2.Choix de l'API de traitement du XML
L'analyseur, généralement 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 basées sur un traitement hiérarchique qui construisent une structure
hiérarchique contenant des objets représentant les éléments du document, et dont les
méthodes permettent d'accéder aux propriétés. La principale API utilisant cette approche
est DOM (Document Object Model).
- Les API basées sur un mode événementiel permettant de réagir à des événements
(comme le début d'un élément, la fin d'un élément) et de renvoyer le résultat à l'application
utilisant cette API. SAX (Simple API for XML) est la principale interface utilisant l'aspect
événementiel.
Ainsi, on a tendance à associer l'approche hiérarchique avec DOM et l'approche
événementielle avec SAX. Les propriétés de chaque API sont présentées par le tableau
suivant :
PFE-Sup'com 2006 Réalisation du système pour le service à valeur ajoutée
Confidentiel 43
Tableau 3.1: Comparaison SAX/DOM.
Selon la comparaison ci-dessus. L'interface SAX est la plus adaptée à nos besoins. En
effet, nous aurons besoin seulement du parseur pour vérifier 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 mémoire afin de les réutiliser. Par suite les fonctionnalités qu'il offre,
rudimentaires qu'elles soient, sont suffisantes. En plus, elle est plus rapide, ce qui construit un
apport pour notre système qui a besoin de cette rapidité.
I.3.Choix du SGBD
En ce qui concerne la base de données, nous avons choisi le SGBD MySQL. En effet ce
choix est justifié par le fait que :
- C'est un serveur de base de données SQL. SQL est le langage des bases de données le
plus populaire dans le monde.
- Il est libre, gratuit et très utilisé aussi bien dans les projets libres que dans le milieu
industriel vu son bon rapport qualité/prix.
DOM SAX - Un processus qui utilise le DOM ne peut traiter l'arbre qu'après la lecture entière du document. - Accès aléatoire. - Utilise beaucoup de mémoire. - Construction de l'arbre du document. - Les objets sont réutilisables. - Richesse des fonctionnalités. - Moins rapide car il construit l'arbre du document.
- Un analyseur SAX délivre les données à un processus au fur et à mesure de la lecture du document. - Accès séquentiel. - Utilise peu de mémoire. - Evénementiel. - Les objets ne sont pas stockés d'ou ils ne sont pas réutilisables. - Fonctionnalités rudimentaires. - Plus rapide car il examine les données au fur et à mesure qu'elles arrivent.
PFE-Sup'com 2006 Réalisation du système pour le service à valeur ajoutée
Confidentiel 44
- Il fonctionne sur beaucoup de plates formes par exemple Windows, Unix, Linux.
II.Environnement de travail
Cette sous-section décrit l'environnement matériel et logiciel avec lequel nous avons
réaliseé ce projet de fin d'études.
II.1.Environnement matériel
L'application a été développée à l'aide d'un micro-ordinateur ayant les caractéristiques
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 : système d'exploitation.
- EasyPHP : c'est une plateforme de développement 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 téléphonie IP.
- Macromedia DreamWeaver : logiciel de conception des applications Web.
- Pacestar UML diagrammer : logiciel de conception UML.
- Sybase PowerDesigner : logiciel de conception des bases de données.
-Plateforme Eloquent : plateforme française d'hébergement des serveurs
vocauxVoiceXML.
PFE-Sup'com 2006 Réalisation du système pour le service à valeur ajoutée
Confidentiel 45
III. Présentation du système réalisé
L'IHM représente un élément clé dans l'utilisation de tout système informatique et
conditionne pour une large part son succès. En théorie, une interface doit être naturelle,
efficace, intelligente, fiable, de compréhension et d'utilisation facile. Autrement dit la plus
proche possible des différents 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 système dispose d'une interface à la fois efficace et
conviviale.
L'interface illustrée par la figure 3.1 représente la page d'authentification pour l'accès
aux fonctionnalités protégées du système selon la nature de l'utilisateur (administrateur ou
professionnel).
Figure 3.1 : Page d' athentificaton.
La figure 3.2 représente le menu principal des différentes fonctionnalités pour gérer les
gardes des pharmacies. Ce menu comporte les liens suivants :
- "Ajouter phamacie" permet la saisie d'une fiche de pharmacie.
PFE-Sup'com 2006 Réalisation du système pour le service à valeur ajoutée
Confidentiel 46
- "Consulter garde" permet l'administration des gardes.
- "Rechercher pharmacie" permet de rechercher une pharmacie.
- "Gérer district" permet la gestion de la liste des districts.
- "Se déconnecter" permet de retourner vers la page d'authentification.
Figure 3.2 : Menu principal de la gestion des gardes.
Pour illustrer de façon claire les fonctionnalités offertes par le système, on va les
présenter sous forme de scénarii.
1. Ajout/Suppression d'un district
Figure 3.3 : Ajout de district.
PFE-Sup'com 2006 Réalisation du système pour le service à valeur ajoutée
Confidentiel 47
Ce scénario est réalisé lorsque le professionnel désire insérer un nouveau district. Ce
dernier saisit les informations nécessaires et valide. Le système lui affiche alors un message
pour l'informer de l'état de sa requête.
Dans le cas de la Figure 3.3, le professionnel a voulu insérer un district qui existe déjà.
Comme réponse le système lui a affiché le message "District existant".
2. Ajout de pharmacie
Figure 3.4 : Ajout de pharmacie.
PFE-Sup'com 2006 Réalisation du système pour le service à valeur ajoutée
Confidentiel 48
Ce scénario (Figure3.4) représente l'opération de l'insertion d'une nouvelle pharmacie.
Après avoir saisi les informations nécessaires, le professionnel clique sur le bouton "Ajouter".
Le système l'avise du bon déroulement de l'opération et affiche la page de l'insertion de
l'annonce vocale relative à la pharmacie. Cette annonce vocale va être déposée sur le serveur
des fichiers audio de la plateforme d'hébergement 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 résume l'opération de la consultation des gardes à partir du SVI. En effet,
cette interface Web a été développée pour montrer la possibilité de la diffusion multi-canale
de l'information, puisque les informations affichées ci-dessus sont les mêmes transmises au
serveur vocal interactif.
Dans ce cas, l'utilisateur a tapé le code postal 38100. Selon la date, le système affiche la
liste des pharmacies de garde pour ce code postal.
PFE-Sup'com 2006 Réalisation du système pour le service à valeur ajoutée
Confidentiel 49
4. Recherche d'une pharmacie
Figure 3.6 : Recherche d'une pharmacie.
PFE-Sup'com 2006 Réalisation du système pour le service à valeur ajoutée
Confidentiel 50
Ce scénario (Figure 3.6) décrit l'opération de recherche d'une pharmacie en se basant sur
le numéro de département.
Un click sur le bouton "Rechercher" affiche des liens vers les fiches des pharmacies qui
appartiennent au département n° 38. Le professionnel peut alors consulter les informations
déjà saisies et les modifier, écouter l'annonce vocale d'une pharmacie et la modifier.
5. Gestion des gardes
Ce scénario représenté par la Figure 3.7, illustre l'opération de la gestion des gardes. Le
professionnel choisit le département, le district et la date pour lesquels il veut connaître les
pharmacies qui sont de garde. Le système 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
flèches présentes 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 façons sont proposées. La première par un
click sur le bouton (+), ce qui permet de planifier une garde en fournissant seulement le nom
de la pharmacie. La deuxième par un click sur le lien "Ajouter garde" si le professionnel
désire planifier les gardes pour un autre district. Quant à la suppression des gardes, le lien (-)
présent devant chaque nom de pharmacie permet de le faire.
PFE-Sup'com 2006 Réalisation du système pour le service à valeur ajoutée
Confidentiel 51
Figure 3.7 : Gestion des gardes.
PFE-Sup'com 2006 Réalisation du système pour le service à valeur ajoutée
Confidentiel 52
6. Gestion des professionnels
Figure 3.8 : Gestion des professionnels.
La Figure 3.8 représente les fonctionnalités d'ajout et de suppression des professionnels.
Cette interface est accessible seulement par l'administrateur.
Conclusion
Ce chapitre, le dernier de ce rapport, a présenté les choix qui ont été faits pour élaborer
notre système, les outils utilisés, ainsi que le résultat de notre travail.
PFE-Sup'com 2006 Conclusion générale
Confidentiel 53
Conclusion générale Les révolutions technologiques dans l'informatique et les télécommunications ont rendu
possible le développement de nouveaux services qui fournissent une grande valeur ajoutée par
rapport à certains services traditionnels.
Dans ce cadre, le présent projet de fin d'études avait pour but la mise en place d'un
service de télécommunications à forte valeur ajoutée à base d'un système Web-Vocal pour la
résolution de la problématique de la gestion des gardes des pharmacies en France et l'accès du
grand public aux informations qui les concernent par le grand public. En effet, l'absence d'un
système centralisé a fait sentir ses effets, créant par exemple des inflexibilités pour la
consultation de la liste des pharmacies de garde.
Nous avons donc développé un système composé d'une application Web dédiée à la
gestion des gardes des pharmacies et d'une application vocale basée sur la technologie
VoiceXML pour permettre un accès faciles aux informations sur les gardes. Nous avons aussi
assuré la liaison entre ces deux applications à travers le développement d'un module qui
génère du XML et l'adapte selon le canal de communication. De cette façon, il a été possible
au serveur vocal de récupérer les données dynamiquement du serveur Web qui assure leur
mise à jour. Ceci a permis la centralisation de la gestion des gardes des pharmacies et de
l'accès aux informations qui les concernent. Ainsi, nous avons éliminé le risque de fournir des
informations obsolètes et rendu plus flexible cette tâche.
En ce qui concerne la démarche, nous avons en premier lieu effectué une phase
bibliographique afin de découvrir les techniques existantes pour le développement des
systèmes tel que le nôtre. En deuxième lieu nous avons spécifié notre système pour en
discerner les fonctionnalités. En troisième lieu, nous avons procédé à sa conception ainsi
qu'aux choix technologiques pour sa réalisation. Enfin, nous l'avons mis en œuvre par le
développement et la liaison des deux sous systèmes Web et vocal.
PFE-Sup'com 2006 Conclusion générale
Confidentiel 54
Ce projet peut encore évoluer en intégrant au système d'autres canaux de
communication comme le "Pocket PC". Il peut aussi intégrer une couche Web service, de
cette façon les échanges des informations entre ce système et ses clients seront standardisés.
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 bénéfices, tant au niveau technique qu'aux niveaux professionnel
et relationnel. En effet, un aspect important dans mon expérience était l'esprit d'équipe, ceci
m'a appris qu'un problème ne peut être résolu sans la synergie des compétences.
En plus, j'ai eu l'occasion de faire appel à mes connaissances d'élève ingénieur qui a fait
le choix de l'option services et communication pour les réseaux multimédia, une option qui
m'a permis de découvrir le monde de développement des services de télécommunications et
dont le but se concordait parfaitement avec le but de ce projet de fin d'études.
J'ai eu aussi l'occasion de côtoyer une technologie qui est en train de révolutionner le
domaine des services des télécommunications à valeur ajoutée, d'enrichir ma base de
connaissance sur les technologies du Web et d'approfondir mes compétences en tant
qu'ingénieur en télécommunications.
PFE-Sup'com 2006 Annexe : La famille XML
Confidentiel 55
Annexe : La famille XML
PFE-Sup'com 2006 Annexe : La famille XML
Confidentiel 56
1. XML
XML (eXtensible Markup Language) est un langage de balisage des documents.
Une recommandation du W3C du 10 février 1998 le définit dans sa version 1.0.
Un document XML est un arbre et par conséquent, il est toujours composé d'un seul
élément, l'élément racine qui est généralement une collection de sous éléments. Ses
principales caractéristiques sont :
- Un ensemble extensible de balises.
- Une séparation entre la représentation et les données.
- Une bonne adaptation à la diffusion Internet.
2. DTD et XSD
On dit qu’un document XML est bien formé, s’il ne comporte pas de caractères
invalides, si les balises sont bien imbriquées, si les balises ouvertes sont fermées, si la casse
est respectée et s’il n’y a qu’un seul élément racine.
On dit qu’un document XML est valide, s’il est bien formé et qu’il correspond à un
formalisme prédéfinis. Ce dernier peut être un document DTD ou XSD, et peut soit être inclus
dans le document soit être référencé dans ce dernier.
DTD (Document Type Definition) et XSD (XML Schema Description) sont donc des
documents XML qui décrivent de quelle manière en XML un objet ou une relation doit être
formé. Cela permet de décrire un schéma relationnel.
3. Les feuilles de style : XSLT, XPATH, XSL-FO
XSL
Le 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 données XML et produit
PFE-Sup'com 2006 Annexe : La famille XML
Confidentiel 57
la présentation ou l'affichage de ce contenu XML selon les souhaits du créateur de la page. Le
XSL comporte en fait trois langages :
- Le XSLT qui est un langage qui Transforme un document XML en un format,
généralement en Html, reconnu par un navigateur.
- Le Xpath qui permet de définir et d'adresser des parties de document XML.
- Le XML Formatter pour "formater" du XML de façon à ce qu'il puisse être rendu sur des
"Pocket PC" ou des unités de reconnaissance vocale.
XSLT
C’est le eXtensible Stylesheet Langage Transformations. Il permet la transformation
d‘un fichier XML en un autre document XML ou en d’autres formats comme HTML,
XHTML, WML et même des formats inattendus tel que du code source Java. XSLT est plus
complexe et plus sophistiqué que HTML mais l’est moins que Java.
XSL-FO
Les feuilles de style XSL-FO permettent de créer des documents à partir de fichiers
XML. Cette norme est le plus souvent utilisée pour générer des fichiers PDF. Il est ainsi
possible, dans une feuille de style XSL-FO, de définir la mise en page que devra avoir le
document final (en-tête, pied de page, etc.).
Cette norme est complémentaire à 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 téléchargé et imprimé par l'utilisateur final.
Il est ainsi tout à fait possible de proposer sur un site Web le même contenu sous diverses
formes sans jamais avoir à toucher au document XML initial.
PFE-Sup'com 2006 Bibliographie
Confidentiel 58
Bibliographie
Ouvrages et Rapports : [1] V.MAILLARD, "Rapport d'activité", Institue de Télécommunications TCOM, août 2002.
[2] J. DUCLOY, "Tutorial XML", INIST, Octobre 2002.
[3] P. ROQUES & F. VALEE, "UML en action", Editions Eyrolles, 2000.
[4] J.JACOBSON et G. BOOCH, "Le guide de l'utilisateur UML", Editions Eyrolles,2000..
[5] F.BOIS, P.BALABKO, "Specifying Design Patterns in OOAD", Laboratoire de
Modélisation Systématique, 2002.
[6] V.Maillard, "Tutorial VoiceXML", TCOM, 2001.
[7] P. PRADOS, "VoiceXML", INST,2000.
[8] F. JULLIARD, "Méthode d'analyse Merise", Université de Bretagne Sud, UFR SSI-IUP
Vannes, 2001.
[9] Y.BOURDA, "Base de données relationnelles et SGBD", Supelec,2000. [10] VoiceXML Forum, "Voice eXtensible Markup Language", March 2000.
[11] F.ALIOTTI, "Etude de 2 chaînes numériques XML - Projet de diffusion électronique de
production scientifique de l'INSA", INSA, Septembre 2003.
Sites Web :
[12] www.php.mvc.com
[13] www.paris.pref.gouv.fr/ arretesPrefectoraux/gardespharma2005.pdf
[14] www.developpez.com
[15] www.w3c.com
[16] www.supinfo-projects.com/fr/
[17] www.wikipedia.org
[18] www.zend.com/zend/tut/tutorial-DOM-XML.php
PFE-Sup'com 2006 Bibliographie
Confidentiel 59
[19] www.voxpilot.com
[20] www.onlamp.com/pub/a/php/2006/03/02/mvc_model.html?page=3
[21] https://studio.tellme.com/vxml2_ir/ircgi_api-p.html
[22] http://www.prnewswire.co.uk/cgi/news/release?id=118798
[23] http://www.neteco.com/dico_20030224223158_.html
[24] http://www.internationalcompetitionnetwork.org/capetown2006/
[25] http://shiva.istia.univangers.fr/~tahe/ressources/web3tier.pdf#search='MVCexemple'
[26] http://no.bibleinfo.com/old/H1/bil00756.htm
[27] www.indexel.net/1_6_3034_3/7/28/1/Sauvegardeeconomique.htm