Ministère de l’Enseignement supérieur,

de la Recherche Scientifique et de la Technologie

Université de la Manouba

Ecole Nationale des Sciences de l’Informatique

Rapport

Projet deux Modules

Développement d’une application web dynamique pour la gestion des

réservations et des occupations des résidences de longue durée

Encadré par :

Docteur BEN HADJ ALOUANE Nejib

Réalisé par :

LTIFI Taha

BEJI Mohamed Hichem

Notes de l’encadrant
 Remerciements

Il nous est particulièrement agréable, avant de présenter notre travail, d’exprimer toute notre
gratitude envers les personnes qui nous ont, de près ou de loin, apporté leur soutien.

Qu’il nous soit permis d’adresser nos remerciements et nos gratitudes à notre encadrant
Docteur BEN HADJ ALOUANE Nejib pour sa disponibilité, son soutien, son aide précieuse,
ses encouragements et ses conseils judicieux tout le long de ce projet.

Par ailleurs, nous remercions tous les enseignants qui ont assuré notre formation et tous ceux
qui nous ont fourni les moyens techniques et scientifiques pour accomplir ce projet dans de
bonnes circonstances.

Nous adressons un remerciement amical à tous nos collègues pour leur soutien et leurs
encouragements.

Nous tenons, aussi, à exprimer l’honneur que nous font les membres du jury pour avoir
accepté de nous prêter leur attention et évaluer notre travail.
Table des matières

Introduction générale 1
1. Etude de l’ existant 2

1.1 Contexte général 2

1.1.1 Gestion des réservations 3

1.1.2 Gestion des ménages 3

1.2 Historique de notre application 3

1.2.1 Les systèmes de réservation informatique 3

1.2.2 Applications similaires dans le web 4

2. 3 Besoins et fonctions des applications présentes 4

2. Etude Technologique 7

2.1 Microsoft .NET 7

2.1.1 Introduction 7

2.1.2 Caractéristiques 7

2.1.3 Le framework 8

2.1.4 Les langages 9

2.1.5 Membership 10

2.2 Technologies offertes par .NET utilisées par notre application 10

2.2.1 asp.NET 10

2.2.2 LINQ 11

2.2.2.1 Présentation de LINQ 11

2.2.2.2 Nouveautés apportées par LINQ 11

2.2.3 L’accès concurrentiel sous LINQ 11

2.2.4 LINQ et transactions  12

2.3 Architecture à trois niveaux 13

2.3.1 Introduction 13

2.3.2 Avantages et inconvénients d'une architecture 3-tiers 14

3. Analyse et conception 16

3.1 Analyse et spécification des besoins 16

3.1.1 Spécification des besoins 16

3.1.1.1 Besoins fonctionnels 16

3.1.1.2 Besoins non fonctionnels 18

3.1.2 Diagrammes de cas d’utilisation 19

3.1.2.1 L’administrateur 19

3.1.2.2 L’agent 19

3.1.2.3 Le réceptionniste 20

3.2 Conception détaillée 22

3.2.1 Conception de la basse de données 22

3.2.2 Conception du serveur d’application 23

3.2.3Diagrammes de séquences 24

4. Implémentation 30

4.1 Environnement et outils de travail 30

4.1.1 Plateforme matérielle 30

4.1.2 Plateforme logicielle 30

4.2 Interfaces Homme machine 31

4.2.1 Interfaces communes 31

4.2.2 Interfaces agent 33

4.2.3 Interfaces réceptionniste 38

4.2.4 Interfaces administrateur 40

4.3 Problèmes rencontrés 41

Conclusion générale 42
Table des figures

1.1 Framework .NET 9

2.2 Architecture trois niveaux 14
3.1 Use case administrateur 19
3.2 Use case agent 20
3.3 Use case réceptionniste 21
3.4 Diagramme de base de données 22
3.5 Diagramme de classes 23
3.6 Diagramme de séquences authentification 25
3.7 Diagramme de séquences ajout agent 26
3.8 Diagramme de séquences ajout agent 27
3.9 Diagramme de séquences réceptionniste 28
4.1 Ecran accueil 32
4.2 Ecran authentification 32
4.3 Ecran description 33
4.4 Ecran réservation 34
4.5 Ecran confirmation réservation 35
4.6 Ecran historique 36
4.7 Ecran clients 37
4.8 Ecran ménages 38
4.9 Ecran attribution ménages 39
4.10 Ecran chambres 40
 Introduction Générale

La gestion des réservations et des différentes sections d’une résidence demeura

longtemps un handicap aux conséquences lourdes tant pour le gérant de l’établissement q
pour l’employé retrouvé souvent dans l’ambigüité en effectuant ses tâches.

C’est ainsi que la conception d’un outil permettant à la fois de gérer les réservations
ainsi que la gestion des différentes sections plus particulièrement celle des ménages
constituerait une grande avancée permettant un gain de temps et d’argent.

En effet, les réservations constituent une tâche primordiale aux résidences qui ont
donc pour objectif de diversifier les points de vente pour avoir plus de client. D’autre part,
gestion des ménages constitue aussi une activité complexe dont la gestion provoque souve
une perte de temps aux résidences.

C’est dans ce contexte que nous développerons notre application qui permettra de
remédier aux problèmes rencontrés par les gérants et les employés d’une résidence. Nou
soulèverons surtout le problème de conflit dans les réservations, celui de la gestion des
ménages, ainsi que diverses autres contraintes.

Notre projet s’étale sur quatre chapitres : Dans le premier chapitre, nous présentons
une étude de l’existant et du contexte général de notre application. Le deuxième chapitre
sera consacré à une étude des technologies utilisées lors du développement de notre
application. Le troisième chapitre présente l’analyse et la spécification ainsi que la
conception avec les diagrammes nécessaires. Enfin et dans un dernier chapitre nous
présentons le niveau de réalisation de l’application.
 Chapitre 1

Etude de l’existant
Introduction

Dans ce chapitre, nous présentons le contexte général dans lequel nous développons
notre application, nous évoquons un bref historique sur les applications qui furent
développées dans le même contexte. La dernière partie de ce chapitre est consacrée à une
présentation des différentes fonctions que requiers notre application et les besoins de ces
fonctions.

1.1 Contexte général :

La gestion des réservations est une vitalité indispensable dans le déroulement des
activités normale d’une résidence.

Notre travail consiste donc à la conception et l’implémentation d’une application de

gestion des réservations d’une résidence qui prendra en compte toutes les contraintes qui
peuvent survenir lorsqu’un agent hôtelier établi des réservations. Nous essayerons donc de
répondre aux divers besoins énoncés plus tard dans ce rapport.

Notre application consiste au développement d’une application qui permette de gérer

d’une part les réservations, d’autre part les ménages de notre résidence.

1.1.1 Gestion des réservations

Notre application permettra la gestion des réservations effectuées par des agents de la
résidence.
 En effet, la résidence possède un ensemble d’agents dans différents sites. Le client se
dirige donc vers l’un des endroits où se situe l’un des agents pour effectuer sa réservation.

Il s’en suit ainsi un ensemble de contraintes dont l’accès concurrentiel à la même

chambre.

1.1.2 Gestion des ménages

Cette partie de notre application sera exclusivement réservée au réceptionniste de notre

résidence qui pourra donc générer l’affectation des chambres à nettoyer à chaque femme de
ménage.
Cette affectation se fait successivement par bloc, étage et chambre. Il sera donné donc
aux femmes de ménage les blocs à nettoyer, les étages dans ces blocs et enfin les chambres
dans ces étages.
La contrainte essentielle dans cette affectation réside dans le fait d’attribuer les chambres
à une femme de ménage de façon à ce qu’elle ait ses attributions dans le même bloc voire
dans des blocs voisins.

1.2 Historique de notre application

1.2.1 Les systèmes de réservation informatique

Les GDS (Global Distribution System ou Systèmes de réservation informatique) sont des
plates-formes électroniques de gestion des réservations qui permettent aux agences de
voyages de connaître l'état du stock des différents fournisseurs de produits touristiques
(compagnies aériennes, chaîne d'hôtels, société de location de voiture, tour operateurs...) et
de réserver à distance. Ils sont de fait les premiers services de commerce électronique à
grande échelle.[5] Les GDS ont été développés à l'origine par les compagnies aériennes pour
simplifier et automatiser la gestion des réservations. La première à avoir mis en place en
1962 un système performant de ce type est "American Airlines" avec le GDS Sabre. Elle a été
rapidement suivie par les autres compagnies. Aujourd'hui, on dénombre une quinzaine de
GDS dont les plus importants sont les américains Sabre, Galileo (créé par trois compagnies
américaines et neuf européennes) et Worldspan ainsi que l'européen Amadeus créé par Air
France, Iberia et Lufthansa. Concurrencés par les fournisseurs qui proposent via Internet des
systèmes de distribution directe, les GDS développent des services associés au tourisme.[5]

1.2.2 Applications similaires dans le web

Un grand nombre d’applications réalisant les mêmes fonctionnalités que la nôtre sont
présentes en téléchargement sur le web. La majorité sont des logiciels payants mais on a
toutefois pu avoir quelques versions d’évaluation parmi lesquelles :

 Comfy hotel reservations

 Gest-hôtel
 EducHotel

Alors que nous retrouvons toujours les fonctionnalités de réservation et de gestion des
chambres, on notera que rares sont les logiciels présents sur le web permettant la gestion
des ménages. On ne sait toutefois pas si ces mêmes logiciels respectent la notion d’accès
concurrentiel.

2. 3 Besoins et fonctions des applications présentes

Après l’étude des diverses applications présentes sur le web, nous sommes arrivés à définir un
ensemble de services souvent offerts aux utilisateurs à savoir :

Fonctions Besoins
Accessibilité partout depuis le web grâce à un accès sécurisé par
Logiciel en nom d'utilisateur et mot de passe. L'agent récupère instantanément les
ligne réservations effectuées sur le web par les autres agents, et en temps réel
 Entièrement
nom, couleurs, styles, police et logo de la résidence, langue d'utilisation,
paramétrable
monnaie, taxes , pourcentage d'arrhes, jours d'arrivée, durée de séjour.

Multi langues
Français, Anglais, Espagnol

Gestion des
clients  Fiche complète avec coordonnées et observations

Gestion des
chambres et des
types de chambre
Descriptif complet avec photo: Nom de la chambre, type, étage, descriptif.

- Tarif de base par type de chambre + Possibilité de gérer les tarifs

par type et/ou par chambre et par période + Possibilité de gérer les
tarifs des nuitées par nuit et par chambre directement sur la grille
Gestion grille tarifaire.
tarifaire avancée - Lit supplémentaire
- Tarifs des différents régimes: petit-déjeuner, demi-pension, pension
complète

Réservations et Suivi de la réservation jusqu'à la facturation. Possibilité de rajouter

Facturation une remise sur l'ensemble de la facture. Edition de la facture avec logo
de la résidence et coordonnées.
 Gestion des
jours d'arrivée et Possibilité de modifier les jours d'arrivée autorisés et les durées de séjours
des durées de
séjour minimum par chambre, par type et sur une période donnée

FIG. 1.1 F ONCTIONS ET BESOINS

Conclusion

Tout au long de ce chapitre, nous avons proposé des solutions techniques disponibles sur
le marché pour le développement des applications web. Nous avons évoqué certaines
d’entre elles, à présent nous entamerons dans le chapitre qui suit une étude des
technologies utilisées lors du développement de notre application.

Chapitre 2

Etude technologique
 Introduction

Cette partie s’intéresse aux différentes technologies utilisées lors du développement de

notre application ainsi qu’à la plateforme de développement.

2.1 Microsoft .NET

2.1.1 Introduction

Microsoft .NET est le nom donné à un ensemble de produits et de technologies

informatiques de l'entreprise Microsoft pour rendre des applications facilement portables sur
Internet.

Il s’agit d’un standard proposé par la société Microsoft, pour le développement

d'applications d'entreprises multi-niveaux, basées sur des composants.

Le but est de fournir un serveur web local permettant de gérer des services et évitant
d'externaliser des données privées sur un service web de stockage ou un hébergement web
tiers.

2.1.2Caractéristiques

 Interopérabilité 

Du fait de la nécessité de pouvoir interagir avec les anciennes applications, .NET fournit
des moyens pour accéder aux fonctionnalités en dehors de l'environnement .NET. La
possibilité d'accéder aux composants COM est fournie par les espaces de noms
System.Runtime.InteropServices et System.EnterpriseServices. L'accès aux autres
fonctionnalités est fourni grâce à P/Invoke.[1]

 Common Runtime Engine 

Les langages de programmation de .NET sont compilés dans un langage intermédiaire

appelé Common Intermediate Language, ou CIL. Ce langage n'est pas interprété, mais subit
une compilation à la volée et une compilation au niveau de la Common Language Runtime
(CLR). La CLR est l'implémentation de la CLI.[1]

 Indépendance du langage 

La spécification du Common Type System (ou CTS) définit l'ensemble des types de
données et structures de programmation supportés par la CLR ainsi que leurs interactions. Par
conséquent, le .NET supporte l'échange des instances des types entre les programmes écrits
dans un des langages .NET.[1]

2.1.3 Le framework

On parle de Framework pour désigner l'ensemble constitué des services (API) offerts et de
l'infrastructure d'exécution. Le framework .NET comprend :

 Un environnement d'exécution :

 Un moteur d'exécution, appelé CLR (Common Language Runtime), permettant de

compiler le code source de l'application en un langage intermédiaire, baptisé MSIL (Microsoft
Intermediate Language) et agissant telle la machine virtuelle Java. Lors de la première
exécution de l'application, le code MSIL est à son tour compilé à la volée en code spécifique
au système grâce à un compilateur JIT (Just In Time).
 Un environnement d'exécution d'applications et de services web, appelé ASP .NET ;
 Un environnement d'exécution d'applications lourdes, appelé WinForms.

 Des services

Sous forme d'un ensemble hiérarchisé de classes appelé Framework Class Library (FCL).
La FCL est ainsi une librairie orientée objet, fournissant des fonctionnalités pour les
principaux besoins actuels des développeurs. Le SDK (Software Development Kit) fournit
une implémentation de ces classes.[1]
 FIG 2.1 F RAMEWORK .NET

2.1.4 Les langages

Grâce au CLR, la plate-forme .NET est indépendante de tout langage de programmation et

supporte un grand nombre de langages de programmation, dont on cite :

 Ada,
 APL,
 C#,
 C++,
 Cobol,
 Eiffel,
 Fortran,
 J#,
 Jscript,
 Mercury,
 Pascal,
 Perl,
  Python,
 Visual Basic

2.1.5Membership

L'appartenance de .NET intègre la possibilité de valider et de stocker des informations

d'identification utilisateur. Par conséquent, elle permet de gérer l'authentification utilisateur
dans les sites Web. Nous pouvons utiliser l'appartenance de .NET avec l'authentification par
formulaires.NET ou avec les contrôles d'ouverture de session.NET pour créer un système
complet d'authentification des utilisateurs.

L'appartenance de .NET, qu'on implémente à travers l'API membership prend en charge

les opérations suivantes :
- Création d'utilisateurs et de mots de passe .
-Gestion des mots de passe, notamment leur création, leur modification ou leur
réinitialisation.
-Stockage d'informations d'appartenance (noms d'utilisateurs, mots de passe et données de
prise en charge)
-Authentification des utilisateurs qui visitent votre site.

2.2Technologies offertes par .NET utilisées par notre application :

2.2.1 asp.NET

Asp.NET est basé sur la technologie .NET. Il permet la programmationd’applications Web

dynamiques, du côté du serveur. Les navigateurs Web, à l’aide de pages au format html,
servent donc d’interface entre l’application .NET et l’utilisateur. [2]

2.2.2 LINQ
2.2.2.1 Présentation de LINQ

Language Integrated Query est un composant qui ajoute des capacités d'interrogation sur
des données aux langages .NET en utilisant une syntaxe proche de celle de SQL. LINQ définit
un ensemble d’opérateurs de requêtes qui peuvent être utilisés pour effectuer des requêtes,
filtrer et projeter des données dans des collections, dans des classes énumérables, dans des
structures XML, dans des bases de données relationnelles, et dans des sources de données
tierce

2.2.2.2 Nouveautés apportées par LINQ

Depuis maintenant plusieurs années, la programmation orientée objet est devenue un

standard pour tout nouveau projet informatique et ses avantages.
La récupération d’information se fait généralement avec un autre langage, SQL ou
XPath/XQuery par exemple, et impose au développeur de bien les connaître. Un autre
problème sous-jacent rencontré est l’intégration de ces données avec le modèle objet : les
données sont représentées par des tables et des lignes alors que nous programmons avec des
classes et des collections.

LINQ se veut novateur car il se propose d’intégrer directement dans le langage de

programmation les fonctionnalités de requête et d’intégration. Sa généricité lui permet d’être
lié avec toute source d’information : un serveur SQL, un fichier XML et même des objets en
mémoire, le tout simultanément.

Cette intégration directe au langage a des avantages certains :

 Détection des erreurs à la compilation : la requête est vérifiée par le compilateur.

Auparavant, les erreurs dans les requêtes SQL n’étaient détectées que lors de l’exécution.
 Support de l’IntelliSenSe.
 Ecriture des requête en langage C# ou VB : il n’est plus besoin d’envoyer des chaines
de caractères au serveur SQL, le langage de programmation traduit lui-même la requête en
SQL (ou XPath, ou tout autre langage de requête).

2.2.3 L’accès concurrentiel sous LINQ

LINQ implémente un accès concurrentiel optimiste, c'est-à-dire que les données ne sont
pas verrouillées lorsqu'elles sont utilisées.

Dans le cas où les données ont changé entre le cache d'Entity Framework et la source de
données, il est possible de résoudre ce conflit via 2 solutions :
  Les données de la base font office de référentiel.
 Les données dans le cache d'Entity Framework font office de référentiel.

Cependant, cet accès concurrentiel n'est pas activé par défaut. Tout d'abord, l'accès
concurrentiel concerne une propriété d'une entité. Une fois activée, la logique de mise à jour
ou de suppression peut générer des exceptions de type "OptimisticConcurrencyException",
lorsque les données du cache d'Entity Framework et de la base de données ne sont plus les
mêmes au moment de l'appel à la méthode "SaveChanges" du contexte. Ce cas de figure
arrive fréquemment lorsque plusieurs clients consomment et mettent à jour la même base de
données. Ainsi, soit nous utilisons comme référentiel les données locales ou bien celles de la
base de données. Ceci est décidé grâce à la méthode "Refresh" de l'objet contexte, qui prend
en paramètre une valeur de l'énumération RefreshMode et l'entité à rafraîchir.

2.2.4 LINQ et transactions :

LINQ supporte les transactions de manière automatique, tout du moins en ce qui concerne
la source de données.

Les transactions sont utiles lorsqu'il est nécessaire d'exécuter plusieurs opérations comme
si ce n'était qu'une seule. Si une opération de la transaction échoue en générant une exception,
toutes les opérations précédentes sont annulées. D'une façon générale, une transaction
respecte les 4 contraintes suivantes :

 Atomicité : Une transaction doit s'exécuter totalement ou pas du tout.

 Cohérence : La cohérence des données doit être absolument respectée même en cas
d'erreur. Il doit être possible d'annuler les opérations en cas d'erreur.
 Isolation : La transaction doit s'effectuer dans un mode isolé où elle seule peut voir les
modifications en cours.
 Durabilité : Une fois la transaction terminée, le système est dans un état stable,
quelque soit ce qui s'est passé durant la transaction.
 2.2 Architecture à trois niveaux

2.3.1 Introduction

L'architecture 3-tiers est composée de trois éléments, ou plus précisément de trois couches.
En effet, dans ce contexte, et dans la philosophie qui a guidé l'élaboration de cette
architecture, il est plus adéquat de parler de couche fonctionnelle où à chacune d'elle est
attachée un élément/entité logique.[3]

Dans le modèle 3-tiers il faut distinguer trois couches/élements :

 La couche présentation associée au client qui de fait est dit "léger" dans la mesure où
il n'assume aucune fonction .
 La couche fonctionnelle liée au serveur, qui dans de nombreux cas est un serveur Web
muni d'extensions applicatives.
 La couche de données liée au serveur de base de données

Le schéma suivant résume la structure générique d'une architecture 3-tiers :

FIG 2.2 Architecture trois niveaux

D'un point de vue général quelques points importants sont à souligner pour l'architecture 3-
tiers :
  Le client qui n'a donc que des fonctions d'affichage ne fait que des requêtes vers le
serveur, aucun calcul n'est éffectué par le client. Les résultats de ses requêtes sont ensuite
affichées.
 C'est le serveur qui va effectuer tous les calculs ou faire des requêtes vers d'autres
serveurs additionnels. Ce tiers serveur se caractérise notamment par :

 Avoir été codé dans un langage présentant une forte portabilité et non
propriétaire tel que le langage C,
 Être multithread et pouvant être ainsi accessible par de multiple clients
(typiquement un serveur Web),
 Des requêtes clients via divers mécanismes

2.3.2 Avantages et inconvénients d'une architecture 3-tiers

Les avantages de l'architecture 3-tiers sont principalement au nombre de quatre :

 Les requêtes clients vers le serveur sont d'une grande flexibilité; en effet les appels
clients ne spécifient que des paramêtres et des structures de données pour les valeurs de
retour.
 L'utilisateur n'est pas supposé connaître le langage SQL, qui ne sera pas implémenté
dans la partie client qui ne s'occupe le que de fonctions d'affichage. De fait des modifications
peuvent être faites au niveau du SGBD sans que cela impacte la couche client
 D'un point de vue développement, la séparation qui existe entre le client, le serveur et
le SGBD permet une spécialisation des développeurs sur chaque tiers de l'architecture.
 Plus de flexibilité dans l'allocation des ressources; la portabilité du tiers serveur
permet d'envisager une allocation et ou modification dynamique au gré des besoins évolutifs
au sein d'une entreprise.

Les inconvénients sont au nombre de deux :

 Une expertise de développement à acquérir qui semble plus longue que dans le cadre
d'une architecture 2-tiers.
 les coûts de développements d'une architecture 3-tiers sont plus élevés que pour du 2-
tiers. [4]
Conclusion

Nous nous sommes intéressés dans cette partie aux divers aspects technologiques et architecturaux
de notre application. Nous allons maintenant spécifier les diverses analyses et conceptions pour le
développement de notre site.
Chapitre 3

Analyse et conception

Introduction

Dans cette partie nous abordons la phase d’analyse et conception. Ainsi, nous présentons les
besoins fonctionnels se notre application en recourant au langage UML (Unified Modeling Language)
comme un moyen simple et compréhensible. Cette modélisation permettra de structurer les besoins
du projet, définir ses limites et modéliser une vue fonctionnelle de l’application. Nous enterons
ensuite la phase de conception des différents modules de notre appliaction, toujours utilisant le
langage UML.

3.1 Analyse et spécification des besoins

3.1.1 Spécification des besoins
3.1.1.1 Besoins fonctionnels
Un besoin fonctionnel est un besoin spécifiant une action que le système doit être capable
d’effectuer. Il décrit les fonctions utiles et les données.

L’application que nous développons concerne trois types d’utilisateurs : l’administrateur, l’agent
et le réceptionniste.

 L’administrateur :
 Les services fournis par l’application pour l’administrateur sont les suivants:
- Gestion des agences : l’administrateur peut ajouter de nouvelles agences ou en
supprimer des déjà existantes. L’ajout d’une agence implique l’entrée du nom de cette
dernière, ses coordonnées, etc.

- Gestion des agents : l’administrateur peut de même ajouter des nouveaux agents ou en
supprimer des anciens. L’ajout d’un nouvel agent implique, outre l’entrée des informations
personnelles et des coordonnées, l’affectation de cet agent à une agence.

- Gestion des chambres, blocs et étages : l’administrateur gère les compartiments et

unités de la résidence. Il peut en effet ajouter de nouveaux blocs à notre résidence, ajouter des
étages à ces blocs et enfin des chambres dans ces étages.

- Gestion des femmes de ménage : l’administrateur gère de même les femmes de

ménage en entrant ou supprimant des ces employées. Dans le cas d’un ajout, les informations
personnelles sont entrées avec les différentes coordonnées.

 Les agents :

- Gestion des réservations : cette partie, gérée par les agents, implique l’entrée des
dates d’entrée de la réservation, du début et fin de cette dernière. L’agent indique aussi la
chambre concernée par cette réservation ainsi que la personne qui désire effectuer une
réservation avec le nombre de personnes.

- Gestion des fiches client : les agents peuvent gérer les fiches clients en ajoutant ou
supprimant de nouveaux clients. L’ajout des clients se fait par ajout des informations
personnelles et coordonnées de ces derniers.

- Consultation de l’historique des réservations : Les agents ont aussi la possibilité de

consulter l’historique des réservations. Ils peuvent soit entrer la date désirée pour avoir
l’ensemble des réservations effectuées durant la date entrée, ou consulter les réservations
effectuées par un client donné.

- Vérification de la disponibilité des chambres : L’agent a la possibilité de vérifier si une

chambre est occupée ou pas pour une période donnée.
 - Faire des factures : L’agent peut imprimer des factures contenant les coordonnées du
client, le nom de l’agent, l’agence où a eu lieu la réservation, les dates concernées par la
réservation ainsi que la chambre.

 Les réceptionnistes

Outre les fonctionnalités offertes aux agents, les réceptionnistes ont la possibilité de :
- Sélectionner les femmes de ménage disponibles : Le réceptionniste sélectionne, pour
une journée déterminée, les femmes de ménage disponibles et susceptibles de nettoyer des
chambres.
- Obtenir une répartition des femmes de ménage : Le réceptionniste obtient, selon les
femmes de ménage disponibles et les chambres occupées, une répartition de ces femmes de
ménages sur ces chambres. Ainsi, à chaque employée sera affecté un ensemble de
chambres.
- Imprimer les répartitions des femmes de ménage : Cette impression comporte la
date, le nom de la femme de ménage concernée ainsi que la date.

3.1.1.2 Besoins non fonctionnels

Un besoin non fonctionnel est une restriction ou une contrainte qui pèse sur un service
du système, telles que les contraintes liées à l’environnement et à l’implémentation, et les
exigences en matière de performance, de dépendance de plate-forme, de facilité de
maintenance, d’extensibilité et de fiabilité.

Le système doit :

- Fournir une interface simple et conviviale à utiliser pour tous les utilisateurs
- Avoir un accès rapide aux données et une bonne utilisation des ressources
- Minimiser le temps de chargement d’une page afin de ne pas nuire aux utilisateurs.
- Traiter le cas où la même chambre est réservée au même temps par deux agents différents.
- Répondre au critère de dépendance du prix des chambres selon la saison.
- Attribuer les chambres aux femmes de ménage de façon optimale (chambres proches les
unes des autres).
- Répondre aux besoins fonctionnels précédemment spécifiés.
 3.1.2 Diagrammes de cas d’utilisation
Le diagramme de cas d’utilisation est un modèle communicationnel. En effet, un cas
d’utilisation permet de modéliser les besoins, les points de vue des clients d’un système. Il
définit les limites du système avec une notation très simple, compréhensible, y compris le
client.
 3.1.2.1 L’administrateur
La première phase pour l’administrateur consiste à s’authentifier, ensuite en accédant à
sa page, il pourra accéder au menu de gestion du personnel, des agences et de la résidence.

FIG 3.1 Use Case administrateur

 3.1.2.2 L’agent :
La première phase pour l’agent consiste à s’authentifier, ensuite en accédant à sa page, il
pourra accéder au menu des réservations et de la gestion des clients.

FIG 3.2 Use Case agent

 3.1.2.3Le réceptionniste :

La première phase pour l’agent consiste à s’authentifier, ensuite en accédant à sa page, il

pourra accéder au menu des réservations et de la gestion des clients ainsi que celle de
gestion des ménages.

FIG. 3.3 Use Case réceptionniste

 3.2 Conception détaillée

Dans cette partie, nous entamons la phase de conception qui permet de décrire de
manière non ambigüe le fonctionnement désiré du système afin d’en faciliter la réalisation.

3.2.1 Conception de la basse de données

Dans cette partie nous élaborons le modèle relationnel de la base de données. Ce modèle
présenté sur la figure FIG 3.4 sera d’une utilité majeure pour la création de notre base de
données.

FIG. 3.4 Diagramme de base de données

 3.2.2 Conception du serveur d’application
Le serveur applicatif est un élément central de notre architecture. Il constitue le véritable
moteur du système.

FIG 3.5 Diagramme de classes

 3.2.3Diagrammes de séquences

Dans cette partie nous présentons quelques diagrammes de séquences pour représenter
les différents scénarios du fonctionnement de l’application. En effet, les diagrammes de
séquences décrivent les cas d’utilisation d’une manière plus détaillée. Aussi, ils décrivent les
interactions entre les différents objets de l’application.

Après la saisie du login et du mot de passe, le système interroge la base de données et

vérifie la validité des entrées. Si les entrées sont erronées, le système affichera un message
d’erreur, sinon l’utilisateur qu’il soit administrateur, agent ou réceptionniste accède aux
différentes fonctionnalités qui lui sont offertes.
FIG 3.6 Diagramme de séquence authentification
 FIG 3.7 Diagramme de séquence ajout agent

Une fois la phase de négociation de l’authentification achevée, l’administrateur peut ajouter,

supprimer ou mettre à jour un des champs de la base de données. Pour ce faire, il doit remplir les
informations pour passer sa demande (FIG. 3.6) , de sa part le système met la base de données à jour
et envoie une notification.
 FIG 3.8 Diagramme de séquence agent

L’agent demande la disponibilité d’une chambre et l’obtient directement de la base de données ;

il peut aussi demander l’historique, mais il lui est demandé d’entrer les paramètre pour enfin avoir
son historique ; ou encore demander l’effet d’une facture, avec entrée aussi des paramètres, le
système cherche les paramètres complémentaires de la base de données qui seront ajoutées à la
facture.

FIG 3.9 Diagramme de séquence réceptionniste

 Le réceptionniste demande la liste des ménages disponibles. Le résultat lui est fourni directement,
il sélectionne alors les femmes de ménage disponibles. Cette liste lui étant affichée, il demande alors
une répartition de ces ménages sur les chambres disponibles consultées sur la base de données. Il
obtient une répartition ainsi une répartition qu’il peut demander à imprimer.

Conclusion

Dans ce chapitre, nous avons expliqué et justifié notre analyse conceptuelle de l’application.
Après avoir analysé les divers besoins relatifs à notre application, nous avons détaillé l’architecture
des différents composants.
 Chapitre 4
Implémentation

Introduction

Suite à la présentation de l’analyse des différents besoins ainsi que la conception détaillée
des différentes fonctionnalités offertes par notre application, nous achevons notre travail
par la mise en œuvre de la solution retenue. En fait, la solution n’est autre que le fruit des
études effectuées dans les chapitres précédents.

Dans cette partie, il est question de décrire l’aspect d’implémentation. Nous commençons
alors par présenter l’environnement matériel et logiciel supportant notre application.
Ensuite, nous allons passer en œuvre les différentes tâches réalisées pour terminer par un
récapitulatif des différents problèmes rencontrés tout au long de ce travail.

4.1 Environnement et outils de travail

4.1.1 Plateforme matérielle
Ce projet a été développé sur une machine dotée de :

- Intel Core 2 CPU 1.60 GHZ.

- RAM 1GB.
- Système d’exploitation Windows XP Service Pack 3

4.1.2 Plateforme logicielle 

Le choix de l’IDE adéquat est primordial pour le développement d’une application
d’entreprise.
 Nous avons choisi Microsoft Visual Studio 2008 : un environnement de développement
complet offrant beaucoup de fonctionnalités. Ce produit est destiné aux développeurs
professionnels autonomes ou aux petites équipes et leur permet de développer des
applications connectées performantes offrant des fonctionnalités utilisateur
révolutionnaires. Visual Studio 2008 a été conçu pour prendre en charge les projets de
développement à destination du Web, de Windows Vista, Windows Server 2008, Office
System 2007, SQL Server 2008 et des appareils Windows Mobile.

Grâce à Visual Studio 2008, les développeurs professionnels peuvent :

 Gagnez en productivité : Gestion des données plus efficace avec LINQ, possibilité de
cibler la plateforme .NET de la version 2.0 au 3.5, choix du langage parmi C#, VB, C++ ou
J#.
 Bénéficiez d'une meilleure gestion du cycle de vie des applications, meilleure
intégration entre les outils développeurs et designers.
 Compatibilité ascendante avec Microsoft Visual Studio 2005
 Version de mise à jour vers l'édition 2008 à partir d'une version 2005 existante

4.2 Interfaces Homme machine

4.2.1 Interfaces communes

Accueil : Cette interface présente dans la figure 4.1, est visible par tous les employés,
éventuellement par les clients qui pourront avoir diverses informations sur la résidence.
 FIG 4.1 Ecran accueil

Authentification : Cette interface permet de s’identifier. Elle dirige ensuite, selon le nom
d’utilisateur, à l’espace agent, administrateur ou réceptionniste.

FIG 4.2 Ecran authentification

 Pages de description de la résidence : Ces pages donnent des informations sur notre résidence.
Elles seront éventuellement consultables par les clients désirant avoir des informations sur le site.

FIG 4.3 Ecran description

4.2.2 Interfaces agent :

Critères de réservation : L’agent entre les différentes informations nécessaires à l’obtention

des chambres disponibles.
 FIG 4.4 Ecran réservation

Disponibilité selon critères de réservation : L’application communique avec la base de

données pour avoir les chambres disponibles répondant aux critères cités.
FIG 4.5 Ecran confirmation réservation
 Consultation de l’historique : L’agent obtient la liste des réservations effectuées à une
date données avec le client ayant effectué la réservation, l’agent ayant passé la réservation
et la chambre réservée.

FIG 4.6 Ecran historique

 Gérer les clients : L’agent a la possibilité de manipuler la table des clients et d’ainsi
ajouter, supprimer ou mettre à jour celle-ci.

FIG 4.7 Ecran clients

4.2.3 Interfaces réceptionniste

Gestion du ménage : Le réceptionniste sélectionne les femmes de ménage disponibles

pour la journée.

FIG 4.8 Ecran Ménages

Attribution des chambres aux femmes de ménage : A chaque femme de ménage est
attribué un ensemble de chambres selon le bloc, l’étage et enfin le numéro de chambre.

FIG 4.9 Ecran attribution ménages

4.2.4 Interfaces administrateur

Gérer les chambres : L’administrateur manipule les données de notre base de données plus
particulièrement les chambre et peut ainsi ajouter, supprimer ou mettre a jour des
chambres.

FIG 4.10 Ecran chambres

4.3 Problèmes rencontrés

Le long de ce travail, nous nous sommes retrouvés face à divers problèmes imprédictibles que nous
avons essayé de surmonter. Nous en citons :

- Difficulté à s’adapter à l’environnement de développement.

- Difficulté dans la connexion entre l’application et le serveur de base de données.
- Exécution du serveur très lente dans une machine qui ne permet pas de prendre en
compte des applications d’une telle importance.
- Difficulté dans l’initiation aux technologies .NET

Conclusion

Ainsi s’achève cette partie de réalisation dans laquelle nous avons mis en relief les différentes
interfaces liées à notre application ainsi que les interactions possibles avec le système. A travers ces
diagrammes ainsi que les imprime écran, nous avons présenté les différentes facettes de notre
application.
 Conclusion générale

Dans le présent rapport et dans le cadre du projet deux modules, nous avons réalisé une
application web dynamique de réservation de résidences qui intègre trois types
d’utilisateurs : les agents, les réceptionnistes et l’administrateur.

En fait les progrès vécus par l’économie mondiale rendent indisponible l’informatisation des
activités commerciales des entreprises, plus particulièrement des résidences.

Au cours de projet, nous avons réussi à concevoir et à implémenter une application web
ayant une architecture 3-tiers. Cette application est réalisée dans le but d’effectuer les
réservations et d’ordonnancer les ménages dans une résidence.

Tout au long du développement de cette application, nous avons acquis plusieurs

connaissances dont nous citons à titre d’exemple :

- L’initiation aux technologies offertes par .NET

- La manipulation du langage « Linq »
- La connaissance approfondie de l’architecture client serveur
- Administration des bases de données

Néanmoins, notre application présente quelques lacunes, citons à titre d’exemple l’absence
de traitement de quelques erreurs générées par l’application elle-même.

Pour conclure, nous avons essayé tout long de notre travail d’assurer l’efficacité de
traitements de l’information ainsi que la portabilité des données. Mais cette application
reste extensible. En effet, nous pouvons l’améliorer afin de la rendre accessible par les
clients et leur permettre d’effectuer une réservation moyennant une caution par carte
bancaire.

Bibliographie
[1]M.S.PLATT : Découvrir Microsoft .NET « Microsoft Press »

[2]G.JOHNSON, T.NORTHENP : Microsoft .NET Framework 2.0- Web-based client

Development »Microsoft Press »
Né tographie

[3] http://www.commentcamarche.net/contents/dotnet/dotnet-intro.php3 (visité le 08/04/2010)

[4] http://ditch.developpez.com/aspnet/introduction/tome1/html/ (visité le 29/03/2010)

[5] http://www.bd.enst.fr/~dombd/Cours/Applications/3tiers/index.html (visité le 08/04/2010)

[6] http://www.resalys.com/images/architecture.gif(visité le 09/04/2010)

[7]http://www.journaldunet.com/encyclopedie/definition/387/44/21/global_distribution_system_i_
gds_i.shtml (visité le 08/04/2010)

[8] http://www.materiel.net/ctl/Bureautique/43850-Visual_Studio_Professionnel_2008_MAJ_.html
(visité le 15/04/2010)