Ministère de l’Enseignement supérieur, de la Recherche Scientifique et de la Techno Université de la Manouba Ecole Nationale des Sciences de l’Informat Rapport Projet deux Modules Développement d’une application web dynamique gestion des réservations et des occupations résidences de longue durée Encadré par : Docteur BEN HADJ ALOUANE Nejib
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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,
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)