TP 9-10 — Exceptions et génériques

Objectif des TP : le TP 9 fait des exceptions personnalisées et des fichiers un réflexe ; le TP 10, le plus long du semestre, construit un ordonnanceur de tâches générique en quatre phases — la synthèse de tout le cours, et le sujet type du contrôle TP.

TP 9 — Login et exceptions personnalisées

LogInManagement boucle sur la saisie (login, mot de passe) jusqu'au couple correct, défini par les constantes LOGIN/PWD. La consigne clé : getUserPwd() ne doit contenir ni try ni catch — les exceptions sont propagées (throws) et les captures ont lieu dans la méthode principale. On crée d'abord WrongLoginException et WrongPwdException en dérivant Exception, avec un message spécifique à l'affichage ; puis la méthode passe à un retour void en lançant explicitement le bon type ; enfin WrongInputLengthException (saisie de plus de 10 caractères) ajoute un troisième type.

TP 9 — Extraction, récursion, Scanner

1. DicoJava.txt : chaque ligne contient trois champs séparés par des tabulations — un mot, son type, une description. BufferedReader.readLine() puis découpage par tabulation, sélection des lignes dont le type vaut « Mot-clé », construction d'une liste ordonnée, écriture de MotsJava.txt à raison d'un mot par ligne.
2. printExecutable(File) : lister, à toute profondeur, le chemin absolu des fichiers exécutables et non cachés. La méthode est récursive : sur un répertoire (isDirectory), on itère sur listFiles() ; sur un fichier, on teste canExecute() et !isHidden(). Le générateur d'arborescence HierarchyCreation (jar fourni, méthode hierarchyCreation(String aPath)) fabrique le jeu d'essai attendu — 4 fichiers à afficher, les cachés exclus.
3. Validation.checkFile(String) : valider un CSV typé — premier champ = type de données (1 pour les booléens, 2 pour les entiers, sinon des chaînes), deuxième = nombre de valeurs de la ligne, suivies des données. La méthode renvoie true ou lève : InputMismatchException (mauvais type lu), InvalidStructureException (à définir soi-même), FileNotFoundException. Toutes les captures ont lieu dans le main.

TP 10 — Phase 1 : la file simple

Les objets d'abord : l'interface IPriority (getPriority) et la classe Task qui l'implémente — priorité fixée à la création, toString basé sur getClass() qui affiche Task:t1(3). Puis l'interface générique IScheduler<T> : addElement, highestPriority (sélectionne et retire la tâche à traiter), isEmpty, size. L'implémentation SchedulingQueue<T> est une file premier entré, premier sorti appuyée sur une LinkedList<T> — choisie parce que les opérations majoritaires sont l'ajout et la suppression — avec un ID automatique et l'affichage Queue0 -> []. Deux scénarios (Book, puis Task) et la classe de tests SchedulingQueueTest fournie.

TP 10 — Phase 2 : le type générique borné

On ne veut plus accepter n'importe quoi dans la file : PrioritySchedulingQueue<T extends IPriority> dérive de SchedulingQueue avec une borne sur le paramètre de type — le compilateur garantit que tout élément sait donner sa priorité. L'implémentation reste minimaliste : trier la file à chaque ajout (rappel : priorité faible = urgente), sans redéfinir autre chose. Scénario à écrire : trois tâches de priorité décroissante sortent dans l'ordre inverse de leur ajout. Classe de tests PrioritySchedulingQueueTest fournie.

TP 10 — Phase 3 : plusieurs files de priorité

Le tri systématique après chaque ajout ne passe pas à l'échelle. PriorityScheduler gère une liste de files, dont le nombre est fixé à la création (l'aspect générique est ici laissé de côté). Une tâche de priorité supérieure au nombre de files part dans la dernière file — priorité 5 dans un ordonnanceur à 3 files : file numéro 2. À écrire : size(int priority), l'affichage PriorityQueue: suivi des files, et le scénario t1(2), t2(3), t3(1), t4(4), t5(2) sur 5 files, en vérifiant l'ordre de sortie. Classe de tests PrioritySchedulerTest fournie.

TP 10 — Phase 4 : les jobs et l'équité

L'interface IJob étend IPriority (héritage entre interfaces) avec execute() et isOver() — un processeur peut re-remettre une tâche non terminée dans l'ordonnanceur. Puis une famille de travaux, tous dérivés de Task :

• JobDisplay : un message, une seule exécution, priorité par défaut 3 — l'affichage DISPLAY:<msg> n'ajoute la priorité que si elle diffère du défaut ;
• JobLoop : s'exécute un nombre donné de fois, priorité par défaut 2, affichage LOOP:<msg>:<NB-EXECUTION> ;
• JobIO dérive de JobDisplay : première exécution = saisie du message au clavier, seconde = affichage du message saisi ; priorité par défaut 1 ;
• JobDynamic dérive de JobLoop : priorité évolutive — elle diminue d'exécution en exécution si le travail est urgent, augmente sinon, la modification précédant l'affichage du message.

La vérification se fait par rejeu de fichiers de traces, format IN|OUT:TYPE-JOB:<PARAM>:PRIORITY (séparateur :, priorité en dernier champ si différente du défaut). Dans SchedulerChecking, checkSimpleLog() rejoue schedulerDisplayJobOnly.log — instancier un IJob approprié à chaque ligne IN, comparer le sortant à la ligne OUT, lever une exception au moindre écart — puis checkLog() rejoue scheduler.log avec les trois types de jobs. Enfin FairScheduler garantit l'équité : un tableau priorities[i] compte les invocations de highestPriority() sans exécution d'un processus de priorité i — c'est la tâche qui a le plus attendu qui sort, à égalité la plus prioritaire.

---