Rapport de stage d’Immersion en Entreprise

Schéma générale de l’architecture .................................................................................. 20

2. Conception détaillée ................................................................................................................ 21

2.1.

Diagrammes de classes .................................................................................................... 21

2.2.

Diagramme d’états-transitions ........................................................................................ 24

2.3.

Diagramme de déploiement ............................................................................................ 25

3. Conception de l’interface graphique ........................................................................................ 26

4. Conclusion ................................................................................................................................ 26

Chapitre 4 ......................................................................................................................................... 27

1.

Environnement matériel .......................................................................................................... 27

2. Choix technologiques ............................................................................................................... 27

2.1.

Coldfusion......................................................................................................................... 28

2.2. Macromedia Dreamweaver ............................................................................................. 28

2.3.

SQL server ......................................................................................................................... 29

2.3.1.

Avantages de SQL Server .......................................................................................... 29

2.3.2.

Les procédures stockées .......................................................................................... 30

2.4.

JavaScript .......................................................................................................................... 30

2.5.

Ajax ................................................................................................................................... 31

2.6.

Java ................................................................................................................................... 31

3.

Travail réalisé ........................................................................................................................... 31

3.1.

Solutions proposées ......................................................................................................... 32

3.1.1. Méthode 1 ................................................................................................................ 33

3.1.2. Méthode 2 ................................................................................................................ 33

3.1.3. Méthode 3 ................................................................................................................ 33

3.1.4.

Comparaison des solutions et conclusion ................................................................ 34

3.2.

Extension de la solution ................................................................................................... 35

4. Aperçu de l’interface ................................................................................................................ 37

5. Conclusion ................................................................................................................................ 38

Chapitre 5 ......................................................................................................................................... 39

1. Choix du test ............................................................................................................................. 39

1.1.

Tests de performance ...................................................................................................... 39

1.2.

Tests de chargements ...................................................................................................... 40

1.3.

Tests de stresse ................................................................................................................ 40

2. WebServer Tool ........................................................................................................................ 40

3.

Tests et résultats ...................................................................................................................... 41

4. Conclusion ................................................................................................................................ 44

CONCLUSION GENERALE .................................................................................................................. 45

Annexe A .......................................................................................................................................... 47

Annexe B .......................................................................................................................................... 48

Table des figures

FIGURE 1. EXEMPLE DE MOTEURS DE RECHERCHE DE VOLS .............................................................................................. 3 FIGURE 2. EXEMPLE D'INVOCATION TYPIQUE D'UN SERVICE WEB ...................................................................................... 5 FIGURE 3. MOTEUR DE RECHERCHE D’EASYVOYAGE.COM ............................................................................................... 7 FIGURE 4. MOTEUR DE RECHERCHE D'EBOOKERS.FR ...................................................................................................... 8 FIGURE 5. MOTEUR DE RECHERCHE DE VOAYAGER-MOINS-CHER.FR .................................................................................. 9 FIGURE 6. DIAGRAMME DES CAS D'UTILISATION ......................................................................................................... 14 FIGURE 7. DIAGRAMME DE SEQUENCE: CAS D'UTILISATION LANCER UNE RECHERCHE ......................................................... 14 FIGURE 9. DIAGRAMME D'ACTIVITE .......................................................................................................................... 15 FIGURE 10. ARCHITECTURE 3 TIERS .......................................................................................................................... 18 FIGURE 11. ARCHITECTURE GENERALE DE L'APPLICATION ............................................................................................. 20 FIGURE 12. PACKAGE MODELE ............................................................................................................................... 22 FIGURE 13. PACKAGE VUE ..................................................................................................................................... 23 FIGURE 14. PACKAGE CONTROLEUR ......................................................................................................................... 24 FIGURE 15. DIAGRAMME D'ETATS-TRANSITIONS ......................................................................................................... 24 FIGURE 16. DIAGRAMME DE DEPLOIEMENT ............................................................................................................... 25 FIGURE 17. MODELE GRAPHIQUE DE LA PAGE ............................................................................................................ 26 FIGURE 18. MOTEUR DE RECHERCHE ........................................................................................................................ 37 FIGURE 19. RESULTAT DE LA RECHERCHE ................................................................................................................... 38 FIGURE 20. CONFIGURATION DE WEBSERVER STRESS .................................................................................................. 41 FIGURE 21. UTILISATION DES RESSOURCES DU SERVEUR: METHODE OPEN XML ................................................................. 42 FIGURE 22. UTILISATION DES RESSOURCES DU SERVEUR: METHODE XSL ........................................................................... 42

Table des tableaux

TABLEAU 1. TEMPS DE REPONSE : FICHIERS EN LOCAL .................................................................................................. 34 TABLEAU 2. TEMPS DE REPONSE: FICHIERS DISTANTS ................................................................................................... 34 TABLEAU 3. COMPARAISON DU TEMPS DE REPONSE ENTRE UNE RECHERCHE SEQUENTIELLE ET UNE PARALLELE ........................ 36 TABLEAU 4. RESULTATS PAR UTILISATEUR: METHODE OPEN XML .................................................................................... 43 TABLEAU 5. RESULTATS PAR UTILISATEUR: METHODE XSL ............................................................................................. 44

INTRODUCTION

Dans un monde actif et continuellement évolutif, la motivation d’avoir des moyens

performants et efficaces de communication et d’échange d’informations devient de plus en

plus fondamentale .Cette motivation donne naissance à une révolution favorisant le travail

à distance et l’accès aux besoins en temps réduit voire immédiat. C’est pourquoi on a

assisté ces derniers temps à un développement exponentiel du réseau Internet qui, depuis

son apparition, ne cesse de s’étendre pour devenir enfin un terrain pour diverses

applications et un outil du premier plan pour de nombreux services.

Aujourd’hui, l’utilisation du web s'oriente de plus en plus vers l'interaction entre les

utilisateurs, et la création de réseaux sociaux rudimentaires, pouvant servir du contenu

exploitant les effets de réseau. Ces aspects entraînent la naissance de nouvelles visions et

applications fondant une interaction de plus en plus riche entre l’homme et le web.

Résultat de cette irruption de l’Internet, nouveau secteur en plein essor, une belle

avancée qui a su s’intégrer dans l’économie mondiale et qui se forge rapidement sa place :

le E-Tourisme. Cette branche d’activité renferme toutes les solutions applicatives basées

sur les technologies E-business afin de gérer les achats en ligne des billets d’avions, des

séjours, etc.

L’E-Tourisme, fondée sur le net, constitue une avancée technologique de ces

dernières années où Internet est devenu un vecteur de croissance. En effet, avec 50%

d'internautes européens recherchant on-line des données pour réserver leurs voyages,

loisirs… Internet est devenu l'une des plus importantes sources d'information du monde du

voyage.

En raison de la croissance exponentielle de ce domaine, la société Net Technologie

s’est fixée dans le développement d’applications classées dans le secteur E-Tourisme.

Propriétaire du nom de domaine www.Hammamet.com, Net Technologie souhaite

1 | P a g e

INTRODUCTION

développer des moteurs de recherche sur Internet permettant un accès facile et rapide à

l’information afin de les intégrer dans ses prochains sites web. Elle cherche et teste

différentes solutions visant à minimiser le temps de réponse.

Dans ce cadre, nous sommes appelés à mettre au point d’une application web

permettant de lancer une recherche de vols disponibles chez plusieurs fournisseurs et

afficher les meilleurs tarifs.

Il s’agit en premier temps de concevoir, implémenter et tester différentes méthodes

de recherche séquentielle. Le but essentiel de cette tâche est de comprendre quelques

mécanismes des moteurs de recherche sur Internet. Une seconde tâche consiste à trouver

des moyens permettant la réduction du temps de réponse d’une requête de recherche.

Le présent rapport s’inscrit dans l’optique d’éclaircir les différents aspects de cette application depuis sa phase de spécification jusqu'à sa phase de test. Il comporte quatre

chapitres. Le premier est consacré à une étude de l’existant dans laquelle nous élaborons une analyse de quelques sites concernant notre domaine d’étude. Le deuxième chapitre comporte une analyse et spécification des besoins fonctionnels et non fonctionnels de l’application. Le troisième chapitre présente la conception de notre application avec une approche globale et détaillée. L’étape de la réalisation de notre application Web est décrite dans le quatrième chapitre. Enfin, le dernier chapitre, présente la phase de tests et intégration.

2 | P a g e

Chapitre 1 ETAT DE L’ART

A travers ce chapitre nous allons définir les notions de moteur de recherche de vols et

des Web Services. Ensuite nous allons présenter les différents moteurs de recherche de

vols disponibles sur le marché mondial en mettant les points sur les services proposés par

chacun d’entre eux.

1. Notion de moteurs de recherche de vols

Les moteurs de recherche de prix de vol sont crées suite à un besoin humain de

s’informer de la disponibilité de vols sans perdre son temps. Ils sont apparus dans les

années. Depuis ce temps, et avec la révolution des technologies du web ainsi que les

infrastructures, ces moteurs ont connu de nombreuses évolutions remarquables.

Actuellement, les moteurs de recherche de vols offrent des fonctionnalités très poussées,

telles que la comparaison des prix, la détection des promotions et les meilleurs tarifs, ainsi

qu’un nombre important d’options de choix.

Figure 1. Exemple de moteurs de recherche de vols

3 | P a g e

Chapitre 1 : ETAT DE L’ART

Aujourd’hui, on assiste à une utilisation massive de ce type de moteur de recherche

et on compte environ visiteurs par jour. Parmi les moteurs de recherche de vols les connus

en Europe on cite www.easyvoayage.com, www.govoyage.com, www.easyvol.fr...

2. Les services web

Un service web est un programme informatique permettant la communication et

l'échange de données entre applications et systèmes hétérogènes dans des environnements

distribués. Il s'agit donc d'un ensemble de fonctionnalités exposées sur Internet ou sur un

Intranet, par et pour des applications ou machines, sans intervention humaine, et en temps

réel.

Il existe plusieurs technologies derrière le terme services web:

(cid:1) Les Services Web de type REST exposent entièrement ces fonctionnalités

comme un ensemble de ressources (URI) identifiables et accessibles par la

syntaxe et la sémantique du protocole HTTP. Les Services Web de type REST

sont donc basés sur l'architecture du Web et ses standards de base: HTTP et URI.

(cid:1) Les Services Web WS-* exposent ces mêmes fonctionnalités sous la forme de

services exécutables à distance. Leurs spécifications reposent sur les standards

SOAP et WSDL pour transformer les problématiques d'intégration héritées du

monde Middleware en objectif d'interopérabilité. Les standards WS-* sont

souvent décriés comme l'étaient leurs ancêtres CORBA, RMI ou DCOM: des

technologies complexes héritées du vieux principe RPC, fortement couplées et

difficilement interopérables dans des environnements hétérogènes.

L'architecture des Web Services s'est imposée (tout comme le langage XML) grâce à

sa simplicité, à sa lisibilité et à ses fondations normalisées. Elle articule actuellement

autour des trois acronymes suivants :

(cid:1) SOAP (Simple Object Access Protocol) est un protocole d'échange inter-

application indépendant de toute plate-forme, basé sur le langage XML. Un appel

de service SOAP est un flux ASCII encadré dans des balises XML et transporté

dans le protocole HTTP.

4 | P a g e

Chapitre 1 : ETAT DE L’ART

(cid:1) WSDL (Web Services Description Language) donne la description au format

XML des Web Services en précisant les méthodes pouvant être invoquées, leur

signature et le point d'accès (URL, port, etc..). C'est, en quelque sorte,

l'équivalent du langage IDL pour la programmation distribuée CORBA.

(cid:1) UDDI (Universal Description, Discovery and Integration) normalise une

solution d'annuaire distribué de Web Services, permettant à la fois la publication

et l'exploration. UDDI se comporte lui-même comme un Web service dont les

méthodes sont appelées via le protocole SOAP.

Figure 2. Exemple d'invocation typique d'un service web

Les services web ont une collection d’avantages dont voici quelques uns :

(cid:1) Les services Web fournissent l'interopérabilité entre divers logiciels fonctionnant

sur diverses plateformes.

(cid:1) Les services Web utilisent des standards et protocoles ouverts.

5 | P a g e

Chapitre 1 : ETAT DE L’ART

(cid:1) Les protocoles et les formats de données sont au format texte dans la mesure du

possible, facilitant ainsi la compréhension du fonctionnement global des

échanges.

(cid:1) Basés sur le protocole HTTP, les services Web peuvent fonctionner au travers de

nombreux pare-feux sans nécessiter des changements sur les règles de filtrage.

Malgré tous ces avantages, les services web présentent ces inconvénients :

(cid:1) Les normes de services Web dans certains domaines sont actuellement récentes.

(cid:1) Les services Web souffrent de performances faibles comparées à d'autres

approches de l'informatique répartie telles que le RMI, CORBA, ou DCOM.

(cid:1) Par l'utilisation du protocole HTTP, les services Web peuvent contourner les

mesures de sécurité mises en place au travers des firewalls.

3. Etude de l’existant

Le secteur du tourisme est l’un des domaines influé par l’irruption de l’Internet.

Aujourd’hui, différentes applications sont mise en place afin de faciliter l’échange et le

traitement de l’information principalement pour un but commerciale.

Dans ce secteur le prix représente le facteur essentiel. On propose également des

tarifs négociés et des prestations dont on possède l'exclusivité. Face à la multitude des

choix, l’homme a besoin d’outils permettant de filtrer ces options, rôle que jouent

principalement les sites web de l’E-tourisme.

Dans le cadre d’une étude de recherche préalable des applications Web semblable à

la notre, nous avons remarqué l’existence d’une multitude de sites Web qui traitent ce

sujet, mais nous sommes limités à l’étude de trois sites :

3.1. Exemple d’étude un : Easy Voyage.fr

Dans ce premier exemple, nous nous intéressons à faire une étude du site

www.easyvoyage.com. Il présente un portail attirant qui en plus des services de

6 | P a g e

comparaison de prix classiques propose des informations touristiques et des cartes pour de

nombreuses destinations.

Chapitre 1 : ETAT DE L’ART

Figure 3. Moteur de recherche d’easyvoyage.com

Des fonctionnalités très puissantes, des options offrant un choix vaste aux visiteurs,

un design agréable, tous ces arguments font d’easyvoyage.com une des références dans ce

domaine.

7 | P a g e

Chapitre 1 : ETAT DE L’ART

3.2. Exemple d’étude deux : Ebookers.fr

Dans ce deuxième exemple, nous étudions le site www.ebookers.fr. Ebookers est un

outil de recherche de vols et de réservation en ligne en temps réel au départ de la France

pour plus de 500.000 tarifs de vols en provenance de 100 compagnies aériennes.

Figure 4. Moteur de recherche d'Ebookers.fr

Ebookers est un service très exhaustif qui en plus des prix négociés affiche tous les

tarifs listés dans les systèmes internationaux de réservations. La seule imperfection de ce

moteur est le temps de réponse qui demeure plus élevé que ses concurrents.

8 | P a g e

Chapitre 1 : ETAT DE L’ART

3.3. Exemple d’étude trois : Voyager-moins-cher.fr

Dans ce dernier exemple, nous étudions le site www.voyager-moins-cher.fr. C’est un

portail sur les voyages avec des moteurs de recherche pour trouver les meilleur prix pour

les voyages, les billets d’avion, les hôtels, la location d'appartement ou encore les voitures

de location. Ces offres proviennent de 100 agences de voyages et tour-opérateurs. Avec

des fiches techniques par pays, ce site rend de nombreux services.

Figure 5. Moteur de recherche de voayager-moins-cher.fr

L’avantage de ce moteur c’est qu’il offre un choix plus varié au niveau du prix.

Exhaustivité et indépendance dans la présentation des offres référencées sont les deux

objectifs que Voyager-Moins-Cher a fixés pour devenir un outil original et performant.

9 | P a g e

Chapitre 1 : ETAT DE L’ART

3.4. Conclusion de l’étude

D’après l’étude de ces sites, nous constatons qu’ils offrent pratiquement les mêmes

fonctionnalités. Les paramètres métiers dont dépend la recherche sont identiques. Ce qui

diffère vraiment entre ces sites c’est le temps de réponse d’une requête de recherche, chose

qui peut influer sur le rendement du site. Ainsi, le temps de réponse demeure un facteur

essentiel et une problématique dont on doit tenir compte.

4. Présentation des solutions proposées

Afin de répondre à la contrainte du temps de réponse, nous tenons en premier temps

à choisir le trafic séquentiel optimisant ce temps. Pour ce faire, nous adoptons le concept d’Ajax2, et nous testons trois méthodes3différentes. Le second objectif est de rendre la recherche en cycles parallèles4.

5. Conclusion

Dans ce chapitre nous avons défini les différents termes spécifiques à notre

application Web et réalisé une étude sur les services offerts par des sites existants dans le

domaine touristique. Nous avons également présenté notre solution proposée de manière

globale.

L’analyse et la spécification des besoins des différents utilisateurs de l’application

sont l’objet du chapitre suivant.

2 Voir chapitre Réalisation, section Choix technologiques. 3 Voir chapitre Réalisation, section Travail réalisé. 4 Voir chapitre Réalisation, section Extension de la solution.

10 | P a g e

Chapitre 2 ANALYSE ET SPECIFICATION

Dans ce chapitre, nous abordons la phase d’analyse et spécification des besoins.

Ainsi, nous présentons les besoins fonctionnels et non fonctionnels de notre application

Web tout en recourant au modèle UML comme un moyen simple et compréhensible afin

de structurer les besoins de l’application, définir ses limites et modéliser le point de vue de

ses utilisateurs.

1. Spécification non formelle des besoins

Dans le cadre de ce stage, nous sommes appelés en premier temps à réaliser un

moteur de recherche séquentielle de vols sur Internet. Vu que la recherche prend en charge

plus qu’un seul fournisseur, la seconde tâche consiste à rendre cette recherche en cycles

parallèles afin de minimiser le temps de réponse. L’application finale doit répondre à un

certains critères de choix et fournir un temps de réponse acceptable.

1.1. Besoins fonctionnels

Les besoins fonctionnels représentent les attentes de chaque acteur de la future

application. Toute solution conceptuelle doit satisfaire, préalablement, à des besoins

fonctionnels afin de délimiter le périmètre fonctionnel de l‘application et surveiller la

traçabilité des besoins lors de la phase de développement.

La présente application doit satisfaire les besoins fonctionnels suivants :

11 | P a g e

Chapitre 2 : ANALYSE ET SPECIFICATION

(cid:1) Recherche de vols : il s’agit de définir un moteur qui permet la recherche de vols

suivant des critères choisis par l’utilisateur. Les principaux critères de choix

sont :

o Ville et date d’aller.

o Ville et date de retour s’il s’agit d’un voyage aller/retour.

o Nombres d’adultes, d’enfants et de bébés.

o Aller simple ou Aller/Retour.

o Classe économique.

(cid:1) Affichage du résultat de la recherche : le résultat doit être affiché après qu’il

soit trié selon le prix.

(cid:1) Réservation dans un vol : l’utilisateur aura la possibilité de réserver le nombre

de places désiré pour un vol choisi.

1.2. Besoins non fonctionnels

Un besoin non fonctionnel est une restriction ou une contrainte qui pèse sur un

service du système, telle les contraintes liées à l’environnement et à l’implémentation et les

exigences en matière de performances, les dépendances de plate-forme, de facilité de

maintenance, d’extensibilité et de fiabilité.

Les besoins non fonctionnels sont :

(cid:1) dynamicité, robustesse et maintenabilité : l’application doit permettre le

stockage des

informations et

les différents

traitements utiles pour

le

fonctionnement correct, et assurer une gestion complète des erreurs.

(cid:1) Sécurité : les visiteurs peuvent consulter le site sans modifier son contenu, ni

consulter les informations personnelles des autres.

(cid:1) Fiabilité et rapidité : l’application doit garantir la rapidité et la fiabilité de la

recherche, ainsi qu’une bonne utilisation des ressources.

12 | P a g e

Chapitre 2 : ANALYSE ET SPECIFICATION

(cid:1) Esthétique : il s’agit de développer une interface simple et conviviale à utiliser

pour tous les utilisateurs.

2. Spécification formelle des besoins

Cette activité consiste à identifier les acteurs qui sont en interaction avec

l’application. Dans notre cas, nous avons distingué un seul acteur potentiel qui est le

Visiteur.

2.1. Cas d’utilisation

Le diagramme de cas d’utilisation est un modèle communicationnel. Il permet de

modéliser les besoins, les points de vue d’utilisateur et de définir les limites précises du

système tout en utilisant une notation simple compréhensible par tous.

2.1.1. Les acteurs

Dans cette application nous distinguons un acteur principal qui est Visiteur et dont

les cas d’utilisation sont :

(cid:1) Lancer une recherche de voyages chez plusieurs fournisseurs.

(cid:1) Configurer les paramètres de la recherche.

(cid:1) Modifier les paramètres métiers de la recherche.

(cid:1) Filtrer le résultat de la recherche selon le critère de prix.

(cid:1) Réserver un vol.

2.1.2. Le diagramme des cas d’utilisation

La figure suivante présente le digramme des cas d’utilisation du l’application. Elle

schématise les différents acteurs ainsi que leurs cas d’utilisation associés en utilisant la

méthodologie UML.

13 | P a g e

Chapitre 2 : ANALYSE ET SPECIFICATION

Figure 6. Diagramme des cas d'utilisation

Dans le paragraphe suivant nous éclaircissons les cas d’utilisation à travers quelques

diagrammes de séquence.

2.2. Diagrammes de séquence

Dans cette partie, nous faisons une présentation détaillée des cas d’utilisation de

l’acteur Visiteur ex exposant les diagrammes de séquences principaux. Nous nous

contentons par le cas d’utilisation principal Lancer une recherche.

Figure 7. Diagramme de séquence: cas d'utilisation Lancer une recherche

14 | P a g e

Chapitre 2 : ANALYSE ET SPECIFICATION

Le visiteur demande d’abord de faire une recherche, le moteur lui retourne la page de

configuration des paramètres métiers. Après toute configuration, l’acteur visiteur lance la

recherche. Le moteur lui renvoie le résultat.

2.3. Diagramme d’activité

Le diagramme d’activité représente le comportement interne d’une opération ou d’un

cas d’utilisation en termes d’action, les concepts de base d’activité et de transition déjà

définie sont repris dans le diagram