Embed Size (px)
Citation preview
1
RAPPORT DE PROJET
SITE WEB - DEV-FLY
JULIE NUGUET
2
TABLE DES MATIÈRES
Définitions / Abréviations .......................................................................................................................................................................... 3
Introduction ....................................................................................................................................................................................................... 3
Contexte ................................................................................................................................................................................................................ 4
Exigences .............................................................................................................................................................................................................. 4
Outils utilisés ..................................................................................................................................................................................................... 4
Base de données ............................................................................................................................................................................................... 6
Diagramme de cas d’utilisation ............................................................................................................................................................... 8
Maquettage des IHM ...................................................................................................................................................................................... 9
Diagrammes de séquence système : réservation d'un vol ..................................................................................................... 15
Architecture de l'application ................................................................................................................................................................. 16
Rendu .................................................................................................................................................................................................................. 20
Code source de l'application .................................................................................................................................................................. 24
Mise en ligne du site .................................................................................................................................................................................... 30
Conclusion ........................................................................................................................................................................................................ 30
Webographie ................................................................................................................................................................................................... 31
Annexes .............................................................................................................................................................................................................. 31
3
DÉFINITIONS / ABRÉVIATIONS
Cahier des charges : document fixant les modalités de réalisation d’un projet, en listant les besoins et exigences auxquels le prestataire doit se conformer. CamelCase : pratique qui consiste à relier des mots ensemble, en mettant une majuscule aux premières lettres de chaque mot. Diagramme de cas d'utilisation : en UML, diagramme fonctionnel permettant de donner une vision globale des fonctionnalités que le logiciel doit fournir. Diagramme de séquence système : en UML, représentation des échanges de messages entre les acteurs et le système selon un axe temporel. Dictionnaire des données : recense l'ensemble des données élémentaires (= non décomposables) nécessaires à la conception de la base de données. Expression régulière ou rationnelle : les expressions régulières ou « regex » permettent de trouver les chaînes de caractères correspondant à un modèle défini (le modèle est en fait une chaîne de caractères souvent appelée « motif »). IHM : acronyme utilisé pour désigner les Interfaces Homme / Machine, c’est-à-dire l’ensemble des moyens utilisés par l’homme pour communiquer avec une machine. Modèle Conceptuel de Données (MCD) : représentation graphique des informations de l'entreprise, telles qu'elles ont été recensées dans le dictionnaire des données. On parle également de modèle entité – association. Lorsque ces termes sont employés au sein du présent document, ils sont mentionnés sous cette forme.
INTRODUCTION
Dans le cadre du Titre Professionnel Développeur Logiciel, j'ai réalisé une application de gestion des vols pour une compagnie aérienne. Ce projet a été fait en groupe de 3 personnes. Après avoir réfléchi ensemble à notre objectif, nous avons décidé que chacun d'entre nous serait responsable d'une partie distincte de l'application, que nous avons scindée comme suit :
- réservation d'un vol, - espace client, - back-office.
Bien qu'ayant participé à tous les aspects de l'application, je me suis focalisée plus particulièrement sur la réservation des vols, que je présenterai plus en détails ici. Étant donné que le projet était un « exercice » (bien que réalisé dans un contexte professionnel, il ne concernait pas une réelle compagnie aérienne), nous avons décidé de nous imposer un contexte fictif. Ainsi,
4
nous avons réalisé en amont un cahier des charges avec des exigences que nous nous sommes efforcés de respecter. Le cahier des charges se trouve en annexe du présent rapport.
CONTEXTE
Nous sommes partis du principe que nous travaillions pour DEV-FLY, une filiale d'Air Greta France spécialisée dans le marché low-cost du transport de passagers. Jusqu’à présent, ils avaient recours au logiciel de la maison mère, et souhaitaient maintenant avoir leur propre application, afin d’avoir un outil personnalisé.
EXIGENCES
Il a été décidé que l'application serait un site web qui permet :
- la réservation d'un vol, pour un ou plusieurs passagers,
- la gestion d’un espace client, avec possibilité de consulter ses anciennes réservations,
- une partie back-office, permettant par exemple de visualiser les employés travaillant sur un vol
particulier.
Par ailleurs, la compagnie nous a fait part des remarques suivantes, dont nous avons dû tenir compte :
- sur chaque vol, on retrouve systématiquement 5 membres du personnel : 1 pilote, 1 copilote, et 3 stewards ou hôtesses.
- le prix d'un billet dépend du vol choisi et de l'âge du passager (les enfants de moins de 3 ans ne
payent que le prix de l'assurance, soit 50 €).
- les vols doivent avoir un numéro unique (ex : le Berne - Sydney du 02/03 n'a pas le même numéro que le Berne – Sydney du 26/03).
- les couleurs à utiliser pour le site doivent être celles de la compagnie : bleu et/ou blanc et/ou rouge.
- un client peut réserver pour plusieurs passagers (quelqu’un réserve pour son conjoint et ses enfants
par exemple). Ainsi, une réservation est associée à un seul client mais peut être reliée à plusieurs passagers.
OUTILS UTILISÉS
J'ai réalisé ce site en grande partie dans un environnement Linux (Debian et dérivées), qui offre un panel d'outils adaptés à la programmation. Certaines parties ont cependant été réalisées sous Windows 7, qui est le système d'exploitation utilisé sur mon lieu de formation.
5
Afin de mener à bien ce projet, j'ai utilisé :
- différents navigateurs web afin de vérifier la compatibilité
- le gestionnaire de versions Git, afin de garder un historique du travail produit, de faciliter le travail en groupe, et de gérer un backup des données
- Balsamiq pour réaliser la maquette du site
- WinDesign pour réaliser le MCD
- Dia, logiciel libre utilisé pour la création des diagrammes pour le cahier des charges
- Bootstrap, framework développé par Twitter, dont des éléments ont été intégrés au sein du site (le
carousel de la page d'accueil, les menus en haut du site...)
- et différents logiciels dédiés à l'écriture de code. Les navigateurs web utilisés :
- Firefox : navigateur libre de la fondation Mozilla. Un test complet a été réalisé sur la version 22 de ce navigateur. Le rendu est conforme à ce qui était attendu. Des tests plus succincts ont été effectués sur les versions précédentes, et se sont également révélés concluants.
- Chrome : navigateur développé par Google. Le site fonctionne parfaitement sur la version 28. Là
encore, des tests ont été effectués sur les versions précédentes, le rendu est identique et conforme aux attentes.
- Internet Explorer : navigateur développé par Microsoft, afin de vérifier la compatibilité (en effet, si ce navigateur souvent décrié par les développeurs voit sa part de marché décroître régulièrement, il est cependant toujours utilisé par ~30% de la population à l'heure actuelle [1] ). Nous avons fait en sorte que le site s'affiche correctement sur ce navigateur. J’ai réalisé un test complet sur la version 10, et des tests de compatibilité sur les versions antérieures pour m'assurer que le site fonctionnait correctement.
Concernant l'écriture du code, j'ai eu recours à :
- NetBeans, un environnement de développement intégré qui fonctionne aussi bien sous Windows que sous Linux
- Vim, éditeur de texte modal qui s'utilise directement dans la console sous Linux. Une fois pris en main, il permet de coder rapidement, et est également très personnalisable.
________________________________________________________________________________________ [1] https://fr.wikipedia.org/wiki/Parts_de_march%C3%A9_des_navigateurs_web
6
BASE DE DONNÉES
En premier lieu, nous avons réfléchi à la base de données. Nous avons commencé par lister toutes les données nécessaires à conserver. Voici le dictionnaire des données correspondant :
Nom Rubrique Commentaire Type Taille Domaine
numclient Clé primaire numérique 15
civilite alphanumérique 3 {"mme", "m"}
nom alphanumérique 50
prenom alphanumérique 50
adresse alphanumérique 100
codepostal alphanumérique 10
ville alphanumérique 20
pays alphanumérique 20
mail alphanumérique 80
telfixe Peut contenir un + alphanumérique 15
mobile Peut contenir un + alphanumérique 15
login Utilisé pour la connexion au site alphanumérique 20
password Sera chiffré alphanumérique 100
numemploye Clé primaire alphanumérique 5 ex. P0001 pour le 1er pilote
civilite alphanumérique 3 {"mme", "m"}
nom alphanumérique 50
prenom alphanumérique 50
adresse alphanumérique 100
codepostal alphanumérique 10
ville alphanumérique 20
pays alphanumérique 20
fonction Fonction au sein de la compagnie alphanumérique 10 {"pilote", "copilote", "hotesse", "steward"}
numpassager Clé primaire numérique 15
civilite alphanumérique 3
nom alphanumérique 50
prenom alphanumérique 50
datenaissance date
numplace Clé primaire numérique 15
prix flottant
7
numreserv Clé primaire – numéro de réservation
numérique 15
datereservation date
travailler_date date à laquelle un employé X travaille sur un vol Y
date
numvol Clé primaire alphanumérique 15
lieudep Lieu de départ du vol alphanumérique 50
lieuarriv Lieu d'arrivée du vol alphanumérique 50
dateheuredep Date et heure de départ du vol datetime
dateheurearrivee Date et heure d'arrivée du vol datetime
tarif Le tarif standard pour un passager adulte.
flottant
iduser Clé primaire (concerne les personnes qui ont accès au back office)
alphanumérique 5
statut alphanumérique 20 Ex : administrateur, directeur...
login Utilisé pour la connexion alphanumérique 20
password Sera chiffré alphanumérique 100
droits 0 = consultation / 1 = consultation et modification. (note : dans un premier temps, seule la partie « consultation » est prévue en production).
booléen 0 ou 1
À partir de ces données, nous avons réalisé le modèle conceptuel de données page suivante (représentation selon la méthode Merise).
8
On constate par exemple qu'une réservation n'est effectuée que par un seul client. En revanche, elle peut concerner plusieurs places, chacune ne pouvant être attribuée qu'à un seul passager. Remarque : certaines tables ne sont pas reliées aux autres, et n'apparaissent pas sur ce modèle. C'est le cas notamment de la table « user », dans laquelle sont renseignées les personnes qui ont accès au back-office. Le script de création de la structure de la base de données est visible en annexe du présent document.
DIAGRAMME DE CAS D’UTILISATION
La fonctionnalité de « réservation d’un vol » sur le site a d'abord été représentée schématiquement, à l'aide du diagramme de cas d'utilisation page suivante.
9
La relation d'extension, symbolisée par le mot clé « extend » indique qu'une réservation peut être faite après la recherche d'un vol. Pour réserver, le client doit impérativement être authentifié, comme le montre la relation d'inclusion sur le schéma (mot-clé « include »).
MAQUETTAGE DES IHM
Avant de commencer à coder, nous avons d'abord défini le résultat auquel nous souhaitions arriver. Nous avons défini le scénario de recherche basique d'un vol, pour lequel nous avons réalisé les IHM correspondantes. Ce travail a également permis de mettre en lumière les règles de gestion auxquelles il fallait penser lors de la phase de codage (colonne de droite ci-dessous). Ici, le cas d'un nouveau client est choisi pour illustrer le scénario de recherche d'un vol.
Scénarios IHM Règles de gestion
La personne arrive sur la page d’accueil et doit cliquer sur « bienvenue » afin d’entrer sur le site.
Image 1
La personne se rend sur la page de recherche et saisit les critères de recherche : ville de départ, ville d’arrivée, date de départ, nombre d’adultes et nombre d’enfants.
Image 2 Tous les champs doivent être renseignés et valides : la date doit être au format approprié et ne doit pas être antérieure à la date du jour. Les villes doivent correspondre aux destinations prévues par la compagnie. Les villes de départ et d’arrivée doivent être différentes. Le nombre d’adultes indiqué doit être numérique et supérieur ou égal à 1. Le nombre d’enfants indiqué doit être numérique et supérieur ou égal à 0.
La compagnie renvoie une page de résultats.
Image 3
10
L’utilisateur sélectionne un choix. Image 3 Le choix sélectionné doit correspondre à ce que la compagnie propose.
La compagnie envoie un formulaire d’inscription de(s) passager(s) : civilité, nom, prénom, date de naissance.
Image 4
L’utilisateur remplit le formulaire. Image 4 Tous les champs doivent être renseignés et valides : les dates doivent être au format approprié. La civilité doit être soit « Monsieur » soit « Madame ». Les noms et prénoms doivent être constitués de lettres. Au minimum un passager doit être majeur.
La compagnie envoie une fiche client à remplir pour inscription : civilité, nom, prénom, adresse, code postal, ville, pays, mail, tél fixe, mobile, identifiant, mot de passe.
Image 5
L’utilisateur remplit le formulaire. Image 5 Tous les champs doivent être renseignés et valides. La civilité doit être soit « Monsieur » soit « Madame ». Le nom et le prénom doivent être constitués de lettres. Les numéros de téléphone doivent comporter des chiffres exclusivement, et peuvent commencer par « + ». L’adresse e-mail doit être au format correct, sans espaces ni caractères spéciaux ([email protected]). Le login doit être alphanumérique, et ne doit pas être déjà existant dans la base de données. Le mot de passe doit être une chaîne de caractères.
La compagnie envoie une fiche de synthèse + le formulaire de paiement.
Image 6
Le client procède à la transaction. Image 6 Remarque : seul le paiement par carte bancaire est possible.
La compagnie génère et affiche le billet.
Image 7
Remarques:
- Si une valeur dans un des champs du formulaire n’est pas conforme aux attentes, le formulaire est retourné avec un message explicatif en en-tête.
- Tout au long de la procédure, le client a la possibilité à tout moment de revenir à l’accueil en
cliquant sur « Accueil » dans le menu.
11
Image 1
Sur la page d'accueil du site, on trouve un carousel dans lequel défilent des images illustrant des destinations proposées par la compagnie. Image 2
La page de recherche d'un vol est la première visible après avoir cliqué sur « bienvenue » (IHM précédente). Elle contient un formulaire à remplir avec les choix de l'utilisateur.
12
Image 3
La compagnie renvoie une liste de propositions, en fonction du trajet et de la date choisis. Les vols partant le jour souhaité sont affichés s'il y en a. À défaut, les vols ultérieurs à la date choisie sont proposés au client. Image 4
L'utilisateur renseigne les données sur les passagers. La date de naissance pourra influencer le prix du billet. Le nombre de passagers pour lesquels les informations sont attendues correspond aux nombres d'adultes et d'enfants préalablement renseignés.
13
Image 5
Ici l'utilisateur s'inscrit sur le site. Il pourrait s'identifier directement s'il possédait déjà un compte client.
14
Image 6
Un récapitulatif est affiché afin de permettre au client de vérifier l'exactitude des données avant de procéder au paiement.
Image 7
Après avoir procédé au règlement, l'utilisateur visualise les détails de son billet, avec la liste des passagers et les places qui leur sont attribuées.
15
DIAGRAMMES DE SÉQUENCE SYSTÈME : RÉSERVATION D'UN VOL
Des diagrammes de séquence système ont été réalisés avant de démarrer la phase de codage, afin d'être clairs sur la manière de gérer le processus de réservation d'un billet. J'ai fait ressortir différents cas :
1) Cas d’un nouveau client
On voit les échanges entre le client (à gauche) et la compagnie DEV-FLY (à droite). Le client indique des critères de voyage, la compagnie lui renvoie une liste de vols trouvés, il en sélectionne un, et ainsi de suite... Si le client n'a pas encore de compte chez DEV-FLY, on lui demandera de remplir un formulaire pour inscription.
2) Cas d’un client déjà enregistré Un client disposant déjà d’un compte ne remplira pas la fiche d’inscription. On distingue 2 cas :
a) le client est déjà connecté à son compte lors de la recherche du billet :
On saute tout simplement la partie «d'authentification ou d’inscription », car le client est déjà identifié.
16
b) Le client n’est pas connecté à son compte lors de la recherche du billet :
Le client va tout simplement renseigner ses login et password déjà existants lorsqu'il lui sera demandé de s'inscrire ou de s'identifier. Pour tous les cas présentés ci-dessus :
- si un vol a lieu le jour souhaité vers la destination choisie, celui-ci sera proposé au client.
- si aucun vol n'a lieu le jour souhaité vers la destination choisie, le client se verra proposer les vols suivants.
- si le nombre de passagers souhaité par le client est supérieur au nombre de places restantes dans
l'avion, le vol est considéré comme complet.
- si tous les vols susceptibles d'être proposés sont complets, le client est informé qu'aucun vol ne correspond à sa demande.
ARCHITECTURE DE L'APPLICATION
L'application a été réalisée en PHP5 orienté objet et construite selon le modèle MVC2. Le modèle MVC2 est un motif de conception (on emploie souvent la dénomination anglaise « design pattern »). Le principe du modèle MVC repose, comme ses initiales l'indiquent, sur la séparation entre les différents éléments du code :
- le Modèle (Model en anglais) concerne le cœur du métier. C'est lui qui va interagir avec la base de données, et traiter les données pour fournir de l'information aux contrôleurs.
- le Contrôleur (Controller en anglais) va diriger vers une page ou une autre en fonction des informations reçues.
- la Vue (View en anglais), comme son nom le laisse penser, concerne tout ce qui a trait à la présentation.
17
La spécificité du MVC « 2 » est l'utilisation d'un contrôleur frontal (on emploie très souvent la dénomination anglaise « front-controller »), qui est un point d'entrée unique dans l'application. De plus, chaque contrôleur correspond à une classe (ce qui n'est pas le cas avec le MVC « 1 »). Concernant l'application pour la société DEV-FLY, voici l'arborescence des fichiers constituant le projet : ├── conf
│ └── configuration.ini
├── controller
│ ├── AffichageClientController.php
│ ├── AffichageEmployeController.php
│ ├── AffichagePassagerController.php
│ ├── AffichagePassagersController.php
│ ├── AffichageReservationController.php
│ ├── AffichageVolController.php
│ ├── AffichageVolsController.php
│ ├── AuthAdminController.php
│ ├── AuthClientController.php
│ ├── BilletController.php
│ ├── ContactController.php
│ ├── CreationClientController.php
│ ├── DeconnexionController.php
│ ├── DetailsReservationController.php
│ ├── EnregistrementPassagersController.php
│ ├── ListeReservationsController.php
│ ├── PropositionsController.php
│ └── SyntheseController.php
├── dao
│ └── MysqlDao.php
├── entity
│ ├── Client.php
│ ├── Employe.php
│ ├── Passager.php
│ ├── Personne.php
│ ├── Place.php
│ ├── Reservation.php
│ ├── User.php
│ └── Vol.php
├── public
│ ├── css
│ │ ├── bootstrap.css
│ │ └── style.css
│ ├── images
│ │ ├── avions1.jpg
│ │ ├── img10.jpg
│ │ ├── img11.jpg
│ │ ├── img12.jpg
│ │ ├── img13.jpg
│ │ ├── img1.jpg
│ │ ├── img2.jpg
│ │ ├── img3.jpg
│ │ ├── img4.jpg
│ │ ├── img5.jpg
│ │ ├── img6.jpg
│ │ ├── img7.jpg
│ │ ├── img8.jpg
18
│ │ ├── img9.jpg
│ │ └── logo.jpg
│ ├── include
│ │ ├── footer.php
│ │ ├── formulaire_auth_admin.php
│ │ ├── formulaire_connexion_client.php
│ │ ├── formulaire_creation_client.php
│ │ ├── menu_bo.php
│ │ └── menu_front_office.php
│ ├── js
│ │ └── bootstrap.js
│ ├── accueil.php
│ ├── billet.php
│ ├── bo_choix_critere.php
│ ├── bo_client.php
│ ├── bo_employe.php
│ ├── bo_passager.php
│ ├── bo_passagers.php
│ ├── bo_reservation.php
│ ├── bo_vol.php
│ ├── bo_vols.php
│ ├── confirmation_inscription.php
│ ├── connexion_client.php
│ ├── contact.php
│ ├── enregistrement_passagers.php
│ ├── erreur_401.php
│ ├── erreur_500.php
│ ├── espace_client.php
│ ├── index.php
│ ├── la_compagnie.php
│ ├── propositions.php
│ ├── recherche.php
│ ├── retour_contact.php
│ └── synthese.php
├── test
│ ├── test_motdepassechiffre.php
│ └── test_MysqlDao.php
└── setup.php
On constate que les fichiers sont séparés dans différents dossiers :
- « dao », pour Data Access Object (= objet d’accès aux données). À l'intérieur se trouve le fichier MysqlDao.php dans lequel la classe « MysqlDao » contient des méthodes qui « attaquent » la base de données pour en extraire de l'information utilisable.
- « entity » est utilisé pour les objets métiers. Les différentes classes (Client, Passager, Vol...) vont permettre de créer au sein de l'application un ensemble d'objets partageant les mêmes méthodes et attributs. Par exemple, chaque vol possède un numéro, un lieu de départ, et un lieu d'arrivée.
- « controller », qui comme son nom l'indique, regroupe les contrôleurs utilisés. Ceux-ci font les
vérifications nécessaires et, en fonction de cela, renvoient vers une vue ou une autre. Par exemple, le contrôleur « PropositionsController » intervient après que l'utilisateur ait renseigné les données concernant le vol qu'il recherche (villes de départ et d'arrivée, date...). Le contrôleur va vérifier la saisie de l'utilisateur, et il peut notamment :
19
o renvoyer vers une vue contenant une liste des différents vols correspondant aux critères du client, s'il y en a.
o rediriger vers la page précédente, si le client a par exemple « omis » de préciser une ville
d'arrivée (un message lui demandera alors d'indiquer la destination choisie).
- « public » contient les différentes vues. Par exemple, le fichier propositions.php correspond à la vue évoquée précédemment. Les différents vols correspondant aux critères du client sont listés au sein d'un formulaire. Il doit en choisir un et valider.
« public » contient également :
o un sous-dossier « include » pour les portions de vues qui se répètent sur plusieurs pages
(elles sont alors « inclus » dans ces pages). C'est le cas par exemple du pied de page ou des menus.
o un sous-dossier « images », dans lequel sont stockées les images utilisées par l'application.
o un sous-dossier « css » contient le code css. On y trouve le fichier css de Bootstrap (pour
rappel, il s'agit du framework développé par Twitter qui offre un panel important de « briques » réutilisables au sein de notre propre site). Un second fichier (style.css) contient le style personnalisé que nous avons écrit « à la main » pour nos pages.
o un sous-dossier « js » contient le code JavaScript de Bootstrap dont nous avons intégré des
éléments au site (par exemple, le carousel de la page d'accueil).
o un fichier nommé .htaccess. Il permet de définir les règles de réécriture d'URL sur lesquelles l'application se base. Le principe est d'accéder aux pages via des URL « réécrites », plus propres (on a parfois recours à ces méthodes pour améliorer le référencement par exemple). À cet effet, on utilise les expressions régulières : on indique un motif, ainsi que la page vers laquelle on doit être renvoyé si l'URL correspond au motif.
Pour illustrer, prenons le code suivant :
Les parenthèses servent à capter un motif qui pourra être réutilisé dans la redéfinition de l'URL (ici, le $1 sera remplacé par le motif capté). L'expression régulière définie ici correspond à « une chaîne de lettres majuscules et/ou minuscules (qui sera captée) suivi d'un C majuscule ». Ex : BilletC La chaîne captée est « Billet ». On sera renvoyé vers l'URL indiquée, en remplaçant $1 par la chaîne captée, ce qui donnera : index.php?controller=BilletController&method=action (Le visiteur, lui, verra seulement la chaîne « BilletC » dans la barre d’adresse de son navigateur).
o le fichier index.php qui est le fameux point d'entrée dans l'application (front controller).
Lorsqu'on veut appeler une méthode d'un contrôleur, on arrivera toujours en premier sur index.php (cf la réécriture d'URL précédemment évoquée). C'est en récupérant les informations dans l'URL que le front controller « saura » vers quel contrôleur rediriger, et quelle méthode « activer ». Si on reprend l'exemple du paragraphe précédent, le contrôleur sera « BilletController » et la méthode « action ».
20
- « test » est un dossier qui n'est pas utile pour l'application finale. Il contient des tests qui ont été réalisés au fur et à mesure du développement, lors de la phase de programmation.
- « conf » contient un fichier configuration.ini. Celui-ci contient les informations de connexion à la
base de données (nom de la base, nom de l'utilisateur, mot de passe...). Enfin, on trouve à la racine un fichier nommé setup.php. Il permet de définir des constantes qui pourront être utilisées au sein de l'application. Par exemple, la constante VIEW correspond au chemin absolu vers le dossier « public » contenant les vues. Le fichier setup.php récupère les informations concernant la base de données contenues dans le fichier configuration.ini. Concernant les noms de fichiers, j'ai essayé de respecter une norme :
- les controllers sont en CamelCase avec la première lettre en majuscule (car ce sont des classes) - les vues ont des noms en minuscules séparés par des underscores.
RENDU
Cette section présente les différentes pages qui s'affichent, de l'arrivée du visiteur sur le site à la fin du processus de réservation. On peut remarquer que le rendu est conforme au maquettage des IHM présenté en amont.
On voit ici la page d'accueil du site, avec des images qui défilent et donnent envie de voyager. Ici, la photo illustre des vacances à la mer. En arrière-plan, une image représentant des avions est présente. On retrouve les couleurs de la compagnie : bleu, blanc, et rouge. Cette image reste fixe sur la totalité des pages du site. Seul le rectangle au premier plan voit son contenu changer. Les autres vues présentées ci-après se focalisent sur cette partie centrale. Tout d’abord, le visiteur doit indiquer ses critères pour le vol qu'il souhaite réserver (vue suivante).
21
On remarque un menu en haut, qui est présent sur chaque page lorsqu'on visite le site (sauf en cas de connexion à la partie « administrateur »). Une indication montre la section sur laquelle on se trouve (ici, « chercher un vol »). Pour la couleur de fond, nous sommes restés dans les tons bleus à la demande de la compagnie. Le bleu ciel s'est imposé, car il semble approprié pour une compagnie aérienne et n'est pas agressif à l’œil. À droite, une barre de défilement permet de faire défiler verticalement le contenu de la page. Elle est présente sur tout le site, dès lors que le contenu d'une page l'impose. On voit ici la même page, mais remplie par l'utilisateur : En cas d'erreur, un message indicatif s'affiche. Par exemple ici, le visiteur souhaite voyager à une date passée : il doit donc corriger son erreur. Les champs du formulaire sont déjà préremplis pour lui éviter une ressaisie. Pour l'exemple, le visiteur corrige la date de départ souhaitée à une date ultérieure :
22
Le visiteur arrive ensuite sur une page de résultats : Si un vol avait été trouvé à la date de départ souhaitée (05/12/2013), on lui aurait proposé uniquement ce vol à cette date. À défaut, comme ici, on lui propose les vols suivants. Les prix indiqués dépendent des nombres d'adultes et d'enfants renseignés à la vue précédente. L'utilisateur doit sélectionner un vol avant de poursuivre. Ici, il a tenté de valider sans avoir choisi de vol au préalable, il y a donc un message qui s'affiche en rouge lui demandant de faire un choix. Pour l'exemple, le visiteur choisi finalement le vol N°DF5 :
On lui demande ensuite d'inscrire les passagers : Ici, 2 passagers sont renseignées car le client a indiqué qu'1 adulte + 1 enfant participeraient au vol. À cette étape, les dates de naissance vont être vérifiées. Il faut au minimum qu'une personne majeure voyage (la compagnie ne propose pas de service d'encadrement pour les mineurs voyageant seuls). Par ailleurs, l'âge des passagers à la date du vol est calculé, afin de déterminer le prix définitif du billet. Sur l'écran suivant, l'utilisateur peut :
- se connecter s'il possède déjà un compte
- s'enregistrer pour se créer un compte.
23
Lors de la phase d'enregistrement, plusieurs vérifications sont faites : les champs doivent être au format valide, et le client ne doit pas choisir un login déjà utilisé par quelqu'un d'autre. On vérifie aussi que le client ne modifie pas le code HTML pour indiquer une civilité farfelue au lieu de « Monsieur » ou « Madame ». On arrive ensuite sur une page récapitulative : Ici, le prix à payer pour le billet est de 1522€, ce qui est conforme à ce qui était prévu : un adulte + un enfant de moins de 3 ans (à la date du vol !). Si jamais le client avait finalement renseigné 2 adultes, le prix final indiqué sur cette vue serait différent du prix indicatif donné initialement. Pour finir, le client obtient un récapitulatif de son billet : On constate que le prix pour le passager « enfant » n'est bien que de 50 € (soit uniquement l'assurance).
24
CODE SOURCE DE L'APPLICATION
Voici quelques extraits du code relatif au processus de réservation décrit précédemment. J'ai fait en sorte de commenter tout le code que j'ai produit, afin de faciliter sa compréhension par toute personne ayant à le consulter. Avant de proposer des vols à l'utilisateur, des vérifications sont effectuées, par exemple :
$jour, $mois, $annee ont été récupérées depuis le formulaire. $datedujour est un objet DateTime, auquel va être comparé la date de départ souhaitée, préalablement mise également sous forme d'objet DateTime. $messages[] correspond à un tableau de messages d'erreur qui seront affichées au client le cas échéant. On va d'ailleurs l'utiliser pour savoir si le client doit être ramené sur le formulaire de recherche (= si le tableau contient des erreurs, autrement dit s'il n'est pas vide), ou si on peut appeler la méthode de recherche d'un vol.
On initialise ici un nouvel objet MysqlDao que l'on nomme $dao. On appelle sa méthode getPropositions(), qui retourne un tableau d'objets Vol. Voici une requête SQL utilisée dans cette méthode :
On cherche les vols circulant à la date demandée (passée en paramètre de la méthode sous forme d'objet DateTime).
25
DATE_FORMAT permet de déterminer un format pour la date, ici jour/mois/année heures:minutes. Il est important de vérifier que les vols proposés au client ne sont pas complets ! On doit vérifier que le nombre de places libres dans l'avion est supérieur ou égal au nombre de places requises par le client. Pour connaître le nombre de places libres : 1) on récupère le nombre de places total dans l'avion, qui est en fait une constante, car tous les avions de la compagnie ont le même nombre de places. Constante définie dans la classe Vol :
Utilisation de la constante au sein de la méthode getPropositions() :
2) on compte le nombre de places déjà réservées avec « count », que l'on retranche du nombre précédent. Si aucune place n'est réservée (cf « ifnull »), on retranche zéro. On remarque l'utilisation de «:datedepart » ou «:villearrivee ». Cela est dû à l'utilisation de requêtes préparées. Si on exécutait les requêtes directement, on courrait le risque d'une injection SQL de la part d'un utilisateur malveillant (cela consiste à exploiter une faille de sécurité, en interagissant avec la base de données). Avec les requêtes préparées, le code que l'on tenterait d'injecter ne serait pas interprété. Pour cela, on prépare d'abord la requête (mot-clé « prepare »), puis on lie les paramètres, par exemple ici à l'aide de bindParam :
(...) Enfin, on exécute la requête :
Les vols trouvés sont récupérés sous forme d'un tableau d'objets Vol. Ils sont ensuite affichés sur la vue (propositions.php) :
26
On utilise un « foreach » pour parcourir le tableau d'objets. foreach($vols as $vol) va permettre d’interagir sur chaque objet (qu'on nommera $vol) contenu dans la tableau d'objet $vols. On peut donc appeler les méthodes sur chaque objet (autrement dit à chaque passage dans la boucle). Par exemple, $vol->getNumVol() permet de récupérer le numéro de vol. On utilise la méthode statique createFromFormat de la classe DateTime (d'où les « :: ») pour indiquer dans quel format se trouve la date à partir de laquelle on souhaite créer un objet DateTime. Une fois l'objet créé, on peut appeler les méthodes dessus, par exemple ici « format ». Le tout est mis dans un formulaire (on voit la balise HTML « form ») : l'utilisateur devra en effet sélectionner un vol parmi ceux proposés. C'est le contenu de l'attribut « value » (donc le numéro de vol) qui sera récupéré via la méthode POST. L'attribut « action » permet de spécifier la page qui fera le traitement. Ici, on a « /EnregistrementPassagersC ». Pour rappel, cela correspond à la règle de réécriture suivante définie dans le .htaccess :
Autrement dit, la page qui traitera les données en réalité est le controller « EnregistrementPassagersController » dont on appelle la méthode « action ». Lors de la phase d'enregistrement des passagers, on doit vérifier l'âge des personnes : 1) il faut s'assurer qu'au minimum une personne majeure voyage. 2) il faut voir si la personne a plus ou moins de 3 ans, à la date du vol, car cela détermine le prix du billet. On va faire appel pour cela à 2 méthodes dans MysqlDao :
On utilise des objets DateTime qu'on initialise en passant en paramètre des dates au format ISO (AAAA-MM-JJ) : la date de naissance du passager à tester d'une part, et la date du vol d'autre part. On récupère ensuite l'intervalle entre les 2 dates grâce à « diff », qui renvoie un objet de type DateInterval qu'on nomme $interval. $interval->format('%a') permet de récupérer un nombre de jours, que l'on compare à 365 * 18 (soit 18 ans). La fonction retourne un booléen (true si la personne est majeure à la date du vol).
27
La seconde méthode est basée sur le même principe, mais vérifie si la personne a plus de 3 ans (autrement dit, si elle paye plein tarif).
L'âge de la personne (en jours, à la date du vol) est comparé à 365 * 3. Là encore, un booléen est renvoyé (true si la personne paye plein tarif). Ces 2 méthodes du dao sont appelées dans le controller « EnregistrementPassagersController » :
On fait le test autant de fois qu'il y a de passagers : on entre dans la boucle while tant que $i est inférieur au nombre de passagers en session, et on incrémente $i de 1 à chaque passage dans la boucle. En fonction de l'âge trouvé, on incrémente le nombre « d'adultes » (+ de 3 ans) ou le nombre d'enfants, que l'on stocke en session. On vérifie également la présence d'un « vrai » adulte (+ de 18 ans). On commence par initialiser le booléen $un_vrai_adulte_present à false. On le passe à true dès lors que $dao->estMajeur renvoie vrai. Après l'enregistrement des passagers, on regarde si le client est connecté.
28
Le controller va, avec la fonction « header », renvoyer sur :
- la page de synthèse si le client est déjà connecté
- la page de connexion dans le cas contraire. Au préalable, on enregistre en session la « page sur laquelle on devra aller » une fois la connexion effectuée. Cela permet de ne pas perdre les informations sur la réservation en cours.
Lorsque le client va s'authentifier, on aura recours à la méthode clientLogin() du dao :
On recherche le login qui correspond aux login et password renseignés. S'il y a une correspondance, un tableau contenant le login et le mot de passe (chiffré) est renvoyé. On a recours là aussi à une requête préparée pour se protéger des injections SQL. J'ai choisi de chiffrer les mots de passe pour plus de sécurité. J'utilise pour cela la fonction « crypt » avec l’algorithme de hachage « sha256 ». L'emploi d'un grain de sel permet de compliquer le déchiffrage de la chaîne. Une fois le client connecté, si tout s'est bien passé, il visualise la page récapitulant sa réservation. On a recours à nouveau à un foreach pour afficher les informations sur chaque passager.
29
On ouvre la balise HTML <ul>, pour unordered list = liste non ordonnée. À l'intérieur, on boucle sur chaque passager trouvé que l'on va lister (balise <li>). À chaque tour de boucle, on agit sur l'objet Passager $passager qui se trouve dans le tableau de Passagers en session. On appelle dessus les méthodes getNom() et getPrenom() pour récupérer ses nom et prénom. Pour la date de naissance, on utilise un objet DateTime sur lequel on appelle « format('d/m/Y') », afin d'afficher la date dans un format français (JJ/MM/AAAA). Pour finir, une fois le paiement et les vérifications nécessaires effectués, le client aura un aperçu de son billet sous forme de tableau (balise <table>). Hormis la ligne de titres, chaque ligne (<tr>) correspond à un passager. On utilise htmlentities pour convertir les caractères en entités HTML : c'est une sécurité, car les informations affichées sur cette page proviennent de la base de données. Si un script avait été inséré dans la base de données pour une raison ou une autre, il ne serait pas interprété, grâce à cette protection. On peut remarquer que le tout se trouve dans une balise <div> avec l'id=''billet''. Cela sert uniquement pour définir le style. Voici un extrait du fichier style.css :
Ce style s'applique au tableau à l'intérieur de l'id billet. On définit sa couleur de fond, sa taille, son positionnement par rapport à l'élément parent. De plus, le texte sera centré.
30
MISE EN LIGNE DU SITE
J'ai choisi d'héberger le site chez moi, sur mon propre serveur (tournant sous Debian Wheezy), largement suffisant pour un site qui concerne une compagnie fictive, n'ayant donc pas vocation à accueillir des milliers de visiteurs simultanément... Pour que le site fonctionne correctement, j'ai configuré un hôte virtuel avec Apache2, en autorisant la réécriture d'URL (module « rewrite »).
CONCLUSION
La réalisation de ce site web est un projet intéressant. Cela m’a permis de mettre en application les connaissances théoriques enseignées en cours, pour obtenir un résultat concret. J’ai même été incitée à aller plus loin que le cours, et à parcourir la toile pour enrichir mes connaissances en programmation, afin d’optimiser mon site. Le résultat est concluant, les exigences définies dans le cahier des charges ont été respectées, le rendu obtenu est conforme à ce qui était attendu. Le site pourrait encore être amélioré, on pourrait implémenter des fonctionnalités supplémentaires, telles que :
- l’auto-complétion des villes de départ et d'arrivée depuis une liste d'aéroports définie,
- la réservation d’un billet aller-retour, avec une réduction qui s'appliquerait dans ce cas,
- la possibilité pour un client de récupérer son mot de passe en cas de perte,
- un système de points de fidélité qui donnerait droit à des réductions. Concernant un aspect plus technique, on pourrait :
- rendre le site pleinement responsive (avoir le même confort de navigation quels que soient l'appareil et l'écran),
- harmoniser davantage le code : par exemple, faire en sorte que les contrôleurs incluent systématiquement les vues, au lieu de rediriger parfois dessus,
- ajouter du JavaScript, pour la vérification des formulaires par exemple. Il pourrait faire des tests préliminaires pour s'assurer côté client que les informations sont correctement rentrées. Les mêmes tests seront toujours effectués côté serveur, mais étant donné que la plupart des utilisateurs n'ont pas désactivé le JavaScript, cela économiserait le renvoi d'une page.
Ce site n'est pas parfait, mais il s'agit d'une bonne première expérience, qui marque le début d’une longue série de sites web que je serai amenée à réaliser...
31
WEBOGRAPHIE
J'ai consulté différents sites web pour m'aider à réaliser le mien, parmi lesquels : PHP.net, le site de référence sur le langage PHP http://php.net Developpez.com, qui offre des réponses sur des questions de programmation http://www.developpez.com Wikipédia, pour des informations diverses, sur l'UML par exemple http://fr.wikipedia.org Le site de Bootstrap, en anglais http://twitter.github.io/bootstrap
ANNEXES
Vous trouverez en annexes : - le script de création des tables de la base de données, - la copie du cahier des charges sur laquelle l’application se base.
1 ) Voici le script de création des différentes tables de la base de données (structure uniquement) : -- -- Base de données: `DEVFLY` -- -- -------------------------------------------------------- -- -- Structure de la table `client` -- CREATE TABLE IF NOT EXISTS `client` ( `numclient` int(15) NOT NULL AUTO_INCREMENT, `civilite` varchar(3) DEFAULT NULL, `nom` varchar(50) DEFAULT NULL, `prenom` varchar(50) DEFAULT NULL, `adresse` varchar(100) DEFAULT NULL, `codepostal` varchar(10) DEFAULT NULL, `ville` varchar(20) DEFAULT NULL, `pays` varchar(20) DEFAULT NULL, `mail` varchar(80) DEFAULT NULL, `telfixe` varchar(15) DEFAULT NULL, `mobile` varchar(15) DEFAULT NULL, `login` varchar(20) DEFAULT NULL, `password` varchar(100) DEFAULT NULL, PRIMARY KEY (`numclient`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -------------------------------------------------------- --
32
-- Structure de la table `contact` -- CREATE TABLE IF NOT EXISTS `contact` ( `id` int(20) unsigned NOT NULL AUTO_INCREMENT, `nom` varchar(50) NOT NULL, `prenom` varchar(50) NOT NULL, `mail` varchar(80) NOT NULL, `sujet` varchar(100) NOT NULL, `telephone` varchar(15) NOT NULL, `message` text NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -------------------------------------------------------- -- -- Structure de la table `destination` -- CREATE TABLE IF NOT EXISTS `destination` ( `codeaeroport` varchar(3) NOT NULL, `ville` varchar(50) NOT NULL, `pays` varchar(50) NOT NULL, PRIMARY KEY (`codeaeroport`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -------------------------------------------------------- -- -- Structure de la table `employe` -- CREATE TABLE IF NOT EXISTS `employe` ( `numemploye` varchar(5) NOT NULL, `civilite` varchar(3) NOT NULL, `nom` varchar(50) NOT NULL, `prenom` varchar(50) NOT NULL, `adresse` varchar(100) NOT NULL, `codepostal` varchar(10) NOT NULL, `ville` varchar(20) NOT NULL, `pays` varchar(20) NOT NULL, `fonction` varchar(10) NOT NULL, PRIMARY KEY (`numemploye`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -------------------------------------------------------- -- -- Structure de la table `passager` -- CREATE TABLE IF NOT EXISTS `passager` ( `numpassager` int(15) NOT NULL AUTO_INCREMENT, `civilite` varchar(3) NOT NULL, `nom` varchar(50) NOT NULL, `prenom` varchar(50) NOT NULL, `datenaissance` date NOT NULL, PRIMARY KEY (`numpassager`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- --------------------------------------------------------
33
-- -- Structure de la table `place` -- CREATE TABLE IF NOT EXISTS `place` ( `numplace` int(15) NOT NULL AUTO_INCREMENT, `numpassager` int(15) NOT NULL, `numvol` varchar(15) NOT NULL, `numreservation` int(15) NOT NULL, `prix` float NOT NULL, PRIMARY KEY (`numplace`), KEY `numreservation` (`numreservation`), KEY `numvol` (`numvol`), KEY `numpassager` (`numpassager`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -------------------------------------------------------- -- -- Structure de la table `reservation` -- CREATE TABLE IF NOT EXISTS `reservation` ( `numreserv` int(15) NOT NULL AUTO_INCREMENT, `datereserv` date NOT NULL, `numclient` int(15) NOT NULL, PRIMARY KEY (`numreserv`), KEY `numclient` (`numclient`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -------------------------------------------------------- -- -- Structure de la table `travailler` -- CREATE TABLE IF NOT EXISTS `travailler` ( `vol` varchar(15) NOT NULL, `pilote` varchar(5) NOT NULL, `copilote` varchar(5) NOT NULL, `hotesse_steward1` varchar(5) NOT NULL, `hotesse_steward2` varchar(5) NOT NULL, `hotesse_steward3` varchar(5) NOT NULL, `date` date NOT NULL, KEY `vol` (`vol`), KEY `pilote` (`pilote`), KEY `co-pilote` (`copilote`), KEY `hotess/stewart1` (`hotesse_steward1`), KEY `hotess/stewart2` (`hotesse_steward2`), KEY `hotess/stewart3` (`hotesse_steward3`), ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -------------------------------------------------------- -- -- Structure de la table `user` -- CREATE TABLE IF NOT EXISTS `user` ( `id` varchar(5) NOT NULL, `statut` varchar(20) NOT NULL, `login` varchar(20) NOT NULL, `password` varchar(100) NOT NULL,
34
`droits` tinyint(1) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -------------------------------------------------------- -- -- Structure de la table `vol` -- CREATE TABLE IF NOT EXISTS `vol` ( `numvol` varchar(15) NOT NULL, `lieudep` varchar(50) NOT NULL, `lieuarriv` varchar(50) NOT NULL, `dateheuredep` datetime NOT NULL, `dateheurearrivee` datetime NOT NULL, `tarif` float NOT NULL, PRIMARY KEY (`numvol`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -- Contraintes pour les tables exportées -- -- -- Contraintes pour la table `place` -- ALTER TABLE `place` ADD CONSTRAINT `place_ibfk_4` FOREIGN KEY (`numpassager`) REFERENCES `passager` (`numpassager`) ON DELETE CASCADE ON UPDATE CASCADE, ADD CONSTRAINT `place_ibfk_5` FOREIGN KEY (`numvol`) REFERENCES `vol` (`numvol`) ON DELETE CASCADE ON UPDATE CASCADE, ADD CONSTRAINT `place_ibfk_6` FOREIGN KEY (`numreservation`) REFERENCES `reservation` (`numreserv`) ON DELETE CASCADE ON UPDATE CASCADE; -- -- Contraintes pour la table `reservation` -- ALTER TABLE `reservation` ADD CONSTRAINT `reservation_ibfk_1` FOREIGN KEY (`numclient`) REFERENCES `client` (`numclient`) ON DELETE CASCADE ON UPDATE CASCADE; -- -- Contraintes pour la table `travailler` -- ALTER TABLE `travailler` ADD CONSTRAINT `travailler_ibfk_10` FOREIGN KEY (`hotesse_steward3`) REFERENCES `employe` (`numemploye`) ON DELETE CASCADE ON UPDATE CASCADE, ADD CONSTRAINT `travailler_ibfk_11` FOREIGN KEY (`vol`) REFERENCES `vol` (`numvol`) ON DELETE CASCADE ON UPDATE CASCADE, ADD CONSTRAINT `travailler_ibfk_2` FOREIGN KEY (`pilote`) REFERENCES `employe` (`numemploye`) ON DELETE CASCADE ON UPDATE CASCADE, ADD CONSTRAINT `travailler_ibfk_7` FOREIGN KEY (`copilote`) REFERENCES `employe` (`numemploye`) ON DELETE CASCADE ON UPDATE CASCADE, ADD CONSTRAINT `travailler_ibfk_8` FOREIGN KEY (`hotesse_steward1`) REFERENCES `employe` (`numemploye`) ON DELETE CASCADE ON UPDATE CASCADE, ADD CONSTRAINT `travailler_ibfk_9` FOREIGN KEY (`hotesse_steward2`) REFERENCES `employe` (`numemploye`) ON DELETE CASCADE ON UPDATE CASCADE;
2) Vous trouverez, page suivante, le cahier des charges du projet :
35
36
Sommaire
Contexte ___________________________________________________________________________ 37
Objectif ____________________________________________________________________________ 37
Contraintes _________________________________________________________________________ 37
Scénario de recherche d’un vol _________________________________________________________ 38
Réservation d’un billet ________________________________________________________________ 46
Cas d’un nouveau client ____________________________________________________________________ 46
Cas d’un client déjà enregistré _______________________________________________________________ 47
Espace client ________________________________________________________________________ 48
Back-office _________________________________________________________________________ 48
Recherche par vol _________________________________________________________________________ 49
Recherche par passager ____________________________________________________________________ 49
Recherche par employé ____________________________________________________________________ 50
Recherche par réservation __________________________________________________________________ 50
Recherche par client _______________________________________________________________________ 51
Cas d’une recherche par N° de vol ____________________________________________________________ 52
Cas d’une recherche par N° de passager _______________________________________________________ 53
Cas d’une recherche par N° d’employé ________________________________________________________ 54
Cas d’une recherche par N° de réservation _____________________________________________________ 56
Cas d’une recherche par N° de client __________________________________________________________ 58
Modèle Conceptuel de Données ________________________________________________________ 59
37
CAHIER DES CHARGES
PROJET DEV-FLY
Contexte DEV-FLY est une filiale d'Air Greta France créée en décembre 2012. Elle est spécialisée dans le marché
low-cost du transport de passagers. Implantée à Paris, elle emploie 978 salariés. Sa flotte est constituée de
126 avions Airfly E321 de 170 places qui desservent 42 destinations, une fois par semaine.
Jusqu’à maintenant, Air Greta France ne gérait pas les vols low-costs. C’est pour se faire une place sur ce
marché porteur qu’elle a décidé de créer DEV-FLY. En effet, les vols low-costs devraient s’accroître de
50% d’ici 2020, et Air Greta France souhaite prendre part à cette croissance.
Objectif Jusqu’à présent, la filiale DEV-FLY avait recours aux logiciels de sa maison-mère. Aujourd’hui, elle
souhaite avoir son propre système d’information, afin d’avoir un outil personnalisé, sur lequel de
nouvelles fonctionnalités pourraient facilement se greffer.
L’application devra couvrir :
- la possibilité de consulter et réserver des vols, pour 1 ou plusieurs passagers
- la gestion d’un espace client (avec login et mot de passe)
- des fonctionnalités en back-office : visualisation détaillée des passagers, des vols, des
réservations, des clients et des employés. Chaque élément renvoie vers d’autres informations.
Ainsi par exemple, la description d’un vol contient les différents employés qui y travaillent. Un
clic sur l’identifiant d’un employé amène à la page détaillée sur cet employé, etc.
Le tout prendra la forme d’un site web.
Remarques :
- La gestion des bagages n’est pas prise en compte (chaque voyageur a droit à un bagage de 23kg en soute
et à un bagage à main de 10kg maximum, inclus dans le prix du billet – seule exception : les enfants de
moins de 2 ans n’ont droit qu’au bagage à main).
- Sur un vol, on retrouve systématiquement 5 membres du personnel : 1 pilote, 1 copilote, et 3 stewards
ou hôtesses.
- L'accès au back-office sera protégé par un login et un mot de passe individuels, qui seront directement
délivrés aux personnes concernées par l'administrateur de la base de données.
- Le prix d'un billet dépend du vol choisi et de l'âge du passager (les enfants de moins de 3 ans ne payent
que le prix de l'assurance, soit 50 €).
- Un vol a un numéro unique (ex : le Paris - Tunis du 02/03 n'aura pas le même numéro que le Paris –
Tunis du 26/03).
Contraintes - Seulement 3 personnes dédiées au projet.
- L’application doit avoir un temps de réponse de 2 secondes maximum avant d’afficher un résultat.
- Un élément de la charte graphique de la société doit être respecté : une référence aux couleurs
bleu, blanc, et rouge, doit être faite.
- Le projet doit être terminé dans un délai de 2 mois à compter de l'approbation du cahier des
charges par le comité de pilotage.
- Un client peut réserver pour plusieurs passagers (quelqu’un réserve pour son conjoint et ses
enfants par exemple). Ainsi, une réservation est associée à un seul client mais peut être reliée à
plusieurs passagers.
38
Scénario de recherche d’un vol Ici, le cas d’un nouveau client est choisi pour illustrer ce scénario.
Scénarios IHM Règles de gestion
La personne arrive sur la page
d’accueil et doit cliquer sur
« bienvenue » afin d’entrer sur le
site.
Image 1
La personne se rend sur la page de
recherche et saisit les critères de
recherche : ville de départ, ville
d’arrivée, date de départ, nombre
d’adultes et nombre d’enfants.
Image 2 Tous les champs doivent être
renseignés et valides : la date doit
être au format approprié et ne doit
pas être antérieure à la date du jour.
Les villes doivent correspondre aux
destinations prévues par la
compagnie. Les villes de départ et
d’arrivée doivent être différentes. Le
nombre d’adultes indiqué doit être
numérique et supérieur ou égal à 1.
Le nombre d’enfants indiqué doit
être numérique et supérieur ou égal à
0.
La compagnie renvoie une page
de résultats.
Image 3
L’utilisateur sélectionne un choix. Image 3 Le choix sélectionné doit
correspondre à ce que la compagnie
propose.
La compagnie envoie un
formulaire d’inscription de(s)
passager(s) : civilité, nom,
prénom, date de naissance.
Image 4
L’utilisateur remplit le formulaire. Image 4 Tous les champs doivent être
renseignés et valides : les dates
doivent être au format approprié. La
civilité doit être soit « Monsieur »
soit « Madame ». Les noms et
prénoms doivent être constitués de
lettres. Au minimum un passager doit
être majeur.
La compagnie envoie une fiche
client à remplir pour inscription :
civilité, nom, prénom, adresse,
code postal, ville, pays, mail, tél
fixe, mobile, identifiant, mot de
passe.
Image 5
L’utilisateur remplit le formulaire. Image 5 Tous les champs doivent être
renseignés et valides. La civilité doit
être soit « Monsieur » soit
« Madame ». Les noms et prénoms
doivent être constitués de lettres. Les
numéros de téléphone doivent
comporter des chiffres
exclusivement, et peuvent
commencer par « + ». L’adresse e-
39
mail doit être au format correct, sans
espaces ni caractères spéciaux
([email protected]). Le login doit être
alphanumérique, et ne doit pas être
déjà existant dans la base de données.
Le mot de passe doit être une chaîne
de caractères.
La compagnie envoie une fiche de
synthèse + le formulaire de
paiement.
Image 6
Le client procède à la transaction. Image 6 Remarque : seul le paiement par carte
bancaire est possible.
La compagnie génère et affiche le
billet.
Image 7
Remarques:
- si une valeur dans un des champs du formulaire n’est pas conforme aux attentes, le formulaire est
retourné avec un message explicatif en en-tête.
- Tout au long de la procédure, le client a la possibilité à tout moment de revenir à l’accueil en
cliquant sur « Accueil » dans le menu. Image 1
40
Image 2
41
Image 3
42
Image 4
43
Image 5
44
Image 6
45
Image 7
46
Réservation d’un billet
La fonctionnalité de « réservation » sur le site par un client est résumée ici au moyen d'un diagramme de
cas d'utilisation :
Pour réserver un billet, le processus sera le suivant :
Cas d’un nouveau client
47
Cas d’un client déjà enregistré Un client disposant déjà d’un compte ne remplira pas la fiche d’inscription.
On distingue 2 cas :
a) le client est déjà connecté à son compte lors de la recherche du billet :
b) Le client n’est pas connecté à son compte lors de la recherche du billet :
Pour tous les cas présentés ci-dessus :
- si un vol a lieu le jour souhaité vers la destination choisie, celui-ci sera proposé au client.
- si aucun vol n'a lieu le jour souhaité vers la destination choisie, le client se verra proposer les vols
suivants.
- si le nombre de passagers souhaité par le client est supérieur au nombre de places restantes dans l'avion,
le vol est considéré comme complet.
- si tous les vols susceptibles d'être proposés sont complets, le client est informé qu'aucun vol ne
correspond à sa demande.
48
Espace client Les différentes opérations dans l’espace client sont :
Dans le cas d’une modification de la réservation, le client est informé dès le début que sa réservation
précédente sera annulée, il doit l'accepter avant de poursuivre.
Back-office Les employés de la compagnie qui ont accès au back-office peuvent effectuer des recherches
multicritères, pour retrouver des informations.
Ci-dessous le diagramme d’activités système symbolisant les différentes options :
Voici les IHM montrant les différentes possibilités de recherche (page suivante):
49
Recherche par vol
Recherche par passager
50
Recherche par employé
Recherche par réservation
51
Recherche par client
Selon le critère choisi, le résultat affiché à l’écran sera différent (page suivante).
52
Cas d’une recherche par N° de vol
53
Cas d’une recherche par N° de passager
54
Cas d’une recherche par N° d’employé
55
56
Cas d’une recherche par N° de réservation
57
58
Cas d’une recherche par N° de client
59
Modèle Conceptuel de Données
L’application se base sur le modèle de données suivant (ici, représentation selon la méthode Merise) :
Remarque : on utilise également une table « user », dans laquelle sont renseignées les personnes qui ont
accès au back-office en consultation. La table contient un champ « droit » (booléen), ce qui pourra
permettre à terme de distinguer les personnes qui ont uniquement le droit de consultation de celles qui ont
également le droit de modification. Dans un premier temps, seule la partie « consultation » est prévue en
production.
