LIFAP4 Conception et développement d'applications --- Projet






Emploi du temps

Les dates clés:

  • Mardi 22 janvier : premier cours
  • Jeudi 14 février : CC individuel mi-parcours
  • Vendredi 15 février : date limite du dépôt du module Image sur TOMUSS à 18h
  • A partir du mardi 26 février : TP réalisation du projet
  • Jeudi 7 mars : date limite du dépôt du cahier des charges sur TOMUSS à 18h
  • Mardi 26 mars : démo intermédiaire du projet
  • Lundi 6 mai : date limite du dépôt du projet sur TOMUSS à 18h
  • Mardi 7 mai: soutenance du projet




Cours et TD

Cours 1 : Conception et gestion de projet

>>Télécharger les transparents du cours

  • Notions de gestion de projet
    • Méthodes de conception
    • Cahier des charges
    • Diagramme de Gantt
  • Programmation modulaire/classes
    • Diagramme des classes


Cours 2 : Outils et règles pour la programmation

>>Télécharger les transparents du cours

  • Compilation de fichier (G++)
  • Compilation de projet (Makefile)
  • Débogage (gdb)
  • Règles de programmation


Cours 3 : IHM/Librairies

>>Télécharger les transparents du cours

  • Une IHM : qu'est-ce que ca change?
  • en TXT
  • avec SDL2
  • avec un framework plus conséquent (Qt, Gtk, etc.)


Cours 4 : Gestion du code

>>Télécharger les transparents du cours


TD Conception de logiciel
TD outils 1 : Editeur de code, débogueur et diagramme


TD outils 2 : Gestion de mémoire/Optimisation de code


TD outils 3 : Bibliothèques


TD outils 4 : Gestionnaire de version




Evaluation

  • Un contrôle mi-parcours de 1h30 (40%) avant la phase de réalisation du projet
  • Evaluation du module “Image” (TDs outils) (10%)
  • Projet (50%) : Cahier des charges (2%), Démo mi-projet (3%), 3 notes finales “Technique”, “Conception” et “Organisation” (3×15%). Regardez dans la section Projet de cette page pour le détail des notes.




Rendu du module Image (TD outils)

  • Votre archive sera testée avec un script particulier (cf. plus bas). Vous devez donc respecter exactement le format attendu par ce script sinon vous aurez la note zéro.
  • Déposez votre archive sur TOMUSS, dans la case DepotModuleImage du cours. Vous devez respecter l'heure limite car le dépôt sera désactivé après l'heure limite. Une soumission en retard (par email ou autre) entraînera la note zéro pour tout le groupe. Un seul dépôt par groupe d'étudiants (sur n'importe lequel des comptes).


Votre module Image doit respecter les conventions suivantes:

  • A faire en groupe de 3 (2 ou 4 si accord donné par un enseignant)
  • Votre archive s'appelle NUMEROETU1_NUMEROETU2_NUMEROETU3.tgz ou NUMEROETU1_NUMEROETU2_NUMEROETU3.tar.gz (pas de zip) où NUMEROETU1 est le numéro étudiant du premier membre du groupe etc.
  • Tous les fichiers se décompressent dans un répertoire ayant pour nom NUMEROETU1_NUMEROETU2_NUMEROETU3 (même nom que l'archive)
  • Ce répertoire doit contenir les sous-répertoires bin, src, obj, data et doc
  • Le fichier Makefile compile les trois programmes (vous pouvez travailler avec un projet CodeBlocks mais il faut tout de même fournir un Makefile fonctionnel) :
    • bin/exemple exécute le code génèrant les images en sortie (i.e. exécute mainExemple.cpp)
    • bin/test appelle testRegression (test de non-régression qui vérifie tout) et affiche les tests effectués à l'écran (i.e. exécute mainTest.cpp)
    • bin/affichage fait l'affichage de l'image dans une fenêtre SDL avec zoom/dézoom (i.e. exécute mainAffichage.cpp)
  • Readme.txt est un fichier texte expliquant la librairie. Au minimum comment compiler et exécuter, ce que fait le module et chacun des exécutables, l'organisation de l'archive etc. et il doit indiquer les noms/prénoms/numéros des étudiants.
  • Vos fichiers sources (.h et .cpp) sont placés dans le dossier src
  • Les images sauvées et lues seront toujours placées dans le dossier data
  • doc/image.doxy est le fichier de configuration de doxygen
  • doc/html/index.html est la page d'entrée de la documentation (générée avec doxygen)

Ces conventions sont très répandues, et il serait de bonne habitude de les appliquer pour tous vos rendus de TP (info ou autres), ou vos projets futurs publiés sur internet. Vous utiliserez notamment ces conventions pour votre projet.


Vous n'avez pas le droit de modifier le code fourni. Les programmes principaux, les noms des fichiers, des classes, des fonctions, des données etc. doivent être exactement les mêmes que ceux donnés. Ceci conditionne fortement le succès du script.


Script de test du module Image

Votre archive du module Image sera testée avec le script présent dans le répertoire TD_moduleImage fourni durant le TD ici, s'appelant evalModuleImage.py (script Python). Avant de soumettre votre archive, vérifiez que l'exécution du script se déroule sans erreur en tapant la commande :

python3 evalModuleImage.py NUMEROETU1_NUMEROETU2_NUMNUMEROETU3.tgz

Précision sur ce script :

  • Si le script échoue à une étape, le correcteur n'ira pas plus loin (même si la suite est juste).
  • Si le script rapporte des erreurs, corrigez les avant de soumettre votre archive.
  • Le script vous donne également une note INDICATIVE à la fin. Pour la note finale, des vérifications supplémentaires (non automatiques) seront effectuées par les enseignants.

Précision technique sur ce script :

  • Ce script doit tourner sous Linux avec python3 (uniquement Linux à cause de valgrind). Si vous l'exécutez sur votre machine personnelle, il faut installer python, doxygen, valgrind, SDL2, etc.
  • Si votre code nécessite l'utilisation du standard C++11 ou plus, n'oubliez pas d'ajouter l'option -std=c++11 (ou plus) dans les lignes de commande g++ de votre Makefile.
  • Sous MacOS vous devez installer une machine virtuelle Linux.
  • A la ligne 15 du script changez le booléen VERBOSE à True pour que le script affiche plus de détails, ça peut vous aider à deboguer
  • Si le message suivant apparaît :
    File "evalModuleImage.py", line 120
       print("Numeros des etudiants =", end=' ')
    SyntaxError: invalid syntax​
    

Vous devez utiliser Python 3 (Python 2 produit ce type d'erreur).



Installation pour faire tourner le script (Linux et Windows)


Sous linux, vous devez installer python3, valgrind, doxygen et tout SDL2 :

sudo apt install python3 valgrind doxygenlibsdl2-dev libsdl2-image-dev libsdl2-ttf-dev libsdl2-mixer-dev

Sous windows, installez Window Subsystem (qui est comme une machine virtuelle en bien plus léger, ne prend pas de partition supplémentaire, ne demande pas de double boot, etc.).




Réalisation du projet en TP

Sujet et critères de notation

Vous êtes libre du sujet de votre projet, mais discutez-en avec les intervenants de TD et TP afin d'obtenir leur accord. Si vous êtes en panne d'inspiration, voici quelques idées de sujets.

  • Le projet est à réaliser en groupe de 3 (2 ou 4 toléré si justifié)

Cahier des charges

Après quelques séances de conception et développement, vous devez rédiger et soumettre un cahier des charges (case 'DepotCahierDesCharges' sur Tomuss au format pdf, un seul dépôt par groupe). Ce cahier des charges reprend l'organisation vue en cours et en TD. Il doit comporter au moins une présentation du projet, une description détaillée de l'application (ex. règles du jeu ou fonctionnalités du logiciel), une liste exhaustive et détaillée des tâches à réaliser, un diagramme des classes et un diagramme de Gantt (tous les deux prévisionels). Ce document fait typiquement entre 4 et 10 pages.

Démo mi-parcours

A la moitié de votre projet, vous donnerez une démonstration aux intervenants de 10 minutes, qui sera suivie de quelques questions. Le but de cette démonstration est de faire un point sur ce qui marche et ce qui reste à faire, ainsi que de présenter l'organisation et la gestion de votre projet en général. Vous devez donc à la fois montrer ce que votre application est déjà capable de faire, mais aussi que vous avez les capacités à finaliser le projet à temps.

Soutenance

La soutenance dure 20 min = 15 min de présentation + démo, suivi de 5 min de questions
La présentation devra être réalisée sous Powerpoint (le mieux est de générer un PDF pour des raisons de compatibilité).
Quelques conseils pour la présentation (entre 8 et 10 minutes):

  • Il s'agit d'une présentation technique. Passez donc rapidement sur l'interface graphique et les fonctionnalités, sur lesquelles vous pourrez plus vous attarder durant la démo. La majeure partie devra être consacrée à expliquer comment vous avez conçu et programmé votre application, en décrivant les modules et les structures correspondantes.
  • Le fruit d'un travail de plus de 40h doit être décrit en quelques minutes, ce qui est très court. Allez rapidement à l'essentiel ! Le planning étant très serré, vous serez interrompu si vous dépassez le temps imparti.
  • Pour les projets réalisés en groupe, le temps de parole devra être équitablement réparti entre les étudiants.
  • Le meilleur aperçu de la conception de votre projet reste le diagramme des modules. Soignez sa présentation !

Plan de la présentation : un Powerpoint de quelques slides est un maximum et devrait être suffisant. Voici un plan possible :

  • Slide 1: Titre du projet, auteurs, principe de l'application (très rapide, avec une capture d'écran)
  • Slide 2: Vue d'ensemble du diagramme des modules (donc le diagramme doit être à jour)
  • Slide 3 à n-1: Explications détaillées des 3 ou 4 modules les plus importants et/ou les plus intéressants (ex. ceux dont vous êtes les plus fiers, sur lesquels vous avez passé le plus de temps)
  • Slide n: Conclusion. Attention à éviter les banalités du style “Le projet a été intéressant…” (ou l'inverse !). Les intervenants vous ont suivis pendant un semestre et ont déjà leur idée là-dessus ! Décrivez par exemple ce qui marche et ce qui ne marche pas (les objectifs initiaux du cahier des charges ont-ils été atteints?), les éventuelles difficultés rencontrées, et ce que vous (re)feriez avec un peu (ou beaucoup) plus de temps.

Quelques conseils pour la démo (entre 5 et 7 minutes):

  • Le code doit être compilé, et la démo doit être lancée via l’exécutable
  • Préparez la démo pour être lancée tout de suite après la présentation (ex. sur votre ordinateur portable)
  • Répétez les actions que vous voulez illustrer, concentrez vous sur ce qui fonctionne (soyez vendeur!)
  • Utilisez le plein écran si approprié, prévoyez de quoi entendre sons et musiques si besoin
  • Si nécessaire, testez votre démo avant sur écran externe (ie. apprenez comment afficher en double écran sur votre machine)

Faîtes au moins une répétition complète pour éviter les surprises (timing, démo qui fonctionne pas, etc.).

Travail à rendre (case 'DepotProjetFinal' dans Tomuss)

Préparer et soumettre une archive suivant les mêmes conventions que le module Image nommée NOM_PROJET_NUMEROETU1_NUMEROETU2_NUMEROETU3.tar.gz et contenant au minimum:

  • Un readme.txt à la racine de l'archive contenant au moins
    • les informations factuelles du projet : noms, prénoms, numéros étudiant et identifiant du projet sur la forge
    • un manuel : commandes de compilation et d'exécution, règles du jeu ou utilisation de l'application, la liste des fonctionnalités du programme
    • une description de l'organisation de votre archive
  • Tout le code (dans le répertoire src)
  • Un makefile (dans le répertoire racine)
    • Attention, toute autre librairie que la SDL devra être incluse dans l'archive
  • Les assets de votre application (dans le répertoire data, ex. images, sons, modèles 3D, fonts, fichiers de configuration)
  • Les exécutables (dans le répertoire bin)
  • La documentation de votre projet (dans le répertoire doc) contenant au minimum
    • La présentation orale (fichier PowerPoint ou pdf)
    • Le diagramme des modules à jour (fichier image ou pdf)
    • Le diagramme de Gantt à jour (fichier image ou pdf) avec une description de qui a fait quoi dans le projet (associations entre les tâches du diagramme et les étudiants)
    • La documentation du code (dans le répertoire doc/html, générée par doxygen)

Veillez à bien nettoyer votre archive avant soumission, i.e. supprimer les fichiers inutiles (fichiers objets, dossiers/fichiers git etc.).




Lien vers documentations et tutoriels

Git et la FORGE LYON 1

SDL

  • Pour installer SDL2 sous Linux
$> sudo apt-get install libsdl2-dev libsdl2-image-dev libsdl2-ttf-dev libsdl2-mixer-dev

Librairies GTK+

Framework Qt

$> sudo apt-get install qtcreator qt5-default

Diverses lib qui peuvent servir

Divers


Les 12 commandements de Git

  • git clone URL : récupère en local une copie du dépôt central (web) repéré par l’URL
git clone https://forge.univ-lyon1.fr/Alexandre.Meyer/L2_ConceptionDevApp.git
  • git commit –m “message” FILES : envoie les modifications de FILES du répertoire de travail vers le dépôt local. FILES peut contenir un répertoire comme “.” pour commiter tous les fichiers de ce répertoire. IL FAUT UN FILES.
git commit –m "ajout de f affichage"  .
  • git push : envoie les modifications du dépôt local vers le dépôt central (web)
  • git pull : mise à jour du dépôt local et des fichiers locaux
  • git status [path] : affiche l‘état des fichiers du répertoire path, tous les fichiers si vide
  • git log : donne tout l’historique des versions
  • git add [FILES] : le fichier path est noté “à ajouter” lors du prochain commit, fonctionne récursivement.
  • git rm [FILES] : le fichier est noté “à effacer” lors du prochain commit, fonctionne récursivement.
  • git mv src dest : déplace un fichier/répertoire et note le renommage pour le prochain commit, conserve l'historique
  • git checkout [FILES] : remet FILES de la copie de travail dans l’état HEAD (la dernière version commit)!!! Perte des changements.
  • git reset HEAD^ : annule le dernier commit et reviens à l’avant dernier.
  • git tag : Liste toutes les versions qui ont un tag
  • git tag –a TAG –m “msg” : ajoute un TAG à la version courante
git tag -a v1.4 -m "my version 1.4"
$ git tag
v0.1
v1.3
v1.4
  • git commit : après résolution de conflit, ATTENTION : le git commit n'a pas de FILES. Par exemple après un conflit tur toto.cpp. Sans -m git ouvre l'éditeur de texte avec un message pré-écrit qui indique que le conflit est résolu.
$ git commit -m "resolution conflit"
$ git push