TD N°1 - EXERCICE N°1

PROJET de PROGRAMMATION EVENEMENTIELLE Guichet de réservation de voyages en train
SOMMAIRE 1°) Introduction 3
1.1°) Objectif du projet 3
1.2°) Hypothèses de départ 3
1.2.1°) Application 3
1.2.2°) Base de données 3
1.3°) Différentes solutions possibles 3
1.3.1°) Solutions au niveau de la gestion de l'Application 3
1.3.2°) Solutions au niveau de l'application (ou partie d'app.) destinée
aux employés 4
1.3.3°) Solutions au niveau de l'application (ou partie d'app.) destinée
aux voyageurs 4
1.3.4°) Solutions au niveau de la documentation et l'aide 4
2°) Solution retenue 5
2.1°) Hypothèses complémentaires 5
2.2°) Description de la solution 5
2.2.1°) Solutions au niveau de la gestion de l'Application 5
2.2.2°) Solutions au niveau de l'application (ou partie d'app.) destinée
aux employés 5
2.2.3°) Solutions au niveau de l'application (ou partie d'app.) destinée
aux voyageurs 6
2.2.4°) Solutions au niveau de la documentation et l'aide 7
2.2.5°) Solutions au niveau de la base de donnée 8
3°) Améliorations 8
4°) Conclusion 8
Introduction
1 Objectif du projet Construction d'une base de données et réalisation d'un programme en
Visual Basic permettant l'exploitation de cette base de données dans
le cadre d'une simulation d'un guichet de réservation d'un billet de
train.
Cette application donne aux voyageurs la possibilité de consulter les
trajets de la journée et de réserver. Elle donne aux employés un
certain nombre d'informations complémentaires sur les trajets, le
chiffre d'affaire, les statistiques, etc. 2 Hypothèses de départ
1 Application - On se limite aux voyages d'une journée sans correspondances
- Places paires coté fenêtre, places impaires cotées couloir
- Pas de notion de compartiment
- Dans un voyage les places vont de 1 àNbrPlaceTotal 2 Base de données - Pour un voyage et une classe donnée le nombre de réservation doit
être inférieur ou égal aux nombres de places
- Le tarif d'une première classe est supérieur au tarif du même voyage
en deuxième classe 3 Différentes solutions possibles Après analyse, nous en déduisons rapidement que nous avons deux
parties essentielles
. Une partie destinée aux voyageurs
. Une partie destinée aux employés
Les différentes solutions possibles déclinent donc ces deux aspects
1 Solutions au niveau de la gestion de l'Application ( Une seule application, le logiciel démarre automatiquement sur une
interface destinée aux clients et par un appel particulier, nous
accédons à la partie dite employé.
Dans ce cas l'appel peut être
Contrôler par un accès sécurisé
- Un bouton qui se trouve dans la partie voyageur
- Une fenêtre de choix
Contrôler par un mode d'appel du programme
- Option d'installation et gestion de la ligne de commande
- Lecture dans la base de registre
- Lecture dans un fichier.Ini
( Deux applications, une pour les voyageurs et l'autre pour les
employés.
L'avantage est de scinder les deux parties bien distinctes
Pas de risque de mélange (Client, voyageur)
Facilité de passer une partie dans un autre environnement (Internet
par exemple)
L'inconvénient est la possible redondance du code (qui peut être
contrée en partie par la création de DLL) 2 Solutions au niveau de l'application (ou partie d'app.) destinée aux
employés ( Plusieurs fenêtres pour les différentes entités (Ville, Voyage,
Classe etc..)
( Fenêtres avec un niveau de détail en direct et passage d'une donnée
à l'autre en restant sur le même niveau de détail. Nous n'avons pas
dans ce cas de vision générale de type liste
( Une seule fenêtre avec une gestion d'onglets pour la définition des
différentes statistiques
( Des fenêtres de définition générale avec appel d'autres fenêtres
pour obtenir un niveau de détail (Notion de liste et, par sélection,
de détail d'un élément de la liste) 3 Solutions au niveau de l'application (ou partie d'app.) destinée aux
voyageurs Logique d'enchaînement
( L'utilisateur n'est contraint par aucune restriction. Il arrive sur
une fenêtre et choisi ce qu'il veut. L'application lui répond la ou
les solutions qui correspondent à ses demandes
( L'utilisateur est en permanence guidé par l'application, en
appliquant un certain nombre d'enchaînements. Par exemple, Les villes
possibles au départ, en fonction du choix de la ville de départ on
propose les villes d'arrivées etc.
Interactivité
( Le logiciel est doté d'un certain nombre de boutons sur lesquels le
voyageur doit cliquer pour obtenir un résultat.
( Le logiciel réagit automatiquement à l'action du voyageur.
Exemple : dés qu'il a choisit les villes on lui propose le ou
les trajets.
( Proposition d'un certain nombre d'informations à saisir ou au
contraire on ne lui fait saisir que le minimum nécessaire. 4 Solutions au niveau de la documentation et l'aide ( Nous pouvons avoir une documentation papier, manuel utilisateur, qui
explique en détail le fonctionnement de l'application
( La même chose que précédemment mais en ligne
( Une aide interactive Solution retenue Une seule application permettant de faire l'ensemble des opérations
destinées aux voyageurs et aux employés.
1 Hypothèses complémentaires . On n'a pas de définition maxi du nombre de place (toutes classes
confondues)
. On ne donne pas la possibilité à l'utilisateur de voir tous les
trajets à la fois, c'est à dire toutes villes confondues.
. L'utilisateur ne peut pas annuler une réservation par le biais du
logiciel
. Lors de la réservation, aucun système de paiement n'est géré.
. L'employé ne paramètre pas le logiciel (Ajout de ville, de voyage,
modification d'un trajet, etc.)
. Pas de préférence de tarif pour un voyageur lors de la réservation
. On ne peut pas rechercher un trajet directement par le N° du trajet
. On ne peut pas rechercher une réservation pour la consulter ou
l'annuler
2 Description de la solution
1 Solutions au niveau de la gestion de l'Application Je retiens la solution de démarrage avec une option dans la ligne de
commande
- Si pas d'option particulière l'application arrive sur une fenêtre
uniquement destinée aux voyageurs
Dans ce cas ,il n'y pas de possibilité d'obtenir l'écran de l'employé
- Si option particulière l'application arrive sur une fenêtre de
statistiques
Dans ce cas , un menu déroulant de choix est ajouté dans la barre de
menu. Il permet d'appeler la fenêtre de réservation. 2 Solutions au niveau de l'application (ou partie d'app.) destinée aux
employés Principe d'une fenêtre unique avec l'ensemble des statistiques
accessibles à travers des onglets. Le principe d'une feuille comme celle-ci est de rassembler divers éléments
de statistiques dans un même écran 3 Solutions au niveau de l'application (ou partie d'app.) destinée aux
voyageurs Principe d'une fenêtre dynamique qui réagit automatiquement en
fonction des choix de l'utilisateur et sur 4 temps principaux.
TEMPS N°1 : Sélection d'une ville de départ puis la liste des villes
d'arrivée est mise à jour en fonction du choix de la ville de départ
TEMPS N°2 : Si il y a des trajets avec des places disponibles
Affichage des trajets disponibles
Affichage des options possibles(Préférences)
Sinon
Indication au voyageur qu'il n'y a pas de train, ou
que le train est complet !
TEMPS N°3 : Le voyageur sélectionne ses préférences et/ou son trajet.
Le logiciel réagit immédiatement. Si ses préférences ne sont pas
possibles on lui affiche les trajets possibles. Une fois son trajet
sélectionné on lui donne la possibilité de le réserver en lui
demandant de saisir son nom
TEMPS N°4 :
Le voyageur rentre son nom et clique sur le bouton Réserver. Le billet
sort avec toutes les informations (Animation écran) et l'écran
retourne sur l'interface au TEMPS1 en effaçant tout ce qui à été fait
précédemment
Note :
Dès que l'utilisateur à agit sur l'interface , un bouton Effacer
apparaît. Il permet la réinitialisation de l'interface 4 Solutions au niveau de la documentation et l'aide Je pars des hypothèses suivantes.
1°) Aujourd'hui la manipulation informatique est devenue assez
courante quant à l'utilisation de la souris et la manipulation des
différents contrôles informatiques. Ceci certainement favorisé par
l'utilisation d'Internet et l'utilisation importante d'un point de vue
professionnel.
2°) Il ne me paraît pas concevable qu'un document papier soit à
coté de l'ordinateur lorsque le voyageur doit réserver son billet.
Je décide donc de ne pas faire de manuel utilisateur destiné aux
utilisateurs, mais d'intégrer dans l'interface une aide interactive et
contextuelle. Celle-ci donne les indications nécessaires aux voyageurs
pour permettre de réserver et d'obtenir leur billet sans avoir à lire
de manuel.
J'imagine donc un ordinateur pourvu d'une souris sur laquelle il y a
écrit SOURIS et un seu