Projet

Sujet

Le sujet retenu est la réalisation d'une application permettant de jouer à un jeu de type Sliding Block, un puzzle où il faut réussir à sortir d'un plateau un bloc identifié en déplaçant d'autres blocs pour libérer le passage.

Par rapport à la description figurant sur le site, la terminologie et les modifications suivantes sont retenues :

• le plateau est constitué de cases, chaque case est repérée par un numéro de ligne et un numéro de colonne ;
• il n'y a pas de blocs gris, mais des cases spéciales, que l'on appellera murs, qui n'autorisent pas la présence d'un bloc ;
• il n'y a pas un bloc jaune et des blocs bleus, mais l'un des blocs sera identifié comme principal ;
• les blocs sont numérotés (pour faciliter l'affichage), le bloc principal a le numéro 0 ;
• pour déplacer un bloc, il faudra le sélectionner puis le déplacer avec les flèches du clavier.

Déroulement

Le séquencement du projet est prévu ainsi :

• Le TD du 15 décembre 2025 est consacré au début de la conception UML du modèle métier de ce projet ; vous devrez continuer à travailler sur cette conception sur vos HEE.
  
  
• L'objectif est de terminé cette conception et de compléter le code Java généré pour avoir un code fonctionnel avec une interface textuelle : via la définition de méthodes toString(), l'état du jeu est affiché avec des caractères, par exemple, la configuration utilisée en TD peut être affichée sous la forme :
  
  

  | M | M | M | M |
  | M | 1 | C | S |
  | M | C | 0 | S |
  | M | C | 0 | M |
  | M | M | M | M |
  

• Le double-TD du 7 janvier 2026 vous permettra d'apprendre les bases pour réaliser une interface homme-machine graphique en Java ; vous aurez alors le choix entre 3 possibilités :
  • votre application utilisera une interface « en mode texte » : l'état du jeu est affiché après chaque action avec des System.out.println(), les actions de l'utilisateur sont lues via un Scanner ;
  • votre application utilisera l'interface graphique qui sera proposée. Le lien sera disponible après le TD.
    • télécharger de zip gloo.projet.ihm.zip et le transférer dans votre environnement,
    • importer le zip dans Eclipse comme projet : menu File ➔ Import… ➔ Existing Projects into Workspace ➔ Next ➔ Select archive file: ➔ Browse…,
    • vous pouvez déplacer ensuite le code Java fourni dans votre propre projet,
    • votre classe contrôleur devra implémenter l'interface IControleur fournie en respectant les spécifications indiquées ;
  • vous développez vous-même une interface graphique en vous basant sur le double TD du mardi 7 janvier 2026.
    
    

• Le TD du 13 janvier 2026 sera dédié au travail sur le projet intégré : l'encadrant vous aidera à résoudre vos difficultés.
  
  
• Vous aurez jusqu'au mardi 3 février 2026 inclus pour terminer et livrer votre projet en veillant à prendre en compte les aspects qualité exposés lors du cours du 16 janvier 2026 (voir aussi plus bas).

Quelques conseils

• Les diagrammes de séquence UML vous servent à identifier les opérations nécessaires au déroulement du jeu, c'est la partie métier du comportement de vos classes. Vous allez avoir besoin d'autres opérations : des constructeurs, évidemment, des méthodes utilitaires pour construire un jeu… Il est inutile de commencer à les représenter dans votre modèle UML ; il est au contraire plus rapide de les écrire en Java directement dans Eclipse, puis d'utiliser le mode rétro-conception de Modelio pour les intégrer dans votre modèle. Ceci est justifié car ces opérations sont utilitaires.
• Vous pouvez procéder de même pour ajouter un attribut permettant de mémoriser une valeur ; par contre, les extrémités d'associations (qui deviennent des attributs Java) doivent être modélisées en UML pour la partie modèle métier (inutile pour la partie interface graphique).
• Attention aux noms utilisés dans votre modèle UML, il ne faut pas utiliser de mots réservés dans le langage Java. Par exemple, si vous avez une classe Case, une extrémité d'association nommée case provoquera une erreur puisque c'est un mot-clef Java.
• Pour tester votre code, ne commencer pas par vouloir tout de suite lire un fichier qui décrit un plateau. Contentez vous de créer ce plateau en dur (à l'aide d'instructions Java), et débuter par un petit exemple (par exemple celui du TD n°3).

Démarche proposée

1. Vous devez avoir modélisé avec Modelio, sous la forme de diagrammes de séquence, 3 situations sur l'exemple de jeu du TD sur le modèle métier du projet :
   • Sélection du bloc n°1
   • tentative de déplacement du bloc n°1 à gauche,
   • déplacement du bloc n°1 à droite ou du bloc n°0 en haut,
   • Vous avez ainsi déjà trouvé les opérations nécessaires à ces scénarios.
2. Dans Eclipse, créer une classe TestSlidingBloc dans le paquetage projet avec sa méthode main().
3. Dans cette méthode main(), vous allez déjà construire avec des instructions Java le plateau du TD ExerciceProjetModeleBlocs :
   • Des constructeurs seront nécessaires : ajouter les dans Eclipse, sauvegarder vos fichiers, faire un reverse dans Modelio.
   • Des getters et des setters seront nécessaires : sauvegarder vos fichiers dans Eclipse, faire un reverse dans Modelio, sélectionner les getters et setters nécessaires, générer le code Java. Ou alors, générer ces getters et des setters nécessaires dans Eclipse et faire un reverse dans Modelio.
4. Quand le plateau est construit, essayer de l'afficher sous forme textuelle : cela va se traduire par l'ajout de méthodes toString() dans Eclipse qu'il faudra récupérer dans Modelio.
5. Quand le plateau s'affiche correctement, créer dans main() un contrôleur et dérouler les scénarios tels que modélisés dans les diagrammes de séquence en complétant le code Java au fur et à mesure. Si un scénario s'avère incorrect, corriger le afin qu'il reste conforme au code.
6. Quand les 3 scénarios se déroulent correctement, imaginer la suite des actions, sans obligatoirement les modéliser avec des diagrammes de séquence.

Livrables

Le résultat de ce projet devra être livré sur Edunao au plus tard le 3 février 2026. Ce résultat sera constitué d'un rapport au format PDF, d'un export ZIP du projet Modelio (Menu File → Close project puis menu contextuel sur le projet → Export the project…) qui contient aussi le projet Eclipse.

Récupération de vos fichers sur MyDocker

Comment obtenir une image d'un diagramme ?

L'icône disquette dans la barre des outils crée un fichier PNG (d'autres formats sont possibles) du diagramme courant. Choisir Home dans la partie gauche, choisir un nom pour votre fichier et cliquer sur Save. Voir ci-dessous pour le récupérer.

Comment obtenir une archive d'un projet Modelio ?

• Fermer et exporter votre projet (Menu File → Close project puis menu contextuel sur le projet → Export the project…, choisir Home dans la partie gauche et cliquer sur Save).
• Transférer cette archive ZIP sur votre poste (voir ci-dessous).

Comment échanger des données entre votre poste et votre environnement sur MyDocker ?

• Il y a, sur la gauche de la fenêtre, une pointe blanche dans un petit rectangle noir. Si vous cliquez dessus, une liste d'outils s'affiche, avec en particulier un outil Presse-papiers permettant de transférer les presse-papiers entre votre poste et l'environnement MyDocker.

• Deux icônes sont aussi affichées dans la partie supérieure. L'icône File Manager permet de télécharger un fichier (par exemple un fichier PNG obtenu à partir d'un diagramme de classes !) de l'environnement MyDocker vers votre poste mais aussi d'envoyer un fichier (bouton Upload Files) de votre poste vers l'environnement MyDocker (bouton Upload Files). Il faut parfois forcer la mise à jour des fichiers qui s'affichent dans ce File manager en se déplaçant dans un autre dossier (par exemple, Desktop) et en revenant au dossier Parent (..).

Qualité

Quelques exemples de points pris en compte pour évaluer la qualité :

• Chaque classe a une, et une seule, responsabilité identifiée. Une classe ne doit connaître que les classes qui sont nécessaires à mettre en œuvre sa responsabilité ; il ne faut pas par exemple que le plateau connaisse toutes les autres classes.
• Une information est mémorisée une seule fois par un objet dont c'est la responsabilité, elle n'est donc pas dupliquée.
• Les attributs et les extrémités des associations sont privés.
• Les seuls getters et setters présents sont ceux nécessaires.
• La navigabilité des extrémités d'association n'est conservée que si elle est nécessaire.
• Les principes de bonne conception, dont le patron MVC (pas de référence à awt ou swing dans le paquetage métier) et la loi de Demeter, sont pris en compte.
• La conception est prévue pour faciliter l'évolution du logiciel : est-ce facile d'avoir plusieurs niveaux, avec des tailles différentes, de faire des variantes, etc.

Rapport

Le rapport sera structuré ainsi :

• Introduction : l'introduction doit décrire l'objet du document et son organisation.
• Cahier des charges : il s'agit ici d'indiquer l'objectif général du logiciel réalisé en se basant la version du jeu donné comme cible.
• Expression des besoins : cette partie est une description du comportement attendu du logiciel et de ses fonctionnalités d'un point de vue externe (point de vue utilisateur). Elle peut comprendre des diagrammes UML tels que des diagrammes de cas d'utilisation et des scénarios d'utilisation décrits par des diagrammes de séquence (voir ces transparents), mais pas de diagrammes de classes.
• Conception : la partie conception du rapport est une description de l'architecture et du fonctionnement du logiciel d'un point de vue interne (point de vue concepteur). L'objectif de cette partie est de fournir les informations nécessaires à la compréhension de la structure du logiciel. Elle doit notamment comprendre :
  • les explications sur les choix effectués,
  • un diagramme de classes du modèle métier,
  • pour chaque classe, une description de sa responsabilité et des méthodes associées à cette responsabilité (inutile de décrire les attributs, si nécessaire des commentaires dans le code Java suffisent),
  • différents scénarios, sous la forme de diagrammes de séquence, permettant de justifier les opérations présentes dans les classes.
• Réalisation : il n'est pas question ici de mettre le code source du projet, qui doit être livré à part. La partie réalisation du rapport présente la façon dont le modèle UML a été transformé en code Java, la façon dont les développements ont été organisés (organisation temporelle de la réalisation, répartition des tâches au sein du binôme, etc.). Il faut également décrire l'ensemble des tests effectués pour la vérification du bon fonctionnement du logiciel (il n'est pas obligatoire de faire des tests JUnit).
• Conclusion : la conclusion doit présenter le bilan du projet et donner les perspectives envisageables pour l'évolution du logiciel.