Projet LO02 Simulation d une station service Montassier Guillaume & Olivier Matthieu 13 juin 2009 1
Tester un programme peut démontrer la présence de bugs, jamais leur absence. [ Edsger Dijkstra ] 2
Table des matières 1 Introduction 4 2 Guide de l utilisateur 5 2.1 Introduction.............................. 5 2.2 Les interfaces graphiques....................... 5 2.2.1 Les interfaces client..................... 5 2.2.2 L interface opérateur..................... 5 2.3 Les interfaces textes......................... 6 2.3.1 L interface texte client.................... 6 2.3.2 L interface texte opérateur.................. 6 3 Modélisation UML 7 3.1 Diagramme de cas d utilisation................... 7 3.2 Diagramme de classe......................... 8 3.3 Diagramme de séquence....................... 11 3.3.1 scénario : paiement en liquide avec ticket......... 11 3.3.2 scénario : paiement par carte avec ticket.......... 13 3.4 Les changements........................... 14 4 Etat actuel de l application 15 5 Perspective 16 6 Conclusion 16 3
1 Introduction Le projet LO02 que nous vous présenter consiste en une simulation d une station d essence. Il y aura 2 parties visibles dinstinctes : Une partie client et une partie opérateur. Ces 2 parties sont accessibles à tout moment en graphique ou en console. La partie client permet à un utilisateur de choisir une borne dans un premier temps. Le choix de la borne conditionnera le type de carburant que l utilisateur pourra retirer. A cela s ajoute le type de paiement auquel il veut proceder : liquide, chèque ou carte bleu. Cette dernière est totallement gerée par la borne, tandis que les 2 autres doivent être encaissés auprès de l opérateur. Aussi le client à la possibilité de tirer un ticket, et de soit choisir un montant sans décider de la quantité, soit d une quantité sans décider du montant. L interface opérateur sera composée en plusieures parties. L une consistera à la reinitialisation de la station, c est à dire remettre toutes les bornes en état opérationnelles, et re-remplir les cuves. Une autre permettra de vérifier le niveau des cuves. Encore une autre aura pour but d indiquer la disponibilité des bornes. Aussi, il sera tenu informé des caisses en attente de paiement, et pourra procéder à ceci. Enfin lorsque l opérateur décidera de partir, il pourra désactiver les paiements par chèque ou liquide. En temps qu utilisateur de logiciel, nous pourrons aussi sauvegarder l etat des cuves dans un fichier pour reprendre la simulation à plus tard. Au travers de ce document, vous verrez l élaboration de cette station, à partir de la phase de conception UML, jusqu au résultat final, c est à dire le code joint lors de la remise des traveaux. Nous nous sommes aussi attachés de trouver quelles parties auraient mérité plus de dévellopement, ainsi que certains problèmes encore présents. 4
2 Guide de l utilisateur 2.1 Introduction Lorsque le programme est lancé, l utilisateur a le choix d utiliser soit les interfaces graphiques, soit l interface texte, par le biais d un terminal. Les fonctionnalités de ces 2 types d interfaces sont identiques. Ainsi, l encaissement d un client peut tout aussi bien se faire en graphique qu en texte. Tout dépend des préférences de l utilisateur du logiciel. 2.2 Les interfaces graphiques Lorsque le programme est lancé, 7 panneaux apparaîssent. 6 représentent les différentes bornes, tandis que la derniere est l interface de l opérateur. 2.2.1 Les interfaces client Elles sont structurées de manière séquentielles, de manière à ce que le client soit guidé dans les étapes. Ainsi le premier panneau proposera le(s) carburant(s) disponible(s), ainsi que la possibilité de prendre un ticket. Le second demande que l on renseigne soit le prix, soit la quantité de carburant à prévelever (L un ET l autre ne seront pas acceptés par l interface). Ensuite, un troisième panneau demande avec quel type de paiement veut-on procéder (carte, chèque ou espèces). Le quatrième panneau est un écran de confirmation, qui propose au choix de valider ou bien d annuler. Enfin, le cinquième panneau est un récapitulatif de prix, de la quantité, et indique si il faut payer au guichet, auquel cas il faut que l opérateur encaisse la transaction. 2.2.2 L interface opérateur Organisé de manière cohérente, l interface de l opérateur donne une vision globale sur toute la station en un seul panneau. Une zone permet de consulter le status des bornes (opérationnelles ou non), de les désactiver et d encaisser les paiements. Les bornes en attente de paiement sont quant à elles signalées dans une autre zone de texte. Dans la partie de droite, une jauge de carburant est disponible pour chacune des cuves, donnant une vision directe sur leur niveau. A côté, des boutons permettent à l opérateur de réinitialiser la station, ce qui remontera tous les niveaux à 100% et remettra toutes les bornes en opérationnel. Un autre bouton permet de sauvegarder l état des cuves dans un fichier xml. Enfin 2 autres boutons permettent à l opérateur de se connecter ou de se déconnecter, ce qui aura pour effet de n accepter ques les paiement en carte bleu sur les bornes. Enfin, une dernière zone permet de notifier si le niveau des cuves deviens bas, ainsi que la présence ou non de l opérateur, et de confirmer les sauvegardes. 5
2.3 Les interfaces textes Comme la partie client et opérateur se déroulent dans la même console, un petit menu permet de choisir soit l un, soit l autre, avec possibilité de changer à la fin d une opération. 2.3.1 L interface texte client Dans un premier temps, l utilisateur est invité de choisir une borne. De celle-ci, il pourra choisir le carburant qu il veut retirer. Il sera ensuite invité à entrer une quantité ou bien un prix. Il renseigne ensuite le mode de paiemement et si il veut un ticket. Dans la cas d un paiement carte bleu, le ticket apparrait sous forme d une petite fenêtre qu il faut refermer pour continuer. 2.3.2 L interface texte opérateur L opérateur a accès à toutes les fonctionnalités de l interface graphique, des boutons jusqu aux notifications. Il peut, dans l ordre : réinitialiser la station, contrôler l état des bornes, désactiver des bornes, encaisser des paiements, se déconnecter/reconnecter et sauvegarder l état des cuves. Ces fonctions ont le même effet que dans l interface graphique. 6
3 Modélisation UML 3.1 Diagramme de cas d utilisation Fig. 1 diagramme de cas de notre projet L opérateur a accès à 4 actions principal sur notre système : Contrôler le niveau des cuves : Permet d afficher le niveau de toutes les cuves à carburant. Vérifier le status des bornes : Affiche le nombre et le type de bornes ainsi que leur status (hors service). Réinitialiser la station : Consiste à remettre la station à son état d origine : cuves pleines et toutes les bornes en service. Enregistrer les paiements : Permet à l opérateur d encaisser les paiements par chèque ou liquide en fonction de la borne et de proposer un ticket de caisse. L opérateur pourra aussi se connecter/déconnecter ce qui enclechera une obligation de payer par carte pour les clients. 7
Notre client (véhicule) pourra donc choisir son carburant, ce qui inclura le fait de payer. La méthode paiement permettra de choisir entre 2 actions : le règlement par carte, qui proposera ensuite un ticket, et le règlement par liquide ou chèque qui permettra de payer au près de l opérateur. La classe créer ticket permettra quand à elle de créer un ticket si le client le désire. 3.2 Diagramme de classe Fig. 2 diagramme de classe de notre projet 8
Voici les différentes classes de notre diagramme : Cuve : Cette classe nous permettra de gérer le niveau de tous les carburants. Elle sera instancié autant de fois qu on a de carburants différents. Une instance possédera un niveau qui évoluera en fonction de la consommation des clients ainsi qu un prix au litre. Enfin, cette classe possédera des méthodes pour prélever du carburant, un indicateur de niveau et une méthode pour renvoyer le tarif à la borne. Ticket : Comme la borne et l opérateur peuvent générer des tickets (selon le paiement), nous avons centralisé leur création dans une seule classe. Un ticket sera créé, le prix et la quantité de carburant étant récupérés via la classe borne (chèque, liquide) ou l opérateur (CB). Une méthode consistera à l afficher en texte, et une autre en graphique. Borne : Elle n est définie que par son état : en service ou hors service. Comme le client a à loisir de spécifier la prix qu il veut dépenser ou la quantité de carburant, il existe 2 méthodes pour convertir l un vers l autre. L utilisateur doit choisir le type de carburant qu il désire (au travers de l interface graphique), et peut spécifier aussi le type de paiement auquel il veut recourir. Une méthode récupére le tarif ou la quantité. La borne vérifie si le niveau de la cuve est suffisant. Dans dans la cadre d un paiement par carte, une méthode spécifique lance une procédure de paiement immédiat et une autre permettra l impression d un ticket. Dans le cadre d un paiement par chèque ou liquide, le montant et la consomation seront envoyé à l opérateur qui encaissera le règlement. Une fonction permet de retirer du carburant. La vérification d interface permet de vérifier que si à l initialisation une interface graphique ne s est pas lancé (InterfaceG), alors la borne s auto-désactive. Aussi, il existe une méthode pour donner le status des bornes auprès de l opérateur. Opérateur : Il est uniquement caractérisé par son status. Ensuite il a le pouvoir de réinitialiser la station. Il est aussi en mesure de jauger le niveau des cuves à tout moment, ainsi que l état des bornes. Enfin, il doit pouvoir encaisser les paiements liquide et chèque que les bornes lui notifient, et il doit pouvoir générer le ticket de caisse. Enfin, il existe une méthode pour changer le status de l opérateur, en fonction de sa présence, ce qui modifira le comportement des bornes. Lorsque le l opérateur est de retour, le changement de status a pour effet de vérifier le niveau des cuves. Il peut aussi sauvegarder l état de la station (niveau des cuves, prix des carburants). Station : Cette classe détermine le fonctionnement ou non de la station. Elle définis aussi le nombre de pompes et de cuves, et les créé. La station définis aussi les rêgles de navigibilité pour les classes créées. Client (terminal) : Chaque instance (ou client) sera caractérisé par un type de carburant, la quantité de carburant qu il voudra prélever et le prix qu il devra payer. Il sera aussi caractérisé par le moyen de paiement qu il utilisera, et le fait de savoir si il veut ou non un ticket. Pour cela, il possède une méthode démarrage qui initialise différents paramètres : l id du client, le mode de paiement, le prix qu on veux mettre, la quantité de carburant, l impression ticket. 9
Enfin, il posséde d autres méthodes pour procéder au paiement ainsi que pour prélever du carburant. InterfaceG : Elle est du côté client. Chaque interface représente une borne qui proposera un carburant, affichera le tarif du carburant, la quantité à débiter, le prix qu il devra, le choix de paiement. Une interface peut signaler si elle est hors service. Elle affiche le prix ou la quantité manquante. Enfin, elle affiche des informations complémentaires. InterfaceGOperateur : Elle affiche en permanance le status des bornes et l état des cuves. Elle affiche aussi les informations sur l opérateur, les alertes niveau cuves, et les bornes qui sont en attente de paiement. On peut encaisser ces paiements, désactiver des bornes à distance, réinitialiser la station, sauvegarder les données des cuves, et permettre à l opérateur de s absenter. Interface texte : Il s agit entre autres de la console opérateur. Elle affiche les mêmes actions que l interface graphique opérateur. En outre, un client peux l utiliser pour faire un plein. Il aura accès aux mêmes choix que dans l interface graphique. Chacune des méthodes affiche et interprete les saisies de l utilisateur. On notera que toutes les données des clients actifs (6 au maximum) sont stockées ici afin de procéder aux encaissements et à la création des tickets. 10
3.3 Diagramme de séquence 3.3.1 scénario : paiement en liquide avec ticket Fig. 3 diagramme de séquence dans le cas d un paiement en liquide 11
Pour ce diagramme, Gérard est l utilisateur de notre simulateur de station. Lorsqu il arrive sur l interface graphique, il ne pourra utiliser que les bornes fonctionnelles. Il va ensuite saisir les informations utiles à son plein sur la bonne borne (l interface graphique modélisant les 6 bornes possibles). Dans notre cas, le client choisit de payer en liquide, et choisi de faire son plein en spécifiant le prix qu il veux mettre, et le type de carburant désiré. Ici étant opérationnelle, l interface graphique va déclencher l envoi des informations á son client(terminal). Cette instance de client n aura pour but que de suivre la consommation et les conditions de paiement du client le temps d un plein. Ensuite, l instance client va renseigner la borne sur les conditions du plein. Pour notre exemple, Gérard a spécifié qu il veut du gasoil en fonction du prix qu il veut payer, avec un paiement par liquide et un ticket de caisse. Une fois ces informations transmises de la classe client à la borne, cette dernière va récupérer le tarif au litre du gasoil, et faire la conversion prix vers quantité. Après cela, le niveau de la cuve gasoil sera contrôlé pour être sûr qu il reste assez de carburant. Au même moment, la borne notifie l opérateur que le client en cours va devoir lui régler le montant du plein. Une fois le plein effectué, le client doit payer auprès de l opérateur de station, et un ticket sera créé et remis au client. 12
3.3.2 scénario : paiement par carte avec ticket Fig. 4 diagramme de séquence dans le cas d un paiement par carte La démarche est semblable à la précédente, à savoir si la borne la borne est en service, il peut l utiliser. Ensuite, le client veut retirer du gasoil, en fonction d un prix, mais cette fois-ci il désire payer par carte. L interface va créer une instance de client, qui va relayer toutes les informations utiles à la borne. Cette dernière effectue la conversion prix vers quantité de carburant, auprès de la cuve, et vérifie qu il y reste suffisamment de gasoil. Ensuite une fois les opérations prêtes, le client est débité et il peut alors faire son plein. Enfin, le plein terminé, il peut retirer le ticket. 13
3.4 Les changements Plusieurs éléments ont changés depuis le premier jet UML. Ces changements se justifient plus particulièrement du fait qu entre la théorie et la pratique, certaints éléments ne semblaient plus cohérents, inutiles, ou alors nécéssaires d ajouter. Nous allons donc tenter de dresser une liste des différences notables. Les bornes : héritées : Les bornes VL, PL et GPL ont été retirées car elles complexifiaient le développement. Il a été plus simple de choisir d avoir une méthode unique retirerc qui retirait le carburant des cuves, que d en avoir une multitude différente. La station : La plupart des attribus ont été retirés. Elle crée les bornes et les cuves, donc nous avons gardé leur nombre en dur dans les méthodes correspondantes. L interfaceg : Il s agit en réalité de l interface avec laquelle le client possède des intéractions. Nous avons ajouté beaucoup de méthodes au fur et à mesure de son affinage, car certaints éléments d intéraction ne nous avaient pas encore apparut au début de l étude. Le client : Reste identique, à l exception de méthodes pour mettre à jour les informations affichées par l interface graphique. L interface texte : Elle a été étoffée à mesure que certaines subtilitées du projet nous sont apparues. Nous avons donc rajoutés des méthodes pour le contrôle de l opérateur, mais aussi pour que le client puisse lui aussi agir depuis un terminal texte. L interfacegoperateur : Elle a été rajoutée afin d avoir un panneau de contrôle graphique du point de vue opérateur. Elle possède un thread qui permet à l opérateur de suivre le niveau de ses cuves en temps réel. L opérateur : Toujours usité par l interface graphique opérateur et l interface texte, ses méthodes ont été multipliées, aussi à mesure que nous découvrions les fonctionnalités mal cernées au départ. Il perd l attribut nom, plus annecdotique qu autre chose, et gagne un attribut status, lui autorisant de partir de son travail et laisser tourner la station de façon autonome. 14
4 Etat actuel de l application Notre station est bien composée de 3 bornes pour véhicules légers, 2 pour véhicules GPL et une pour les poids lourds, et composé de 5 types de cuves (essence 95, essence 98, gasole, gpl, fuel ). Elle possède aussi une interface texte et graphique pour chaque borne et pour l opérateur Le moteur de notre application fonctionne tel qu il est décris dans la partis 2.3 de notre cahier des charges, à savoir que nous attendons l activité d un client au niveau de nos interfaces puis en fonction de l action de ce client nous répartissons les conséquences (exemple : baisser le niveau d une cuve, afficher un paiement en attente). L interface graphique de l opérateur est définie dans une fenêtre générale qui propose les fonctionnalités classiques de l opérateur (encaissement, sauvegarde de l état de la station etc...), et propose aussi un affichage en continue du niveau des cuves ainsi que du status des bornes, elle affichera aussi une alarme si le niveau d une cuve descend en dessous de 10000L. les bornes sont quant à elle modélisées dans des fenêtres indépendantes, elles proposent un choix de carburant différent selon la borne, un ticket, de choisir une quantité ou un prix et finalement de valider ou d annuler. Par ailleurs si une fenêtre est fermée, la bornes correspondante sera alors désactivé et ne pourra plus être réactivé jusqu au prochain redémarrage de la station. Il reste que le script qui devait pouvoir être chargé puis s exécuter n a pas été réalisé car après discutions avec M. Legrand car il semblait ne pas correspondre au besoin attendu. L interface texte propose un menu général permettant de choisir entre la console de l opérateur ou la console d une borne. Ces consoles (opérateur et client) proposent les mêmes fonctions que l interface graphique. Pour aller plus loin nous avons décidé de sauvegarder les informations de notre station (le niveau des cuves ainsi que le tarif) dans un fichier xml. Pour ce faire, nous avons réalisé 2 classes supplémentaires : l une pour écrire dans notre fichier xml, l autre pour y récupérer les informations. Nous avons aussi ajouté quelques fonctionnalités pour notre opérateur. Il peut par exemple se déconnecter, ce qui empêche le paiement par chèque et espèce, et permet par contre uniquement un paiement par carte. Nous avons aussi rajouté la possibilité de désactiver manuellement des bornes et la possibilité de réinitialiser la station, ce qui remet les cuves à leur niveau maximum et réactive les bornes (exception faite des bornes qui ont été désactivées parce que l interface graphique correspondante à été fermé) 15
5 Perspective notre projet présente différentes parties qui pourraient être améliorer : En premier lieux pour la logique de la modélisation ULM et la logique du programme il faudrait ne plus enregistrer les clients en attentes de paiement dans l interface texte mais dans une classe à part. On pourrai aussi penser à améliorer la sauvegarde des informations en enregistrant d autres information (par exemple le nombre total de client, la quantité totale de carburant retiré, ou encore l argent total encaissé) on pourrai aussi proposer choisir ou l opérateur désire sauvegarder le fichier. Il serai aussi intéressant de faire un bouton contacter le fournisseur qui permettrai de choisir un carburant ainsi qu une quantité pour remplir notre cuve. Pour finir une notification affichant qu une borne en attente de paiement est en attente depuis plus de 10 minutes pourrai être intéressante car permettrai d avertir l opérateur qu un client est partie sans payer. 6 Conclusion Ce projet nous a donné un premier aperçu des enjeux du travail en équipe. En effet, afin de réaliser les objectifs définis en début de projet (programmer le coeur de l application, des interfaces graphiques et rédiger un compte rendu) il a fallu nous organiser et répartir les différentes tâches. Pour réaliser ce travail en équipe l Objet fut d une aide précieuse. En effet le fait de pouvoir diviser son programme en classes nous a facilité la répartition de la programmation. Nous avons aussi vu l intéret que représente l UML (et en particulier le diagramme de classe) qui nous a permis de poser la base sur notre programme et d accélérer le travail. D autre part, les différents problèmes rencontrés nous on permis d apprendre à utiliser la Javadocs de sun. Maintenant que ce projet est terminé, nous pensons qu il reste beaucoup à faire. Nous aurions désiré plus de temps pour pouvoir finir plus en profondeur le projet (nous aurions en particulier voulu corriger les quelques défaults de programmation pour mettre en place à 100% un modèle MVC). 16