M1103 Projet 2017 – 2018

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 26 janvier 2018 23h 59min 59 secondes(inclus);
  • une soutenance orale (par groupe de projet) aura lieu lors de la semaine du 29 janvier (2018);
  • les délégué(e)s des groupes doivent envoyer un email (aux deux enseignants), le vendredi 22 décembre 2017 à 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 vendredi 26 janvier 2018 24h (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;
  • Votre fichier .pro doit obligatoirement contenir la ligne suivante QMAKE_MAC_SDK = macosx10.13. Elle n’aura aucune incidence sur votre compilation sur GNU / Linux, mais elle me permettra de compiler (et donc de tester) vos projets.

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 : Ne perdez pas de temps à faire une IHM, ce n’est pas l’objectif.

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

Il doit être remplacé par celui-ci

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.