2 Bac Info Soir Langage C++ Avril Projet ABC - v5

Transcription

1 2 Bac Info Soir Langage C++ Avril 2013 Projet ABC - v5 1. Contexte L'évaluation des connaissances et compétences passe par la réalisation à domicile d'un projet et la rédaction de sa documentation. Afin d'assurer l'assimilation progressive des concepts et éviter un développement anarchique dans l'urgence, le projet est divisé en plusieurs versions successives qui devront être rendues à des échéances prédéterminées. Les fichiers à rendre sont - seulement les fichiers *.cpp, *.h et l'exécutable (.exe) des versions clés successives (et non tout le dossier Visual Studio zippé!) - une documentation détaillée qui reprend notamment - un commentaire sur la résolution de la version (difficultés rencontrées, solutions originale, etc.) - la description des classes utilisées et des fonctions implémentées. 2. Objectif de la version v5 du projet L'objectif de cette version du projet est d'assurer que l'étudiant possède la maîtrise : - de l'utilisation des fichiers ascii ou binaires en lecture et écriture, - de l'utilisation de l'accès direct à un record donné dans un fichier, - de la récupération des informations fournies par l'os au lancement d'une application, - d'une architecture de développement en modules autonomes (ou quasiautonomes) standards, - de l'utilisation de classes développées par un tiers, - du développement progressif d'un projet en commençant par des choses simples que l'on teste avant de passer à des choses plus complexes. Un autre objectif, tout aussi important, de montrer à l'étudiant arrivé à ce stade - qu'il peut avoir confiance dans ses propres capacités et jugements, - qu'il devient autonome, car il effectue lui-même les choix indispensables au développment de son projet et decide des fonctionnalités supplémentaires qu'il désire implémenter. Cette version projet constitue la cinquième phase du projet final. Dans cette phase, le projet est totalement fonctionnel et répond au souhait d'un utilisateur à l'exception de l'utilisation d'une "vraie" base de données. 1

2 3. Cadre général du problème Rappelons que le cadre général du projet à été défini dans les documents relatifs aux version 1 à 4. Au terme de cette version 4 chaque étudiant dispose d'un programme qui permet à l'utilisateur de gérer logiquement cinq entités quelconques (A, B, C, ) liées par des relations de type un-à-plusieurs. Le programme dispose déjà : - de menus; - de formulaires de saisie; - de containers indirects; - des fonctionnalités CRUD-FNLP-Q 4. Ce qui est demandé dans la version 5 Concernant les classes A, B, C, etc qui ont été définies dans les versions 1 à 4 (la plupart des étudiants ont déjà pris de l'avance sur certain de ces points et c'est tant mieux) - pour chacune des classes centrales, développer une classe fichier (stream) qui conserve les informations encodées d'une exécution de l'application à la suivante. Cette classe doit hériter de la classe fstream. - s'il est possible, gérer les similitudes entre ces trois classes au moyen de l'héritage (classe de base et fonctions virtuelles), des <templates> ou des deux. - inclure ces fichiers (ou, mieux, un pointeur sur ces fichiers) en tant que data membre de la classe de base Application. - pourvoir cette classe fichier de fonctions d'écriture et de lecture a) d'un objet isolé (A, B, C, etc selon les cas) b) d'un ensemble d'objets passés via un container de pointeurs (container de A, B, C, etc selon les cas). Ces fonctions sont implémentées de préférence sous la forme operator<< et operator>> - utiliser - sans la modifier - la classe RegVars ( 1 ) afin de faciliter la gestion des enregistrements. Incorporer cette classe dans chacune des classes de base par héritage (toutes les classes de base héritent de RecVars). - faire en sorte que seuls les objets nouveaux ou modifiés soient effectivement sauvés dans les fichiers en question - faire en sorte qu'il soit impossible de supprimer un objet A s'il existe encore des B qui lui appartiennent. Idem entre B et C etc selon le schéma relationnel (intégrité référentielle) ou lorsqu'on supprime un objet A, détruire automatiquement tous les B qui lui appartiennent (destruction en cascade) Attention, les destructions sont virtuelles (flag estdetruit=true) afin de permettre un "undo" 1 Vue au cours et disponible sur dans le projet Jeu 2

3 - rendre la gestion des fichiers transparente pour l'utilisateur en faisant en sorte que les fichiers soient automatiquement créés ou recherchés dans le dossier qui contient l'exécutable (ou dans un répertoire fils). Autrement dit : assurer la mobilité de l'application. - veiller à réinitialiser les compteurs de manière correcte lors d'une nouvelle exécution du programme (actuellement, ils sont systématiquement remis à zéro) - pour faciliter la demande ci-dessous, créer un fichier d'options (genre fichier.ini) qui conserve des valeurs et des paramètres d'un run à l'autre du programme. S'inspirer des classes Options et StreamOptions en annexe A ce stade, le projet doit être totalement fonctionnel et les données sont conservées d'un appel d'une application à l'autre. 5. Conseils pour la réalisation La réalisation de cette version est totalement axée sur l'utilisation des fichiers. Cette partie a été vue assez rapidement au cours mais de la documentation et des exemples sont disponibles sur le site dans la page consacrée au langage C++, notamment la réalisation du projet Jeu Lecture et sauvegarde Une technique consiste à : - quand on instancie ou qu'on lance l'application, ouvrir le fichier qui contient les enregistrement, puis à lire ces enregistrements en créant les objets et en les stockant au fur et à mesure dans le container. - ensuite, exécuter la fonction Run() inchangée, qui effectue le gros de la gestion. - quand on quitte ou qu'on détruit l'application, sauver tout le contenu du container dans le stream (qui reconnaît ce qu'il doit sauver et ce qui l'est déjà) puis fermer le fichier Quelque chose comme : StreamA.open(); StreamA >> ContainerA; Run(); StreamA << ContainerA; StreamA.close(); // par référence // par référence Les fonctions peuvent être réparties entre les constructeurs, la fonction Run() et les destructeurs de l'application : ApplicA::ApplicA(void) // initialisations diverses puis StreamA.open(); ApplicA::Run(void) StreamA >> ContainerA; Application::Run(); StreamA << ContainerA; 3

4 L'instruction centrale indique qu'on appelle la fonction Run() de la classe de base et non celle de la classe courante. Ceci évite de devoir modifier la classe de base pour y inclure la lecture des fichiers. ApplicA::~ApplicA(void) StreamA.close(); // puis clôtures diverses Nous pourrions aussi mettre le remplissage du container dans le constructeur et sa sauvegarde dans le destructeur. Une autre technique consiste à faire les lectures en début de programme comme cidessus mais de faire les sauvegarde à chaque création, suppression ou modification. Par exemple : void ApplicA::Create(void) pobja = new ObjA; frma >> *pobja; ContainerA.AddPtr(pObjA); StreamA << *pobja; // instancier un nouvel ObjA // le saisir avec le formulaire // pointeur dans le container // objet dans le fichier L'avantage est que même en cas de plantage avant la fin, les objets sont stockés et rien n'est perdu Filtrer les objets Dans notre philosophie du développement, tous les A sont stockés dans un seul et même fichier ; tous les B ensemble, dans un deuxième fichier ; tous les C ensemble, dans un troisième fichier. Un problème se pose lorsqu'on passe de l'application qui gère les objets A à celle qui gère les objets B appartenant à ce A. Il est évident que ApplicB ne doit montrer que les B qui appartiennent au A courant et non tous les B qui se trouvaient dans le fichier. Il importe donc de filtrer la lecture. Nous pouvons - soit lire le StreamB et, au cours de cette lecture, n'envoyer dans le ContainerB que les B qui appartiennent au A courant (test dans la boucle de lecture). - soit lire le StreamB, envoyer dans le ContainerB tous les B et ensuite filtrer le container pour en retirer et détruire les B qui ne correspondent pas au critère (test comme fonction du container). Le choix est laissé au développeur mais il faut respecter la philosophie objet (par exemple avec une fonction operator!=() ou un functor). La même philosophie est applicable lorsqu'on lit tous les C appartenant au B courant Conserver le chemin Nous savons que l'os fournit à l'application son nom et le chemin où elle se trouve. Cette information est récupérée dans les arguments de main(). 4

5 void main (int nargs, char* args[]) char path[pathlen]; strcpy(path, args[0]); // recuperer le chemin complet *(strrchr(path, '\\')+1) = 0; // 0 derrière le dernier \ // etc... Cette information doit être accessible à toutes les applications. Elle doit donc être conservée dans une variable static de la classe de base Conserver les compteurs Lors de l'activation d'une application, les compteurs qui servent à générer les identifiants ne peuvent pas être réinitilisés à 0. Il faut qu'ils reprennent la dernière valeur qu'ils avaient atteinte lors du run précédent. Deux techniques sont généralement utilisées : - lors de la lecture du fichier, on retient la plus grande valeur d'id rencontrée et on l'utilise pour initialiser les compteurs (créer une fonction membre A::setCompteur()) Inconvénient : il faut lire tout le fichier mais, de toutes façons, il faut le lire - utiliser une classe Option et un fichier StreamOption dans lequel on stocke les compteurs avant de quitter l'application (voir annexe) : Option maxcompteur; StreamOption fichierini; : // etc maxcompteur.setnom("maxid_a"); maxcompteur.setvaleur(a.getcompteur()); fichierini << maxcompteur; Option maxcompteur; StreamOption fichierini; : // etc maxcompteur.setnom("maxid_a"); fichierini >> maxcompteur; A.setCompteur(maxcompteur.getValLong()) // sauvegarde // récupération Ces classes existent déjà et peuvent être utilisées telle quelles (ce qui n'empêche pas de les lire pour comprendre ce qu'elles font) Le fichier des options est commun à toutes les applications. Il doit donc aussi être référencé de manière statique dans l'application de base. A ce propos, il est conseillé de créer un classe intermédiaire entre la classe de base développée au cours et les classes ApplicA etc : Application Applicstream ApplicA, ApplicB, ApplicC, etc 6. Les incontournables Ainsi qu'il a été dit, tous les A sont stockés dans un seul et même fichier ; tous les B ensemble, dans un deuxième fichier ; tous les C ensemble, dans un troisième fichier, etc. 5

6 Les fichiers sont de type binaire avec enregistrements de longueur fixe, ouverts en lecture et ecriture. Les nouveaux objets sont toujours ajoutés en fin de fichier; les objets modifiés ou détruits virtuellement sont réécrits à l'endroit d'où ils proviennent. On insiste pour que les classes A, B, C, etc héritent de la classe RecVars pour facilier la gestion des fichiers. D'un run de l'application au suivant, les compteurs doivent poursuivre la numérotation là où elle s'était arrêtée. L'utilisateur ne doit pas se préoccuper ni des noms ni de l'emplacement des fichiers. 7. Pour les pros - Créer une fonction undelete() qui récupère les enregistrements marqués comme supprimés (sur base d'un critère donné tel que l'id du père). - Créer une fonction pack() qui supprime physiquement tous les enregistrements détruits présents dans un fichier soit en déplaçant les records dans un seul fichier soit en recopiant les records valides dans un autre fichier puis en le renommant (opération transparente pour l'utilisateur). 8. Pour terminer Cette version fait appel à des concepts nettement plus avancés. Cette fois, le copier/coller rechercher/remplacer à partir des exemples vus au cours ne suffira plus. Il vous faudra réfléchir et analyser d'autres exemples et projets pour obtenir l'information nécessaire. 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). Si la résolution du problème peut être implémentée de différentes manières, chacun peut choisir sa solution. Un projet rendu ne doit pas présenter de bugs lors d'une exécution "normale"! Dans le cas contraire, il est recommandé de mettre en commentaire les fonctions qui posent des problèmes et de les remplacer par des fonctions simplifiées (p.ex. affichage d'un message "ici, appel de la fonction xyz non implémentée"). Le dossier doit être rendu par à h.schyns@eci-liege.info pour le dimanche 19 mai 2013 à minuit. Ceci fait, vous pourrez vous considérer comme des pros! Bon courage et, une fois de plus, mes sincères félicitations pour l'excellent travail réalisé jusqu'à présent! 6