Java EE : TP 27.01 et 29.01

Exercice 0.

Puisque les deux exercices de la semaine dernière n'ont pas été terminés (et certains travaillaient toujours sur les équations quadratiques, ce que je trouve inquiétant, "beaucoup de bruit pour rien"...), pas d'exercices "officiels", complets cette semaine, seulement un préavis concernant votre exercice suivant. Tout sera répété et précisé, mais lisez soigneusement la description ci-dessous, diagnostiquez les lacunes d'information, essayez d'esquisser votre architecture, peut-être faites des mini-squelettes des éléments/composantes, et éventuellement posez des questions.


Exercice 1.

Votre travail obligatoire prochain consistera à concevoir et implémenter :

Le projet n'est pas très rigide (pour l'instant), et il sera restreint, car dans le contexte de la fac l'installation d'un véritable service Web universel, multi-utilisateur, et pleinement contrôlable, peut poser des problèmes. J'imagine que dans la configuration minimale tout se déroule sur une machine, utilisée par deux joueurs à tour de rôle (ce qui facilitera aussi les tests / correction).

Le servlet d'accueil (pas forcément un servlet au sens strict du terme) vérifie d'abord si la base de données du jeu existe, et si non, initialise le système. Cette initialisation installe deux joueurs, le blanc et le noir, chacun avec son nom qui l'identifiera plus tard, car le jeu sera re-entrant, avec la sauvegarde de l'état courant. La BD Derby est crée.
Variante : La BD est crée avant toute interaction, la configuration initiale y est sauvegardée, et la table "utilisateurs" est crée vide. Le système vérifie si elle est vide, et alors procède à l'initialisation.

Après l'initialisation, l'accès affiche la configuration, et précise qui doit jouer. Le système doit demander l'authentification, assez simpliste, le nom de joueur sauvegardé. Alors la BD est verrouillée, et l'autre utilisateur ne pourra accéder au système, avant que le premier ne clique sur le bouton de terminaison/sortie.

L'interface offre plusieurs options : jouer, afficher l'historique, abandon (ce qui réinitialise le jeu, et offre une option secondaire : garder ou effacer les joueurs actuels), UNDO (uniquement du coup actuel, bien sûr, c'est pour corriger les fautes de frappe), et passer à l'autre joueur tout de suite, sans terminer la session [ceci peut être activé/automatisé comme le comportement par défaut]. Probablement il serait utile de pouvoir exporter la partie (son historique) en format lisible, et aussi importer une partie pour la rejouer.

En principe c'est tout essentiel. Toute modification est sauvegardée, et le client peut se déconnecter, jusqu'à l'étape suivante.
Le projet est extensible, le premier enrichissement qui vient à l'esprit, c'est le refus d'accepter les coups illégaux, par ex. mauvaise topologie du mouvement, mais aussi laisser le roi sous échec, continuation avec le roi maté, roque illégal [R ou T ont bougé, l'espace du roque sous menace], etc. Ceci peut être assez compliqué, donc ne vous concentrez pas trop dessus, car ce module seul peut être aussi volumineux que la totalité du reste... Mais au moins la tentative de déplacer une pièce inexistante, ou l'encastrer sur une autre du même joueur est facile à diagnostiquer.

La communication avec le serveur peut être séquentielle, "ping-pong". Cependant la page du jeu contient une partie statique qui ne change pas, et l'affichage dynamique de la configuration, donc on peut imaginer l'usage des appels AJAX, pour rendre le processus de façon plus moderne. Mais je n'ai pas réfléchi dessus, ce n'est qu'une idée in statu nascendi...

L'architecture de la BD est à vous de concevoir et d'implémenter. On y trouvera les utilisateurs, avec un d'eux actif (il pourra jouer, l'autre devra attendre). La BD conservera, bien sûr la configuration de l'échiquier, mais aussi l'historique des coups, et une option de l'interface doit permettre à ce que le système rejoue la partie.
Utilisez, SVP, la notation standard, algébrique, sauf si vous avez une autre proposition, compacte, commode, justifiée (peut-être l'internationale).

Quand même une question immédiate, moralement obligatoire !   L'illustration sur cette page n'a pas été faite par un jouer d'échecs consciencieux (ou son auteur c'est quelqu'un encore moins sérieux que moi...). Quelle est la propriété de l'illustration qui me permet de tirer cette conclusion? Ceux qui trouvent la réponse sont priés de ne pas la diffuser, car ceci peut seulement influencer votre appréciation dans vos propres yeux... Envoyez la réponse par mail, ou oralement.

Je précise : il s'agit d'une défaillance visible par un joueur d'échecs, en toute indépendance de la "folie décorative" : verres de bière, filles à poil, figurines de politiciens particulièrement laids, robots mécaniques qui tirent balles réelles, etc., ceci n'a pas d'importance...


Solutions (peut-être).

Retour
Semaine suivante