Projet Sudoku

Laboratoire de Développement de Programmes :
Projet
Sudoku
Julie Anciaux et François Schoubben
2ème semestre 2006-2007
Année :
Cours :
Professeur :
Assistants :
1er Bac en Informatique
et Ingénieur de Gestion Orientation Management de l’Information
Laboratoire de Développement de Programmes (B132)
Naji Habra
Bureau Mail
Tel
Julie Anciaux
227
[email protected] 081/ 72 49 98
Anthony Cleve
431
[email protected] 081/ 72 49 81
Badr Jabari
432
[email protected] 081/ 72 52 57
François Schoubben 324
[email protected]
Licence : Cet énoncé est disponible sous GNU Free Documentation License 1 .
1
http://www.gnu.org/copyleft/fdl.html
Table des matières
1 Introduction
1
2 Règles du jeu
2
3 Transposition informatique
3.1 Partie virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Mémorisation des meilleurs scores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
3
4 Calendrier
4
5 Déroulement des séances
4
6 Le rapport
5
7 Le code Pascal
6
8 Présentation intermédiaire
6
9 Remise du projet
6
10 Echéances
7
11 Défense
7
12 Mode de cotation
7
13 Dernière ligne droite
7
14 Bonus
8
15 Seconde session
8
16 Contacts
8
1
1
INTRODUCTION
Introduction
Ce projet a pour but de mettre en pratique les notions apprises durant le cours de programmation du
premier semestre (B131). Il est essentiel d’avoir assimilé les concepts abordés par M. Habra.
Il vous est demandé de concevoir un jeu de Sudoku . La conception ira de l’analyse des besoins jusqu’à
l’affichage des meilleurs scores en passant par le choix de la couleur de la grille. Vous allez donc mener à
bien un véritable projet informatique : de l’idée à la défense du projet, en passant par les spécifications, ....
Nous vous demandons d’agir professionnellement, à savoir qu’il faut tant répondre aux critères algorithmiques que rédiger un rapport complet (spécifications, invariants, méthode de travail, . . .) sur votre
programme. Ce n’est pas parce que le programme “tourne” que vous aurez des points, mais bien parce qu’il
sera réalisé conformément à toutes nos spécifications.
Ceux qui ignorent les vraies règles de ce jeu 2 les trouveront détaillées à la section 2. Les détails de la
transposition en partie virtuelle figurent à la section 3.1.
La section 3.2 vous expliquera comment établir les scores et développer ainsi des statistiques de jeu.
Ensuite, nous vous détaillerons brièvement comment vous pourrez mener à bien ce projet grâce à un
calendrier (section 4) au fur et à mesure des séances (section 5).
Les sections 6 et 7 vous expliquent ce que nous attendons de vous dans le rapport et le code. Évidemment,
il ne s’agit que des grandes lignes. Toute originalité, dans le respect de nos conventions, est la bienvenue.
La procédure d’envoi de votre projet figure à la section 9 et les dates de remise figurent à la section 10.
Les autres points de contrôle sont une présentation intermédiaire (section 8), ainsi que la présentation de
votre projet après Pâques comme expliqué à la section 11.
Ensuite, nous vous expliquons notre méthode de cotation, à lire absolument afin de focaliser vos ressources
cérébrales aux fins les plus utiles (section 12).
Pour les plus rapides, nous proposons un petit bonus (section 14). Vous trouverez aussi des informations
sur la seconde session (section 15), au cas où. Des questions ? Des remarques ? Voir la section contact (16).
Avant de rendre votre rapport, regardez s’il répond à toutes nos attentes... Nous insistons : “Relisez
l’énoncé avant de rendre le rapport” (13).
2
c’est-à-dire les nôtres
31 janvier 2007
Laboratoire de Développement de Programmes
Page 1 sur 8.
3
2
TRANSPOSITION INFORMATIQUE
Règles du jeu
Matériel : La grille de jeu est un carré de neuf cases de côté, subdivisé en 9 carrés identiques (3 sur
3), appelés régions :
Règle : La règle du jeu est simple : chaque ligne, colonne et région doit contenir une et une seule fois
chaque chiffre de un à neuf.
Via Wikipedia : http://fr.wikipedia.org/wiki/Sudoku
3
Transposition informatique
3.1
Partie virtuelle
Voici les grandes lignes d’une partie virtuelle. Elles peuvent ne pas se dérouler dans cet ordre.
– Lire un fichier texte contenant les grilles jouables et le stocker en mémoire ;
– identifier le joueur par un mécanisme de nom d’utilisateur (login), et éventuellement une authentification (par mot de passe) ;
– proposer des statistiques au joueur courant (niveau, statistiques sur le nombre de grilles résolues,
grilles abandonnées, son classement par rapport aux autres joueurs, . . .) ;
– permettre au joueur de créer une nouvelle grille de jeu (à sauver dans le fichier texte) ;
– permettre de jouer une nouvelle partie en choisissant le niveau (Facile, Moyen, Difficile) ;
– afficher la grille, le login, le nombre de cases encore vides et éventuellement les règles ;
– sélectionner une grille, au hasard dans la liste des grilles jouables, selon le niveau choisi par l’utilisateur ;
– permettre le placement des chiffres par le joueur sur les cases “jouables”. Les cases de la grille de
départ, c’est à dire les cases dont les valeurs sont dans le fichier texte, ne peuvent pas être modifiées
par le joueur ;
– vérifier que chaque chiffre placé par le joueur n’est pas en double dans la ligne, la colonne ou la région ;
– annoncer, le cas échéant, la fin de la partie et les points ;
– enregistrer les données relatives au joueur ;
– permettre de rejouer ou de quitter le jeu ;
Nous vous demandons de faire un minimum de contrôle de saisie, c’est-à-dire de gérer le cas où l’utilisateur
introduit un mauvais caractère (une lettre à la place d’un chiffre par exemple).
31 janvier 2007
Laboratoire de Développement de Programmes
Page 2 sur 8.
3
Format du fichier de données :
TRANSPOSITION INFORMATIQUE
le fichier texte contient les grilles sous la forme suivante :
Niveau Taille-C^
oté
Lettre-ligne Chiffre-colonne Valeur
Lettre-ligne Chiffre-colonne Valeur
Lettre-ligne Chiffre-colonne Valeur
...
Ligne Vide
Exemple
(sur 3 colonnes) :
Facile 9x9
....
Difficile 9x9
A 5 2
A 7 9
B 5 6
B 6 3
B 9 8
C 1 3
C 6 8
C 7 1
C
D
D
D
E
E
E
E
F
F
F
G
8
5
7
9
2
3
7
8
1
3
5
2
4
4
8
7
8
4
6
1
1
7
5
1
G
G
G
H
H
H
I
I
3
4
9
1
4
5
2
5
5
9
2
9
4
8
2
1
Moyen 9x9
...
donnera la grille
3.2
Mémorisation des meilleurs scores
Nous vous demandons de permettre la mémorisation de certaines données afin de faire des statistiques sur
les parties jouées. On peut envisager de retenir, pour chaque joueur, des renseignements tels que le nombre
de parties jouées, gagnées, la durée d’une partie, . . . Nous vous laissons libres pour ces spécifications, faites
preuve d’originalité.
Il va de soi que ces informations relatives aux différents utilisateurs de votre programme doivent être
conservées d’une exécution du jeu à l’autre.
31 janvier 2007
Laboratoire de Développement de Programmes
Page 3 sur 8.
5
4
DÉROULEMENT DES SÉANCES
Calendrier
Nous vous proposons de diviser le projet en 5 étapes et éventuellement une 6 ème , considérée comme un
bonus. Vous avez 8 semaines pour les mener à bien.
1. Gérer les données et l’interface (semaines 0 et 1 : 31 janvier et 5 f évrier )
– Définir le type des données que l’on va utiliser pour modéliser le jeu (grille, valeurs, . . .) ;
– gérer un affichage efficace de la grille. Essayez de prévoir tous les affichages possibles au niveau de
la place sur l’écran.
2. Préparer le terrain (semaines 2 et 3 : 12 et 19 f évrier)
– Transformer le fichier texte en grilles de jeu possible ;
– afficher une grille au hasard ;
– placer des valeurs uniquement là où c’est autorisé (i.e. “jouable”).
3. Jouer une partie (semaine 4 : 26 février) et présentation intermédiaire
– Vérifier qu’une valeur introduite n’entre en conflit ni avec la ligne, ni avec la colonne, ni avec la
région.
4. Identifier les joueurs et gérer le jeu complet (semaines 5 et 6 : 5 et 12 mars)
– Identifier les joueurs ;
– gérer le fichier ou les fichiers pour les données relatives aux parties ;
– gérer les statistiques ;
– gérer le menu de jeu.
5. Création de grilles (semaine 7 : 19 mars)
– Permettre de créer une grille de manière “graphique” ;
– sauver les nouvelles grilles dans un fichier texte.
6. Bonus et ergonomie
– Bonus (voir section 14) ;
– améliorer la présentation du jeu. Les atouts d’une interface sont sa simplicité, sa “jouabilité”.
L’ensemble des spécifications étant faites au fur et à mesure, la dernière semaine ne doit vous servir qu’à
finaliser votre rapport.
Nous vous conseillons de respecter le calendrier ci-dessus. Vous êtes libres de concevoir votre programme
à votre gré, du moment que vous respectiez au mieux les étapes fixées.
N’oubliez pas que ce projet ne se réalise pas en une journée et constitue un travail de longue haleine.
Par mesure de sécurité, nous vous conseillons de tenir compte de l’agenda proposé pour réaliser ce projet.
Nous vous recommandons aussi de nous montrer de temps à autre l’état d’avancement de votre travail pour
– éviter que vous vous perdiez trop longtemps dans des culs-de-sac ;
– nous donner une idée de votre travail avant la correction.
5
Déroulement des séances
Les séances de TP se déroulent au Séminaire 1 ou au pool. Durant ces séances, nous ne ferons pas
d’exposé oral puisque la matière correspond à celle vue au cours du premier trimestre. Toutefois, il est utile,
sinon indispensable d’y assister pour que nous puissions juger de l’état d’avancementde votre projet et vous
guider. Des informations supplémentaires circuleront aussi durant ces séances.
31 janvier 2007
Laboratoire de Développement de Programmes
Page 4 sur 8.
6
6
LE RAPPORT
Le rapport
Nous vous demandons d’écrire un rapport :
– dactylographié
– en recto uniquement.
– exempt de fautes d’orthographe3 . Faites le relire !
– contenant impérativement :
1. une page de garde, mentionnant au minimum vos nom et prénom en haut à droite ;
2. une table des matières4 , sur feuille volante, dans laquelle se trouvent les noms de toutes les
procédures ;
3. une description de la manière dont votre projet a pris forme ( 12 page) ;
4. une explication sur le fonctionnement global de votre programme (1 page) ;
5. une feuille volante présentant les types utilisés ;
6. une feuille volante contenant un graphe de dépendance de vos procédures ;
7. une défense des points forts ( 21 page) et faibles ( 12 page) de votre programme . Les points faibles,
c’est ce qui ne va pas dans votre programme, les bugs connus ;
8. une présentation de quelques idées qui amélioreraient votre programme ( 12 page). Modifier les
points faibles n’est pas le genre d’amélioration que nous attendons ici ; nous attendons plutôt ce
qu’il serait intéressant de mettre dans une version 2.0 ;
9. les en-têtes, spécifications, invariants et ordinogrammes de chacune des procédures ainsi que du
programme principal.
Attention,
– mettez en parallèle l’ordinogramme et les spécifications de celui-ci (nous ne voulons pas tourner
la feuille pour lire les spécifications par rapport à l’ordinogramme) ;
– vous ne devez pas mettre dans votre rapport les procédures n’ayant que de l’affichage (sans
postcondition, avec des outputs uniquement) ;
– si une procédure a plusieurs invariants, numérotez-les, et faites en sorte que nous n’ayons pas
besoin de chercher à quelles boucles ils correspondent ;
10. en annexe, nous vous demandons une impression de la dernière version de votre code source, en 2
pages par feuille (et recto uniquement) pour éviter le gaspillage. N’oubliez pas de le documenter...
Pour rappel, une feuille comporte 2 pages : une page recto et une page verso. N’oubliez pas de numéroter
les pages de votre rapport (l’idéal est quelque chose du genre ”prénom nom - page x sur y” en pied de
page). Soyez concis, un rapport de 30 pages hors code source est presque trop gros. Faites aussi un effort
important au niveau de l’expression écrite, de l’orthographe et de la présentation.
Important : le rapport est un document long à faire ! Faites le au fur et à mesure, pas la dernière semaine,
sous peine de nuits blanches et par conséquent, de qualité médiocre.
3
4
S’il y a des fautes, nous retirerons des points !
A générer automatiquement évidemment :)
31 janvier 2007
Laboratoire de Développement de Programmes
Page 5 sur 8.
9
7
REMISE DU PROJET
Le code Pascal
Le code source de votre programme doit être présenté de la manière suivante (exemple fictif) :
Procedure :
procedure choixCouleur(var c :Couleur) ;
{
var globales (seulement si il en faut _*vraiment*_ !)
pré :
post :
I/O :
}
Remarque :
– si une ligne est vide, il n’est pas nécessaire de la mettre.
– les variables globales sont très peu probables hors interface graphique.
Invariant :
while (i <= 10) do
{ inv : }
begin
Remarque : si un invariant n’existe pas, la boucle n’a aucune raison d’exister.
Votre programme pourra être testé sous Linux, Solaris et Windows. Testez le sur plusieurs plateformes si
possible.
8
Présentation intermédiaire
Une présentation intermédiaire personnelle et obligatoire de votre programme aura lieu à la fin de la
2ème étape. Vous nous présenterez l’état d’avancement de votre projet, aussi bien au niveau du code source
qu’au niveau du rapport.
Lors de cette présentation, nous vous demandons d’apporter
– votre graphe de dépendance,
– le code source (compilable) de tout le programme,
– 4 procédures ”intéressantes”, considérées finies pour le rapport final, c’est-à-dire :
– spécifications (en pdf)
– organigramme (en pdf)
– code source commenté dans le fichier .pas
Faites particulièrement attention aux spécifications ainsi qu’à la mise en page globale. L’idée est de vous
aider à ne pas rater le projet pour une ”bête” histoire de rapport.
Si vous ne vous présentez pas, nous ne corrigerons pas votre projet final ! ! !
9
Remise du projet
Nous vous demandons de nous envoyer votre rapport au format pdf et votre code source en pascal (compilable) à nos quatres adresses (cf. page de garde) avec comme sujet : ”projet 1 bac”. Une
réponse automatique doit vous parvenir directement disant que le message est bien reçu 5 . Si vous ne
recevez pas de réponse, considerez que nous n’avons pas reçu votre mail ! Vérifiez bien le sujet (pas de
majuscule, pas d’espace en trop ou trop peu, ...). Envoyez ce mail avec votre adresse des facs ([email protected]), c’est beaucoup plus facile de voir de qui il vient, qu’avec un mail provenant
de [email protected]...
5
Ce système permet de certifier que vos travaux sont entre nos mains et non perdus quelque part sur le web pour des raisons
multiples (serveurs down, mail trop gros, ...).
31 janvier 2007
Laboratoire de Développement de Programmes
Page 6 sur 8.
12
MODE DE COTATION
Afin d’être sûr que nous corrigeons bien votre programme et donc que nous ne mettrons pas vos points à
quelqu’un d’autre, en plus de votre nom en commentaire dans le code source, prenez comme nom de fichiers
votre prénom et nom de famille sans espaces, sans caractères accentués (ou autre cédilles) séparés par des
(par exemple pour François Schoubben, ce serait francois schoubben.pas et francois schoubben.pdf).
10
Echéances
La présentation intermédiaire personnelle obligatoire de votre programme aura lieu à partir du 26
février, un horaire vous sera communiqué ultérieurement.
Le rapport final doit être déposé dans le casier de Julie Anciaux (sas du secrétariat, 3ème étage, Institut
d’Informatique) ET envoyé par mail aux assistants (adresses sur la page de garde).
Le groupe A doit remettre le travail pour le mardi 27 mars avant minuit. Les groupes B et IngGestion
doivent l’avoir remis pour le jeudi 29 mars avant minuit.
Tout retard entraı̂nera une pénalité de 2 points (sur le total de 20) par jour de retard entamé. Après
3 jours de retard non justifié, et dans votre intérêt, nous ne corrigerons pas votre travail. Cela équivaut à
une absence à un examen.
11
Défense
Après les vacances de Pâques, dès que tous les travaux auront été corrigés, chaque étudiant présentera
individuellement son projet oralement. La présentation se fait avec le correcteur 6 de votre travail (l’un des
assistants). Elle dure 10 à 20 minutes selon le cas.
Cette présentation a une double utilité. D’une part elle vous permet de voir quelles sont vos erreurs
fréquentes et d’apprendre comment ne plus les faire, et d’autre part, elle nous permet d’ajuster vos points,
d’avoir la certitude que vous êtes bien l’auteur, d’éclaircir certains points flous, . . .
12
Mode de cotation
Ce projet intervient dans vos résultats officiels (juin et septembre) comme un cours à part entière (B132).
La note du projet est totalement indépendante de celle du cours de programmation du premier semestre
(B131) ! Le projet est coté sur 20 : 9 points pour le code et 9 points pour le rapport (i.e. 7 points pour les
spécifications et 2 points pour les autres éléments demandés). Les 2 points restants sont ceux d’appréciation
personnelle (orthographe, présentation, interface graphique, ...). Il va de soi que, même cotées distinctement,
ces 2 parties doivent constituer un tout cohérent ! Il est donc impératif de s’attarder autant sur le rapport
que sur le code même si la rédaction du rapport vous paraı̂t moins passionnante !
Ce travail est INDIVIDUEL. Ceci signifie que chaque étudiant a un projet personnalisé. Tout élément
indiquant le non respect de cette règle entraı̂ne une division des points entre les différents collaborateurs.
Nous ne vous interdisons pas de vous échanger des idées lors des séances, après tout cela ne peut être que
bénéfique, mais nous ne voulons pas de travaux complètement ou majoritairement communs !
Nous sommes aussi très exigeants quant aux dates de remise du code et du rapport (voir la section 10). En
effet, ces mesures draconiennes nous permettent d’être équitables avec tout le monde : vous connaissez les
règles du jeu !
Ne vous fatiguez pas à faire des interfaces graphiques fouillées, cela ne rapporte qu’au mieux un peu
moins de 1 point sur 20, et encore, il faut que le reste du rapport soit irréprochable. Seule la clarté compte,
pas le fait que vous ayez utilisé des librairies avec souris, 3D et/ou effets sonores.
6
désigné aléatoirement.
31 janvier 2007
Laboratoire de Développement de Programmes
Page 7 sur 8.
16
13
CONTACTS
Dernière ligne droite
Voilà... il ne vous reste plus qu’à rendre votre projet. Quelques précautions sont à prendre avant de
déposer votre rapport et d’appuyer sur la touche “send” de votre client mail !
– Vérifiez bien que vous avez répondu à tout ce qui est demandé ;
– relisez 2 fois votre mail : le sujet est-il bon ? Envoyez-vous bien le fichier attaché ? Le fichier attaché
porte-t-il le bon nom ?
– Avez-vous relu tout l’énoncé avant de relire votre rapport ?
Une fois ces précautions minimum prises, envoyez votre mail et... bon travail pour les autres cours...
14
Bonus
Votre projet est terminé lorsque vous avez fini les 4 premières étapes de l’calendrier et que le rapport
est rédigé. Toutefois, sachant que parfois certaines ou certains progressent plus vite que d’autres, nous vous
offrons la possibilité de gagner quelques points supplémentaires. Ce bonus doit figurer tant dans le rapport
que dans le code pour vous rapporter des points.
Nous vous demandons de rendre le joueur “ordinateur” plus intelligent. A vous d’essayer de le doter
d’un maximum d’intelligence artificielle pour qu’il puisse nous aider à résoudre une grille. Par exemple, si
une seule valeur est possible dans une ligne, colonne ou région, il devrait pouvoir la proposer. Si 2 valeurs
sont possibles, il faut aussi analyser les 2 autres “directions” possibles. Cela a beaucoup plus d’importance
à nos yeux d’analystes-programmeurs de réfléchir sur ces problèmes que d’avoir une “trop belle interface
graphique”7 . Cela dit, n’hésitez pas à vous renseigner sur les règles élémentaires concernant les IHM.
Vous ne pourrez commencer la partie bonus que lorsque nous vous en aurons donné la permission. Pour
rappel, cette dernière étape n’est nullement obligatoire et elle n’a de sens que lorsque le reste est parfait !
Nous préférons nettement un code performant et un rapport clair sans bonus qu’un projet à moitié bâclé
avec un semblant de résolution de bonus !
Parlons chiffres maintenant ! Nous vous offrons la possibilité de gagner jusqu’à 2 points de bonus, c’est-à-dire
que nous cotons sur 22 points tout en affichant les points sur 20. Ne rêvez pas, on tronquera à 20 :). Il est
évident que ce bonus n’est pris en considération que lorsque le reste vaut plus de 15/20.
15
Seconde session
Pour la seconde session, qui pourrait malheureusement être nécessaire, il s’agira du même programme,
coté de la même manière et toujours individuel. Venez trouver Julie Anciaux le jour de la délibération
(fin juin-début juillet), elle vous dira quelles procédures vous devrez refaire. Un second rapport vous sera
demandé pour le 16 août. Nous serons disponibles certains jours, mais probablement beaucoup moins que
durant le semestre.
Nous vous déconseillons fortement cette option :).
16
Contacts
Pour les questions, privilégiez les forums de webCampus, cela permettra aux autres d’avoir aussi la
réponse.
Nous sommes également disponibles dans nos bureaux respectifs ou par mail ou encore par téléphone (voir
page de garde).
Pour être sûr de nous rencontrer dans nos bureaux, prenez rendez-vous...
Bon travail
7
Si c’est ce qui vous intéresse le plus, il s’agit du travail des infographistes, qui est très bien aussi, mais dont la formation se
fait ailleurs.
31 janvier 2007
Laboratoire de Développement de Programmes
Page 8 sur 8.