TP 3 — Qualité de code + branches Git

Objectif du TP : évaluer votre code avec un analyseur statique, manipuler branches et conflits Git hors de tout projet, corriger une erreur de conception par une classe abstraite — et finir sur un planning de soutenances validé par des tests fournis.

1. PMD sur le code du R2.01

Récupérez PMD (site officiel, archive à décompresser) et le fichier de règles pmd-rules_r203.xml sur Moodle, puis analysez votre paquetage tp03 de R2.01 :

pmd check -d <répertoire-source du tp03> -R pmd-rules_r203.xml -f html > rapport.html

Q3. Analysez le rapport HTML, corrigez toutes les erreurs signalées — des règles du type OnlyOneReturn, TooManyFields — puis repassez PMD sur le même paquetage pour valider vos corrections. Q4 — intégrez PMD à votre IDE pour l'utiliser de manière récurrente.

2. Branches et conflit volontaire

Scénario dans un répertoire git-branches, dépôt initialisé, gitk --all ouvert en tâche de fond (F5 après chaque commande).

3. Person, Student1, Student2 — et l'erreur de conception

Des soutenances à planifier, des étudiants de types différents aux durées propres — et chaque soutenance évaluée par un « candide », d'où une classe Person en base de la modélisation. Écrivez Person (name, forename), accesseurs et toString sous la forme <forename> <name>. Puis :

• Student1 : constante DEFAULT_DURATION_STUDENT1 à 20 minutes, booléen thirdTimeCredit (faux par défaut), deux constructeurs, getDefaultDuration(), getDuration() — la durée à laquelle l'étudiant a droit selon son tiers-temps — et toString() sous la forme <forename> <name> (<duration>) ;
• Student2 : même structure et mêmes signatures, durée par défaut à 30 minutes.

Dans UseStudent, affichez « Alice a », « Bruno b » (BUT1) et « Clément c » (BUT2). Affichage attendu :

a Alice
b Bruno (20)
c Clement (30)

Q6 — le diagnostic. Le code fonctionne, mais une erreur de conception s'est glissée : par héritage, une relation de polymorphisme lie Student1 et Student2 — un étudiant de 2e année serait un étudiant de 1re année. Indésirable ici.

4. La correction : une classe abstraite

Q6.1 — dupliquez vos classes en StudentBUT1/StudentBUT2 (trace pédagogique). Q6.2 — puis refactorez : une classe abstraite Student portant le commun, deux dérivées qui ne se distinguent que par leur durée par défaut.

public abstract class Student extends Person {
    private boolean thirdTimeCredit;
    public Student(String name, String forename) { this(name, forename, false); }
    public Student(String name, String forename, boolean thirdTimeCredit) { /* ... */ }
    public abstract int getDefaultDuration();
    public int getDuration() { /* dépend du tiers-temps */ }
    @Override public String toString() { /* <forename> <name> (<duration>) */ }
}

StudentBUT1 et StudentBUT2 fournissent chacune leur constante (DEFAULT_DURATION_BUT1, DEFAULT_DURATION_BUT2) et leur getDefaultDuration(). Q7 — second scénario dans UseStudent, mêmes tâches, même affichage : le polymorphisme est désormais voulu, non subi.

5. Room, Defense, Planning

Q8 — l'enum Room (r0A18, r0A20, r0A51, r0A49) doit s'afficher « room 0A18 » et non r0A18 : redéfinissez toString. Q9 à Q11 — la classe Defense porte whenDay (LocalDate), whenHour (LocalTime), where (Room), who (Student), title (String), avec un constructeur complet et un constructeur sans date ni heure ; son toString respecte scrupuleusement la forme <jour>:<heure> in <lieu> --> <étudiant> :: <titre>, nécessaire à la validation des tests. Ajoutez tous les accesseurs, les mutateurs setDay/setHour, et une méthode déléguée pour la durée de la soutenance. Q12 — récupérez DefenseTest.java, intégrez-le au répertoire test, validez.

Q13 à Q17 — le Planning. Un jour (when) et une liste de soutenances ; defaultStart à 8:00, pauses breakDuration de 5 minutes. addDefense(...) ajoute une soutenance ou une liste d'un coup ; getDefense(idx) retourne la soutenance d'indice donné, null sinon ; getNbDefense() compte. scheduling(...) re-planifie : à chacune sa date et son heure de début, à partir de l'heure fournie ou par défaut, en ajoutant à chaque fois la durée de l'étudiant puis la pause — c'est getDuration(), invoquée via le polymorphisme, qui décide. Q18 et Q19 — swapDefense(d1, d2) permute deux soutenances ; delayDefense(d1, minutesToAdd) retarde toutes les soutenances à partir de d1 incluse — décomposez bien votre code. Q20 — récupérez PlanningTest.java et validez. Q21 — commit : « tpQU-03::exo-planning », puis poussez.