Home Research&Publications Teaching Intranet login

Table des matières

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





Emploi du temps et dates importantes

Les dates clés du printemps 2023 :

  • Mardi 17 janvier : premier cours
  • Jeudi 23 fevrier : date limite du dépôt du module Image sur TOMUSS à 18h
  • Mardi 28 février : CC individuel mi-parcours en amphi
  • A partir du mardi 28 février : TP réalisation du projet
  • Lundi 6 mars : date limite du dépôt du cahier des charges sur TOMUSS à 18h
  • Mardi 21 mars : démo intermédiaire du projet
  • Lundi 1 mai : date limite du dépôt du projet sur TOMUSS à 18h
  • Mardi 2 mai : soutenance du projet


Cours

supports_de_cours.jpg

Cours 0 : Introduction de l'UE

>>Télécharger les transparents du cours

>>Visionner la vidéo du cours

Cours 1 : Conception et gestion de projet

>>Télécharger les transparents du cours

>>Visionner la vidéo du cours

  • Méthodes de conception
  • Cahier des charges
  • Diagramme de Gantt

Cours 2 : Programmation modulaire

>>Télécharger les transparents du cours

>>Visionner la vidéo du cours

  • Diagramme des classes (UML)
  • Règle d'intégrité
  • Règles de programmation

Cours 3 : Outils pour la programmation

>>Télécharger les transparents du cours

>>Visionner la vidéo du cours

  • Compilation de fichier (GCC)
  • Compilation de projet (Makefile)
  • Débogage (gdb)

Cours 4 : Gestion du code

>>Télécharger les transparents du cours

Cours 5 : Notions de programmation C++ avancée

>>Télécharger les transparents du cours

  • Test de regression
  • Valgrind : debug mémoire + profiler
  • Arguments de main
  • Introduction aux operator et aux template en C++
  • Introduction à la STL : string, vector, list, etc.
  • Notion de POO/héritage pour pouvoir introduire les frameworks gérant une interface (Qt)

Cours 6 : Interface Graphique (Graphical User Interface)

>>Télécharger les transparents du cours

  • Une interface, qu'est-ce que cela change ?
  • Notion de callback/pointeurs de fonctions
  • Principe d'organisation du code (introduction rapide à la notion de MVC)
  • Interface en mode texte (un menu)
  • Avec SDL2 + 2 mots sur SFML
  • Avec “Dear ImGui”
  • Avec un framework plus conséquent : Qt

TD

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 (les différentes notes)

  • 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 2 ou 3
  • 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 puis regarder plus bas la doc d'installation Linux.
  • Sous Windows, installer WSL en regardant plus bas les explications sur les installations
  • 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).

Machine distante de l'université pour faire tourner le script

L'université a une machine spécifiquement dédiée à lancer le script sur votre archive avec un ssh -X. Voir les explications ici (Merci Franck).

Installation pour faire tourner le script (Linux et Windows-WSL)

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

sudo apt install python3 valgrind doxygen libsdl2-dev libsdl2-image-dev libsdl2-ttf-dev libsdl2-mixer-dev imagemagick

Sous Windows, installer WSL (voir plus bas) puis depuis le terminal où vous êtes sous Linux faire comme ci-dessus.

Installation pour faire tourner le script (MacOS)

Mise en place des outils en ligne de commande sous MacOS (Merci Erwan).

Projet : réalisation en TP

idea.jpg

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 2 ou 3 maximum (4 n'est pas possible)
  • N'oubliez pas de lire les règles à respecter lors de la conception et la réalisation d'un projet
  • Regardez également les critères de notations (notes “Technique”, “Conception” et “Organisation”) dont le détail est ici (IMPORTANT A LIRE)
  • Vous devez être autonome ET nous montrer régulièrement l'état d'avancement de votre projet. Un groupe dont les membres arrivent à 10h voir plus tard, voir pas du tout et qui, tout d'un coup, une semaine avant la soutenance ont un projet bien abouti, sera considéré comme très très suspect.
  • Travail en équipe : vous disposez de 100 points par projet. A la fin du projet, vous affectez ces points à chacun des membres du groupe en fonction du degré d'implication. Par exemple, un groupe équilibré avec une personne un peu plus leader donnera 30, 30 et 40 points. Cette information servira à moduler les notes de chacuns (voir les critères de notation dans la grille). La modulation peut aller plus loin que juste les points sur l'organisation du travail. Un étudiant non impliqué peut avoir une note très faible sur les 3 parties, loin du reste du groupe.

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 (UML) et un diagramme de Gantt (tous les deux prévisionels). Ce document fait typiquement entre 4 et 10 pages.

Réaliser votre diagramme des classes (UML)
  • Les bases d'un diagramme de classes sur wikipedia. Nous n'utilisons que la notion d'association (et un peu héritage) en LIFAP4 pour les relations entre classes
  • Voir la section “Outils UML / diagramme des classes” en fin de page (faites une recherche sur la page) pour des applications de réalisation du diagramme des classes

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 classes 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 classes (UML). 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 classes (UML) (donc le diagramme doit être à jour)
  • Slide 3 à n-1: Explications détaillées des 3 ou 4 classes 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 classes UML à 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.).

Liens vers des documentations, outils et tutoriels utiles

WSL pour faire tourner un Linux ultra léger sous Windows

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

WSL version 1

  • Depuis le terminal Ubuntu, faire
   export DISPLAY=":0.0"

Tester avec xclock (il faut l'avoir installé avec     sudo apt install x11-apps
  • Pour ne pas refaire ca à chaque fois, il faut définir l'écran local comme l'écran du “display” en ajoutant la ligne export DISPLAY=“:0.0” dans votre fichier .profile ou .bashrc. Lancez Ubuntu puis le fichier .bashrc doit être là dans ${HOME}

WSL version 2

  • Avec WSL2, il y a plus de choses à faire, voir la page de LIFASR5
    • le pare-feu, voir la page de LIFASR5
    • mettre les deux variables DISPLAY et LIBGL_ALWAYS_INDIRECT dans ~/.bashc ⇒ pour SDL j'ai dû mettre LIBGL_ALWAYS_INDIRECT à 0 contrairement à ce qu'indique nombre de sites web.
   export DISPLAY=$(grep -m 1 nameserver /etc/resolv.conf | awk '{print $2}'):0
   export LIBGL_ALWAYS_INDIRECT=0

En cas de problème

  • Problème d'autorisation: can't display :0.0
    Si vous avez des problèmes de connexion/d'authentification essayer aussi de décocher “disable access control” en lançant le programme C:\Program Files (x86)\Xming\Xlaunch.exe. C'est à la dernière question. Puis relancez XMing.
  • Regardez le fichier de log de XMing : depuis l'icône de XMing en bas dans la barre, bouton droit, View Log. Si dans ces log vous voyez que XMing a refusé une connexion, alors essayer de basculer à “disable access control” de la ligne ci-dessus. Dans le fichier “C:\Program Files (x86)\Xming\X0.hosts” ajouter les lignes avec l'adresse IP qui a été refusée dans les logs. Par exemple
172.19.199.187
  • Il faudra potentiellement refaire ca à chaque reboot (car l'adresse IP de la distribution change). Je cherche pour automatiser ceci …
  • Si le fichier de log reste vide, c'est que la demande d'ouverture de fenêtre a été bloquée avant par le pare-feu
  • La doc de Xming


Les commandes WSL dans un power shell 

wsl --set-default-version 2               # définir la version 2 par défaut pour la prochaine installation
wsl -l -v                                 # afficher les versions
wsl --list --verbose                      # afficher les versions
wsl --set-version <votre ditribution> 2   # Convertir la distribution <votre distribution> en version 2

Git et la FORGE LYON 1

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

Outils UML / diagramme des classes

  • Umbrello UML modeller (Linux) est un programme permettant de modéliser les différents diagrammes UML (Unified Language Diagram)
  • Dia est un programme pour dessiner des diagrammes
  • StarUML
  • www.diagrams.net : app en ligne ou app à installer (simple, léger et efficace)
  • Outils online Viual-paradigm. Choisissez “Class diagram”
  • Ce lien répertorie différents outils pouvant être utilisés pour définir des diagrammes de modules
  • Remarque : normalement sur les machines du Nautibus, Umbrello et Dia sont installés, sinon utilisez un outil en ligne.

SDL

  • Pour installer SDL2 sous Linux
$> sudo apt-get install libsdl2-dev libsdl2-image-dev libsdl2-ttf-dev libsdl2-mixer-dev
  • SFML : une alternative à SDL. SFML offre une interface simple vers les différents composants de votre PC, afin de faciliter le développement de jeux ou d'applications multimedia.

Framework Qt

$> sudo apt-get install qtcreator qt5-default

Diverses lib qui peuvent servir

  • imgui : se greffe par-dessus SDL (et plein d'autres framework, même Qt) pour ajouter des Widgets sympa, sans s'“embêter” avec Qt. Vraiment COOL !!!

Les méthodes de conception

Divers