DIC - 2012 - Conception Et Réalisation D́un Framework Pour Le Développement de Systèmes de Réservation en Ligne

REPUBLIQUE DU SENEGAL
***** * * ********
UNIVERSITE CHEIKH ANTA DIOP DE DAKAR
ECOLE SUPERIEURE POLYTECHNIQUE

DEPARTEMENT GENIE INFORMATIQUE
MEMOIRE DE FIN DE CYCLE

Pour l’obtention du :
DIPLOME D’INGENIEUR DE CONCEPTION (DIC) en Informatique
SUJET :
Conception et Réalisation dún Framework pour le
Développement de Systèmes de Réservation en
Ligne
Lieu de stage : Xone-Tech Période stage : 02/2012 Ŕ 06/2012
Présenté et soutenu par Professeur encadreur Maître de stage

Cheikh Sidya CAMARA M. Ahmath Bamba MBACKÉ M. Abdel Kader ALLAM
Année universitaire : 2011 Ŕ 2012

REPUBLIQUE DU SENEGAL
***** * * ********
UNIVERSITE CHEIKH ANTA DIOP DE DAKAR
ECOLE SUPERIEURE POLYTECHNIQUE

DEPARTEMENT GENIE INFORMATIQUE
MEMOIRE DE FIN DE CYCLE

Pour l’obtention du :
DIPLOME D’INGENIEUR DE CONCEPTION (DIC) en Informatique
SUJET :
Conception et Réalisation dún Framework pour le
Développement de Systèmes de Réservation en
Ligne
Lieu de stage : Xone-Tech Période stage : 02/2012 Ŕ 06/2012
Présenté et soutenu par Professeur encadreur Maître de stage

Cheikh Sidya CAMARA M. Ahmath Bamba MBACKÉ M. Abdel Kader ALLAM
Année universitaire : 2011 Ŕ 2012

DEDICACES
Je dédie ce mémoire :
À ma mère Ndèye Fatou NDOYE,
À mon père Mamadou CAMARA,
À mon frère Ibrahima,
À mes sœurs Fatou, Ndèye Fatou et Mame Diarra
À toute ma famille : mes tantes, mes oncles, mes cousins et cousines, …,
À tonton Tidiane Ndiaye,
À tous mes collègues de WAY2CALL (maman Fily, tonton Aristide, papa Hassane,
Guillaume, Hovi et Sokhna)
À tous mes amis,
À tous les étudiants du département Génie Informatique.

REMERCIEMENTS
J’adresse mes remerciements les plus chaleureux à :
 M. Ahmadou Thierno GAYE, Chef du Département Génie Informatique,

 Docteur Alassane Bah, Responsable Pédagogique DIC,
 M. Ahmath Bamba MBACKÉ, mon professeur encadreur,
 M. Abdel Kader ALLAM, mon maitre de stage,
 Tous mes professeurs,
 Tous mes camarades de promotion,
 Tous mes collègues de XONE-TECH,
 Tous mes amis
Toutes les personnes qui de près ou de loin, ont contribué à la réalisation de ce document.
AVANT-PROPOS
Établissement public à caractère administratif doté de la personnalité juridique et de

l’autonomie financière, l’École Supérieure Polytechnique fait partie intégrante de l’université
Cheikh Anta DIOP de Dakar. Elle a été créée par la loi n° 94-78 du 24 novembre 1994.
L'Ecole Supérieure Polytechnique a pour missions de :
1. Former, tant sur le plan théorique que pratique, des techniciens supérieurs, des
ingénieurs technologues, des ingénieurs de conception, des managers en gestion
déntreprises et des docteurs ;
2. Dispenser un enseignement en vue de préparer aux fonctions déncadrement
dans : la production, la recherche appliquée et les services ;
3. Organiser des enseignements et des activités de recherche visant au
perfectionnement permanent, à ládaptation et à la participation à l´évolution
scientifique, technologique, économique et managériale.
Pour lóbtention du DIC (Diplôme dÍngénieur de Conception) du département génie

informatique, les étudiants doivent faire un stage dáu moins cinq (5) mois qui leur permettra
déffectuer une synthèse des connaissances acquises, de prendre conscience de
lénvironnement socioprofessionnel et de préciser ses aptitudes personnelles. Cést dans ce
sens que nous avons effectué un stage à léntreprise XONE-TECH pour une mise en place
dún Framework orienté développement de systèmes de réservation en ligne.
RÉSUMÉ - ABSTRACT
Ce document est un mémoire de fin de cycle pour l’obtention du diplôme d'ingénieur

de conception. Un stage d’une durée de cinq (5) mois a été effectué auprès de la société
XONE-TECH, un fournisseur de services et une firme de consulting servant des clients dans
le monde entier dans les secteurs des télécommunications et de l’IT.
Pendant la durée du stage, il nous a été confié la conception et la réalisation dún

Framework pour le développement de systèmes de réservation en ligne que nous utiliserons
pour mettre en place les sites Location9 (réservation de véhicules) et HGL (réservation de
chambres d’hôtel).
En plus du Framework, nous avons développé un générateur pour aider les

développeurs à réduire le temps de développement des systèmes de réservation.
This document is a brief end of cycle to obtain the Diploma Engineer design. A
probationary period of five (5) months was made with the company XONE-TECH, a service
provider and consulting firm serving clients worldwide in the telecommunications and IT.
During the training period, we were awarded the design and implementation of a
Framework for the development of online reservation systems which we use to develop sites
Location9 (Reservation of vehicles) and HGL (booking hotel rooms).
In addition to the Framework, we have developed a generator to help developers to

reduce the development time of the reservation systems.
Table des matières
Table des figures ........................................................................................................................ 1

Sigles et abréviations .................................................................................................................. 3
Introduction ................................................................................................................................ 4
CHAPITRE 1 : PRESENTATION GENERALE ............................................................. 5
I. Présentation de la structure d’accueil ......................................................................... 5
1. Présentation de Xone-Tech .................................................................................... 5
2. Domaines d’activités .............................................................................................. 5
II. Présentation du sujet................................................................................................... 6
1. Les systèmes de réservation ................................................................................... 6
2. Les Frameworks ..................................................................................................... 8
3. Objectifs ............................................................................................................... 10
4. Gestion de Projet .................................................................................................. 10
CHAPITRE 2 : METHODOLOGIE ................................................................................ 12
I. Définition des concepts ............................................................................................ 12
1. L’analyse .............................................................................................................. 12
2. La conception ....................................................................................................... 12
II. Démarches de conception du Framework ................................................................ 12
III. Classification des méthodes dánalyse et de conception ...................................... 14
1. Rappel sur la classification des méthodes ............................................................ 14
2. Présentation des méthodes dánalyse et de conception ........................................ 16
CHAPITRE 3 : ETUDE DETAILLEE ............................................................................ 29
I. Analyse ..................................................................................................................... 29
1. État de lárt des systèmes de réservation .............................................................. 29
2. Analyse du système de réservation générique ...................................................... 38
3. Analyse du site de réservation Location9............................................................. 57
II. Choix technologique ................................................................................................ 64
1. Le langage Python ................................................................................................ 64
2. Le Framework Django ......................................................................................... 66
III. Conception ........................................................................................................... 71
1. Système de réservation générique ........................................................................ 71
2. Architecture technique du Framework ................................................................. 73
3. Instance Location9 : réservation de véhicule ....................................................... 74
CHAPITRE 4 : MISE EN ŒUVRE ................................................................................. 77
I. Présentation des technologies utilisées .................................................................... 77
1. Git ......................................................................................................................... 77
2. JQuery .................................................................................................................. 78
3. PostgreSQL .......................................................................................................... 79
4. Mezzanine ............................................................................................................ 80
II. Implémentation du Framework ................................................................................ 81
1. Le Framework ...................................................................................................... 81
2. Le générateur ........................................................................................................ 82
III. Présentation du site de réservation de véhicules (Location9) .............................. 86
Conclusion ................................................................................................................................ 93
Bibliographie / Wébographie ................................................................................................... 93
Mémoire de fin de cycle
Cheikh Sidya CAMARA
Table des figures
Figure 1 : Diagramme de GANTT ........................................................................................ 11

Figure 2 : démarche de construction du Framework de location .......................................... 13
Figure 3 : Vue synthétique du processus Scrum ................................................................... 21
Figure 4 : Evolution des versions d’UML ............................................................................ 22
Figure 5 : Booking car réservation (étape 1) ........................................................................ 30
Figure 8 : Air France - Réservation de vols .......................................................................... 33
Figure 9 : Air France - Réservation d'hôtels ......................................................................... 33
Figure 10 : Air France - Réservation étape 2 ........................................................................ 34
Figure 11 : Air France - Finalisation Réservation ................................................................ 35
Figure 12 : Booking - Réservation étape 1 ........................................................................... 36
Figure 15 : Diagramme de cas dútilisation de la gestion des utilisateurs ............................ 39
Figure 16 : Diagramme de séquence du cas d’utilisation de la connexion ........................... 43
Figure 17 : Diagramme de séquence du cas d’utilisation de l’inscription ............................ 43
Figure 18 : Diagramme de cas d’utilisation de la gestion des agences ................................. 44
Figure 19 : Diagramme de séquence de la création d’une agence ........................................ 47
Figure 20 : Diagramme de séquence de la modification d’une agence ................................ 47
Figure 21 : Diagramme de séquence de la suppression d’une agence .................................. 48
Figure 22 : Diagramme de cas d’utilisation de la gestion des ressources ............................. 49
Figure 23 : Diagramme de séquence de l’ajout d’une ressource .......................................... 52
Figure 24 : Diagramme de séquence de la suppression d’une ressource .............................. 52
Figure 25 : Diagramme de séquence de la désactivation d’une ressource ............................ 53
Figure 26 : Diagramme de cas d’utilisation de la gestion des réservations .......................... 53
Figure 27 : Diagramme de séquence d’une réservation ........................................................ 56
Figure 28 : Diagramme de séquence de l’annulation d’une réservation ............................... 56
Figure 29 : Diagramme de classe globale du moteur de location ......................................... 57
Figure 30 : Diagramme de cas d’utilisation de la gestion des véhicules .............................. 59
Figure 31 : Diagramme de séquence de la mise en maintenance d’un véhicule................... 61
Figure 32 : Diagramme de séquence de l’annulation d’une réservation d’un véhicule ....... 61
Figure 33 : Diagramme de cas d’utilisation de la gestion des réservations de véhicules ..... 62
Figure 34 : Diagramme de séquence de la réservation d’un véhicule .................................. 64
Figure 35 : Diagramme de classe d’analyse de location9 ..................................................... 64
Figure 36 : Architecture MVT de Django............................................................................. 68
Figure 37 : Diagramme de classe de conception du moteur de location .............................. 71
Figure 38 : Diagramme de paquetage du système de réservation générique ........................ 73
Figure 39 : Architecture technique du Framework ............................................................... 74
Figure 40 : Diagramme de classe de conception de Location9 ............................................ 75
Figure 41 : diagramme de paquetage de Location9 .............................................................. 76
Figure 42 : Processus de développement d’un module du Framework ................................ 82
Figure 43 : Squelette du générateur ...................................................................................... 83
Figure 44 : Page d’accueil et formulaire de réservation de Location9 ................................. 87
Figure 45 : Liste des véhicules disponibles pour une réservation + les filtres ..................... 88
Figure 46 : Filtre des véhicules utilitaire en fonction du volume sur Location9 .................. 89
1
Conception et Réalisation dún Framework pour le Développement de Systèmes de Réservation en Ligne
Cheikh Sidya CAMARA
Figure 47 : Détail d’une réservation de véhicule sur Location9 ........................................... 90

Figure 48 : Informations sur le conducteur du véhicule pour une réservation ..................... 91
Figure 49 : Termes et conditions + paiement pour une réservation sur Location9 .............. 92
2
Cheikh Sidya CAMARA
Sigles et abréviations
Nous présentons ici certains sigles et abréviations que nous utiliserons dans le document.
API Application Programming Interface
CMS Content Management System (Système de Gestion de Contenu)
CRUD Create – Read – Update – Delete
CSS Cascading Style Sheet
CSV Comma-Separated Values
DOM Document Object Model
HTML HyperText Mark-Up Language
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
IT Information Technology
MVC Model – Vue – Contrôleur
MVT Model – Vue – Template
ORM Object-Relational Mapping
SGBD Système de Gestion de Base de Données
SGBDR Système de Gestion de Base de Données Relationnelles
SGBDRO Système de Gestion de Base de Données Relationnelles et Objet
UI User Interface
UML Unified Modeling Language
VCS Version Control System
XML Extensible Markup Language
3
Cheikh Sidya CAMARA
Introduction
Dans un monde où l’internet occupe une place prépondérante dans presque tous les
secteurs d’activités, il devient nécessaire pour les entreprises de s’approprier de cet outil afin
de rester compétitives. Elles doivent adapter leurs stratégies et leurs organisations pour
toucher un marché toujours plus dynamique et flexible, dimensionné à l’échelle mondiale.
C’est dans cette optique que l’entreprise d’accueil nous a chargé de la réalisation d’un
Framework pouvant servir de base à la création de n’importe quel site de réservation. Nous
utiliserons ensuite cet outil pour créer un site de réservation de chambres d’hôtel et un site
de réservation de véhicules.
Tout au long de ce document, l’accent sera mis sur la démarche utilisée pour arriver à
bout des objectifs qui nous ont été assignés. Pour ce faire, dans un premier temps, une brève
description de la structure d’accueil sera faite, ainsi qu’une définition des concepts importants
et une présentation de la problématique de notre sujet. Dans un second temps l’aspect
méthodologie sera abordé, c'est-à-dire comment comptons nous aborder le problème. Pour
finir, nous allons présenter quelques éléments de conception et montrer ce qui a pu être réalisé
dans le cadre de ce stage avant de terminer par une conclusion.
4
Cheikh Sidya CAMARA
CHAPITRE 1
Présentation générale
I. Présentation de la structure d’accueil
1. Présentation de Xone-Tech
Xone-Tech est un fournisseur de services et une firme de consulting servant des clients
dans le monde entier dans les secteurs des télécommunications et de l’IT.
Les services offerts par Xone-Tech sont le produit d’un large spectre d’expertise
technique (sécurité, architecture convergente, Open Source, etc.) combiné à une approche
méthodologique dont les principes sont industrialisation, capitalisation et pragmatisme.
Xone-Tech vise à offrir une expertise unique dans les mondes convergents d’Internet
et des Télécommunications.
Les consultants Xone-Tech apportent leur expérience dans tous les domaines de la
voix, la vidéo, le Wireless/mobile, la communication unifiée et les technologies réseau.
2. Domaines d’activités
Les solutions orientées Cloud1 rencontrent de nombreux challenges :
 L’interopérabilité
 La scalabilité
 La sécurité
1
http://fr.wikipedia.org/wiki/Cloud_computing
5
Cheikh Sidya CAMARA
Ainsi XONE-TECH s’est donnée pour mission d’aider les clients à comprendre,
maitriser et exploiter les nouvelles dynamiques dans les secteurs des télécommunications et
comment les convertir en opportunités.
En s’appuyant sa taille, Xone-Tech a développé une offre structurée de services qui

couvre la majeure partie des domaines d’expertise incluant :
 L’analyse des besoins
 Choix de systèmes
 Conception d’infrastructures
 Gestion de projets
 Développement de solutions et personnalisation
 Intégration de Backbone clients
 Transfert de connaissances
II. Présentation du sujet
1. Les systèmes de réservation
1.1. Définition
Par définition un système de réservation est une plateforme permettant de réserver

des ressources déterminées pendant une période donnée à une ou un groupe de personnes.
Nous retrouvons des systèmes de réservation dans de nombreux domaines notamment:
 l’immobilier avec la réservation de chambres d’hôtel, de salles de séminaires, et

autres espaces de rencontre
 le domaine du sport avec la réservation de terrains de foot ou de courts de tennis,
 le domaine du transport avec les véhicules de tourisme, utilitaires, les avions,

trains, bateaux
6
Cheikh Sidya CAMARA
 ainsi que dans n’importe quel secteur d’activité où une ressource peut être mise
à la disposition d’une autre personne pendant une plage horaire déterminée.
Un système de réservation est dit centralisé s’il permet de faire le pont entre
plusieurs prestataires de services liés au monde du voyage, comme les compagnies aériennes,
les chaînes d'hôtels et de restaurants, les loueurs de voitures, les compagnies ferroviaires.
1.2. Les enjeux des systèmes de réservation en ligne
Dans un monde où l’usage de l’internet devient de plus en plus primordial dans les
affaires, l’automatisation des systèmes de réservation devient une priorité afin de satisfaire
une clientèle à l’échelle mondiale. Les structures qui se dotent de pareils outils en pro activité
: les procédures de réservation complexes et difficile à prendre en main sont remplacées par
des étapes simples accessibles à tous depuis internet. Ces systèmes anticipent sur les besoins
du client qui est de plus en plus intégré dans le processus de réservation. Ils apportent une
facilité supplémentaire aux clients en leur offrant une porte d’entrée unique comme dans le
cadre des voyages où à partir d’un site, le client peut réserver son billet, son hôtel, sa voiture
et ses restaurants.
1.3. Les cibles des systèmes de réservation en ligne
Les systèmes de réservation touchent des cibles dans des domaines très variés de la vie
active notamment :
 Les touristes
 Les sportifs
 Les patients de services médicaux
 Ou toute autre personne voulant utiliser une ressource disponible pendant un

temps précis moyennant de l’argent.
La personne est souvent identifiée par son adresse postale, téléphone, mail, carte
bancaire. L'adresse postale est vérifiée par facture, par abonnement mensuel (téléphone, gaz,
7
Cheikh Sidya CAMARA
électricité), le numéro de téléphone est vérifié par envoi d'un SMS contenant un code à
utiliser, l'adresse mail est vérifiée par envoi d'un mail contenant un lien à activer.
2. Les Frameworks
2.1. Définition
Un Framework, littéralement traduit par « Cadre de travail » est un ensemble d’outils

permettant de développer rapidement tout ou une partie d’un logiciel. Il peut être considéré en
lui-même comme un squelette d’application pouvant être instancié par un utilisateur afin de
créer une application selon un modèle prédéfini.
La notion de Framework est à différencier de la notion de bibliothèque logicielle et

cela pour plusieurs raisons :
 Le Framework peut en son sein englober une multitude de bibliothèques

spécialisées qui l’aident dans la réalisation de ses fonctionnalités.
 Le Framework est souvent organisé suivant une architecture particulière, les

applications générées suivent aussi une architecture que l’utilisateur du
Framework est obligé de s’approprier.
Nous allons compléter cette définition de Framework en se basant sur cette définition
de Ralph Johnson (Johnson, 1997) qui caractérisait un Framework comme suit :
« Un Framework est la conception réutilisable de tout ou d’une partie d’un système

qui est représenté par un ensemble de classes abstraites et par la manière dont elles
interagissent. »
En mettant en avant la modularité, l’extensibilité et un comportement minimal, un

Framework a pour but de faciliter la construction d’une application en fournissant un petit
ensemble de composants logiciels.
2.2. Les types de Framework
Les Framework existants, sur la base de leur structure et de leur méthode de

réutilisation peuvent être classés en 2 groupes :
8
Cheikh Sidya CAMARA
 Les Framework white-box
Un Framework est dit white-box s’il possède les caractéristiques suivantes:
- L’utilisation, principalement basée sur l’héritage, se fait en ajoutant de

nouvelles classes, sous-classes, en surchargeant les méthodes existantes
- Le code-source est disponible pour le développeur et ce dernier doit l’étudier

avant de pouvoir développer sur ce Framework
Exemple : JUnit1
 Les Framework black-box
Un Framework appartient à la catégorie black-box s’il possède les caractéristiques

suivantes:
- La personnalisation se fait par configuration et assemblage des composants
- Le développeur n’a pas accès au code-source du Framework. Il n’a à sa portée

que les interfaces qui permettent le paramétrage
Une différence majeure entre les Framework white-box et black-box réside dans la
facilité de leur conception et utilisation. Les white-box sont plus simples à concevoir, mais ils
sont plus difficiles, à prendre en main, ils requièrent beaucoup plus d’efforts de
programmation. Les black-box font appels à plus d’effort dans la conception mais cet effort
supplémentaire se traduit par une utilisation simplifiée et beaucoup moins de code pour
l’utilisateur.
2.3. Utilité des Framework
Un Framework est utilisé comme point de départ de la réalisation d’une application.

Pour cela il doit mettre à la disposition du développeur des éléments de facilitation du
processus de développement. Les bénéfices à l’utilisation d’un Framework sont :
 La grande cohérence entre les différentes applications instances du Framework.
1
jUnit est un framework java open source pour la réalisation de tests unitaires
9
Cheikh Sidya CAMARA
 Une productivité accrue
 Une réduction de la maintenance
 L’économie d’argent
3. Objectifs
Le sujet qui nous a été soumis à l’occasion de notre stage répond à des besoins
formulés par un client de la société XONE-TECH. Ces besoins ont été matérialisés par des
cahiers de charge qui décrivent :
 Pour le premier, une application de gestion et de suivi des réservations de

véhicules de tourisme et utilitaire,
 Une application de gestion de réservations de chambres d’hôtel pour le

second,
 Une application générique permettant de réserver des ressources,
 et par extrapolation une possibilité d’interconnexion entre les deux systèmes

afin de fournir une solution globale à l’utilisateur final.
Pour apporter des solutions à ces problèmes soulignés ci-haut, nous avons conçu un
Framework basé sur une plateforme de réservation générique dont les applications de
réservation de véhicules ou de chambres d’hôtel n’en seraient que des instances possibles et
surtout qui offriraient des interfaces sécurisées pour une interconnexion future entre les
instances.
4. Gestion de Projet
4.1. Matrice de répartition des taches
10
Cheikh Sidya CAMARA
taches Mouhamadou Cheikh Sidya

Moustapha SY CAMARA
Réalisation d’une plateforme générique de réservation

✓ ✓
Réalisation d’un Framework orienté applications de

✓
réservation
Interconnexion via web services des différentes

✓
applications générées via le Framework
Réalisation de l’application de réservation de véhicules

✓
en utilisant le Framework
Réalisation de l’application de réservation de chambres

✓
d’hôtel en utilisant le Framework
4.2. Planification
Le diagramme de la page suivante est une estimation du temps de réalisation des

différentes applications.
Figure 1 : Diagramme de GANTT
11
Cheikh Sidya CAMARA
CHAPITRE 2
Méthodologie
I. Définition des concepts
1. L’analyse
Le terme « analyse » désigne une opération intellectuelle de décomposition d’un tout

en ses éléments. Dans notre cadre qui est la réalisation de projets informatiques, la phase
d’analyse est une étape clef dans la réalisation de ces projets. Elle permet en effet de
caractériser les besoins du futur produit, de lister les résultats attendus en terme de
fonctionnalités, de performance, de maintenance, de robustesse, de sécurité etc. L’analyse
permet donc de répondre à la question du «Que faut-il faire ? » et a pour but de se doter d’une
vision claire et rigoureuse du problème posé et du système à réaliser. Dans la phase d’analyse,
Nous nous concentrons sur le problème à résoudre en essayant de cerner ses multiples
dimensions. Il est donc important durant cette phase de ne pas perdre de vue les besoins des
utilisateurs ainsi que les frontières du système à bâtir pour mieux faire ressortir les éléments
pertinent du domaine et leur interaction.
2. La conception
La conception, contrairement à l’analyse, vise à décrire de manière non ambiguë, le

plus souvent en utilisant un langage de modélisation, le futur système, afin d’en faciliter la
réalisation. La conception menée à la suite de la phase d’analyse consiste à répondre à la
question du «Comment ? » en mettant l’accent sur une solution conceptuelle qui satisfait aux
exigences plutôt que sur une implémentation. Ainsi dans la démarche de conception, nous
procédons à des choix sur l’architecture du système ainsi que sur les outils à utiliser. Au sortir
de l’étape de conception, les modèles obtenus auront un tel niveau de détail que l’on pourra
passer directement en phase d’implémentation sans raffinement supplémentaire.
II. Démarches de conception du Framework
12
Cheikh Sidya CAMARA
La mise en place de notre Framework de développement de systèmes de réservation en

ligne doit être le résultat d’une démarche rigoureuse, depuis la spécification des besoins pour
notre Framework jusqu’à la validation de ce dernier.
Les Framework sont basés sur l’abstraction: le point de départ d’un Framework est en
général un ensemble d’exemples concrets qui sont par la suite généralisés. Cette abstraction
suit une approche bottom-up ou analyse ascendante.
La déduction du modèle générique se fera selon le processus suivant:
 retrouver les éléments communs qui existent sous différents noms ;
 paramétrer pour éviter les différences ;
 casser les gros composants en composants de tailles plus réduites pour faire
ressortir les similitudes ;
 classifier les entités similaires par catégorie.
Démarche de construction
État de l'art des systèmes de réservation
Analyse et conception d'un modèle

générique
Réalisation du Framework
Instanciation du modèle générique pour

traiter un cas particulier
Figure 2 : démarche de construction du Framework de location
État de l’art
13
Cheikh Sidya CAMARA
Cette phase consiste à faire une collecte d’un certain nombre d’exemples représentatifs
des systèmes de réservation sur lesquels nous allons nous baser pour bâtir notre Framework.
Analyse et conception d’un modèle générique
Dans cette phase, nous allons nous positionner à un niveau d’abstraction qui permettra
de produire un modèle couvrant les exemples recensés plus haut et mettant l’accent sur la
réutilisation. Pour cela on se basera sur les design patterns1.
Réalisation du Framework
La réalisation du Framework est la suite logique de la phase d’analyse et de

conception du modèle générique. Dans cette phase, nous nous intéresserons aux détails du
générateur d’applications de réservation.
Instanciation du modèle générique
Cette phase consistera à se baser sur le modèle générique, déduire un modèle

spécifique à un domaine particulier des systèmes de réservation pour produire une application.
Après avoir présenté notre manière d’aborder le problème que nous nous sommes
posés, c'est-à-dire réalisé un Framework, nous allons maintenant étudier les méthodes
d’analyse et de conception que nous comptons utiliser.
III. Classification des méthodes dánalyse et de conception
1. Rappel sur la classification des méthodes
Les méthodes d’analyse et de conception peuvent être divisées en quatre grandes

familles.
1.1. Méthodes cartésiennes ou fonctionnelles
Avec ces méthodes (SADT, SA-SD), le système étudié est abordé par les fonctions
qu’il doit assurer plutôt que par les données qu’il doit gérer. Le processus de conception est
vu comme un développement linéaire. Il y’a décomposition systématique du domaine étudié
1
http://fr.wikipedia.org/wiki/Patron_de_conception
14
Cheikh Sidya CAMARA
en sous-domaines, eux-mêmes décomposés en sous-domaines jusqu’à un niveau considéré

comme élémentaire.
1.2. Méthodes systémiques
Dans les méthodes systémiques (MERISE, REMORA, etc.) le système est abordé à
travers l’organisation des systèmes constituants l’entreprise. Elles aident donc à construire un
système en donnant une représentation de tous les faits pertinents qui surviennent dans
l’organisation en s’appuyant sur plusieurs modèles à des niveaux d’abstraction différents
(conceptuel, organisationnel, logique, physique).
1.3. Méthodes objet
L’approche objet permet d’appréhender un système en concentrant l’analyse sur les

données et les traitements à la fois. Les stratégies orientées objet considèrent que le système
étudié est un ensemble d’objets coopérant pour réaliser les objectifs des utilisateurs. Les
avantages qu’offre une méthode de modélisation objet par rapport aux autres sont la
réduction de la distance entre les langages de l’utilisateur et le langage conceptuel, le
15
Cheikh Sidya CAMARA
regroupement de l’analyse des données et des traitements, la réutilisation des composants mis
en place.
1.4. Méthodes agiles
Les méthodes Agiles sont des procédures de conception de logiciel qui se veulent plus
pragmatiques que les méthodes traditionnelles. En impliquant au maximum le demandeur
(client), ces méthodes permettent une grande réactivité à ses demandes, visent la satisfaction
réelle du besoin du client, et non des termes du contrat de développement. La notion de
méthode agile a été officialisée en 2001 par un document Manifeste Agile (Agile Manifesto)
signé par 17 personnalités impliquées dans l'évolution du génie logiciel et généralement
auteurs de leur propre méthode. Les méthodes Agiles étaient antérieures au Manifeste Agile.
Le manifeste Agile n’est donc pas l’acte de naissance des méthodes Agiles ou du mouvement
Agile, ce n’est que la formalisation consensuelle par les auteurs de ces méthodes, toutes nées
dans la deuxième partie de la décennie 90, du fait qu’elles avaient des valeurs communes, une
structure (cycle de développement) commune (itérative, incrémentale et adaptative) et une
base de pratiques, soit communes, soit complémentaires. Parmi ces méthodes on trouve la
version Anglaise du RAD (Développement Rapide d'Applications) de James Martin et
plusieurs autres méthodes reconnaissant leur parenté directe avec RAD la première méthode
Agile publiée (1991). Les deux méthodes Agiles les plus connues sont : la méthode Scrum
(1996) et la méthode XP pour eXtreme Programming (1999).
2. Présentation des méthodes dánalyse et de conception
Dans la suite de notre étude, nous allons nous appesantir sur une approche inspirée des
méthodes agiles Scrum et XP. Nous nous sommes basés sur une variante de Scrum pour la
gestion de projet et sur les principes de XP tels que le Pair-Programming et le Test Driven
Development pour la production de lignes de codes. Pour la modélisation dans les phases
d’analyse et de conception notre choix s’est porté sur le langage UML.
Comme expliqué plus haut, ces méthodes agiles, issues de l’industrie, ont fait leur
première apparition dans les années 90 et depuis 2000, on note une grande diffusion dans les
entreprises.
2.1. XP
16
Cheikh Sidya CAMARA
En informatique et plus particulièrement en génie logiciel, Extreme Programming

(XP) est une méthode agile1 plus particulièrement orientée sur l'aspect réalisation d'une
application, sans pour autant négliger l'aspect gestion de projet. XP est adapté aux équipes
réduites avec des besoins changeants. XP pousse à l'extrême des principes simples.
L'Extreme Programming a été inventé par Kent Beck, Ward Cunningham et Ron
Jeffries pendant leur travail sur un projet « C3 » de calcul des rémunérations chez Chrysler.
Kent Beck, chef de projet en mars 1996 commença à affiner la méthodologie de
développement utilisée sur le projet. La méthode est née officiellement en octobre 1999 avec
le livre Extreme Programming Explained de Kent Beck.
Le but d’XP est de trouver des solutions plus ou moins simples, basées sur des
principes éprouvés, pour tenter de diminuer les risques pour respecter les délais et la qualité
du produit commandé.
Cela, en trouvant un compromis équilibré entre "pas de démarche" et "trop de

démarche", tout en respectant le minimum de discipline nécessaire pour attendre un retour sur
investissement en temps et en effort immédiat et intéressant.
Ainsi, on souhaite réduire radicalement la production de documents en se focalisant

sur un code bien commenté plutôt que sur des documentations techniques très formelles.
XP évite donc avec cela les lourdeurs des méthodes classiques et est donc un habile
compromis entre une méthode traditionnelle et le développement, sans règles précises. Par
conséquent le travail des informaticiens est totalement tourné vers la technique où ils se
sentiront vraisemblablement plus à l’aise.
En outre, XP, en tant que méthode agile, se veut adaptative plutôt que prédictive. C’est
à dire qu’à l’inverse des méthodes lourdes qui tentent de dresser un plan au début du projet,
XP indique qu’il vaut mieux agir sur le court terme. Cela, tout simplement parce qu’il n’existe
pas de projet figé où le prédicat de base ou le contexte ne changent pas du tout. Dans ce cas,
le coût du changement a une croissance logarithmique en fonction du temps.
1
Les méthodes agiles sont des groupes de pratiques pouvant s'appliquer à divers types de projets, mais se
limitant plutôt actuellement aux projets de développement en informatique (conception de logiciel)
17
Cheikh Sidya CAMARA
Le simple fait de ne pas être réticente aux changements permet dans un premier temps
de mieux s’y adapter mais permet aussi une meilleure relation avec le client et la livraison
d’un produit conforme totalement aux exigences de ce dernier.
Enfin, le dernier but d’XP est de se vouloir orienté sur les personnes plutôt que sur les
processus.
L'Extreme Programming repose sur des cycles rapides de développement (des

itérations de quelques semaines) dont les étapes sont les suivantes :
 une phase d'exploration détermine les scénarios clients qui seront fournis pendant
cette itération ;
 l'équipe transforme les scénarios en tâches à réaliser et en tests fonctionnels ;
 chaque développeur s'attribue des tâches et les réalise avec un binôme ;
 lorsque tous les tests fonctionnels passent, le produit est livré.
Le cycle se répète tant que le client peut fournir des scénarios à livrer. Généralement le
cycle de la première livraison se caractérise par sa durée et le volume important de
fonctionnalités embarquées. Après la première mise en production, les itérations peuvent
devenir plus courtes (une semaine par exemple).
L'eXtreme Programming repose sur cinq valeurs fondamentales :
 La communication
C'est le moyen fondamental pour éviter les problèmes. Les pratiques que
préconise l'XP imposent une communication intense. Les tests, la programmation en
binôme et le jeu du planning obligent les développeurs, les décideurs et les clients à
communiquer. Si un manque apparait malgré tout, un coach se charge de l'identifier et
de remettre ces personnes en contact.
 La simplicité
18
Cheikh Sidya CAMARA
La façon la plus simple d'arriver au résultat est la meilleure. Anticiper les

extensions futures est une perte de temps. Une application simple sera plus facile à faire
évoluer.
 Le feed-back
Le retour d'information est primordial pour le programmeur et le client. Les tests

unitaires indiquent si le code fonctionne. Les tests fonctionnels donnent l'avancement du
projet. Les livraisons fréquentes permettent de tester les fonctionnalités rapidement.
 Le courage
Certains changements demandent beaucoup de courage. Il faut parfois changer

l'architecture d'un projet, jeter du code pour en produire un meilleur ou essayer une
nouvelle technique. Le courage permet de sortir d'une situation inadaptée. C'est difficile,
mais la simplicité, le feedback et la communication rendent ces tâches accessibles.
 Le respect
Cette valeur fut ajoutée dans la deuxième édition de Extreme Programming

Explained de K. Beck.
2.2. Scrum
Scrum est une méthode agile conçue pour un usage au sein d'une petite équipe,
cherchant à maximiser sa productivité au travers de "règles de vie" facile à adapter à son cycle
de développement.
Scrum tire son nom du terme anglais "mêlée", au Rugby. Le nom a été choisi pour
l'analogie que constituent les réunions quotidiennes de Scrum avec la mêlée, cette technique
de reprise du jeu après une faute qui remet une équipe sur de bons rails par un effort collectif.
Conçue en 1993 et formalisée en 1995, cette méthode de développement (orientée gestion de
projet) inclut souvent des pratiques venant de XP.
L'idée de Scrum est de tenir compte de la réalité de la plupart des projets pour lesquels
il n'est pas possible de tout définir dès le début : les spécifications seront modifiées et
19
Cheikh Sidya CAMARA
précisées, des outils ou technologies inconnus entreront en jeu, etc. De fait, pour s'adapter aux
changements qui ne manqueront pas d'arriver, Scrum ne suit pas un processus prédictif et les
travaux à faire sont ajustés régulièrement au cours du projet, notamment à la fin de chaque
itération, appelée le "Sprint".
Scrum suppose donc une intense collaboration entre les différentes personnes
impliquées - des caractéristiques ici encore proches de la mêlée. Le directeur de produit
(product owner) est le représentant des clients et utilisateurs, il définit les priorités pour la
réalisation. Le "gestionnaire" est nommé ScrumMaster : il a pour charge de faciliter
l'application de Scrum par l'équipe. L'équipe s'engage pour la réalisation de fonctionnalités et
le ScrumMaster la motive pour y arriver.
Le processus Scrum repose sur deux journaux ou "backlog" :
 backlog de produit : une liste des fonctionnalités pour le produit, définie par le
directeur de produit,
 backlog de Sprint : recense les tâches du Sprint en cours.
Un projet utilisant Scrum a son cycle de vie composé de Sprints successifs. Un Sprint
dure au plus quatre semaines. Pendant un Sprint, des réunions quotidiennes de moins de 15
minutes (appelées Scrum) permettent à toute l'équipe de faire le point sur le travail accompli
par chacun depuis la dernière réunion Scrum, les obstacles rencontrés, et le travail prévu d'ici
la prochaine réunion - rien de plus.
Pendant un Sprint l'équipe développe un produit partiel. Elle déroule toutes les
activités nécessaires pour cela : analyser, concevoir, développer, tester, documenter, intégrer.
Chaque Sprint se termine par une revue de Sprint, pour que le directeur de produit évalue, au
cours d'une démonstration, le produit partiel obtenu et modifie au besoin le backlog de
produit.
En définitive, Scrum introduit des règles pour suivre un processus itératif empirique
permettant d'obtenir un produit très proche de besoins qui évoluent et ainsi de maximiser la
valeur pour les clients.
20
Cheikh Sidya CAMARA
Figure 3 : Vue synthétique du processus Scrum
2.3. TDD
Le développement piloté par les tests (ou TDD en anglais : Test Driven Development)
est une technique de développement de logiciel qui préconise d´écrire les tests unitaires avant
d´écrire le code source du logiciel.
Il est divisé en cinq (5) étapes :
 Ecriture dún premier test ;
 Vérifie quíl échoue afin de vérifier que le test est valide ;
 Ecrire juste le code suffisant pour passer le test ;
 Vérifier que le test passe ;
 Réfactoriser le code : láméliorer tout en gardant les mêmes fonctionnalités.
2.4. Le langage UML
2.4.1. Définition et historique
UML (en anglais Unified Modeling Language ou « langage de modélisation unifié »)

est un langage graphique de modélisation des données et des traitements. C'est une
formalisation très aboutie et non-propriétaire de la modélisation objet utilisée en génie
logiciel. UML est avant tout un support de communication performant, qui facilite la
21
Cheikh Sidya CAMARA
représentation, la compréhension, la comparaison, la spécification et la documentation de

solutions objet. UML est l'accomplissement de la fusion des meilleures approches de la
modélisation objet (Booch, OMT, OOSE) effectuée en 1995. Principalement issu des travaux
de Grady Booch, James Rumbaugh et Ivar Jacobson, UML est à présent un standard défini par
l'OMG (Object Management Group).
UML a démarré avec la version 0.8 intégrant les méthodes BOOCH 93 et OMT. Par la
suite il y a eu l'avènement de la version 0.9 ayant intégré la méthode OOSE. La version 1.0,
proposée à l'OMG en 1996, fut finalement standardisée en 1997 sous la version 1.1. Depuis
cette année il y a eu quatre révisions du standard (d’UML 1.1 à UML 1.5 en 2003). Les
dernières améliorations étant conséquentes, UML est passé à une nouvelle version : UML 2.0
(ou UML 2).
Figure 4 : Evolution des versions d’UML
2.4.2. Le formalisme d’UML
22
Cheikh Sidya CAMARA
UML 2.3 propose 13 types de diagrammes (9 en UML 1.3). UML n'étant pas une
méthode, leur utilisation est laissée à l'appréciation de chacun, même si le diagramme de
classes est généralement considéré comme l'élément central d'UML ; des méthodologies,
telles que l'UnifiedProcess, axent elles l'analyse en tout premier lieu sur les diagrammes de
cas d'utilisation (Use Case). De même, on peut se contenter de modéliser seulement
partiellement un système, par exemple certaines parties critiques.
UML se décompose en plusieurs sous-ensembles :
 Les vues : Les vues sont les observables du système. Elles décrivent le système
d'un point de vue donné, qui peut être organisationnel, dynamique, temporel,
architectural, géographique, logique, etc. En combinant toutes ces vues, il est
possible de définir (ou retrouver) le système complet.
 Les diagrammes : Les diagrammes sont des éléments graphiques. Ceux-ci

décrivent le contenu des vues, qui sont des notions abstraites. Les diagrammes
peuvent faire partie de plusieurs vues.
 Les modèles d'élément : Les modèles d'élément sont les briques des diagrammes
UML, ces modèles sont utilisés dans plusieurs types de diagramme. Exemple
d'élément : cas d'utilisation (CU ou cadut'), classe, association, etc.
2.4.3. Les diagrammes
Les 13 diagrammes UML sont dépendants hiérarchiquement et se complètent, de

façon à permettre la modélisation d'un projet tout au long de son cycle de vie. On peut les
diviser en 3 grands groupes :
Diagrammes structurels ou statiques
 Diagramme de classes : il représente les classes intervenant dans le système.
 Diagramme d'objets : il sert à représenter les instances de classes (objets) utilisées

dans le système.
23
Cheikh Sidya CAMARA
 Diagramme de composants : il permet de montrer les composants du système d'un

point de vue physique, tels qu'ils sont mis en œuvre (fichiers, bibliothèques, bases
de données...)
 Diagramme de déploiement: il sert à représenter les éléments matériels

(ordinateurs, périphériques, réseaux, systèmes de stockage...) et la manière dont
les composants du système sont répartis sur ces éléments matériels et interagissent
entre eux.
 Diagramme des paquetages : un paquetage étant un conteneur logique permettant

de regrouper et d'organiser les éléments dans le modèle UML, le diagramme de
paquetage sert à représenter les dépendances entre paquetages, c’est-à-dire les
dépendances entre ensembles de définitions.
 Diagramme de structure composite : depuis UML 2.x, permet de décrire sous

forme de boîte blanche les relations entre composants d'une classe.
Diagrammes comportementaux
 Diagramme des cas d'utilisation : il permet d'identifier les possibilités d'interaction

entre le système et les acteurs (intervenants extérieurs au système), c'est-à-dire
toutes les fonctionnalités que doit fournir le système.
 Diagramme états-transitions : permet de décrire sous forme de machine à états

finis le comportement du système ou de ses composants.
 Diagramme d'activité : permet de décrire sous forme de flux ou d'enchaînement

d'activités le comportement du système ou de ses composants.
Diagrammes d'interaction ou dynamiques
 Diagramme de séquence : représentation séquentielle du déroulement des

traitements et des interactions entre les éléments du système et/ou de ses acteurs.
24
Cheikh Sidya CAMARA
 Diagramme de communication : depuis UML 2.x, représentation simplifiée d'un

diagramme de séquence se concentrant sur les échanges de messages entre les
objets.
 Diagramme global d'interaction : depuis UML 2.x, permet de décrire les

enchaînements possibles entre les scénarios préalablement identifiés sous forme
de diagrammes de séquences (variante du diagramme d'activité).
 Diagramme de temps : depuis UML 2.3, permet de décrire les variations d'une
donnée au cours du temps.
a. Diagramme de paquetage
Un diagramme de packages est un diagramme UML qui fournit une représentation

graphique de haut niveau de l'organisation de notre application, et nous aide à identifier les
liens de généralisation et de dépendance entre les packages.
Un package est un concept UML destiné à regrouper des éléments de modèle en

groupes. Ces éléments peuvent être des classes, des cas d’utilisation ou même d’autres types
de diagrammes UML.
L’objectif de ce diagramme est de permettre le regroupement en sous modules

indépendants des éléments du système. Chaque module aura par conséquent son
fonctionnement propre mais pourra toutefois interagir avec les autres sous modules du
système. L’ensemble des sous modules forme le système
b. Diagramme de cas d’utilisation
Bien souvent, la maîtrise d'ouvrage et les utilisateurs ne sont pas des informaticiens il
leur faut donc un moyen simple d'exprimer leurs besoins. C'est précisément le rôle des
diagrammes de cas d'utilisation qui permettent de recueillir, d'analyser et d'organiser les
besoins, et de recenser les grandes fonctionnalités d'un système. Il s'agit donc de la première
étape UML d'analyse d'un système.
Un diagramme de cas d'utilisation capture le comportement d'un système, d'un sous-

système, d'une classe ou d'un composant tel qu'un utilisateur extérieur le voit. Il scinde la
25
Cheikh Sidya CAMARA
fonctionnalité du système en unités cohérentes ayant un sens pour les acteurs. Les cas
d'utilisation permettent d'exprimer le besoin des utilisateurs d'un système, ils sont donc une
vision orientée utilisateur de ce besoin au contraire d'une vision informatique.
Il ne faut pas négliger cette première étape pour produire un logiciel conforme aux
attentes des utilisateurs. Pour élaborer les cas d'utilisation, il faut se fonder sur des entretiens
avec les utilisateurs.
Les éléments des diagrammes de cas d'utilisation sont :
 Acteur : un acteur est l'idéalisation d'un rôle joué par une personne externe, un
processus ou une chose qui interagit avec un système.
 Cas d'utilisation : un cas d'utilisation est une unité cohérente représentant une
fonctionnalité visible de l'extérieur. Il réalise un service de bout en bout, avec un
déclenchement, un déroulement et une fin, pour l'acteur qui l'initie. Un cas
d'utilisation modélise donc un service rendu par le système, sans imposer le mode
de réalisation de ce service.
 Association : Une association est le chemin de communication entre un acteur et

un cas d'utilisation.
c. Diagramme de séquences
Le diagramme de séquence est une représentation intuitive lorsque l'on souhaite

concrétiser des interactions entre deux entités (deux sous-systèmes ou deux classes d'un futur
logiciel). Ils permettent à l'architecte/designer de créer au fur et à mesure sa solution. Cette
représentation intuitive est également un excellent vecteur de communication dans une équipe
d'ingénierie pour discuter cette solution.
Les diagrammes de séquence peuvent également servir à la problématique de test. Les

traces d'exécution d'un test peuvent en effet être représentées sous cette forme et servir de
comparaison avec les diagrammes de séquence réalisés lors des phases d'ingénierie. Le
diagramme de séquence permet aussi de représenter un scénario d'un cas d'utilisation.
d. Diagramme d’activité
26
Cheikh Sidya CAMARA
Les diagrammes d'activités permettent de mettre l'accent sur les traitements. Ils sont
donc particulièrement adaptés à la modélisation du cheminement de flots de contrôle et de
flots de données. Ils permettent ainsi de représenter graphiquement le comportement d'une
méthode ou le déroulement d'un cas d'utilisation.
Les diagrammes d'activités sont relativement proches des diagrammes d'états

transitions dans leur présentation, mais leur interprétation est sensiblement différente. Les
diagrammes d'états-transitions sont orientés vers des systèmes réactifs, mais ils ne donnent
pas une vision satisfaisante d'un traitement faisant intervenir plusieurs classeurs et doivent
être complétés, par exemple, par des diagrammes de séquence. Au contraire, les diagrammes
d'activités ne sont pas spécifiquement rattachés à un classeur particulier. Ils permettent de
spécifier des traitements a priori séquentiels et offrent une vision très proche de celle des
langages de programmation impératifs comme C++ ou Java.
Dans la phase de conception, les diagrammes d'activités sont particulièrement adaptés

à la description des cas d'utilisation. Plus précisément, ils viennent illustrer et consolider la
description textuelle des cas d'utilisation. De plus, leur représentation sous forme
d'organigrammes les rend facilement intelligibles et beaucoup plus accessibles que les
diagrammes d'états-transitions.
Les diagrammes d'activités sont également utiles dans la phase de réalisation car ils
permettent une description si précise des traitements, qu'elle autorise la génération
automatique du code.
e. Diagramme de classes
Le diagramme de classes est considéré comme le plus important de la modélisation

orienté objet et le seul obligatoire lors d'une telle modélisation. Il montre la structure interne
d'un système à mettre en place. Il permet de fournir une représentation abstraite des objets du
système qui vont interagir ensemble pour réaliser les cas d'utilisation. Il est important de noter
qu'un même objet peut très bien intervenir dans la réalisation de plusieurs cas d'utilisation.
Les cas d'utilisation ne réalisent donc pas une partition des classes du diagramme de classes.
Un diagramme de classes n'est donc pas adapté (sauf cas particulier) pour détailler,
décomposer, ou illustrer la réalisation d'un cas d'utilisation particulier. Il s'agit d'une vue
27
Cheikh Sidya CAMARA
statique car on ne tient pas compte du facteur temporel dans le comportement du système. Le
diagramme de classes modélise les concepts du domaine d'application ainsi que les concepts
internes créés de toutes pièces dans le cadre de l'implémentation d'une application. Chaque
langage de Programmation Orientée Objets donne un moyen spécifique d'implémenter le
paradigme objet (pointeurs ou pas, héritage multiple ou pas, etc.), mais le diagramme de
classes permet de modéliser les classes du système et leurs relations indépendamment d'un
langage de programmation particulier. Les principaux éléments de cette vue statique sont les
classes et leurs relations : association, généralisation et plusieurs types de dépendances, telles
que la réalisation et l'utilisation.
f. Diagramme de déploiement
Le diagramme de déploiement est une vue statique qui sert à représenter l'utilisation de
l'infrastructure physique par le système et la manière dont les composants du système sont
répartis ainsi que leurs relations entre eux. Les éléments utilisés par un diagramme de
déploiement sont principalement les nœuds, les composants, les associations et les artefacts.
Les caractéristiques des ressources matérielles physiques et des supports de communication
peuvent être précisées par stéréotype.
Un diagramme de déploiement décrit la disposition physique des ressources

matérielles qui composent le système et montre la répartition des composants sur ces
matériels. Chaque ressource étant matérialisée par un nœud, le diagramme de déploiement
précise comment les composants sont répartis sur les nœuds et quelles sont les connexions
entre les composants ou les nœuds.
28
Cheikh Sidya CAMARA
CHAPITRE 3
Étude détaillée
I. Analyse
1. État de lárt des systèmes de réservation
1.1. Présentation de quelques sites de réservation célèbres
Nous allons maintenant présenter le processus de réservation de ressources tel qu’il est
implémenté dans les sites de réservation célèbres.
1.1.1. Booking Car
Booking Car est un site de réservation de véhicules.
Etape 1 :
Le visiteur du site se trouve devant le premier formulaire du processus. Il est invité à

fournir une agence de départ, éventuellement une agence d’arrivée si le visiteur coche la case
«Autre lieu de dépôt ?», la date et l’heure de départ doivent être précisées ainsi que la date et
l’heure d’arrivée. Puisque nous sommes dans un site de réservation de véhicules, le visiteur
qui désire effectuer une réservation précise l’âge du conducteur. Il peut aussi dès le premier
formulaire préciser le groupe de véhicule dans lequel il désire effectuer sa réservation. La
plateforme étant internationale, il choisit aussi le pays de résidence ainsi que la devise.
29
Cheikh Sidya CAMARA
Figure 5 : Booking car réservation (étape 1)
Etape 2 :
Après lui avoir spécifié les paramètres de la réservation, le site renvoie la liste des
véhicules qui sont disponibles à cette période. Le site propose aussi des options pour filtrer le
résultat des recherches. Le visiteur ne peut réserver qu’un seul véhicule à la fois.
30
Cheikh Sidya CAMARA
Etape 3 :
31
Cheikh Sidya CAMARA
1.1.2. Air France
Le site de cette compagnie aérienne permet d’effectuer une réservation de vols, de

chambres d’hôtel et de voitures.
Etape 1 :
Cette étape aussi, comme avec Booking Car, permet de spécifier les paramètres de la
réservation. Ces paramètres, bien que variant en fonction de la ressource à réserver, comporte
à chaque fois, la date de début de la réservation ainsi que la date de fin de même que les lieux
de départ et d’arrivée.
32
Cheikh Sidya CAMARA
Figure 8 : Air France - Réservation de vols
Figure 9 : Air France - Réservation d'hôtels
Etape 2 :
Après le choix des paramètres de la réservation pour un vol et un hôtel en même

temps, nous sommes redirigés vers la page de liste des ressources disponibles à cette période.
33
Cheikh Sidya CAMARA
Figure 10 : Air France - Réservation étape 2
Etape 3 :
Après avoir effectué notre choix, nous sommes redirigés vers une page de
récapitulation de la réservation avec possibilité d’ajouter des suppléments tels qu’une voiture
et de confirmer notre réservation en payant en ligne un montant prédéfini. Cette dernière étape
du processus de réservation demande aussi des informations concernant les futurs passagers et
locataires.
34
Cheikh Sidya CAMARA
Figure 11 : Air France - Finalisation Réservation
1.1.3. Booking
La dernière plateforme de réservation dont nous allons étudier le processus est

Booking, un site de réservation spécialisé dans les hôtels. Son processus de réservation est
similaire aux précédents en cela qu’il se déroule aussi en trois étapes :
Étape 1 :
Nous spécifions nos paramètres de réservation, c’est à dire la date de début et la date
de fin
35
Cheikh Sidya CAMARA
Figure 12 : Booking - Réservation étape 1
Etape 2 :
Nous recevons la liste des chambres qui sont disponibles durant cette période.
Etape 3 :
36
Cheikh Sidya CAMARA
Nous avons la page de récapitulation des paramètres de la réservation ainsi que le

formulaire récupérant les informations sur l’auteur de la réservation.
1.2. Recensement des modules communs aux plateformes
Les plateformes étudiées ci-haut présentent un grand nombre de similitudes sur

lesquelles nous allons nous baser pour créer notre modèle générique. Nous allons procéder au
recensement des modules communs à ces plateformes ainsi qu’à leur spécification et leur
analyse.
Plateformes
Booking Car Air France Booking site générique
Concepts
Objet à louer Véhicule Vol Chambre Ressource
Paramètres Date début Date début Date début Date début
réservations Date fin, Date fin, Date fin, Date fin,
Agence départ Agence départ Lieu Agence départ
37
Cheikh Sidya CAMARA
Agence arrive Agence arrivée

Passagers
Classe
Suppléments Oui Oui Oui Oui
réservations
Inscription Non Oui Oui Oui
Multi-agence Oui Oui Oui Oui
Plusieurs Non Oui Oui Oui
Réservations
simultanées
Prix variables Oui Oui Oui Oui
(Offres spéciales,
remises)
Maintenance des Oui Oui Oui Oui
objets
Annulation Oui Oui Oui Oui
Réservation
Paiement en Oui Oui Oui Non
ligne
Nous pouvons diviser ces fonctionnalités en quatre (4) grandes parties : la gestion des
utilisateurs, la gestion des agences, la gestion des ressources et la gestion des réservations.
Nous allons procéder à l’analyse de chaque module dans la partie suivante.
2. Analyse du système de réservation générique
2.1. Gestion des utilisateurs
2.1.1. Diagramme des cas dútilisation
38
Cheikh Sidya CAMARA
Figure 15 : Diagramme de cas dútilisation de la gestion des utilisateurs
a. Description textuelle : s’authentifier
Acteur principal:
Utilisateur
Objectifs:
Un utilisateur anonyme donne son mot de passe et son nom d’utilisateur afin d’avoir accès à
son profil et pouvoir terminer des réservations.
Pré-Conditions:
L’utilisateur n’est pas connecté
L’utilisateur a activé son compte en cliquant sur le lien d’activation dans sa boite mail.
Post-Conditions:
L’utilisateur est connecté
Scénario nominal:
1. L’utilisateur demande le formulaire de connexion en cliquant sur le lien se connecter
39
Cheikh Sidya CAMARA
2. L’utilisateur lui renvoie le formulaire de connexion demandant nom d’utilisateur et mot

de passe
3. L’utilisateur remplit le formulaire et appuie sur envoyer
4. Le système vérifie le nom d’utilisateur et le mot de passe et aussi si le compte est actif
5. Le système le redirige vers son profil
Scénarios alternatif ou d’extension:
A1. Les paramètres de connexion ne figurent pas dans la base de données
Ce scénario démarre entre le 4 et 5, le couple nom d’utilisateur mot de passe n’est pas
trouvé dans la base, le système renvoie un message d’erreur et le scénario reprend en 2.
A2. Le compte d’utilisateur n’a pas été activé
Ce scénario démarre entre le 4 et 5, le couple nom d’utilisateur mot de passe n’est pas
trouvé dans la base, le système renvoie un message d’erreur et le scénario reprend en 2.
A3. L’utilisateur a oublié son mot de passe
Ce scénario démarre à 1, au lieu de demander le formulaire d’inscription, le visiteur

demande la récupération de mot de passe.
Le système lui demande son nom d’utilisateur
Le système le recherche dans la base de données et récupère son adresse mail
Le système génère un mot de passe et remplace celui perdu dans la base de données
Le système lui envoie le nouveau mot de passe par mail
L’utilisateur peut se connecter avec son nouveau mot de passe
b. Description textuelle : sínscrire
Acteur principal:
40
Cheikh Sidya CAMARA
Utilisateur
Acteurs secondaires:
Super Administrateur
Objectifs:
Ajouter un utilisateur dans la base de données des clients de la plateforme pour qu’il puisse
accéder à son espace personnel.
Pré-Conditions:
L’utilisateur est sur la page de notre site
L’utilisateur ne possède pas encore de compte
Post-Conditions:
L’utilisateur est enregistré dans la base de données et il possède un compte client avec lequel
il peut se connecter à l’application
Scénario nominal:
1. L’utilisateur demande le formulaire d’inscription en cliquant sur le lien “s’inscrire”
2. Le système lui envoie le formulaire d’inscription à remplir
3. L’utilisateur remplit le formulaire et appuie sur envoyer
4. Le système effectue les validations et l’enregistre dans la base de données
5. Le système envoie un mail de notification à l’administrateur
6. Le système envoie un mail d’activation à l’adresse spécifié par l’utilisateur au moment de

l’inscription
7. L’utilisateur se dirige vers son email et clique sur le lien d’activation reçu
8. Le système lui affiche un mot de bienvenue
41
Cheikh Sidya CAMARA
Scénarios alternatifs ou d’extension:
A1. Erreur lors de la validation du formulaire
Ce scénario démarre entre 4 et 5. Le système détecte des champs contenant des données
non conformes aux types attendus. Dans ce cas il renvoie le formulaire avec des messages
d’erreur. Le scénario nominal reprend en 3.
A2. Une réservation est en cours
Ce scénario démarre à 1. L’utilisateur ne demande pas la page inscription mais est

redirigé vers elle par le système. Le scénario continue en 2
c. Description textuelle : gérer son profil
Acteur principal:
Utilisateur
Objectifs:
Un utilisateur met à jour les informations sur son profil.
Pré-Conditions:
L’utilisateur est connecté
Post-Conditions:
Le profil est mis à jour
Scénario nominal:
1. L’utilisateur se connecte
2. Le système le redirige sur sa page de profil
3. L’utilisateur modifie les valeurs et valide
4. Le système enregistre les nouvelles informations
42
Cheikh Sidya CAMARA
2.1.2. Diagramme de séquences
a. S’authentifier
Figure 16 : Diagramme de séquence du cas d’utilisation de la connexion
b. Sínscrire
Figure 17 : Diagramme de séquence du cas d’utilisation de l’inscription
43
Cheikh Sidya CAMARA
2.2. Gestion des agences
Figure 18 : Diagramme de cas d’utilisation de la gestion des agences
a. Description textuelle : créer agence
Acteur principal:
Super administrateur
Acteur secondaire:
Administrateur agence
Objectifs:
Le super administrateur crée une agence et lui affecte un compte administrateur
Pré-Conditions:
Le super administrateur est connecté
Post-Conditions:
44
Cheikh Sidya CAMARA
L’agence a été bien créée
Scénario nominal:
1. Le super administrateur demande la page d’ajout d’une agence
2. Le système lui renvoie le formulaire d’ajout d’une agence
3. Le super administrateur remplit les informations dans le formulaire
4. Le super administrateur choisit l’utilisateur à définir comme administrateur et valide
6. Le système envoie un mail de notification au compte utilisateur désigné comme

administrateur
b. Description textuelle : modifier agence
Acteur principal:
Objectifs:
Le super administrateur modifie les informations relatives à une agence.
Pré-Conditions:
Post-Conditions:
Les informations de l’agence ont été mises à jour
Scénario nominal:
1. Le super administrateur choisit l’agence à modifier
2. Le super administrateur demande la page d’édition de l’agence
45
Cheikh Sidya CAMARA
3. Le système lui renvoie le formulaire d’édition des informations de l’agence
4. Le super administrateur met à jour les informations dans le formulaire et valide
c. Description textuelle : supprimer agence
Acteur principal:
Acteur secondaire:
Objectifs:
Le super administrateur supprime une agence.
Pré-Conditions:
Scénario nominal:
1. Le super administrateur choisit l’agence à supprimer
2. Le super administrateur demande la suppression de l’agence
3. Le système lui renvoie un message de confirmation
4. Le super administrateur confirme son choix
5. Le système supprime l’agence
6. Le système notifie l’administrateur que son agence a été supprimée
Scénario d’erreur:
E1. L’administrateur ne confirme pas son choix de suppression
46
Cheikh Sidya CAMARA
Ce scénario démarre en 3, le super-administrateur ne confirme pas son choix
Le système le renvoie à la page de l’agence. Le cas d’utilisation prend fin.
a. Créer agence
Figure 19 : Diagramme de séquence de la création d’une agence
b. Modifier agence
Figure 20 : Diagramme de séquence de la modification d’une agence
47
Cheikh Sidya CAMARA
c. Supprimer agence
Figure 21 : Diagramme de séquence de la suppression d’une agence
2.3. Gestion des ressources
48
Cheikh Sidya CAMARA
Figure 22 : Diagramme de cas d’utilisation de la gestion des ressources
a. Description textuelle : ajouter ressource
Acteur principal :
Objectifs :
Ajouter une ressource pour une agence
Pré-Conditions :
L’administrateur d’agence est connecté et est sur la page de gestion des agences
Post-Conditions :
Une ressource est ajoutée pour son agence
Scénario nominal :
1. L’administrateur d’agence clique sur le bouton “ajouter une agence”
2. Le système affiche le formulaire d’ajout d’une agence
49
Cheikh Sidya CAMARA
3. L’administrateur d’agence rempli le formulaire et clique sur “ajouter”
4. Le système valide les données et ajoute l’agence et le redirige vers la page de gestion des
agences
Scénario alternatif ou d’extension :
A1. il y’a une erreur sur les données
Le scénario reprend à l’étape 2 avec un message d’erreur affiché sur la page
b. Description textuelle : supprimer ressource
Acteur principal :
Objectifs :
Supprimer une ressource de son agence
Pré-Conditions :
L’Administrateur d’agence est connecté et est sur la page de gestion des agences
Post-Conditions :
Une ressource est supprimée de l’agence
Scénario nominal :
1. L’administrateur de l’agence sélectionne une ressource et clique sur “supprimer”
2. Le système supprime la ressource et le redirige sur la page de gestion des ressources
A1. La ressource est réservée
50
Cheikh Sidya CAMARA
Si la ressource que l’administrateur de l’agence veut supprimer est réservée par un client
le système le lui signale en lui affichant un message de confirmation, s’il confirme le
système supprime la ressource et envoie un mail de notification aux clients qui l’avaient
réservée.
c. Description textuelle : désactiver ressource
Acteur principal :
Objectifs :
Permet de désactiver une ressource sur une période
Pré-Conditions :
L’Administrateur d’agence est connecté et est sur la page de gestion des agences
Post-Conditions :
La ressource est désactivée et n’est plus disponible sur la période de désactivation
Scénario nominal :
1. L’administrateur de l’agence sélectionne une ressource et clique sur “désactiver”
2. Le système lui affiche un formulaire lui demandant la période de désactivation
3. L’administrateur de l’agence remplit et envoie le formulaire
4. Le système désactive la ressource sur la période et le redirige sur la page de gestion des
ressources
A1. La ressource est réservée
51
Cheikh Sidya CAMARA
Si la ressource que l’administrateur de l’agence veut supprimer est réservée par un client
le système le lui signale en lui affichant un message de confirmation, s’il confirme le
système désactive la ressource et envoie un mail de notification aux clients qui l’avaient
réservée.
a. Ajouter ressource
Figure 23 : Diagramme de séquence de l’ajout d’une ressource
b. Supprimer ressource
Figure 24 : Diagramme de séquence de la suppression d’une ressource
c. Désactiver ressource
52
Cheikh Sidya CAMARA
Figure 25 : Diagramme de séquence de la désactivation d’une ressource
2.4. Gestion des réservations
Figure 26 : Diagramme de cas d’utilisation de la gestion des réservations
a. Description textuelle : réserver
Acteur principal :
Client
53
Cheikh Sidya CAMARA
Acteur secondaire :
Objectifs :
Permet à un client de réserver des ressources sur une période.
Pré-Conditions :
Le client est connecté
Post-Conditions :
L’utilisateur a fait une réservation
Scénario nominal :
1. Le client clique sur le lien de réservation
2. Le système lui affiche un formulaire lui demandant la date de début, la date de fin et
l’agence
3. Le client remplit le formulaire et clique sur envoyer
4. Le système lui affiche la liste des ressources disponibles pour sa réservation
5. Le client sélectionne une ressource et clique sur le bouton “ajouter à mon panier”
6. Le client répète les étapes 4 et 5 jusqu’à ce qu’il ajoute toutes les ressources qu’il veut
réserver à son panier
7. Le client clique sur le bouton “réserver”
8. Le système lui affiche le résumé de la réservation
9. Le client clique sur “valider”
10. Le système enregistre la réservation et envoie un mail au client et à l’administrateur de

l’agence pour la validation
54
Cheikh Sidya CAMARA
11. L’administrateur de l’agence fait la validation
12. Le système envoie un mail au client pour lui informer que sa réservation est validée
A1. Il n y a pas de ressource disponible pour la réservation
Le système lui affiche un message lui disant qu’il ne trouve pas une ressource disponible
et le scénario reprend en 3
b. Description textuelle : annuler une réservation
Acteur principal :
Client
Objectifs :
Permet à un client d’annuler une de ses réservations
Pré-Conditions :
Le client s’est connecté et avait déjà fait une réservation
Post-Conditions :
Le client a annulé une réservation.
Scénario nominal :
1. Le client clique sur le lien “mes réservations”
2. Le système lui affiche la liste des réservations
3. Le client sélectionne une réservation et clique sur annuler
4. Le système annule la réservation et le redirige sur la page de ses réservations
55
Cheikh Sidya CAMARA
a. Réserver
Figure 27 : Diagramme de séquence d’une réservation
b. Annuler une réservation
Figure 28 : Diagramme de séquence de l’annulation d’une réservation
56
Cheikh Sidya CAMARA
2.5. Diagramme de classe d’analyse
Figure 29 : Diagramme de classe globale du moteur de location
3. Analyse du site de réservation Location9
Location9 est un site de réservation de véhicules au Maroc. On retrouve les mêmes

modules que dans le système de réservation générique que nous avons présenté dans la partie
précédente. Les seules différences se situent dans les modules de gestion de ressources
(véhicules) et de la gestion des réservations.
3.1. Gestion des agences
Les agences se gèrent de la même manière que ceux du système de réservation

générique. Mais il y’a aussi une matrice de parcourt des véhicules entre agences doit être mise
en place.
3.1.1. Description textuelle de l’ajout d’une agence
57
Cheikh Sidya CAMARA
Acteur principal:
Acteur secondaire:
Objectifs:
Le super administrateur crée une agence et lui affecte un compte administrateur
Pré-Conditions:
Post-Conditions:
L’agence a été bien créée
Scénario nominal:
1. Le super administrateur demande la page d’ajout d’une agence
2. Le système lui renvoie le formulaire d’ajout d’une agence
3. Le super administrateur remplit le formulaire, donne la liste des agences où on peut

déposer ses véhicules, choisit l’utilisateur à définir comme administrateur et valide
5. Le système envoie un mail de notification au compte utilisateur désigné comme

administrateur
3.2. Gestion des véhicules
3.2.1. Diagramme des cas d’utilisation
58
Cheikh Sidya CAMARA
Figure 30 : Diagramme de cas d’utilisation de la gestion des véhicules
a. Description textuelle : mettre en maintenance
Acteur principal :
Objectifs :
Mettre en maintenance un véhicule pour une période
Pré-Conditions :
L’administrateur d’agence est connecté et est sur la page de la gestion des véhicules
Post-Conditions :
Un véhicule est ajouté à la liste des maintenances et ne sera pas disponible dans la période de
maintenance
Scénario nominal :
59
Cheikh Sidya CAMARA
1. L’administrateur sélectionne un véhicule et clique sur le bouton « mettre en

maintenance »
2. Le système lui affiche un formulaire lui demandant la période de mise en maintenance
3. L’administrateur de l’agence rempli et envoie le formulaire
4. Le système ajoute le véhicule sur la liste des maintenances et le redirige sur la page de
gestion des véhicules
A1. Le véhicule est réservé par un client dans la période de maintenance
Si le véhicule que l’administrateur de l’agence veut mettre en maintenance est réservé par un
client, le système le lui signale en lui affichant un message de confirmation, s’il confirme le
système le met en maintenance et annule les réservations du véhicule pour cette période.
b. Description textuelle : annuler maintenance
Acteur principal :
Objectifs :
Annuler la maintenance d’un véhicule
Pré-Conditions :
L’administrateur d’agence est connecté et est sur la page de la gestion des maintenances
Post-Conditions :
La maintenance d’un véhicule est annulée et la ressource est de nouveau disponible pour la
période.
Scénario nominal :
60
Cheikh Sidya CAMARA
1. L’administrateur sélectionne un véhicule et clique sur le bouton « annuler la maintenance

»
2. Le système annule la maintenance du véhicule et le redirige sur la page de la gestion des

maintenances
a. Mettre en maintenance
Figure 31 : Diagramme de séquence de la mise en maintenance d’un véhicule
b. Annuler maintenance
Figure 32 : Diagramme de séquence de l’annulation d’une réservation d’un véhicule
3.3. Gestion des réservations
3.3.1. Diagramme de cas d’utilisation
61
Cheikh Sidya CAMARA
Figure 33 : Diagramme de cas d’utilisation de la gestion des réservations de véhicules
a. Description textuelle : réserver
Acteur principal :
Client
Acteur secondaire :
Objectifs :
Permet à un client de réserver un véhicule
Pré-Conditions :
Le client est sur le site
Post-Conditions :
Le client a fait une réservation
Scénario nominal :
62
Cheikh Sidya CAMARA
1. Le client clique sur le lien de réservation
2. Le système lui affiche un formulaire lui demandant la date de début, la date de fin,
l’agence de départ et l’agence d’arrivée
3. Le client remplit le formulaire et clique sur envoyer
4. Le système lui affiche la liste des véhicules disponibles pour sa réservation
5. Le client sélectionne un véhicule et clique sur le bouton « réserver »
6. Le système lui affiche le résumé de la réservation et le formulaire pour avoir les

informations sur le conducteur
7. Le client remplit le formulaire et clique sur « valider »
8. Le système enregistre la réservation et envoie un mail au client et à l’administrateur de

l’agence pour la validation
9. L’administrateur de l’agence fait la validation
10. Le système envoie un mail au client pour lui informer que sa réservation est validée
A1. Il n y a pas de véhicule disponible pour la réservation
Le système lui affiche un message lui disant qu’il n y a pas de véhicules disponibles pour sa
réservation et le scénario reprend en 3.
b. Diagramme de séquences de la réservation d’un véhicule
63
Cheikh Sidya CAMARA
Figure 34 : Diagramme de séquence de la réservation d’un véhicule
3.4. Diagramme de classe d’analyse
Figure 35 : Diagramme de classe d’analyse de location9

II. Choix technologique
1. Le langage Python
64
Cheikh Sidya CAMARA
1.1. Présentation
Python est un langage portable, dynamique, extensible, gratuit, qui permet (sans
l'imposer) une approche modulaire et orientée objet de la programmation. Python est
développé depuis 1989 par Guido van Rossum et de nombreux contributeurs bénévoles. Sa
première version est sortie en 1991.
Python est un langage qui peut s'utiliser dans de nombreux contextes et s'adapter à tout
type d'utilisation grâce à des bibliothèques spécialisées à chaque traitement. Il est cependant
particulièrement utilisé comme langage de script pour automatiser des tâches simples mais
fastidieuses comme par exemple un script qui récupérerait la météo sur Internet ou qui
s'intégrerait dans un logiciel de conception assistée par ordinateur afin d'automatiser certains
enchaînements d'actions répétitives. On l'utilise également comme langage de développement
de prototype lorsqu'on a besoin d'une application fonctionnelle avant de l'optimiser avec un
langage de plus bas niveau. Il est particulièrement répandu dans le monde scientifique, et
possède de nombreuses extensions destinées aux applications numériques.
Quelques projets et grandes organisations utilisant le langage Python :
 Zope, un serveur d'application innovant, et CPS, un Framework de gestion de

contenu et de travail collaboratif basé sur Zope ;
 Les programmes d'administration système spécifiques à la distribution Red Hat

Linux ;
 Des moteurs de recherche comme Google ou Yahoo!;
 Chandler, le projet de PIM (Personnal Information Manager) de l'Open Source

Applications Foundation.
1.2. Les eggs
65
Cheikh Sidya CAMARA
Un egg est un packaging d’un module Python incluant ses métadonnées telles que sa
version, sa documentation et les éventuelles dépendances d’autres eggs. La grande majorité
des eggs publics sont distribués sur le site pypi1.
Un package Python peut être distribué sous la forme d’une simple archive (zip ou
tar.gz). Python inclut la librairie distutils2 afin de réaliser ces distributions source, mais celle-
ci ne gère pas les dépendances entre packages. Distutils contient une extension : destribute qui
ajoute de nombreuses fonctionnalités :
 dépendances (metadata install_requires)
 distribution binaire, egg
 entry points
Le package distribute fournit la commande easy_intall qui permet d’installer un

package donné :
$ easy_install <nom_du_paquet>
Il y a également pip3 qui lui propose un moyen alternatif à easy_install pour installer
un package.
2. Le Framework Django
2.1. Présentation
Django est un Framework web open-source développé en Python, initialement pour un

journal local dans le Kansas : World Online. Il a pour but de rendre le développement web
simple et rapide. Le projet a pour slogan « Le framework web pour les perfectionnistes sous
pression ». Django a été publié sous licence BSD à partir de juillet 2005.
1
http://cours-plone-niveau-1.ecreall.com/integrateur/glossaire.html#term-pypi
2
http://docs.python.org/library/distutils.html
3
http://pypi.python.org/pypi/pip
66
Cheikh Sidya CAMARA
Le but premier de Django est de faciliter la mise en œuvre de sites web complexes
interfacés à des bases de données. Par framework, Django peut être considéré comme une
boîte à outils où chaque module peut fonctionner de façon indépendante.
2.2. Le MVT dans Django
Django se base sur un design pattern appelé MVT pour modèle, vue, template (dérivé
du MVC : modèle – vue – contrôleur) :
 Les modèles décrivent la structure de notre Base de Données sous forme d'objets
 Les vues correspondent à chacune de nos pages et fournissent les données

dynamiques aux templates, elles ont un rôle d'interface entre les modèles et les
templates.
 Les templates spécifient le squelette HTML pour l'affichage des données
L'intérêt de fonctionner sous ce modèle MVT est que notre code devient extrêmement
maintenable : une modification des modèles n’entraîne pas nécessairement une modification
des vues ou des templates, et vice versa car chacune des parties a un rôle défini bien différent,
voire indépendant.
67
Cheikh Sidya CAMARA
Brower
Template URL dispatcher
View
Model
DataBase
Figure 36 : Architecture MVT de Django
2.3. Un typage fort des données
Une des principales choses que l'on peut reprocher à des langages comme PHP, c'est le
typage quasi inexistant des données : on laisse à PHP le soin de définir si telle variable est un
String ou un int par exemple.
Avec Django, il nous est imposé de typer nos attributs de modèles qui nous
permettront par la suite de générer automatiquement notre base de données (le framework
supporte plusieurs types de BDD). En guise d'exemple, nous pouvons créer une table Membre
toute simple, il nous suffit d'écrire ceci :
class Membre(models.Model):
pseudo = models.CharField(max_length=200)
mail = models.EmailField(max_length=75)
68
Cheikh Sidya CAMARA
dateCreation = models.DateField(auto_now=True)
Ces quelques lignes suffisent à définir entièrement notre table Personne qui sera
automatiquement créée dans la BDD par Django. De plus, ce typage de modèle va plus loin
car il permet par la suite de vérifier que les données entrées correspondent bien au type
spécifié dans nos modèles, et ce, de manière complètement automatique : nous n'avons pas
besoin de nous soucier du code de la validation de nos formulaires !
Le champ mail sera automatiquement vérifié à chaque envoi pour correspondre à la

forme pseudo@domaine.fr. La vérification peut même aller plus loin : Django peut tester si
domaine.fr existe réellement avant de valider le formulaire...
Il existe également un type ImageField() qui permet de tester si l'utilisateur envoie

bien un fichier de type image, et Django se chargera d'uploader le fichier dans le dossier de
notre choix sur votre serveur.
2.4. Un moteur de template extensible
Django utilise un moteur de templates se rapprochant de TWIG1. Ainsi, nos fichiers

templates ne peuvent contenir QUE du HTML, de l'affichage de variables passées par la vue
ainsi que des tests « if » et des boucles « for » : c'est tout. Il n'y aura pas de code Python dans
les templates, ainsi cela nous force à respecter le modèle MVT pour ne pas aller au-delà du
rôle de template.
Une particularité Django appelée les template tags permet d'étendre ce moteur de
templates en lui ajoutant d'autres fonctionnalités que nous pouvons coder nous-même, par
exemple : une balise qui permettrait de redimensionner automatiquement les images sur le
serveur ou ce genre de choses...
2.5. Programmation sous forme d’applications
Un projet Django est généralement composé de plusieurs applications ayant des

objectifs différents mais qui interagissent tout de même entre elles. L'intérêt d'un tel
découpage est que nous pouvons reprendre certaines de nos applications précédemment
1
TWIG est un moteur de template PHP
69
Cheikh Sidya CAMARA
codées pour les greffer sur un autre projet sans avoir forcément besoin de les adapter. Cette
pratique favorise également le partage d'applications de la part de la communauté Django :
nous pouvons trouver beaucoup d'applications réutilisables sur le net.
2.6. Quelques fonctionnalités et composants utiles
 Construction automatique de la BDD à partir des modèles
 Interface d'administration automatiquement générée et facilement personnalisable
 Construction et validation de formulaires en quelques lignes seulement
 Protection CSRF des formulaires : gain de sécurité
 Installation d'applications externes au projet très facile
 Gestion d'envoi de fichiers sur le serveur totalement gérée
 Module de commentaires, pour nos pages, déjà installé de base
 Gestion de comptes utilisateur et zones d'authentification, déjà installés de base
 Un serveur web : Zope, léger permettant de développer et tester ses applications

en temps réel sans déploiement ;
 Un système élaboré de traitement des formulaires muni de widgets permettant

d'interagir entre du HTML et une base de données. De nombreuses possibilités de
contrôles et de traitements sont fournies ;
 Un framework de cache web pouvant utiliser différentes méthodes (MemCached,

système de fichier, base de données, personnalisé) ;
 Le support de classes intermédiaires (middleware) qui peuvent être placées à des

stades variés du traitement des requêtes pour intégrer des traitements particuliers
(cache, internationalisation, accès…) ;
 Un support complet d'Unicode.
70
Cheikh Sidya CAMARA
2.7. Les limites du Framework
Django en tant que framework ne permet pas, seul, l'intégration d'AJAX côté client
web. Ceci est un choix de l'équipe de développement qui préfère laisser à l'utilisateur le choix
de la librairie AJAX à combiner avec Django (Prototype, Mochikit, jQuery, dojo, ext, etc.).
Il n'y a pas d'outil intégré au framework pour gérer les migrations lors des
modifications des modèles. Mais des applications Django comme South permettent de pallier
ce manque.
Nous pouvons aussi noter une contrainte du côté de l’hébergement : Django étant codé
en Python, le fournisseur d'hébergement où vous souhaitez mettre votre projet devra installer
Python ainsi qu'un accès SSH pour pouvoir installer les modules dont vous avez besoin.
III. Conception
1. Système de réservation générique
Figure 37 : Diagramme de classe de conception du moteur de location
django.contrib est un package du Framework Django qui regroupe toutes les classes
pour la gestion des utilisateurs et droits.
71
Cheikh Sidya CAMARA
La classe Model dans le package django.db.models de Django permet de faire la

correspondance entre les tables de la base de données et nos classes. Donc toutes les classes
de notre package sysres héritent de Model.
Nous allons passer à la description des méthodes que nous avons implémentées dans le
tableau ci-dessous.
Méthodes Description
Les méthodes de la classe Model
save() Permet d’enregistrer un objet dans la table

correspondante de la base de données
delete() Permet de supprimer un enregistrement de la table

correspondant à l’objet en cours
Les méthodes de la classe Client
activer(cle_actication) Cette méthode est utilisée pour activer le compte d’un

client après la confirmation de son e-mail
desactiver() Désactive le compte d’un client
duree() Calcule la durée (nombre de jours) de la réservation

pour pouvoir calculer le prix total
Les méthodes de la classe Reservation
annuler() Annuler la réservation
confirmer() Permet à un administrateur d’agence de confirmer une

réservation
annuler_confirmation() permet à un administrateur d’agence d’annuler une

réservation déjà confirmée
72
Cheikh Sidya CAMARA
ressourcesDisponibles() Récupère toutes les ressources disponibles pour une

réservation
ressourcesDisponiblesType(type_res Récupère toutes les ressources de type

source) « type_ressource » disponibles pour une réservation
Figure 38 : Diagramme de paquetage du système de réservation générique
2. Architecture technique du Framework
Pour le déploiement du Framework nous auront besoin :
 d’installer un interpréteur python ;
 d’un serveur WEB intégrant le module libapache2-mod-python pour pouvoir

exécuter des scripts python ;
 d’installer le Framework Django ;
 et d’un serveur de base de données.
73
Cheikh Sidya CAMARA
Figure 39 : Architecture technique du Framework
3. Instance Location9 : réservation de véhicule
Pour le développement du site de réservation de véhicule (Location9) nous utiliserons

le Framework du système de réservation générique.
Dans le diagramme de classe de conception ci-dessous nous avons représenté les

classes qui viennent du Framework avec un fond blanc dans le paquetage « sysres » et les
classes spécifiques à Location9 en bleu.
74
Cheikh Sidya CAMARA
Figure 40 : Diagramme de classe de conception de Location9
Méthodes Description
Les méthodes de la classe ReservationVehicule
distance_totale_parcourue() Cette méthode calcule la distance totale parcourue par le

client.
prix_unitaire_dirham() Calcule le prix à payer par jour en dirham
total_a_payer_dirham() Calcule le prix total à payer pour une réservation en dirham
payable_maintenant() Si un client réserve un véhicule il doit payer les 20% sur le

champ. C’est cette méthode qui calcule ce montant
payable_maintenant_dirham() Calcule le montant à payer sur le champ en dirham
75
Cheikh Sidya CAMARA
Figure 41 : diagramme de paquetage de Location9
76
Cheikh Sidya CAMARA
CHAPITRE 4
Mise en œuvre
I. Présentation des technologies utilisées
1. Git
Pour conserver le code source relatif aux différentes versions de nos applications nous
avons utilisé le logiciel de gestion de versions (ou VCS en anglais, pour Version Control
System) Git : un logiciel libre créé par Linus Torvalds, le créateur du noyau Linux, et
distribué selon les termes de la licence publique générale GNU version 2.
Un logiciel de gestion de versions agit sur une arborescence de fichiers afin de

conserver toutes les versions des fichiers, ainsi que les différences entre les fichiers.
Ce système permet par exemple de mutualiser un développement. Un groupe de

développeurs autour d'un même développement se servira de l'outil pour stocker toute
évolution du code source. Le système gère les mises à jour des sources pour chaque
développeur, conserve une trace de chaque changement. Ceux-ci sont, en bonne utilisation,
chaque fois accompagnés d'un commentaire. Le système travaille par fusion de copies locale
et distante, et non par écrasement de la version distante par la version locale. Ainsi, deux
développeurs travaillant de concert sur une même source, les changements du premier à
soumettre son travail ne seront pas perdus lorsque le second, qui a donc travaillé sur une
version non encore modifiée par le premier, renvoie ses modifications.
Généralement, chaque nouvelle version d'un fichier est appelée révision et son numéro
de version est incrémenté de un (1) par rapport à la précédente.
Git dispose notamment des commandes1 parmi lesquelles nous pouvons citer :
 git init : crée un nouveau dépôt.

1
Pour une liste complète des commandes git aller sur http://www.kernel.org/pub/software/scm/git/docs/
77
Cheikh Sidya CAMARA
 git clone : clone un dépôt distant.
 git add : ajoute de nouveaux objets blobs dans la base des objets pour chaque
fichier modifié depuis le dernier commit. Les objets précédents restent inchangés.
 git commit : intègre le haché d'un objet tree et les hachés des objets commits
parents pour créer un nouvel objet commit.
 git branch : crée une nouvelle branche de développement.
 git merge : fusionne plusieurs branches de développement.
Comme hébergeur nous avons utilisé Bitbucket (http://www.bibucket.org ) qui utilise

le système de version Mercurial et Git. Nous l’avons choisi parmi beaucoup d’autres
hébergeur (github : http://www.github.com, sourceforge : http://sourceforge.net, Google
Code : http://code.google.com, …) parce que nous pouvons créer des projets privés
gratuitement.
2. JQuery
jQuery est une bibliothèque JavaScript libre qui porte sur l'interaction entre JavaScript
(comprenant Ajax) et HTML, et a pour but de simplifier des commandes communes de
JavaScript. La première version date de janvier 2006.
Le framework contient notamment les fonctionnalités suivantes :
 Parcours et modification du DOM (y compris le support des sélecteurs CSS 1 à 3

et un support basique de XPath) ;
 Événements ;
 Effets et animations ;
 Manipulations des feuilles de style en cascade (ajout/suppression des classes,

d'attributs…) ;
 Ajax ;
78
Cheikh Sidya CAMARA
 Plugins ;
 Utilitaires (version du navigateur…).
3. PostgreSQL
Pour le stockage des données du site de réservation de véhicules nous avons utilisé le
SGBDRO PostgreSQL. Il est fondé sur une communauté mondiale de développeurs et
d'entreprises et est un outil libre disponible selon les termes d'une licence de type BSD.
PostgreSQL fonctionne selon une architecture client/serveur, il est ainsi constitué :
 d'une partie serveur, c'est-à-dire une application fonctionnant sur la machine

hébergeant la base de données (le serveur de bases de données) capable de traiter
les requêtes des clients. Il s'agit dans le cas de PostgreSQL d'un programme
résident en mémoire appelé postmaster ;
 d'une partie client devant être installée sur toutes les machines nécessitant
d'accéder au serveur de base de données (un client peut éventuellement
fonctionner sur le serveur lui-même).
PostgreSQL supporte une grande partie du standard SQL tout en offrant de

nombreuses fonctionnalités modernes :
 requêtes complexes ;
 clés étrangères ;
 déclencheurs (triggers) ;
 vues ;
 intégrité des transactions ;
 contrôle des accès simultanés (MVCC ou multiversion concurrency control).
79
Cheikh Sidya CAMARA
De plus, PostgreSQL apporte une puissance additionnelle substantielle en incorporant

les concepts de classes, héritage, types et fonctions afin que les utilisateurs puissent
facilement étendre le système.
PostgreSQL possède de nombreuses caractéristiques en faisant un SGBDR robuste et

puissant digne des SGBD commerciaux :
 des interfaces graphiques pour gérer les tables (pgAdmin, phppgAdmin, …) ;
 des bibliothèques pour de nombreux langages : frontaux, afin d'accéder aux

enregistrements à partir de programmes écrits en Java (JDBC), C/C++, Perl,
Tcl/Tk, Ruby, Python, … ;
 une API ODBC permettant à n'importe quelle application supportant ce type

d'interface d'accéder à des bases de données de type PostgreSQL.
4. Mezzanine
Mezzanine est un système de gestion de contenu puissant et flexible basé sur le

Framework Django. Il est sous licence BSD et a une grande communauté derrière. Mezzanine
fonctionne comme Wordpress qui fournit une interface intuitive pour gérer des pages, des
blogs, des formulaires et permet aux développeurs d’intégrer leur propre type de contenu.
En plus des fonctionnalités quóffre le Framework Django telles que lárchitecture

MTV, les ORMs, le moteur de Template, la gestion des caches et línterface dádministration
Mezzanine fournit :
 La gestion de la hiérarchie des pages ;
 Un éditeur WYSIWIG ;
 Création de formulaire HTML5 en faisant du drag-and-drop (glisser-déposer) avec

la possibilité d’export en CSV ;
 Personnalisation des templates des pages et blogs
80
Cheikh Sidya CAMARA
 Intégration de Twitter Bootstrap1 dans sa nouvelle version ;
 Des APIs pour ajouter d’autres types de contenu ;
 Un moteur de blog ;
 Une intégration de Google Analytics ;
 Une gestion des comptes d’utilisateurs et des profils avec une vérification des e-
mails ;
 …
II. Implémentation du Framework
1. Le Framework
D’après le diagramme de paquetage du système de réservation générique (voir Figure

38) nous avons développé les modules du système générique dans l’ordre suivant :
 Module de gestion des utilisateurs ;
 Module de gestion des agences ;
 Module de gestion des ressources ;
 Module de gestion des réservations.
Pour l’implémentation de chaque module, nous avons utilisé le développement piloté

par les tests2.
1
Un outil HTML, CSS et JavaScript développé par Twitter pour gérer les composants et interactions des UI
WEB
2
Voir la Partie Méthodologie (III.2.3)
81
Cheikh Sidya CAMARA
Réfactoriser le
Écriture dún
Vérifier que le code :
premier test Implémentation
test échoue afin Vérifier que le láméliorer tout
unitaire pour des classes du
de vérifier la test passe en gardant les
chaque classe du module
validité du test mêmes
module
fonctionnalités
Figure 42 : Processus de développement d’un module du Framework
Après avoir développé les quatre (4) modules du système de réservation générique
nous avons créé un générateur.
2. Le générateur
Le générateur permet aux développeurs d’accélérer la mise en place d’un site de

réservation. Avec ce générateur on peut :
 Créer un squelette de site de réservation utilisant notre Framework ;
 Créer un système de tarification ;
 Créer des ressources.
Le générateur est un egg (plugin python). Nous avons commencé par installer le egg
PasterScript qui fournit la commande « paster » avec laquelle on peut créer des squelettes de
code. Après l’installation on tape la commande
paster create -t basic_namespace
82
Cheikh Sidya CAMARA
qui va nous demander par la suite le nom du projet qu’on veut générer, la version, une
description, les noms des développeurs et les emails, les mots clés utilisés pour des recherches
une fois qu’on mette notre plugin sur le site officiel des eggs, le nom de la licence, …
Le schéma ci-dessous montre le squelette de notre générateur.
Figure 43 : Squelette du générateur
Le fichier le plus important c’est « setup.py » qui est le point d’entré lors de
l’installation du plugin.
from setuptools import setup, find_packages
import os
version = '1.0'
long_description = (
open('README.txt').read()
+ '\n' +
83
Cheikh Sidya CAMARA
'Contributors\n'
'============\n'
+ '\n' +
open('CONTRIBUTORS.txt').read()
+ '\n' +
open('CHANGES.txt').read()
+ '\n')
setup(name='generateur_ml',
version=version,
description="un generateur pour le framework de site de location",
long_description=long_description,
classifiers=[
"Programming Language :: Python",
],
keywords='',
author='',
author_email='',
license='gpl',
packages=find_packages('src'),
package_dir = {'': 'src'},
namespace_packages=['generateur_ml'],
include_package_data=True,
zip_safe=False,
install_requires=[
'setuptools',
'django >= 1.3.1',
'sysres'
84
Cheikh Sidya CAMARA
# -*- Extra requirements: -*-
],
entry_points="""
# -*- Entry points: -*-
[console_scripts]
sysres = generateur_ml.main:main
sysres_ressource = generateur_ml.generateur_ressource:main
sysres_tarification = generateur_ml.generateur_tarification:main
""",
Le générateur dépend de trois (3) paquets : setuptools, django et du Framework de site

de réservation sysres.
C’est dans la dernière partie du fichier (« entry points ») que nous définissons les
commandes de notre générateur (sysres, sysres_ressource et sysres_tarification) avec pour
chacune la fonction principale.
2.1. Création d’un projet
sysres nom_du_projet [-d driver_BD [-p port] [-h host] [-u username] [-w
password]]
Pour créer un nouveau site de location il faut utiliser la commande sysres en utilisant
la syntaxe ci-dessus. Il va créer un projet Django et installer automatiquement les 5
applications de notre moteur de location : sysres.gestion_client, sysres.ressource,
sysres.disponibilite, sysres.tarification et sysres.reservation.
Exemple :
sysres location9 –d postgresql –u root –w passer
2.2. Génération d’un système de tarification
sysres_tarification nom_tarif [-a attribut:type [attribut:type]]
85
Cheikh Sidya CAMARA
Cette commande permet au développeur de générer un système de tarification en

précisant le nom de la classe et les attributs supplémentaires à ajouter. Le générateur créera
une application Django dans le projet et ajoute un modèle qui hérite de la classe
sysres.tarification.Prix, le développeur pourra redéfinir les méthodes de calcul de prix et
l’affecter à ses ressources.
Exemple :
sysres_tarification prix_duree –a "duree_min:models.IntegerField

duree_max:models.IntegerField prix_par_defaut:models.BooleanField"
2.3. Génération d’une ressource
sysres_ressource nom_ressource [-a attribut:type [attribut:type]] [-t

nom_tarif]
Cette commande permet de générer une ressource. Il crée une application Django en
générant un modèle de type ressource, les tests unitaires et les templates CRUD de la
ressource. Si on précise un système de tarification il l’applique sur la ressource.
Exemple :
sysres_ressource vehicle –a "description:models.TextField

registration:models.CharField kilametrage_max:models.IntegerField
prix_supplementaire_par_km:models.FloatField"
III. Présentation du site de réservation de véhicules (Location9)
Nous allons présenter le workflow de réservation véhicule sur le site Location9.
86
Cheikh Sidya CAMARA
Figure 44 : Page d’accueil et formulaire de réservation de Location9
Le formulaire de réservation est disponible sur la page d’accueil. On donne la date de

départ, la date d’arrivée, l’agence de départ et d’arrivée.
87
Cheikh Sidya CAMARA
Figure 45 : Liste des véhicules disponibles pour une réservation + les filtres
Sur la deuxième étape le site nous montre les véhicules disponibles pour notre
réservation et on peut faire aussi des filtres suivant les catégories ou bien suivant le volume si
c’est un véhicule utilitaire comme le montre la figure 46.
88
Cheikh Sidya CAMARA
Figure 46 : Filtre des véhicules utilitaire en fonction du volume sur Location9
89
Cheikh Sidya CAMARA
Figure 47 : Détail d’une réservation de véhicule sur Location9
Après avoir choisi un véhicule on nous affiche les détails de la réservation.
90
Cheikh Sidya CAMARA
Figure 48 : Informations sur le conducteur du véhicule pour une réservation
Ensuite on donne les informations sur le conducteur du véhicule.
91
Cheikh Sidya CAMARA
Figure 49 : Termes et conditions + paiement pour une réservation sur Location9
Et enfin, on choisit le type de paiement et confirme la réservation.
92
Cheikh Sidya CAMARA
Conclusion
Dans le cadre de notre stage, nous avons réalisé un Framework pour le développement
de systèmes de réservation en ligne.
Pour la conception du Framework nous avons fait une analyse ascendante. Celle-ci
débute par l’étude des systèmes de réservation les plus utilisés dans des domaines tels que les
réservations de véhicules, de chambres d’hôtel et de billets d’avion. Dans notre approche,
nous avons noté l’exemple d’Air France, de Booking Car et de Booking qui sont les plus
connus. Ensuite, nous avons recensé les modules communs aux différents systèmes afin
d’avoir un modèle générique qui a été utilisé pour l’implémentation du Framework. Et enfin,
la mise en place des sites de réservation de véhicules et de chambres d’hôtel a été faite sous
forme d’instances du Framework.
Nous avons aussi implémenté un générateur qui permet de personnaliser et de

diminuer le temps de développement d’un site de réservation d’une ressource.
Le Framework est en production et nous prévoyons l’ajout d’un module de gestion des
tests unitaires et d’intégration sur les versions à venir.
93
Cheikh Sidya CAMARA
Bibliographie / Wébographie
 http://extremeprogramming.free.fr
 https://docs.djangoproject.com
 http://www.journaldunet.com
 http://fr.wikipedia.org
 http://www.siteduzero.com
 http://mezzanine.jupo.org
 http://www.omg.org
 “The Definitive Guide to django, Web Development Done Right” de Adrian Holovaty
et Jacob Kaplan-Moss
94

Langue

DIC - 2012 - Conception Et Réalisation D́un Framework Pour Le Développement de Systèmes de Réservation en Ligne

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

DIC - 2012 - Conception Et Réalisation D́un Framework Pour Le Développement de Systèmes de Réservation en Ligne

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE DU SENEGAL

UNIVERSITE CHEIKH ANTA DIOP DE DAKAR

ECOLE SUPERIEURE POLYTECHNIQUE

MEMOIRE DE FIN DE CYCLE

Lieu de stage : Xone-Tech Période stage : 02/2012 Ŕ 06/2012

Présenté et soutenu par Professeur encadreur Maître de stage

Année universitaire : 2011 Ŕ 2012

UNIVERSITE CHEIKH ANTA DIOP DE DAKAR

ECOLE SUPERIEURE POLYTECHNIQUE

MEMOIRE DE FIN DE CYCLE

Lieu de stage : Xone-Tech Période stage : 02/2012 Ŕ 06/2012

Présenté et soutenu par Professeur encadreur Maître de stage

Année universitaire : 2011 Ŕ 2012

À ma mère Ndèye Fatou NDOYE,

À mon père Mamadou CAMARA,

À mon frère Ibrahima,

À mes sœurs Fatou, Ndèye Fatou et Mame Diarra

À toute ma famille : mes tantes, mes oncles, mes cousins et cousines, …,

À tonton Tidiane Ndiaye,

Guillaume, Hovi et Sokhna)

À tous mes amis,

À tous les étudiants du département Génie Informatique.

J’adresse mes remerciements les plus chaleureux à :

 M. Ahmadou Thierno GAYE, Chef du Département Génie Informatique,

Établissement public à caractère administratif doté de la personnalité juridique et de

Pour l´obtention du DIC (Diplôme d´Ingénieur de Conception) du département génie

Ce document est un mémoire de fin de cycle pour l’obtention du diplôme d'ingénieur

Pendant la durée du stage, il nous a été confié la conception et la réalisation d´un

En plus du Framework, nous avons développé un générateur pour aider les

In addition to the Framework, we have developed a generator to help developers to

Table des figures ........................................................................................................................ 1

Table des figures

Figure 1 : Diagramme de GANTT ........................................................................................ 11

Figure 47 : Détail d’une réservation de véhicule sur Location9 ........................................... 90

API Application Programming Interface

CMS Content Management System (Système de Gestion de Contenu)

CRUD Create – Read – Update – Delete

CSS Cascading Style Sheet

CSV Comma-Separated Values

DOM Document Object Model

HTML HyperText Mark-Up Language

HTTP HyperText Transfer Protocol

HTTPS HyperText Transfer Protocol Secure

MVC Model – Vue – Contrôleur

MVT Model – Vue – Template

ORM Object-Relational Mapping

SGBD Système de Gestion de Base de Données

SGBDR Système de Gestion de Base de Données Relationnelles

SGBDRO Système de Gestion de Base de Données Relationnelles et Objet

UML Unified Modeling Language

VCS Version Control System

XML Extensible Markup Language

I. Présentation de la structure d’accueil

Les solutions orientées Cloud1 rencontrent de nombreux challenges :

En s’appuyant sa taille, Xone-Tech a développé une offre structurée de services qui

 L’analyse des besoins

 Développement de solutions et personnalisation

 Intégration de Backbone clients

II. Présentation du sujet

1. Les systèmes de réservation

Par définition un système de réservation est une plateforme permettant de réserver

 l’immobilier avec la réservation de chambres d’hôtel, de salles de séminaires, et