2 Grad Info Soir Langage C++ Juin Projet BANQUE

Transcription

1 2 Grad Info Soir Langage C++ Juin 2007 Projet BANQUE 1. Explications L'examen comprend un projet à réaliser à domicile et à documenter : - structure des données, - objets utilisés, - relations de dépendance et d'héritage entre les objets, - les fonctions publiques (méthodes) dont dispose chaque objet. Le dossier doit être rendu une semaine avant le jour de l'examen (début juin). L'examen proprement dit est la présentation orale du programme, sa démonstration et l'explication de son fonctionnement. 2. Enoncé du problème Le projet consiste en une gestion (très) élémentaire d'une agence bancaire. La banque est un organisme financier dans lequel des clients viennent ouvrir des comptes pour effectuer leurs transactions financières. Dans le cadre du projet, tous les clients sont des personnes physiques. Ils sont identifiés par leurs nom, prénom, adresse, numéro de carte d'identité et la date de leur inscription. On leur attribue en outre un identifiant unique. La banque offre trois types de comptes : - les compte ordinaires, - les comptes d'épargne, - les lignes de crédit (réserve permanente). Chaque client peut ouvrir autant de comptes ordinaires ou d'épargne qu'il désire, mais il n'a droit qu'à une seule ligne de crédit. Les comptes sont caractérisés par un numéro unique et leur date de création. Ils sont toujours libellés en Euros. Chaque compte ne peut avoir qu'un seul titulaire. Un compte ordinaire ne peut jamais être en négatif (débiteur). Il ne porte pas d'intérêt mais est soumis à des frais annuels. Un compte épargne, comme le compte ordinaire, ne peut jamais être négatif et est aussi soumis à des frais annuels. Par contre, il porte un intérêt supposé constant au fil du temps. La ligne de crédit ne peut jamais être positive (créditrice). Elle est soumise à un taux d'intérêt supérieur à celui du compte épargne et à des frais annuels. Elle ne peut pas dépasser une certaine limite fixée en fonction du client. Tous les taux d'intérêt sont fixés par la banque et identiques pour tous les clients. 1

2 Le client débite et crédite ses comptes en effectuant des mouvements financiers tels que dépôts, retraits, virements. Les mouvements sont gérés "en partie simple" à la manière d'un livre de caisse. Selon ce principe, un virement de la ligne de crédit vers le compte courant fait l'objet de deux mouvements. Un mouvement est caractérisé par sa date, le montant (positif pour dépôt, négatif pour retrait), un numéro d'ordre et une communication. Deux mouvements spéciaux, appelé clôture et report, permettent de clôturer les comptes en fin de période et de reporter le solde en début de la période suivante (p.ex.: clôture au 31/12/200x à minuit, report au 01/01/200x+1 à 00h). Un mouvement validé ne peut jamais être supprimé. l'annuler par un mouvement inverse. Le cas échéant, on devra A tout moment, le client peut connaître le solde de ses comptes. Celui-ci s'obtient en faisant le total des mouvements depuis le dernier report. Le client peut décider de clôturer l'un ou l'autre de ses comptes pour autant que son solde soit nul. Toutefois, les obligations légales imposent à la banque de garder les enregistrements y relatifs pendant une durée de 30 ans. On marquera donc le compte comme "clôturé" ainsi que la date de clôture. Seuls les comptes clôturés depuis plus de 30 ans peuvent être détruits. La banque peut supprimer un client qui n'a plus de compte. Toutefois, les même obligations légales lui imposent de garder les enregistrements y relatifs pendant une durée de 30 ans. On marquera donc le client comme "désactivé" ainsi que la date de désactivation. Seuls les clients désactivés depuis plus de 30 ans peuvent être détruits. 3. Schéma de résolution Interface Banque Banque Lecture des menus Navigation entre menus Client Compte Mouvement Entités Banque Saisies & affichages possède subit Client Compte Mouvement Relations entre entités s Banque Sauvegardes & reprise Clients Binaire Comptes Binaire Mouvemt Binaire s Texte 2

3 On propose ci-dessous un schéma de résolution. L'étudiant est libre de remettre cette analyse en question, de faire preuve d'imagination et de s'écarter du schéma proposé. L'important est de rester dans une philosophie "objet" Les entités On peut voir le projet comme la gestion d'une petite base de données à trois entités (zone centrale du graphique) : - client, - compte, - mouvement. Ces entités sont reliées par des relations de type "un à plusieurs" qui définissent une hiérarchie. Elles deviendront des classes dans le projet C++. Une classe "Banque" englobe le tout. Il est bien entendu que des classes supplémentaires peuvent être ajoutées au projet pour en simplifier la réalisation au maximum Les fichiers Entre deux exécutions du programme, toutes les données doivent être conservées dans des fichiers (zone inférieure du graphique). Pour des raisons de simplicité, on définit un fichier par entité. Les données y sont stockées en format binaire sous la forme d'enregistrements de longueur fixe. L'accès direct à un enregistrement en sera simplifié. La reprise et la sauvegarde éventuelle des informations en début et fin de programme doit être automatique. Tous ces fichiers ayant sensiblement le même fonctionnement, ils peuvent évidemment être considérés comme des classes qui dérivent d'une classe commune L'interface L'interface (zone supérieure du graphique) est prévue pour le mode console (p.ex.: DOS). On veillera toutefois à bien séparer les entrées/sorties et les traitements afin de pouvoir porter facilement l'application dans un environnement graphique (Windows par exemple). Un menu principal doit apparaître au démarrage de l'application. Il propose l'accès à plusieurs sous-menus. Le passage d'un sous-menu à un autre ne se fait qu'en revenant au menu principal (structure en arbre). Tous les menus ont la même structure : Titre du menu A - Option A B - Option B : Q (ou sortie) Le choix se fait en tapant une lettre (hotkey) différente pour chaque option du menu (pas de gestion graphique ou semi-graphique). Comme les menus ont tous la même structure, il peut être intéressant d'en faire une classe dont on dérivera les menus particuliers. On notera aussi que les menus sont hiérarchisés, tout comme les entités. 3

4 Dans le même ordre d'idées, les lignes devant apparaître dans le menu sont stockées sous forme de texte dans un fichier texte unique. Chaque ligne de ce fichier contient - un code qui identifie le menu (p.ex.: P pour principal, C pour clients, etc.) - un numéro de ligne éventuel, - la hotkey, - le texte de la ligne. Lors du chargement d'un menu, l'objet va simplement rechercher les lignes qui le concernent dans ce fichier. On n'implémente pas de sortie vers l'imprimante Les fonctions On propose ci-après une organisation des fonctions en menus. L'étudiant est libre d'en choisir une autre (plus ergonomique ou plus simple) mais toutes les fonctions de création, suppression, modification et recherche des clients, comptes et mouvements doivent être implémentées (et éventuellement interdites) principal Le menu principal propose (par exemple) quatre fonctions : - Gestion des clients : provoque l'affichage du menu de gestion des clients - Gestion des comptes provoque l'affichage du menu de gestion des comptes - Gestion des mouvements provoque l'affichage du menu de gestion des mouvements - Quitter l'application provoque l'effacement de l'écran et la fermeture de l'application Gestion des clients Le menu de gestion des clients propose trois fonctions : - Créer un nouveau client : provoque l'affichage d'un écran de saisie (semblable à un menu) avec deux souscommandes : Valider et Abandonner - Rechercher un client existant : provoque l'affichage d'un menu de saisie du mode de recherche : provoque le retour au menu principal Le menu de saisie du mode recherche permet la recherche d'un client - Sur base du nom : demande le nom puis effectue la recherche et affiche le client trouvé - Sur base de son code : demande le code puis effectue la recherche et affiche le client trouvé - Sur base d'un de ses numéros de compte (éventuellement) : demande le numéro de compte puis effectue la recherche et affiche le client trouvé 4

5 L'affichage du client liste les informations qui le concernent ainsi que quatre options : - Modifier - Désactiver - Supprimer En cas de modification on demande l'item à modifier (éviter absolument le réencodage de toute la fiche) Gestion des comptes Le menu de gestion des clients propose trois fonctions : - Créer un nouveau compte : provoque l'affichage d'un écran de saisie avec deux sous-commandes : Valider et Abandonner - Rechercher un compte existant : provoque l'affichage d'un menu de saisie du mode de recherche provoque le retour au menu principal Evidemment, la création d'un compte impose de l'attacher à un client existant. On pourra soit commencer par choisir le client, soit terminer par le choix du client. Le menu de saisie du mode recherche permet la recherche d'un compte - Sur base du numéro de compte : demande le nom puis effectue la recherche et affiche le compte trouvé - Sur base du nom du titulaire (éventuellement) : L'affichage du compte liste les informations qui le concernent (type de compte, solde) ainsi que trois options : - Clôturer - Supprimer Gestion des comptes Le menu de gestion des clients propose trois fonctions : - Créer un nouveau mouvement : provoque l'affichage d'un écran de saisie avec deux sous-commandes : Valider et Abandonner - Rechercher un mouvement existant : provoque l'affichage d'un menu de saisie du mode de recherche provoque le retour au menu principal Evidemment, la création d'un mouvement impose de l'attacher à un compte existant d'un client existant. On pourra soit commencer par choisir le client puis le compte, soit terminer par le choix du client. 5

6 Le menu de saisie du mode recherche permet la recherche d'un mouvement : - Sur base de la date : demande la date puis effectue la recherche et affiche le(s) mouvement(s) - Sur base du montant : L'affichage du mouvement liste les informations qui le concernent (compte, montant, date) ainsi que l'option :. 4. Conseils pour la réalisation La réalisation de ce projet est moins compliquée qu'il n'y paraît si on tient compte du fait que le projet est structuré : - horizontalement Client Comptes Mouvements avec des fonctionnalités identiques dans les trois cas; - verticalement Entité avec un transfert d'information similaire dans les trois cas. En d'autres mots, il "suffit" de résoudre la gestion de l'une des entités et d'appliquer cette solution aux autres. Il est conseillé de commencer par l'implémentation des mouvements en simplifiant le problème au maximum - définir la classe avec ses fonctions habituelles : constructeurs, destructeurs, opérateur =, constructeur de recopie, SetNnn, GetNnn - tester chacune de ces fonctions dans un programme principal élémentaire, - ajouter des fonctions liées au fichier sauvegarde, reprise, recherche(s) Il est permis de charger tout ou partie du fichier dans un conteneur, de faire les traitements en mémoire puis de sauver le conteneur dans le fichier. Mais il est plus élégant de faire des accès directs dans les fichiers. - définir un conteneur pour cette classe (éventuellement, implémenter une pile semblable à celle vue au cours). On reprend ensuite ce processus avec l'entité suivante en essayant de généraliser au maximum. Dans une seconde phase - définir une classe menu pour cette entité : Un menu n'est qu'une pile de strings. En plus des fonctions habituelles, il lui faut (entre autres) une fonction de chargement à partir d'un fichier, une fonction d'affichage et une fonction de choix. - tester le menu seul, - interfacer le menu avec la classe dont il assure la gestion. Dans une troisième phase on hiérarchise les menus. 6

7 5. Les incontournables Il s'agit de programmation orientée objet! Seul "main" n'est pas une classe. L'utilisation de la compilation séparée est obligatoire : un fichier.cpp et un fichier.h par classe réunis à l'aide d'un fichier projet. Tous les tableaux, vecteurs, listes doivent utiliser l'allocation dynamique (new, delete) sauf dans le cas de tableaux dont le nombre d'éléments est connu est constant par définition (p.ex.: la liste des touches acceptées dans un menu). Le projet doit contenir et utiliser à plusieurs endroits au moins une classe "template" (p.ex.: un conteneur, une pile) provenant soit d'une bibliothèque, soit développée par soi-même. Toutes les classes doivent hériter d'une classe de base (pas nécessairement la même pour toutes les classes), qui contient au moins une fonction virtuelle. Les classes clients, comptes et mouvement disposent chacun d'un compteur "static" pour numéroter automatiquement les enregistrements. Lors de la relecture du fichier, il ne faut pas oublier de réinitialiser ce compteur au plus grand numéro relu (ou le suivant). 6. Pour terminer La discussion entre élèves est encouragée mais chaque élève doit rendre un projet personnel (ce qui se reconnaît immédiatement au style de programmation) et le connaître sur le bout des doigts (ce qui se voit immédiatement par les explications sur la résolution de certains problèmes). La résolution du problème peut être implémentée de différentes manières, chacun peut choisir sa solution. Mieux vaut un projet dans lequel on a réussi à gérer verticalement une ou deux entités (menu entité fichier) en intégrant proprement tous les "incontournables" qu'un foutoir dans lequel on fait tout n'importe comment. Ceci dit, seul un projet complet et correct mérite le maximum de points. Bon courage! 7