M1103 – Projet 2020 – 2021

Le projet

Le fichier de solution est une ébauche de solution. Vous disposez d’un peu plus de 1 mois pour y ajouter toutes les fonctionnalités que vous souhaitez (sans pour autant changer de langage de programmation).
  • Le projet est obligatoire, sa note complète votre note en M1103 (Note Algo / Prog 2° module du S1);
  • vous devez constituer des groupes d’étudiants (4 personnes minimum, 5 personnes maximum, appartenant au même groupe de TD) pour effectuer le projet;
  • la date maximale de rendu de projet est fixée au vendredi 22 janvier 2021 12h 00min 00 secondes(inclus) – ie avant midi;
  • une soutenance orale (par groupe de projet) est prévue entre le 25 et le 27 janvier (2021);
  • les délégué(e)s des groupes doivent envoyer un email (aux deux enseignants), le mercredi 16 décembre 2020 à 18h, fixant la composition des équipes.

La documentation

Doxygen est un puissant outil permettant de générer automatiquement une partie de la documentation de votre projet de C++. Pour lancer cet outil sur les ordinateurs du département, entrez simplement doxywizard dans un terminal Linux. Une fois que vous êtes sûr que votre code est “fonctionnel”, ajouter les balises nécessaires en suivant cette aide. Veillez à bien activer dans doxywizard :
  1. les références croisées entre le code source et la sortie;
  2. la générations des graphes des fonctions appelantes et appelées.
Faites des tests jusqu’à que ce votre fichier de sortie ressemble à celui fourni dans la correction. Ce fichier est le fichier généré par la solution (partielle) du projet. NB: vous pouvez aussi consulter cette la video ci-dessous si vous souhaiter lier Qt Creator et Doxygen.

Le rendu de projet

    • Vous devez envoyer par email à Marc Laporte et à Alain Casali une archive zip (pas d’autre format) de votre rendu de projet avant le dimanche 19 janvier 2020 23h 59min 59 secondes (un lien sur le web où on puisse télécharger votre projet est aussi accepté);
    • L’archive devra être nommée selon cette nomenclature : GX_Nom1_Nom2_Nom3.zip.
      1. X désigne votre numéro de groupe de TD;
      2. Nom1, Nom2, … sont les noms des étudiants composants le groupe ordonné alphabétiquement.
      Par exemple, si je fais parti du groupe 6 et que je fais un projet les noms des étudiants de nom groupe sont : Casali, Ernst, Laporte et Quetelard alors l’archive à envoyer sera nommée G6_Casali_Ernst_Laporte_Quetelard.zip;
    • L’archive a envoyée est l’archive de votre projet générée par QT Creator (elle ne doit pas contenir d’exécutable).
    • Sa structure est la suivante :
       G6_Casali_Ernst_Laporte_Quetelard
       |Correc_prof
       |Doc
       |Nos_fichiers
       G6_Casali_Ernst_Laporte_Quetelard.pdf
       G6_Casali_Ernst_Laporte_Quetelard.pro
       main.cpp
      
      NB : le caractère '|' sert à matérialiser un sous-dossier.
    • Vous ne devez pas modifier les fichiers se trouvant dans le répertoire Correc_prof;
    • Tous vos ajouts / modifications doivent être dans le répertoire Nos_fichiers;
    • Le répertoire Doc contient la documentation, en français ou en anglais, de votre projet générée par Doxygen. Cette dernière n’est relative qu’à vos fichiers (i.e. ceux présents dans le répertoire Nos_fichiers);
    • Si vous avez besoin de lire des fichiers textes (ou binaires), les chemins vers ceux-ci doivent être mis en chemin relatif. Par exemple, supposons que je veuille lire le fichier config.yaml, alors dans mon code source, le chemin vers ce fichier sera ../G6_Casali_Ernst_Laporte_Quetelard/Nos_fichiers/config.yaml;
    • Le fichier GX_Nom1_Nom2_Nom3.pdf (dans notre exemple G6_Casali_Ernst_Laporte_Quetelard.pdf) est une documentation succincte expliquant quelles sont les modifications que vous avez apportées et comment vous avez testez vos nouvelles fonctionnalités afin de vous assurer qu’elles ne contiennent pas d’erreur. Vous pouvez inclure vos fichiers de tests dans votre documentation / rendu de projet;
. Vous trouverez ici une ébauche de ce qui est attendu. Dans cette ébauche :
  1. Nous avons ajouté la lecture du fichier de configuration au format YAML;
  2. Nous avons répercuté la prise en compte de ces paramètres dans certaines fonctions (mais pas dans toutes);
  3. Nous avons généré une partie de la documentation en conséquence;
  4. Il manque cependant la documentation (fichier pdf) expliquant les modifications apportées.
Remarque : Vous pouvez utiliser MinGL comme bibliothèque graphique.

Soutenance orale

Lors de votre soutenance, vous aurez 15 minutes (maximum) pour effectuer une présentation via diaporama afin d’expliquer quels sont les apports de votre projet par rapport à la version initialement proposée. S’en suivra une discussion de 15 mn.

Pénalités

La liste de pénalités suivante n’est pas exhaustive :
  1. Projet rendu en retard : -1 pt par heure d’envoi de l’email (les emails sont horodatés);
  2. Copie sur un autre groupe (on ne savait pas comment implémenter telle ou telle fonctionnalité dont on avait besoin pour aller plus loin, on l’a donc copiée sur un autre groupe), plusieurs cas se distinguent :
    • si le groupe est clairement nommé, cette fonctionnalité ne sera pas prise en compte dans la notation;
    • si le groupe est clairement nommé, et qu’il y a une amélioration de la fonctionnalité, (note pour la fonctionnalité / 2 – seulement la moitié du travail a été réalisée);
    • 0 aux deux groupes sinon.
    Deux groupes peuvent développer la même fonctionnalité, mais ils ne doivent pas avoir la même implémentation, les mêmes jeux d’essais.

Mode non canonique

Afin de rendre le jeu plus réactif, certains souhaitent ne plus valider la saisie des touches en utilisant la touche entrée. C’est possible en utilisant le mode dit “non canonique”. Vous pouvez le faire en copiant le code ci-dessous
//http://www.gnu.org/software/libc/manual/html_node/Noncanon-Example.html
void set_input_mode (void)
{
struct termios tattr;

/* Make sure stdin is a terminal. */
if (!isatty (STDIN_FILENO))
{
fprintf (stderr, "Not a terminal.\n");
exit (EXIT_FAILURE);
}

/* Set the funny terminal modes. */
tcgetattr (STDIN_FILENO, &tattr);
tattr.c_lflag &= ~(ICANON|ECHO); /* Clear ICANON and ECHO. */
tattr.c_cc[VMIN] = 0;
tattr.c_cc[VTIME] = 3;
tcsetattr (STDIN_FILENO, TCSAFLUSH, &tattr);
}
Comme indiqué dans la documentation de la struct termios, l’instruction tattr.c_cc[VTIME] = 3; a pour conséquence d’attendre activement qu’une touche soit appuyée pendant 0,3s. De plus, si le mode non canonique est activé la lecture d’un caractère ne peux plus se faire en utilisant le flux cin. Autrement dit, le code ci-dessous ne fonctionnera plus
char c;
cin<< c; 
&#91;/cpp&#93;</pre>
Il doit être remplacé par celui-ci
<pre>[cpp]
char c;
read (STDIN_FILENO, &c, 1);
Pour pouvoir passer du mode non canonique au mode canonique (et donc continuer d’utiliser le flux cin), la solution se trouve ici.