La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Programmation Objet en JAVA Cours 8 : Projet de Programmation, JUnit, retour sur le partiel.

Présentations similaires


Présentation au sujet: "Programmation Objet en JAVA Cours 8 : Projet de Programmation, JUnit, retour sur le partiel."— Transcription de la présentation:

1 Programmation Objet en JAVA Cours 8 : Projet de Programmation, JUnit, retour sur le partiel

2 Infos pratiques Rattrapage du 11/11 –TD : lundi 16/11 –Cours jusquau 2/12 Le projet a démarré : –Il y a 6 séances –Ne ratez pas les évaluations ! –Les retards seront pénalisés.

3 Gestion de projet : méthode

4 Agir avec méthode Pour un développement conséquent, ne pas se perdre. Les objectifs de base : –quels sont les objets nécessaires ? – quelles sont les interfaces de ces objets ? –existent-t-ils des classes ? Comment les écrire si nécessaire ? Phase 0 : faire un plan ! Phase 1 : définir lobjectif -> cahier des charges –Quel est le « produit » ? une application java –Faire des scénarii dutilisation (use case) Permet de répondre aux 3 questions de base. Faire un fichier par classe, y écrire les signatures des méthodes publiques, et surtout beaucoup de commentaires. Commencer lécriture des interfaces qui répondent aux use cases. Pas dimplémentation

5 Méthode - suite Phase 2 : Comment construire ? Classes et interaction –Etendre la phase 1 et prévoir des classes utilisables et réutilisables. –Commencer lécriture de chaque classe. –Bien choisir son nom. –Définir les responsabilités de chaque classe. –Définir les collaborations entre les classes. –Aboutir à un diagramme de classe –Un fichier source par classe, des classes courtes ! –Dans les commentaires, indiquer quelles sont les informations stockées et comment elles sont traitées. –Penser au polymorphisme.

6 Méthode - suite Phase 3 : écrire le coeur de lapplication –écrire les classes principales –« remplir » les fichiers, réaliser les commentaires. –implémentation, choix des attributs –encapsulation des données. –Tests unitaires Phase 4 : Retour sur les scénarii utilisateur. –compléter, augmenter les use cases –Ajouter des classes et des méthodes –retour à la phase 2. Phase 5 : évolution

7 Mise en oeuvre Stratégies pour le code –Extreme programming : écrire dabord les tests. –Pair programming Divers : –noubliez les packages dans la conception. –Ne pas réinventer la roue, utiliser lAPI Java, les conteneurs,... –Documenter au maximum son code, pour lutilisation et la réutilisation -> javadoc, vous travaillez à deux ! –Lutilisation de CVS (ou svn) est obligatoire Voir sur le wiki de lIE2, il existe un server svn paramétrable Contacter Gilles Soufflet pour avoir un compte.

8 Test Unitaire, JUnit 4

9 Pourquoi tester ? Principe de programmation : un programme terminé est un programme testé ! Lobjectif est de garantir le fonctionnement dun programme : –test formel : démontrer quun algorithme respecte un ensemble de spécification formel. –test exhaustif : envisager tous les cas possibles !!! –test heuristique : choisir judicieusement des cas dutilisation critique.

10 Les différents types de test test unitaire : –test les modules indépendamment test dintégration : –intégration des différents modules é –orienté utilisateur test de régression : –sassurer quune modification ne remet pas tout en cause. Les manières : black box testing –vérification du respect par un objet de son interface, ses spécifications test fonctionnel white box testing –vérification des dé́tails dune implémentation.

11 Problématique des tests unitaires Cycle de développement « en TP » : –écriture dun petit bout de code (quelques heures) –test avec le debugger ou avec des println. –vérification « à la main » des résultats Le code ajouté au fur et à mesure est testé incrémentalement. Mais : –peut-on ré-exécuter les tests ? non. –comment faire avec plus de 10 classes qui interagissent ? rien. –Comment visualiser tous les println ? Peut mieux faire !

12 Principe des tests unitaires Détecter les erreurs le plus tôt possible dans le cycle de développement : –tester la méthode dès son écriture –répéter lensemble des tests à chaque modification (régression) –garder la trace des résultats. Les questions à se poser pour écrire un « bon test » : –la méthode fait-elle ce qui est attendu ? –supporte-t-elle les modifications dautres méthodes ? –envisager des cas critiques dutilisation. Une approche extrême : –écrire les tests dabord à partir du cahier des charges, coder ensuite !

13 Principe des tests unitaires - conséquences Au moins un test par méthode ! Le contenu dun test : –fixture : code dinitialisation du test –assert : comparer la valeur attendue avec celle obtenue –un rapport (mail, gaphique,...) –les tests sont indépendants. Couverture : envisager le plus de cas possible Conditions « au bord » Répétition dopération

14 Erreurs habituelles -> tests habituels On a tendance a répéter les mêmes erreurs –faire des tests au plus tôt permet de réduire cet effet Les erreurs habituels : –avec les nombres : 0, le plus grand/petit, positif/négatif,... –avec des structures de données : structure vide avec un seul éléments avec le maximum déléments accès répéter à un même élément duplication dun élément effacer un élément...

15 Selon les phases de travail Phase de développement : –les tests qui doivent réussir : test aux limites : trier une liste vide ou avec un seul élément cas intéressant simple : trier une liste de deux valeurs cas général : trier une liste de 11 valeurs –les tests qui doivent échouer : entrée, accès invalides mauvaise « entrée de lutilisateur » Phase de test : –dès quune anomalie est détectée : écrire le test qui correspond –documenter ses erreurs courantes.

16 Exemple chiffré Logiciel resolver (www. resolversystems.com) 57k lignes de codes 2 millions de dollars 1 an et demi de développement pour 10 développeurs (10 lignes par jours) 31k lignes de tests unitaires : 55%

17 JUnit 4 / Java > 1.4 Un ensemble de test est regroupé dans une classe « normale » : –avec des attributs et des méthodes. Les méthodes relatives aux tests utilisent les annotations public void methodeDeTest(){.... } –Les annotations accrochent une information à une méthode, un attribut, ou une classe. –Cette information peut ensuite être traitée par un mécanisme indépendant (compilateur, interpréteur, environnement dexécution,... ). Se créer et sexécute avec un IDE. Voir un exemple avec Eclipse : –création de la classe de test –exécution

18 JUnit4 - les assertions static void assertTrue(boolean test) – méthode JUnit : vérifie (test == true) – dans le cas contraire lance une exception (en fait une Error) de type AssertionFailedError => traitée par lexécuteur JUnit. Les autres : –assertFalse –assertEquals –assertSame, sur les références –assertNotSame –assertNull, assertNotNull fail : lance une erreur, avec un message.

19 Les « fixtures » et autres subtilités Pour initialiser avant chaque test Initialiser une seule fois Pour Ignorer un Tester dans un temps Pour plus dinformation : –Le site junit.org –Un étude de cas : abreslav.googlepages.com/j-junit4-a4.pdf –Le site des furieux : extremeprogramming.org Pratiquer pendant le projet : –Les tests unitaires seront bienvenus !

20 Projet de programmation Introduction

21 Un projet de développement (objet) Les 5 phases fondamentales Analyse du problème Conception objet Implémentation Test et vérification Documentation Ces 5 phases sont dégales importances. Le projet se fait en binôme.

22 Les objectifs du projet réaliser entièrement, de zéro, un projet à partir de spécifications informelles (énoncé en français) et formelles (un ensemble d'interfaces); étape de conception préalable à l'implémentation; encapsuler vos données pour obtenir des programmes robustes; éprouver l'intérêt de séparer la partie traitement d'un programme de sa partie interface utilisateur; tester au fur et à mesure ! des programmes réutilisables par dautres et par vous; donc les écrire lisiblement en les commentant judicieusement; utiliser javadoc pour générer la documentation utiliser des outils développements appropriés.

23 Le sujet, le jeu Parcourir lArdèche en passant par un maximum de villages différents Mais à chaque route son moyen de transport.

24 Les éléments de Jeu Les joueurs (un nom, une couleur) La carte de lArdèche : 20 villages reliés par 36 routes Une route relie 2 villages et traverse un type de paysage parmi 4 : –plaine, forêt, garrigue, montage –le type de la route implique des moyens de transport et des coûts spécifiques. Un carte moyen de transport = un crédit pour un mode de transport : –l'âne, le sanglier, le vélo, le tracteur, la mobylette, et l'ULM Un pion de transport : –permet dindiquer pour une route de la carte quel moyen de transport DOIT être utilisé. –un seul pion par route (hors obstacle)

25 Tour de jeu : 6 étapes Etape 1 : distribution des cartes Voyage (8 par joueur) –Les cartes doivent donc être distribuée aléatoirement –Créer toutes les cartes, et les ranger dans un paquet –Prévoir une méthode pour distribuer les cartes (une à une, ou n fois) –Un joueur doit pouvoir « contenir » ses cartes Etape 2 : Attribution du pion de transport caché –Chaque joueur reçoit un pion de transport que lui seul connait, pris dans le paquet des pions de transport. –Comme pour les cartes et le paquet de cartes –Un joueur doit connaître son pion caché, mais pas les autres joueurs.

26 Tour de jeu - suite Etape 3 : Attribution des pions de transport –Parmi le paquet de pions de transport, 5 pions sont au préalable piochés et posés face visible –Chaque à tour de rôle joueur a le choix : prendre un des 5 pions visibles, dans ce cas le pion pris est remplacé ou piocher dans le paquet. –Au total, chaque joueur doit acquérir 3 pions de cette manière. –Ces trois pions sont visibles des autres joueurs.

27 Tour de jeu - encore Etape 4 : préparation des routes –chacun son tour, un joueur pose un pion de transport sur une route –Sur une route, il ne peut y avoir qu'un seul pion moyen de transport. –Un moyen de transport ne peut être posé sur une route que s'il est approprié –Ces moyens de transportposés sur le plateau peuvent être utilisés par tous les joueurs lors de leurs déplacements (phase suivante). Au lieu dun pion moyen de transport, un joueur peut placer un obstacle. –Sur un moyen de transport déjà en place. Sur une route il ne peut y avoir qu'un obstacle. –Un obstacle sur une route oblige à payer plus cher. Un joueur peut aussi passer son tour. Si aucun joueur ne veut ou ne peut plus poser de moyen de transport, cette phase est terminée.

28 Tour de jeu - encore Etape 5 : le voyage –chacun son tour, le joueur se déplace sur les routes où sont posés les pions de transport –en payant avec ses cartes de transport, –sur autant de routes qu'il veut et en visitant autant de villages qu'il peut en respectant les règles. Le but : atteindre des villes différentes. Premier passage dans une ville, le joueur prend un pion/marqueur de sa couleur. Une ville doit donc contenir un marqueur par joueur ! on peut lenlever une fois, cest tout.

29 Tour de jeu - cest presque fini Etape 6 : résolution du tour –Le rôle de premier joueur passe au suivant. – Chaque joueur doit redonner tous ses pions moyen de transport pour n'en garder qu'un seul (caché ou visible). –Les obstacles utilisés sont retirés du jeu définitivement. –Toutes les cartes Voyage qui ont été jouées ou défaussées sont remises dans le paquet de cartes Il y a 4 tours de jeu !

30 Représentation du plateau Pas besoin dêtre réaliste Obligatoire : –20 villes, 36 routes –des idées dans le sujet Comment coder une carte ? –une Ville ? un nom une ville doit-elle connaître ses routes ? Un marqueur par joueur,... –une route ? un type deux villes un pion adapté, un obstacle,...

31 Conception du moteur (lIG, connait pas) Lister les classes, écrire pour chacune son interface Choisir ses packages Ecrire le main dun tour de jeu –ici les 6 phases –chaque phases peut manipuler les interfaces Joueur, Ville, Pion,.... –Faire des schémas dutilisation et des diagrammes de classes !

32 Exemple de létape 1 : distribution des cartes Une classe Carte ? –Comment lier le type des routes, le type des pions transport et le type des cartes ? –Comment faire pour quune carte Voyage puisse sutiliser sur une route ayant un certain pion de transport ? –Une route avec un pion de transport ne pourra être empruntée par un joueur quavec une carte adaptée ! Le joueur transmet une liste de carte ? Comment traiter les Exceptions ? Une classe Paquet de Carte : –contient au plus 72 cartes => un tableau –répartition des types de cartes => constructeur –une interface pour les constantes ? Une classe Config ? –méthode shuffle (mélange les cartes) –méthode distribution(Joueur j, int nbCartes) Que renvoie-t-elle ? Exception ?

33 Autre exemple de use case Le joueur veut déplacer son pion : –comment caractériser le déplacement ? le choix de la voie est mieux que le choix de la destination (plusieurs voies possibles) –Le paramètre de la méthode peut être une voie de transport. –Il faut alors vérifier que le joueur peut effectuer ce déplacement : qui le fait ? le joueur, la voie ? –Prévoir par exemple un « type » voie avec une méthode public int empruntablePar(Joueur j) Cette méthode doit avoir accès à la position et les cartes du joueur => getters On peut contraindre le choix du joueur en lui passant toutes les voies empruntables (pratique pour le moteur et pour lIG).


Télécharger ppt "Programmation Objet en JAVA Cours 8 : Projet de Programmation, JUnit, retour sur le partiel."

Présentations similaires


Annonces Google