Projet Génie Logiciel Avancé, Version 1.0 14 février 2012 1 Introduction Un certain client aimerait un clone de Worms. Sa demande est fournie séparément. Remarquez que l on ne vous demande pas : De prévoir un mode de jeu contre l ordinateur D avoir des caisses d objets tombant aléatoirement De pouvoir jouer un contre un sur le même ordinateur Néanmoins, comme le suggère les grands principes du génie logiciel, on essaiera de faire un logiciel le plus abstrait et générique possible, et également de faciliter les extensions futures. Après avoir livré la version finale du projet, aura lieu un test grandeur nature i.e. le client jouera intensivement et il est possible qu il demande certaines améliorations. Il faudra s organiser pour y répondre (le client est roi) ainsi qu aux demandes de corrections de bugs. Toute question sur le projet devra être posée sur la mailing list (inscription obligatoire pour tout le monde) : https://listes.sc.univ-paris-diderot. fr/sympa/info/m1gl-projet 2 Déroulement du projet 2.1 Calendrier Les moments clés du projet (intervenant dans la notation) : 1. 5/03 : rendu de la spécification du projet 2. semaine du 2/04 : livraison provisoire 3. semaine du 30/04 : livraison finale 4. du 01/05 au 18/05 : phase de test grandeur nature 5. semaine du 21/05 (ou 28/05) : soutenance 2.2 Analyse et spécification En ayant en tête les grand principes du génie logiciel, vous spécifierez le système : 1
En spécifiant ce à quoi peut s attendre l utilisateur final. Si vous avez des doutes sur ce que veut le client (ce qui est normal), vous pouvez soit le contacter, soit supposer ce qu il attend à condition de le spécifier en plus de la description actuelle. En spécifiant l architecture, les différents composants, ainsi que la répartition des différentes tâches aux différentes équipes. En spécifiant les différentes interfaces, les protocoles, que les différentes équipes devront respecter. Pour les deux dernières parties, vous donnerez des diagrammes UML spécifiant les grandes lignes (mais pas forcément chaque diagramme de classe). 2.3 Livraison provisoire Le but de cette livraison est d avoir un programme qui tourne même si tout n est pas implémenté. Il serai bien d avoir à ce moment du projet : Une partie avec une carte chargée, des vers pouvant se déplacer correctement (ils tombent s il y a un précipice) La gestion des collisions entre deux vers (ils ne peuvent pas se croiser) En particulier, les points suivants pourront être laissés de côté : L utilisation des armes (du moins celles compliquées) L interaction entre les deux clients Le système de points de vie La gestion du vide Le déplacement d écran (scrolling) 2.4 Livraison finale Tout devra être fini à ce moment là, y compris les différentes documentations. Le logiciel rendu devra être utilisable, il va de soit qu on doit pouvoir jouer correctement sans bug majeur. Il faudra préférer avoir fait peu mais bien que le contraire. Si par hasard le projet ne compile pas, la note vaudrait bien évidemment 0. 2.5 Phase de test Pendant ce temps là, le client va tester le logiciel et soumettra des rapports pour les bugs qu il rencontrera. S il l estime nécessaire, il pourra demander de nouvelles fonctionnalités. Celles-ci devront être prêtes pour le jour de la soutenance. 2.6 Soutenance Vous présenterez votre projet, vos choix techniques, les améliorations futures. La forme exacte reste à déterminer. 2
3 Articulation du projet 3.1 Graphismes On ne vous demande pas de réaliser des graphismes. Vous pourrez réutiliser des images libres de droit comme celles utilisées par d autre clones de Worms (http://www.hedgewars.org). Si vous désirez réaliser vous même des images, il faudra utiliser la canal alpha pour gérer la transparence (http://fr.wikipedia. org/wiki/canal_alpha). 3.2 Gestion de l affichage Votre travail doit avoir un aspect irréprochable. Pour cela il ne faudra pas redessiner à la main les worms. Vous devrez utiliser des techniques plus évoluées comme le double-buffering ou page flipping (http://docs.oracle.com/ javase/tutorial/extra/fullscreen/doublebuf.html). Il existe des classes standards en Java qui font le travail pour vous (http://docs.oracle.com/ javase/tutorial/extra/fullscreen/bufferstrategy.html). Prenez également en compte les conseils donnés ici : http://docs.oracle.com/javase/tutorial/ extra/fullscreen/rendering.html. Vous êtes libres d utiliser les bibliothèques existantes. En Java, il est possible de se contenter de la bilbliothèque standard (avec awt, swing) comme proposé dans ce tutoriel : http://www.cokeandcode.com/index.html?page= tutorials/spaceinvaders101. Ou bien JOGL comme proposé ici : http:// www.cokeandcode.com/index.html?page=tutorials/spaceinvaders103. Remarquez que la gestion de l affichage devrait être indépendante du reste en appliquant le modèle MVC. Dans le précédent tutoriel, en modifiant une ligne on passe de awt à JOGL. Il devrait en être de même dans votre logiciel. Vous pourrez encore utiliser la bibliothèque lwjgl http://www.lwjgl.org comme décrit dans ce tutoriel http://www.cokeandcode.com/index.html?page=tutorials/ spaceinvaders104. Pour Python, vous pouvez utiliser Pygame (http://pygame. org) ou bien PyOpenGL (http://pyopengl.sourceforge.net). Pour avoir un affichage correct, il est important que votre programme soit suffisamment rapide (sur les machines de l UFR) pour afficher au moins 30 images par seconde. De plus, pour éviter certains désagréments visuels, il est préférable que cette vitesse ne varie pas. On pourra donc avoir en permanence 30 images par seconde. 3.3 Réseau Vous devrez vous mettre d accord avec l autre équipe sur un protocole de communication entre le serveur et le client. Il pourra prendre la forme que vous estimez nécessaire mais ne devra pas être trop gourmand en utilisation de la bande passante. Vous utiliserez les fonctions de haut niveau de Java et Python pour pouvoir communiquer. 3
3.4 Détection des collisions Cette partie doit être traitée avec minutie car une implémentation naïve peut donner des performances catastrophiques. Pensez à donner une enveloppe rectangulaire à chacune de vos entités se déplaçant pour pouvoir effectuer des tests rapides. Une partie relativement complexe du projet va consister à transformer une carte (au format.png ou.jpg) en un objet manipulable par votre programme. En particulier le déplacement de votre vers devra épouser les contours de votre carte, et éventuellement s arrêter s il rencontre un mur (ou du moins une pente trop raide pour être montée). Le modèle devra être suffisamment abstrait pour que les calculs soient rapides mais pas trop pour que le vers monte une pente de façon linéaire. Vous pourrez vous inspirer du code de projets existant. 4 Parties techniques 4.1 Langage Vous pourrez utiliser Java ou Python. Chacun des langages a son style que vous devrez respecter. En plus du style, il faudra respecter les conventions données par http://java.sun.com/docs/codeconv/codeconventions. pdf pour Java et par http://python.org/dev/peps/pep-0008. Le respect des conventions est d autant plus important qu il y a de programmeurs différents et de lignes de code. Vous pouvez ne pas être d accord avec la convention mais vous devez la respecter. Il existe des outils comme pep8 ou Checkstyle pour vérifier entre autre le style. 4.2 Environnement de développement Vous pouvez utiliser l environnement qui vous convient et ne devez pas en imposer un au sein du groupe. 4.3 Gestion de projet Le projet devra être versionné avec un accès en écriture pour chacun des membres et en lecture pour l enseignant. Vous pourrez utiliser le gestionnaire de votre choix (Subversion, Git, Darcs,...). Il faudra également avoir un système de gestion des tâches et des bugs. Pensez également à mettre en place un moyen de communiquer accessible à tous et pérenne. Des sites web comme https: //github.com ou http://sourceforge.net proposent de tels services. 4.4 Commentaires Toute classe et toute méthode doit être commentée avec au moins la description des arguments et la description du résultat. Vos commentaires doivent pouvoir générer une documentation HTML avec Javadoc ou pydoc. Si vous l estimez nécessaire, écrivez des commentaires sur les parties complexes de votre 4
code. Si un membre du groupe a mis du temps a comprendre votre code, il faut écrire un commentaire. La meilleure manière consistant à faire écrire tous les commentaires de votre code par quelqu un d autre (et vice-versa) 4.5 Tests Votre programme devra impérativement contenir des jeux de tests. Vérifiez que chaque ajout de fonctionnalité ne casse pas des tests passant auparavant. Utilisez les outils standards pour effectuer des tests comme unittest pour Python ou JUnit pour Java. La méthode de développement piloté par les tests est préconisée mais pas obligatoire. 5 Évaluation Les différents rendus (spécification, livraison provisoire, livraison finale), la réactivité durant la phase de tests, ainsi que la soutenance seront pris en compte dans la note finale. La note de chaque étudiant correspondra à la note du groupe éventuellement modulée. Le groupe ayant le meilleur rendu au des points bonus. 5