Réingénierie et design patterns en JAVA
Objectif
Il vous est demandé d'effectuer une ré-ingénierie d'un code existant en mettant en oeuvre les patrons de conception vus en cours. Vous allez également concevoir une nouvelle application en utilisant le formalisme UML et en exploitant au maximum les procédures de génération de code et de rétro-conception.
Votre travail devra être rendu sous forme d'un projet déposé sur la Forge Lyon 1, au plus tard le dimanche 18 octobre à 23h59.
Déroulement
Le travail peut être organisée en deux étapes :
- la première sera une étape de ré-ingénierie (refactoring) du code des Tortues utilisé au TP1, afin de rendre les packages plus modulaires.
- la seconde sera dédiée à la conception d'une application permettant à deux équipes de Tortues de jouer au ballon.
Partie 1 : Ré-ingénierie du code
Le code qui est fourni dans logo.zip est un package relativement fouillis. Toutes les classes sont dépendantes les unes des autres, les couches graphique et métier ne sont pas séparées.
Il va vous falloir reconcevoir le code (et le modèle) en appliquant les patrons de conception adéquats. Pour cela, vous devez réorganiser les éléments de l'application logo. Entre autres, l'affichage des tortues doit être séparé de la gestion des tortue, de leurs déplacements, etc. Les changements dans le modèle métier (déplacements de la tortue) devront être répercutés dans l'affichage. L'utilisation de l'IHM (boutons) entraînera des changements dans le modèle métier en passant par un contrôleur. On considérera dans cette partie une IHM simplifiée, qui permet juste de commander une Tortue dans ses déplacements (avant, arrière, droite, gauche).
Partie 2 : Conception et développement d'une nouvelle application
On reprend la thématique générale des tortues qui jouent au ballon, pour concevoir une nouvelle application. L'objectif de l'application est de permettre à un utilisateur de faire jouer au ballon l'une contre l'autre deux équipes de joueurs. Le jeu se passera sur un terrain muni de deux enbuts, l'arrivée du ballon dans l'enbut de l'adversaire permettra à une équipe de marquer un point. Un match s'interrompra au bout d'un certain temps.
Chaque équipe aura une tactique de jeu, qu'elle pourra changer en cours de partie (action utilisateur). Une tactique concerne la manière de faire réagir une équipe de façon globale : mouvements, passes, etc. Une tactique peut dépendre de la position des joueurs sur le terrain, de leurs caractéristiques individuelles, de leurs positions respectives, de l'équipe adverse, etc. On définira au moins trois tactiques différentes.
Chaque joueur aura des caractéristiques individuelles. Les caractéristique définissent sa manière de réagir quand il a ou n'a pas la balle, en fonction de son placement sur le terrain, de la proximité des adversaires, etc. Les caractétistiques du joueur déterminent la réaction locale du joueur. On pourra par exemple avoir des défenseurs et des attaquants, des rapides et des lents, etc.
L'action d'un joueur sera donc déterminée d'une part par la tactique employée dans son équipe, d'autre part par ses caractéristiques individuelles. A vous d'imaginer comment vous gérez ces deux informations. L'utilisateur devra au minimum pouvoir lancer un match entre deux équipes, l'interrompre, changer la tactique d'une équipe en cours de jeu. On disposera pour suivre le jeu de trois fenêtres graphiques au minimum
- une présentant le terrain, les joueurs, la balle, etc.,
- une autre présentant le score et les contrôles du jeu
- une troisième présentant en permanence la couleur de l'équipe qui a la balle.
Conseils pour la réalisation
Faites un modèle du domaine du jeu de ballon que vous voulez mettre en place : joueurs, caractéristiques joueurs, ballon, tactique, etc en réutilisant au maximum le modèle correspondant au code mis en place dans la partie 1. Organisez vos classes en packages pertinents. Construisez ensuite le diagramme des classes d'implémentation à partir du modèle du domaine.
Complétez votre conception pour réaliser des scénarios correspondant à des interactions différentes au cours du jeu (création du jeu, phase où une équipe à la balle, passe d'une balle, etc.), notamment avec des diagrammes de séquence. Faites évoluer les classes avec les besoins identifiés, en complétant petit à petit attributs et méthodes (jusqu'à ce que vous pensiez que vous pouvez passer au codage). Utilisez diagrammes d'activités et d'états-transitions pour illustrer les différents fonctionnements : système, équipe, joueurs, etc.
Une fois vos classes de conception à peu près stabilisées, générez le code correspondant à votre projet, et utilisez éventuellement la procédure de round trip engineering pour synchroniser en permanence code et modèle. Parmi les applications de modélisation UML, vous pouvez utiliser ArgoUML, BoUML, UModel... Vous pouvez également utiliser des plugins UML pour Netbeans ou Eclipse.
Rendu du TP
Projet Forge et questionnaire
Votre dépôt sur la Forge devra contenir :
- les sources (fichiers Java)
- la documentation javadoc de vos classes
- le rapport en PDF. Il doit comprendre une présentation globale du projet, une motivation des choix d'architecture (et des patterns choisis), et leur explication en s'aidant de diagrammes appropriés et adaptés au degré de précision et au type d'explication. Donc diagramme de classe, mais pas que cela et pas de plat de spaghetti illisible représentant tout le code et généré automatiquement
- les fichiers natifs de votre modélisation UML (indiquez quel outil a été utilisé)
Barême indicatif :
- Réalisation : 7 points
- Respect des consignes
- Application des patterns
- Fonctionnement
- Rapport : 5 points
- Contenu et forme (voir ci-dessus)
- Orthographe
- Explication des patterns (liens diagrammes - explications)
- Modélisation : 5 points
- Patrons utilisés
- Diagrammes fournis
Dans la configuration de votre projet, ajoutez Lionel MEDINI et Aurélien TABARD en tant que "reporters". Remplissez également le questionnaire Spiral, ce qui permettra aux intervenants de récupérer automatiquement les projets : Questionnaire Spiral