Pensez à utiliser Java 4.
Le but du sujet est de spécifier et coder la gestion de listes de processus (ajout, retrait, test d'appartenance) de deux manières différentes.
La classe Processus représente un processus possédant une priorité entière comprise entre 0 et PRIO_MAX. Un processus est créé avec une priorité fixée qui ne changera plus au cours de sa vie. Il est possible de comparer la priorité de deux processus. Un processus possède un identifiant String (4 chiffres) qui l'identifie de manière unique.
Les processus sont crées via une factory (pattern Factory). Elle contient un pool d'identifiant qui permet de mémoriser les identifiants correspondant à des processus créés non encore détruits. L'unicité des identifiants de processus est ainsi assurée.
L'interface ProcessusList représente une liste contenant des processus non nuls. Une telle liste ne contient pas deux fois le même processus (cad deux processus de même identifiant). Il est possible :
La classe ProcessusFIFO représente une file classique de processus (ajout en queue, retrait en tête). Elle implémente l'interface ProcessusList.
La classe ProcessusPrio représente une liste de processus gérés en file, mais telle que le critère de retrait d'un processus est leur priorité et non leur ordre d'arrivée. Dans cette mise en oeuvre retirer un processus revient à retirer le processus possédant la plus forte priorité. Si plusieurs processus possèdent cette plus forte priorité, c'est le processus entré le premier dans la liste qui est retiré (donc le plus ancien). On choisit d'implémenter cette classe en gardant à jour une liste de processus triée par priorité décroissante.
La Factory vous est fournie (le code contient des assert), ainsi que l'interface ProcessusList : fichiers.
Spécifier et coder la classe Processus. L'interface ProcessusList est fournie, mais non spécifiée. Écrire sa spécification en utilisant des annotations JML, puis spécifier et coder les deux classes qui l'implémentent.
Les contrats devront être les plus précis possibles: il ne doit pas être possible de sous-typer vos classes par une classe qui ne fait pas ce qu'on veut mais respecte vos contrats. Éviter par exemple qu'une méthode d'ajout qui ajoute bien le processus requis mais en profite au passage pour remplacer un autre processus de la liste par un troisième respecte le contrat de votre méthode.
Il faudra bien penser aux contrats de l'interface: ils doivent être les plus précis possibles mais respecter quand même les règles du sous-typage comportemental.