Programmation orientée projet
Topic outline
-
Programmation Orientée Projet (en C++)
pour étudiants de Microtechnique et ElectricitéLe cours utilise et complète ce MOOC :
Projet du semestre de printemps 2024-25 : the great Linked-Crossing challengeOrganisation de l'évaluation sem2 2025:
Projet de programmation (3 rendus + 1 oral individuel aléatoire) = 65%
Examen écrit 11 avril de 14h à 16h = 35%
Horaires, Planning, Dates importantes :
- COURS ex-cathedra en présentiel au CO1 de 14h à 16h, seulement sur 7+1 semaines ( 7 x 2h = 14 x 1h) ; consulter le planning détaillé ci-dessus. Le cours sera aussi donné en streaming sur ce WEBINAR avec un.e TA en-ligne pour répondre aux questions. La video sera mise à disposition après le cours sur moodle.
Composante de contrôle continu (65% de la note finale):- 3 rendus de projet aux dates suivantes : 30 mars, 27 avril, 25 mai
- Tous les rendus de projet peuvent donner lieu à un oral individuel sur le fonctionnement du projet (contrôle aléatoire), à partir de la semaine 10
- Tous les cas de détection de plagiat donneront systématiquement lieu à une convocation individuelle en présentiel
-
S'inscrire pour pouvoir suivre ce MOOC dès la PREMIERE semaine du semestre ; l'heure hebdomadaire en auditoire sera effectuée en classe inversée, ce qui requiert d'avoir suivi la leçon et les quizzs du MOOC avant l'heure de la classe inversée.
-
------------------------------------- Donnée PROJET ----------------------------------------
un état du jeu ; notez que dans cette configuration le faiseur ne détruit pas la chaîne car cela n'arrive que lorsqu'une articulation se trouve à l'intérieur d'un des cercles du faiseur, ce qui n'est pas le cas ici.
-
15.04: fichier tests private avec leur sortie attendue
11.04: notes du code: architecture, classes, style + grading_guidelines
11.04: notes d'exécution V2 (cf message sur newsgroup pour la pondération)
10.04: notes d'exécution (cf message sur newsgroup pour la pondération)04.03: public.zip contient un fichier correct supplémentaire t15.txt qui implique un calcul de réflexion
04.03: quelques corrections purement syntaxiques sur la donnée
28.02: donnée V1.0, mysciper.txt
26.02: constantes.h, public.zip
24.02: module message
-
12.05: rendu2 => grading guidelines + notes execution + notes rapport / Architecture / Classes / Style
01.05: testrd2 = fichier de test utilisés pour noter le rendu2 = sous-ensemble de fichiers déjà connus pour le rendu1 ou fournis sur edstem avant la date de rendu + tests archi-simples supplémentaires pour tester le comportement des particules.
04.04: correction de la date visible sur le pdf du rendu2 => c'est bien le 27 avril qu'il faut le téléverser au plus tard.
03.04: le module gui est disponible avec le minimum nécessaire pour construire un exécutable de test
Il n'y a pas d'autograder pour les rendus 2 et 3 mais quelques fichiers de test seront fournis.
-
25.06: notes + grading guidelines + fichiers de test
01.05: donnée du rendu3
-
dernière mise à jour: 4 mars 2025
-
Cours : Introduction au second semestre / présentation de la programmation modulaire et de la compilation séparée / INSCRIPTION DES GROUPES
TP h1: make et makefile
TP h2: présentation des méthodes de développement de programme avec quelques questions théoriques
-
la date de l'examen écrit est le 11 avril et pas le 4 avril
-
Avec questions Quizz:
Pour la première question, la bonne réponse est B) car au moment où le compilateur compile (séparément) prog.cc il n'a pas accès au code source de l'implémentation du module calcul et donc il ne dispose pas de la définition complète de la fonction div. Par contre il a inclus l'interface et il dispose au moins de la déclaration de la fonction div() ce qui permet de vérifier que la syntaxe de l'appel est correcte. La compilation produit simplement une instruction d'appel de fonction qui sera complétée à l'étape d'édition de liens quand on aura (enfin) aussi le code objet calcul.o.
Pour la seconde question: c'est la réponse A) car le fichier d'interface est inclus dans prog.cc ; s'il change prog.cc doit être recompilé.
-
Suivre le MOOC semaine_1 / Introduction avant la classe inversée
Cours h1: Lien entre le MOOC semaine1 programmation orientée objet et la programmation modulaire
Cours h2: vue générale du projet : fonctionnement, architecture modulaire, classes et types concrets
TP h1: exercices MOOC semaine 1
TP h2: prise de connaissance de la donnée du projet / cf avant le Topic1 sur moodle
-
04.03.2025: version des slides 2025
réponse aux Quizzes (cf video):
quizz1: B car les champs d'une classe sont private par défaut
quizz2: C car la variable b n'est déclarée qu'après y
quizz3: A, cas sans souci
quizz4: A, pas de pb avec print() car il y a surcharge ; le compilateur peut les distinguer.
quizz5: B, collision sur reset() ; détection d'ambiguïté même s'il n'y pas appelé dans prog. le type de la fonction n'est pas pris en compte pour les distinguer.
quizz6: A, plus de pb grâce à namespace tools ; syntaxe comme pour la définition des méthodes d'une classe
quizz7: A, plus de pb grâce à namespace tools ; autre syntaxe possible
quizz8: La réponse est "Non" car, même si techniquement il y a une encapsulation stricte avec les attributs en private, cette protection est contournée en offrant un manipulateur qui affecte directement la valeur des paramètres aux attributs sans aucun controle. Il y a donc là aussi une perte de contrôle du module Datum sur la validité des instances du type Datum.
-
chaque quizz portant sur namespace est illustré dans son répertoire avec son Makefile.
en réponse à une question sur "using namespace tools;" dans prog1.cc, un réprtoire supplémentaire illustre l'impact de cet ajout. Conclusion: pas d'erreur de compilation si on n'appelle pas la fonction reset(). Par contre une erreur est détectée dès qu'on enlève l'instruction en commentaire.
-
L'exercice 2 est optionnel ; utilisez ce temps pour la série théorique avancée sur le développement de projet.
-
-
Suivre le MOOC semaine_2 / Constructeur_Destructeur avant la classe inversée
Cours h1: classe inversée constructeur / destructeur
Cours h2: lecture de fichier, préprocesseur
TP h1: lecture de fichier, préprocesseur et stubs, questions avancées sur la notion de type concret
TP h2: exercices MOOC semaine 2
-
Quizz1: La bonne réponse est E car un constructeur ayant été défini, le compilateur ne met pas en place le constructeur par défaut par défaut pour la variable r dans main(). Il produit une erreur de compilation car aucun constructeur n'existe pour cette déclaration de r.
Quizz2: réponse B car, grâce aux valeurs par défaut des paramètres, le constructeur joue aussi le rôle du constructeur par défaut. de plus les valeurs par défauts des paramètres sont prioritaires par rapport aux valeurs par défaut des attributs.
-
IMPORTANT: relire le cours du semestre d'automne sur les entrées-sorties conversationnelles (semaine 13) avant ce cours. L'exemple introduit à la fin est détaillé dans la série0 1.1 .
-
il y a suffisamment de contenu dans les exercices 5 et 8 ; Les exercices 6 et 7 sont optionnels
-
Suivre le MOOC semaine_3 / Surcharge & notion de "type paramétré"
Cours h1: classe inversée sur static, variable de classe et Surcharge
Cours h2: Forces et faiblesses de vector ; Forces et faiblesses d'un type paramétré
TP h1: static à l'échelle d'un module ; type paramétré
TP h2: exercices MOOC semaine 3 (sauf exercice 11)
-
Suivre le MOOC semaine_4 / Héritage avant la classe inversée
Cours h1: héritage (première partie), pointeur de fonction
Cours h2: petit exemple héritage + Architecture Model-View-Control / GTKmm / dessin
TP h1: GTKmm / dessin
TP h2: exercices MOOC semaine 4
-
il reste à gérer les 2 cas où |delta_a| > Pi pour éviter de tourner dans le sens de l'arc le plus long
-
Suivre le MOOC semaine_5 / Polymorphisme avant la classe inversée
Cours h1: classe inversée polymorphisme
Cours h2: Programmation par événement / GTKmm
TP h1: GTKmm / GUI
TP h2: exercices MOOC semaine 5
Projet : Rendu1 le dimanche 30 mars 23h59-
4. Forme du rendu1
Convention de style : il est demandé de respecter les conventions de programmation du cours.
• On autorise une seule fonction/méthode de plus de 40 lignes (max 80 lignes)Documentation : l’entête de vos fichiers source doit indiquer les noms des membres du groupe, etc.Rapport (pdf max 0.5 page) décrit l’activité individuelle de chaque membre selon ce message edstemRendu : pour chaque rendu UN SEUL membre d’un groupe (noté SCIPER1 ci-dessous) doit téléverser un fichier zip sur moodle (pas d’email). Le non-respect de cette consigne sera pénalisé de plusieurs points. Le nom de ce fichier zip a la forme :SCIPER1_ SCIPER2.zipCompléter le fichier fourni mysciper.txt en remplaçant 111111 par le numéro SCIPER de la personne qui télécharge le fichier archive et 222222 par le numéro SCIPER du second membre du groupe.Le fichier archive du rendu1 doit contenir (aucun répertoire) :• Fichier texte édité mysciper.txt
• Fichier pdf du rapport d'activité
• Votre fichier Makefile produisant un executable projet
• Tout le code source (.cc et .h) nécessaire pour produire l’exécutable.
On doit obtenir l’exécutable projet en lançant la commande make après décompression du fichier zip dans un terminal de la VM (sans utiliser VSCode).Auto-vérification : Après avoir téléversé le fichier zip de votre rendu sur moodle (upload), récupérez-le (download), décompressez-le et assurez-vous que la commande make produit bien l’exécutable et que celui-ci fonctionne correctement.Exécution sur la VM: votre projet sera évalué sur la VM à distance (compilation avec l'option -std=c++17) et sur le système qui met en oeuvre un éventuel autograder.Backup : Il y a un backup automatique sur votre compte myNAS.Debugging: Visual Studio Code offre un outil intéressant pour la recherche de bug (cf notre tuto sur moodle).
-
Suivre le MOOC semaine_6 / Héritage_multiple avant la classe inversée
Cours h1: classe inversée héritage multiple
Cours h2: GTK idle vs timer
TP h1: GTKmm / programmation par événement
TP h2: exercices MOOC semaine 6
-
pour 3.1 : ça ne compile toujours pas même si les prototypes sont différents car le masquage invalide tous les prototypes.
l'exemple 3.2 fonctionne si l'ambiguité est supprimée entre B et C pour autant qu'on utilise la version redéfinie qui masque celle de A.
-
Les 2 heures de TPs sont dédiées au support pour le projet.
Examen en contrôle continu le 11 avril 14h15-15h45
Tous les documents "papier" sont autorisés: livre, notes personnelles, tout document imprimé (cours, séries, projet, etc...)LES APPAREILS ELECTRONIQUES SONT INTERDITS, EN PARTICULIER LES CALCULATRICES, LES MONTRES CONNECTEES, ETC...Votre salle d'examen est indiquée dans le fichier pdf qui sera mis à disposition ci-dessous
-
Projet : Rendu2 à la fin des vacances, le Dimanche 27 avril à 23h59
-
4. Forme du rendu2
Convention de style : il est demandé de respecter les conventions de programmation du cours.
• On autorise une seule fonction/méthode de plus de 40 lignes (max 80 lignes) car le module gui est fourni et respecte déjà la consigne de longueur des fonctions/méthodes.
Documentation : l’entête de vos fichiers source doit indiquer les noms des membres du groupe, etc.
Activité individuelle (max 0.5 page à la fin du rapport/pdf ) de chaque membre selon ce message edstem décrivant la méthode de travail recommandée.
Rendu : pour chaque rendu UN SEUL membre d’un groupe (noté SCIPER1 ci-dessous) doit téléverser un fichier zip1 sur moodle (pas d’email). Le non-respect de cette consigne sera pénalisé de plusieurs points. Le nom de ce fichier zip a la forme :
SCIPER1_ SCIPER2.zip
Compléter le fichier fourni mysciper.txt en remplaçant 111111 par le numéro SCIPER de la personne qui télécharge le fichier archive et 222222 par le numéro SCIPER du second membre du groupe.
Le fichier archive du rendu2 doit contenir (aucun répertoire) :
• Rapport (fichier pdf)
• Fichier texte édité mysciper.txt
• Votre fichier Makefile produisant un executable projet
• Tout le code source (.cc et .h) nécessaire pour produire l’exécutable.
On doit obtenir l’exécutable projet après décompression du fichier zip en lançant la commande make dans un terminal de la VM (sans utiliser VSCode).
Auto-vérification : Après avoir téléversé le fichier zip de votre rendu sur moodle (upload), récupérez-le (download), décompressez-le et assurez-vous que la commande make produit bien l’exécutable lorsqu’elle est lancée dans un terminal de la VM (sans utiliser VSCode) et que celui-ci fonctionne correctement.
Exécution sur la VM: votre projet sera évalué sur la VM à distance (compilation avec l’option -std=c++17).
-
-
TP h1 et h2: temps dédié au projet avec encadrement en salles de TP
-
TP h1 et h2: temps dédié au projet avec encadrement en salles de TP
-
TP h1 et h2: temps dédié au projet avec encadrement en salles de TP
-
Projet : Rendu1 le dimanche 25 mai 23h59
-
3. Forme du rendu3 (copie du document du rendu3)
Convention de style : il est demandé de respecter les conventions de programmation du cours.
• On autorise une seule fonction/méthode de plus de 40 lignes (max 80 lignes) car le module gui est fourni et respecte déjà la consigne de longueur des fonctions/méthodes.Documentation : l’entête de vos fichiers source doit indiquer le nom du fichier et les noms des membres du groupe avec, pour les fichiers .cc, une estimation du pourcentage de contribution de chaque membre du groupe au code de ce fichier.
Rendu : pour chaque rendu UN SEUL membre d’un groupe (noté SCIPER1 ci-dessous) doit téléverser un fichier zip sur moodle (pas d’email). Le non-respect de cette consigne sera pénalisé de plusieurs points. Le nom de ce fichier zip a la forme :
SCIPER1_ SCIPER2.zip
Compléter le fichier fourni mysciper.txt en remplaçant 111111 par le numéro SCIPER de la personne qui télécharge le fichier archive et 222222 par le numéro SCIPER du second membre du groupe.Le fichier archive du rendu3 doit contenir (aucun répertoire) :
• Fichier pdf du rapport (section 1.1, p2)
• Fichier texte édité mysciper.txt
• Votre fichier Makefile produisant un executable projet
• Tout le code source (.cc et .h) nécessaire pour produire l’exécutable.
On doit obtenir l’exécutable projet après décompression du fichier zip en lançant la commande make dans un terminal de la VM (sans utiliser VSCode).Auto-vérification : Après avoir téléversé le fichier zip de votre rendu sur moodle (upload), récupérez-le (download), décompressez-le et assurez-vous que la commande make produit bien l’exécutable lorsqu’elle est lancée dans un terminal de la VM (sans utiliser VSCode) et que celui-ci fonctionne correctement.
Exécution sur la VM: votre projet sera évalué sur la VM à distance (compilation avec l’option -std=c++17).
-
-
Oral aléatoire individuel approfondi sur le projet avec l'enseignant
les oraux seront planifiés pour être effectués entre le 26 et le 28 mai de façon à libérer le vendredi 30 mai.
