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 desré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 quepour 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, la gestion des ménages constitue aussi une activité complexe dont la gestion provoque souventune 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. Nous 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.2Historique 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ésentesAprè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

Logiciel en ligne

Accessibilité partout depuis le web grâce à un accès sécurisé par nom d'utilisateur et mot de passe. L'agent récupère instantanément les

réservations effectuées sur le web par les autres agents, et en temps réel

Entièrement

paramétrable nom, couleurs, styles, police et logo de la résidence, langue d'utilisation,

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.

Gestion grille tarifaire avancée

- 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

tarifaire.- Lit supplémentaire

- Tarifs des différents régimes: petit-déjeuner, demi-pension, pension complète

Réservations et Facturation

Suivi de la réservation jusqu'à la facturation. Possibilité de rajouter 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

des durées de séjour

Possibilité de modifier les jours d'arrivée autorisés et les durées de séjours

minimum par chambre, par type et sur une période donnée

FIG. 1.1 FONCTIONS 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 FRAMEWORK .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 fonctionnelsUn 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 fonctionnelsUn 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’utilisationLe 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’administrateurLa 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éesDans 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’applicationLe 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érielleCe 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)