Ce projet a pour but de proposer une interface conviviale pour concevoir ou résoudre des grilles de Sudoku. Ce jeu de réflexion demande de remplir une grille en respectant une configuration de départ différente à chaque partie et quelques règles simples.
Vous produirez deux programmes, écrits en Java, sans emprunt extérieur (sauf l'API officielle), et accompagnés d'un rapport. Le travail sera fait seul ou en binôme (un binôme est fortement recommandé, afin de vous permettre de vous familiariser avec les techniques de développement collaboratif), et se terminera impérativement avant le dimanche 5 mai 2024 à 18h00.
La partie logicielle sera développée dès le départ à l'aide du serveur Gitea du département. Le rapport prendra la forme d'un fichier au format PDF joint aux sources.
Une grille de Sudoku est composée de neuf lignes et neufs colonnes. Elle est également divisée en neuf régions couvrant chacune trois lignes et trois colonnes.
Chaque case peut accueillir un chiffre compris entre 1 et 9, mais le même chiffre ne peut pas apparaître plusieurs fois sur une même ligne, une même colonne, ou une même région.
| 9 | 5 | 4 | ||||||
| 5 | 3 | 4 | 8 | 7 | 2 | |||
| 7 | 6 | 3 | ||||||
| 9 | 3 | 4 | 8 | |||||
| 4 | 1 | 7 | ||||||
| 2 | 5 | 7 | 6 | |||||
| 4 | 9 | 2 | ||||||
| 6 | 7 | 9 | 3 | 2 | 1 | |||
| 2 | 6 | 5 |
On fournit au joueur une grille où seulement quelques cases sont initialement remplies. Sa tâche consiste à remplir entièrement la grille en respectant les contraintes d'unicité. Les grilles de départ sont délicates à construire car elles doivent conduire à une seule solution. Si cette propriété est respectée, le joueur doit pouvoir remplir la grille grâce à des déductions logiques et non par essais et erreurs (même si pour certaines grilles la logique est loin d'être simple).
Le premier programme servira à l'élaboration des grilles de départ.
Pour construire une grille, on pourra partir d'une grille vide ou charger une grille existante depuis un fichier. Il devient alors possible d'ajouter ou d'enlever des numéros dans la grille (le programme doit empêcher les placements contradictoires). Une fois la grille achevée, elle sera sauvegardée dans un nouveau ou un ancien fichier. Le format employé pour ces fichiers est décrit plus bas. La sélection d'un fichier en lecture ou en écriture pourra se faire par le biais de la classe JFileChooser.
Le second programme servira à résoudre une grille.
On commencera par charger une grille depuis un fichier. Puis on choisira si on souhaite résoudre la grille manuellement ou automatiquement. En mode automatique, le programme affichera la grille résolue et le temps nécessaire à la résolution (on mesurera naïvement le temps écoulé à l'aide de la méthode nanoTime de la classe System).
En mode manuel, le joueur pourra ajouter des chiffres (mais pas si cela contrevient directement aux contraintes d'unicité) et enlever des chiffres (mais pas s'ils apparaissent dans la grille de départ). En cas de doute, il pourra aussi faire temporairement cohabiter jusqu'à quatre chiffres dans une même case (dans ce cas, les chiffres qui cohabitent sont limités par les autres cases, mais ne les contraignent pas en retour). Le joueur sera félicité par le programme lorsque toutes les cases contiendront un chiffre (et un seul).
Mettez autant de code que possible en commun entre les deux programmes : de nombreuses classes devraient être employées par l'un comme par l'autre.
Une case sera représentée par le chiffre qu'elle contient si elle est pleine, ou par 0 si elle est vide. En mettant bout à bout tous les chiffres d'une ligne, on obtient la représentation décimale d'un entier.
Par exemple les lignes de la grille donnée plus haut donnent les entiers suivants :
95004 530408702 700603 900034080 40010070 20570006 409002000 607903021 200650000
Le fichier contient la représentation canonique Java de ces entiers les uns à la suite des autres (sans séparateur). Vous pouvez télécharger le fichier correspondant à cet exemple pour tester votre programme.
Les sources de votre projet (et pas les fichiers .class)
devront être disponibles à tout moment sur le serveur Gitea du département. Votre dépôt sera privé, nommé
obligatoirement SAE21_2023 et incluera Luc Hernandez (login :
hernand) dans la liste des collaborateurs. Le nombre de soumissions, leur
date et l'équilibre entre leurs auteurs influeront sur la note finale.
Pour chaque classe, vous prévoierez un fichier source. Suivez les
consignes habituelles
scrupuleusement. La définition de chaque classe et de chaque membre de classe sera
précédée d'un commentaire formaté pour permettre la génération de documentation technique
par l'outil javadoc (ceci est un exemple de fichier source bien commenté).
Un fichier Makefile devra permettre la compilation de votre projet (par la
commande make) ainsi que son exécution (par la commande make
run). Transcrivez bien toutes les dépendances entre vos fichiers dans les règles.
La commande javac fait déjà (très mal) un travail similaire à
make, ce qui peut créer des interférences. Pour éviter cela, pensez à lui
passer l'option -implicit:none. Ceci est un exemple très basique.
Le rapport d'avancement prendra la forme d'un fichier PDF disponible avec les sources dans votre dépôt Gitea. Vous y inclurez en particulier :
Soignez la présentation ! L'orthographe, la grammaire, les pages de garde, la table des matières, les en-tête et pieds de page ne sont pas en option...
Notez bien que le rapport ne doit pas contenir d'extrait du code source du projet, étant donné que le correcteur peut aller le consulter directement s'il en éprouve le besoin. N'hésitez pas en revanche à illustrer vos propos par des schémas. Ceux-ci peuvent être construits directement dans le logiciel de traitement de texte s'il le permet, ou dans un logiciel dédié, tel que Inkscape ou Draw (tous deux gratuits).