Dans le cadre du module SMZG112 Patron de conception l'utilisation de patrons de conception sera évaluée de la façon suivante. Vous identifierez 5 patrons que vous avez utilisez dans votre projet. Chacun des 5 patrons sera noté sur 4 points selon qu'il est utilisé de façon appropriée à la situation et correctement. La note sera également commune à tout le groupe.

Vous devez remettre votre projet au plus tard le dimanche 19 janvier à minuit. Le chef de projet doit envoyer un e-mail à son chargé de TP en mettant en copie ses équipiers. Le mail aura obligatoirement un titre de la forme [Miage][M1][POO] Projet [Nom du projet] -<Nom de famille des équipiers>

Le corps du mail doit obligatoirement contenir :

Le NOM et prénom des participants du projet
Une archive contenant les sources du projet (un projet Eclipse ou NetBeans), pas les binaires !
Un .jar exécutable qui aura été préalablement testé
Un rapport (20 pages maximum) qui décrit
- La participation de chacun des membres de l'équipe ;
- La procédure à suivre pour tester votre projet ;
- Un calendrier des grandes étapes du projet (par membre) ;
- Pour chacun des 5 points énoncés au début (fonctionnalité, chargement dynamique, persistance, modularité, suivi), la façon dont ils ont été adressés ou pas et les aspects remarquables.
La procédure pour créer de nouveaux plugins
Plusieurs exemples de plugins (au moins 4) avec une courte description (10 lignes maximum) de ce qu'ils font.
Un rapport séparé (5 pages maximum) qui décrit les cinq patrons utilisés et les raisons pour lesquels l'utilisation de ces patrons vous semble pertinente.

Le contenu du mail (si trop gros) peut également être déposé sur un site de gestion de code (type google code ou assembla). Il faudra penser à garder une copie locale au cas où le site tombe en panne la veille de la démonstration.

Une soutenance orale (par groupe) aura lieu le mardi 22 janvier selon un calendrier annoncé ultérieurement. Cette présentation orale de 20 minutes aura pour but de mettre en lumière la contribution individuelle de chaque membre du groupe. Cette note de soutenance sera individuelle.

La note finale de projet sera calculée en faisant la moyenne de la note de rendu de projet (50%) et la note de soutenance (50%).

Fonctionnalité

Le but du projet est de mettre en oeuvre les différents aspects étudiés et appliqués lors des cours et des TDs. Pour cela, on vous propose deux sujets au choix. Vous pouvez également proposer un sujet qui remplit les critères ci-dessus en écrivant une page de description du projet à envoyer à miage.m1@gmail.com :

Sujet 1 - MyPaint

Le premier sujet consiste à réaliser un logiciel de gestion de dessins et figures vectorielles.

Les plugins seront par exemple:

- les figures à créer (formes géométriques simples, groupées, polygones, lignes brisées, zone de texte, ...). Chaque figure a des propriétés spécifiques que le logiciel principal ne connaît pas. Par exemple, le polygone a un nombre de points variables (supérieur à 3). Votre outil devra analyser dynamiquer les propriétés accessibles en lecture ou en écriture et proposer une interface graphique pour les modifier le cas échéant. Chaque figure sera proposée à l'utilisateur à travers une palette et un menu créés dynamiquement en fonction des plugins disponibles.

- des formes polygonales ou de Bézier prédéfinies (ex: smiley, diagramme de classe UML).

- le système de gestion de menus peut être réalisé par un plugin, les plugins de figures devront alors utiliser ce plugin (cf. dépendance).

- le système de gestion de la palette peut également être réalisé comme un plugin.

- les figures peuvent également être des images (affichés à partir d'un fichier). Des plugins supplémentaires peuvent permettre de faire des algorithmes simples de traitement des images. Pour qu'un plugin soit accepté comme tel, il n'est pas nécessaire que vous réalisiez l'algorithme lui-même, vous pouvez utiliser des bibliothèques extérieures. Votre travail sera alors un travail pour packager cette bibliothèque extérieure pour qu'elle soit acceptée comme un plugin de votre programme en gérant, le cas échéant, l'accès au bytecode de la bibliothèque (dépendence vers un fichier .jar).

Sujet 2 - MMORPG

Le but du projet est de réaliser une interface de création de personnage à la manière d'un jeu de rôle (MMORPG) sur PC.

Les classes de personnages:

La caractéristique principale d'un personnage est sa classe:

guerrier, magicien, voleur dans un monde médieval fantastique;
policier, journaliste, scientifique dans un monde contemporain;
cyborg, mutant, ou extraterrestre dans un monde futuriste/post-apocalyptique.

Le module de création de personnage devra charger dynamiquement les classes de personnages détectés et générer une interface (GUI) permettant d'éditer un personnage de cette classe.

Equipements:

Les personnages possédent des équipements dont certains ne sont utilisables que par une classe donnée. Ces équipements fournissent des capacités d'actions au personnage comme lancer des sorts, tirer, taper, se téléporter, se soigner ... (en plus des capacités de base de la personne).
Chacun de ces équipements sera une classe java et devra être détecté dynamiquement par le programme afin d'être attribué au personnage en cours de création.

Les stratégies de combats:

Une fois le personnage créé, il convient de définir le comportement qu'il aura en cas de combat. Quelques règles pourront être données au personnage afin qu'il sache quoi faire. Le nombre de règles peut varier d'un personnage à un autre en fonction de sa classe.
Chaque règle est une action à réaliser quand une condition se présente:
-Si l'ennemi est un guerrier: le paralyser et lancer des sorts de combat
-Si j'ai moins de 15% de mes points de vie: se soigner
-Si l'ennemi est loin, lancer des flèches
En plus de ces actions, chaque personnage devra avoir une action par défaut comme "Ne rien faire" ou "attaque avec l'arme principale".

Pour pouvoir définir ces stratégies, il faut que toutes les capacités du personnage et de son équipement apparaissent dans le menu. Pour celà, il faut aller chercher par introspection les méthodes appropriées. On peut utiliser des annotations pour définir et détecter les bonnes méthodes.

Combats:

Afin qu'il y ait une finalité à la création de personnage, on peut imaginer un module qui simule un combat entre deux personages avec un suivi textuel des actions réalisées par chacun des personnages en suivant les stratégies de combats. Attention, il ne faut pas se perdre dans les détails. cette partie n'est pas essentiel au projet.

Plugin eclipse de création de classe de personnage:

Dans cette dernière partie, le but est d'aider le concepteur de classe de personnage à réaliser une nouvelle classe et /ou objets. Le plugin offrira les messages (warning et error) afin de guider le créateur. Ex:
Erreur: Le champs obligatoire "Point de vie" n'est pas défini.
Warning, L'action par défaut est vide.

Réalisation:

Il faut définir les interfaces/Classes abstraites qui seront utilisées dans le projet: ClasseDePersonnage, Objet
Il faut définir des objets est des classes de personnage
Il faut faire le module de création de personnage (+ sérialisation) et de définition des stratégies.
Il faut faire le module de simulation des combats.
5/Il faut faire le plugin de dévelopement de classe de personnages.

Chargement dynamique

Les fonctionnalités supplémentaires doivent être chargées dynamiquement. Il est impératif de pouvoir recharger des nouveaux plugins à chaud (sans avoir besoin de fermer la fenêtre).

Une considération particulière sera donnée aux projets capables de montrer qu'ils ont intégrés des plugins réalisés par d'autres équipes.

Persistance

La persistance consistera à pouvoir sauvegarder et rétablir l'environnement en restaurant la ou les feuilles ouvertes, en restaurant les fenêtres graphiques, les formules ou les mises en forme lorsqu'elles ont été appliquées.

Attention toutefois à se préoccuper des erreurs potentielles lorsque le plugin associé à une fonctionnalité sauvegardée n'est plus disponible.

Modularité et dépendance

Certains plugins peuvent dépendre d'autres plugins. Par exemple, un plugin ne peut pas ajouter des menus dans la fenêtre s'il n'y a pas un plugin spécifique pour gérer l'ajout des menus. Il n'est pas possible de dessiner des données s'il n'y a pas un plugin pour gérer le contenu de la table.

Le rapport devra décrire le mécanisme mis en place pour gérer les dépendances entre les plugins.

Documentation et suivi de projet

Le code devra être suffisamment commenté pour être lisible. La documentation javadoc sera générée. Cela n'a de l'intérêt que s'il y a au minimum:

Une description du rôle de chaque classe dans l'en-tête de la classe ;
Une description du fonctionnement des méthodes (hors accesseurs et modificateurs) ainsi que des paramètres.

Un des équipiers s'occupera du suivi du projet, de la coordination des actions des équipiers. Il sera déchargé d'une partie du travail de développement pour assurer cette tâche. Cette "décharge" ne sera prise en compte que s'il y a réellement du travail de suivi et de coordination mis en place. Il vous appartient de valoriser cette action dans votre rapport et votre présentation.

Récupéré depuis "http://miageprojet2.unice.fr/index.php?title=User:FredericMallet/Programmation_Avanc%C3%A9e_-_2012%2F%2F2013/Projet_2013-2014"