1  Les objectifs

Réaliser en trinôme une application complète mettant en oeuvre l'allocation dynamique de tableaux, des fichiers de texte, et la compilation séparée, d'après un cahier des charges, en gardant toutes les bonnes habitudes acquises au cours des TD et TP. Les fichiers de texte et la compilation séparée seront vus dans la dernière partie de l'unité.

La procédure indiquée dans ce document est à respecter scrupuleusement, et tout retard donnera lieu a des points de pénalité, y compris lorsqu'il s'agit de prendre un RV pour une soutenance ou de fournir la composition des trinômes.

Il sera donc probablement utile de lire plusieurs fois le présent document, et surtout de s'y reporter régulièrement tout au long du projet.

D'autre part, il est nécessaire de consulter ses messages e-mail tous les jours pendant toute la durée du projet (jusqu'à la publication des notes de projet !). Tout dysfonctionnement doit être immédiatement signalé au SMIG, et si celui-ci n'arrivait pas à résoudre le problème, à Denis BUREAU.

Il est demandé de fournir deux documents :

1.1  Le pré-rapport

Les explications doivent être concises, mais le pré-rapport devra au moins comporter :

1. le groupe, les noms/prénoms des étudiants, et le choix du projet ;
2. une table des matières (éventuellement faite à la main) ;
3. les déclarations des constantes principales en pseudo-langage, et leur utilité ;
4. les déclarations de types en pseudo-langage, et leur utilisation ;
5. un schéma (éventuellement fait à la main) représentant la structure de données complète ;
6. le programme principal en pseudo-langage (consiste essentiellement à appeler correctement les sous-programmes) ;
7. le prototype de chaque sous-programme en pseudo-langage, avec la signification de chaque paramètre ;
8. le rôle (en français) de chaque sous-programme, plus d'éventuelles remarques sur des particularités de réalisation ou des conditions d'utilisation du sous-programme.

1.2  Le rapport final

Les explications doivent être concises, mais le rapport devra au moins comporter :

1. le groupe, les noms/prénoms des étudiants, le choix du projet, et la répartition effective des tâches ;
2. une table des matières ;
3. les fonctionnalités réalisées en plus ou en moins par rapport au cahier des charges (y compris les optionnelles) ;
4. un petit mode d'emploi destiné à une personne ne sachant rien à propos de ce programme ;
5. des jeux de tests montrant les données et les fichiers utilisés, ainsi que les affichages et les fichiers produits (le cas normal et les cas particuliers) ; si les tests ont été correctement effectués, le programme ne plantera pas le jour de la soutenance ...
   Cette partie est longue et nécessite d'avoir pratiquement terminé le programme une semaine avant la date limite.
6. l'organisation des sous-programmes dans les différents fichiers séparés ;
7. les listings commentés, en évitant les procédures "à cheval" sur deux pages ; les commentaires ne sont pas une simple paraphrase du code, mais un moyen d'aider à la compréhension du code C++ ; ces commentaires font partie du fichier .CPP et ne sont pas ajoutés en Word par la suite ;
8. une conclusion résumant les limites ou contraintes du programme, ainsi que les extensions que vous auriez souhaité réaliser si vous en aviez eu le temps.

2  Déroulement du projet

Ces éventuels sujets, ainsi que le choix du sujet et la composition des trinômes devront être définitivement fixés au plus tard vendredi 15 février à 13h. Un mail devra être envoyé à d.bureau avant cette date pour préciser tout cela.

A titre indicatif, chaque groupe est censé utiliser le créneau suivant pour se mettre d'accord sur la composition des trinômes et le choix du sujet, si ce n'est pas déjà réglé avant :

• Groupe 1 : vendredi 15 février de 10h à 12h en salle 3207
• Groupe 2 : jeudi 14 février de 10h à 12h en salle 4305
• Groupe 3 : mercredi 13 février de 13h à 15h en salle 3201

Chaque groupe sera particulièrement suivi par un enseignant parmi : Denis BUREAU ou Albert CORNEC. Les créneaux horaires pendant lesquels ces enseignants s'engagent à être disponibles pour répondre à vos questions concernant ce projet vous seront communiqués ultérieurement. Il est également possible d'aller les voir à d'autres moments, sans garantie de leur disponibilité. Les échanges par mail sont également conseillés.

DANS TOUS LES CAS, il vaut mieux venir demander à Denis BUREAU ce qu'il faut faire, plutôt que de prendre une mauvaise décision. Le jour de la soutenance, il sera trop tard, et en particulier, vous ne pourrez pas dire "je croyais qu'il fallait faire ..."; pour en être sûr, une seule solution : venir demander.

Le programme .EXE, les sources .CPP (et .H), ainsi que les fichiers de tests nécessaires (mais pas les .BAK, .OBJ, DEBUG, ...) devront se trouver dans le répertoire TPINFO\PROJET d'un des membres du trinôme. Après avoir vérifié que le projet se trouve dans le bon répertoire, envoyer un mail à d.bureau pour préciser que le projet est terminé, sur quel compte il se trouve, et le nom des étudiants.

Le mail est à envoyer avant le vendredi 29 mars 2002 à 13h. Les rapports sont à rendre au secrétariat du département informatique (5251) avant cette même date.

Les soutenances pourront commencer dès le vendredi 29 mars et devront toutes être terminées le mercredi 10 avril au soir. TOUS les rendez-vous pour ces soutenances doivent être pris AVANT le vendredi 29 mars à 13h auprès de l'enseignant affecté à votre groupe.
Il n'est pas nécessaire d'avoir terminé le projet pour prendre ce rendez-vous; par contre, il est nécessaire que les 3 membres du trinôme soient présents avec leurs agendas, pour tenir compte à la fois des emplois du temps et des contraintes personnelles, notamment le soir.
Rappel : Des points de pénalités seront appliqués pour tout dépassement de date, quelle qu'elle soit.

Pour pouvoir terminer dans les délais, il est nécessaire de répartir les tâches au sein du trinôme. Il faut commencer par réfléchir ensemble, puis décider de découper le programme en un certain nombre de sous-programmes. Ensuite, il faut se mettre d'accord sur les données que va manipuler ce programme et écrire les prototypes de tous les sous-programmes.

C'est seulement à partir de ce moment que les trois étudiants travaillent séparément, c'est-à-dire décrivent chaque sous-programme en pseudo-langage, puis le traduisent en C++, puis le testent, et écrivent la partie de rapport correspondante.

Enfin, il faut garder un temps suffisant (au moins une semaine) pour regrouper les trois parties, tester l'ensemble, et finaliser le rapport. Prévoir également que des problèmes informatiques peuvent survenir dans la dernière semaine, et conserver toujours la version précédente lorsque des modifications sont apportées.

La répartition des tâches doit être équilibrée, et il n'est pas question qu'un membre du trinôme ne s'occupe que du rapport, ou que des fonctions d'affichage dans le programme par exemple. Lors des soutenances, même si les questions seront plus particulièrement dirigées sur la partie qu'un étudiant a développé, il doit être capable d'expliquer comment fonctionne les autres parties.

Il est possible d'échanger des idées entre les trinômes ; par contre, l'échange de morceaux de programmes entre trinômes n'est pas autorisé.
Cela signifie en particulier que lorsque l'on se fait aider, on doit comprendre l'explication puis essayer de l'intégrer à son programme; en aucun cas, on ne doit intégrer à son projet un fichier qui n'a pas été créé par un membre du trinôme.

Aucune contrainte présente dans ce document ne peut être levée à votre seule initiative. Par contre, si vous avez de bons arguments, vous pouvez venir négocier suffisamment à l'avance pour pouvoir respecter toutes les échéances. Le jour de la soutenance, il sera trop tard.

3  Partie commune aux deux projets

Le programme principal acceptera des commandes et déclenchera les sous-programmes en conséquence, en passant en paramètre tout ce qui est nécessaire (pas de variables globales).
Les données seront sauvegardées dans un fichier de texte. Pendant une session d'utilisation du programme, toutes les données seront chargées en mémoire dans des structures et des tableaux de taille adaptée à chaque session.
Le programme doit pouvoir stocker autant de données que l'on veut ; donc l'utilisation de tableaux statiques est à écarter. Le programme ne doit pas utiliser inutilement de la mémoire ; donc les chaînes de caractères doivent être juste de la longueur nécessaire. Pour ne pas perdre trop de temps, lorsqu'il sera nécessaire d'agrandir un tableau, on lui ajoutera à chaque fois un nombre de cases fixé en constante mais supérieur à 1 (rappel: pas de constantes numériques non nommées).
Toute zone de mémoire allouée dynamiquement doit être libérée lorsqu'elle est devenue inutile.
Enfin, les différentes parties du programme doivent être réparties dans différents fichiers compilés séparément (ce qui ne veut pas dire "un seul sous-programme par fichier").

3.1  Bonus

Attention ! Un programme qui ne fonctionne pas parfaitement ne peut espérer aucun bonus même s'il a des fonctionnalités supplémentaires. Cette possibilité n'est donc à étudier qu'à la fin, lorsque le programme est terminé et en prenant soin d'en conserver une version complète avant modification.

Il est également possible pour des redoublants, après accord préalable de Denis BUREAU, d'utiliser des listes chaînées. Par contre, cela devra être effectué à bon escient et correctement, tout en étant bien expliqué dans le rapport. Il n'y aura pas d'indulgence particulière en ce domaine, et il vaut mieux un programme bien fait avec des tableaux qu'un programme mal fait avec des listes. Par contre, si le programme est bien fait avec des listes, cela donnera lieu à un bonus supplémentaire.

4  Résumé des différentes étapes  nouveau !

1. Avant le vendredi 15 février 2002 à 13h : communiquer la constitution du trinôme et indiquer le choix du projet (ou avoir fait valider le cahier des charges de l'éventuel projet personnel pour les redoublants).
2. Avant le vendredi 8 mars 2002 à 13h : rendre le pré-rapport en 5251.
3. Avant le jeudi 28 mars 2002 à 17h : prendre rendez-vous avec l'enseignant affecté à votre groupe pour la soutenance commune.
4. Avant le mardi 2 avril 2002 à 13h : envoyer le mail à d.bureau pour signaler que le projet est terminé et sur quel compte il se trouve.
5. Avant le mardi 2 avril 2002 à 13h : rendre le rapport final en 5251.
6. Avant le mercredi 10 avril au soir : avoir passé sa soutenance.

5  Projet A : Gestion de répertoire

Le but de cette application est de gérer un répertoire d'adresses.

Cahier des charges détaillé

5.1  Les données

1. L'identification, composée de deux chaînes nom et prénom, et de la civilité qui n'a que 3 valeurs possibles : Mme, Melle, M.
2. L'adresse, composée de deux chaînes voie (toute l'adresse sauf la ville et le code postal) et ville, et le code postal sous forme d'entier naturel.
3. La communication, composée d'un tableau de 7 chaînes (il doit être facile de changer ce nombre) représentant chacune un moyen de communication (téléphone domicile, téléphone travail, téléphone portable, fax, email personnel, email professionnel, site web), et un entier naturel représentant l'indice du moyen de communication principal qui apparaîtra dans la liste non détaillée (NULL sera utilisé pour signifier qu'un moyen de communication n'est pas disponible pour cette personne).

5.2  Les commandes

• C : Charge en mémoire le fichier des adresses en créant les tableaux et structures nécessaires Þ demander confirmation si des modifications non déjà sauvegardées ont été effectuées.
• S : Sauvegarde la mémoire dans le fichier des adresses de telle sorte qu'il soit facile de construire les structures et les tableaux nécessaires lors du rechargement du fichier.
• L : Liste (en les numérotant au fur et à mesure à l'écran) les personnes dans un format abrégé sur une seule ligne (voir paragraphe suivant) ; prévoir un affichage page par page.
• D : Détaille toutes les coordonnées d'une personne (affiche plusieurs lignes pour chaque personne) Þ demander son numéro dans la liste.
• A : Ajoute une personne (à la bonne place dans les tableaux) Þ saisir toutes les informations.
• E : Enlève une personne après confirmation Þ demander son numéro dans la liste.
• ? : Affiche l'aide ; prévoir un affichage page par page et/ou une aide spécifique par commande. Dans tous les cas, les explications seront stockées dans un fichier de texte.
• Q : Quitte le programme Þ propose de sauvegarder le fichier si des modifications non déjà sauvegardées ont été effectuées.

5.3  Affichage abrégé

• numéro d'ordre de la personne : 3 caractères, avec des espaces à gauche si nécessaire.
• espace : 1 caractère.
• civilité : 5 caractères (Mme, Melle, ou M.), avec des espaces à droite si nécessaire.
• espace : 1 caractère.
• nom : 18 premiers caractères, éventuellement suivis de ... si tous les caractères ne sont pas affichés, ou bien complété par des espaces pour que cette partie occupe toujours 21 caractères.
• espace : 1 caractère.
• prénom : 19 premiers caractères éventuellement suivis de ... si tous les caractères ne sont pas affichés, ou bien complété par des espaces pour que cette partie occupe toujours 22 caractères.
• espace : 1 caractère.
• moyen de communication principal : 19 premiers caractères éventuellement suivis de ... si tous les caractères ne sont pas affichés, ou bien complété par des espaces pour que cette partie occupe toujours 23 caractères.
• espace : 1 caractère.
• type du moyen de communication principal : 1 caractère (D, T, P, F, d, t, w).

5.4  Fonctionnalités supplémentaires

• M : Modifie les informations d'une personne Þ demander son numéro dans la liste, puis demander quelle information on veut modifier.
• R : Rechercher des personnes d'après les premières lettres du nom ; si la commande suivante requiert habituellement un numéro dans la liste des personnes, cette commande portera sur la personne trouvée par la recherche sans avoir besoin de saisir de numéro (si la recherche trouve plusieurs personnes, il faudra préciser celle que l'on choisit).
• On pourra optionnellement permettre une recherche plus élaborée sur d'autres critères que le nom.

6  Projet B : Gestion des notes

Le but de cette application est de gérer l'ensemble des notes d'un étudiant.

Cahier des charges détaillé

6.1  Les données

6.2  Les commandes

• CF: Charge en mémoire le Fichier des notes en créant les tableaux et structures nécessaires Þ demander confirmation si des modifications non déjà sauvegardées ont été effectuées.
• SF: Sauvegarde la mémoire dans le Fichier des notes de telle sorte qu'il soit facile de construire les structures et les tableaux nécessaires lors du rechargement du fichier.
  Pour les 3 commandes suivantes, * peut être remplacé par une des trois entités M (pour Module), U (pour UV), ou P (pour Partiel).
• A*: Ajoute une entité (à la bonne place dans les tableaux) Þ saisir toutes les informations.
• D*: Détaille toutes les informations d'une entité (affiche plusieurs lignes pour chaque entité) Þ demander son numéro dans la liste.
• E*: Enlève une entité après confirmation Þ demander son numéro dans la liste.
• LM: Liste (en les numérotant au fur et à mesure à l'écran) les Modules dans un format abrégé sur une seule ligne (voir paragraphe suivant) ; cet affichage sera suivi ou précédé de l'affichage de la moyenne générale coefficientée des modules.
• CM: Calcule les Moyennes coefficientées dans toutes les entités.
• ??: Affiche l'aide ; prévoir un affichage page par page et/ou une aide spécifique par commande. Dans tous les cas, les explications seront stockées dans un fichier de texte.
• QP: Quitte le Programme Þ propose de sauvegarder le fichier si des modifications non déjà sauvegardées ont été effectuées.

6.3  Affichage abrégé

• numéro d'ordre du module : 2 caractères, avec un espace à gauche si nécessaire.
• espace : 1 caractère.
• nom : 20 premiers caractères, éventuellement suivis de ... si tous les caractères ne sont pas affichés, ou bien complété par des espaces pour que cette partie occupe toujours 23 caractères.
• le caractère "deux-points" suivi d'un espace : 2 caractères.
• nombre d'UV : 2 caractères, avec un espace à gauche si nécessaire.
• espace : 1 caractère.
• la chaîne "UV, Moyenne=" sur 12 caractères
• la moyenne au format 2 chiffres+un point décimal+2 chiffres ; éventuellement complété par des zéros, avant comme après le point.
• espace : 1 caractère.
• la chaîne "pour" sur 4 caractères
• espace : 1 caractère.
• la somme des coefficients au format 2 chiffres+un point décimal+2 chiffres ; éventuellement complété par des zéros après le point, mais par un espace avant.
• espace : 1 caractère.
• la chaîne "coefficients" sur 12 caractères

6.4  Fonctionnalités supplémentaires

• M*: Modifie les informations d'une entité Þ demander son numéro dans la liste, puis demander quelle information on veut modifier.
• R*: Rechercher des entités d'après les premières lettres du nom ; si la commande suivante requiert habituellement un numéro dans la liste des entités, cette commande portera sur l'entité trouvée par la recherche sans avoir besoin de saisir de numéro (si la recherche trouve plusieurs entités, il faudra préciser celle que l'on choisit).
• On pourra optionnellement permettre une recherche plus élaborée sur d'autres critères que le nom.
• CC: Calcule les Compensations entre unités suivant les lettres obtenues. Doit afficher le nombre de A, de B, de C, de D, de E, de FX, de F, puis le nombre de FX non compensés, et enfin le nombre de compensations non utilisées.