====== Qualité du logiciel et métriques ====== Sur la base de l'article //[[http://users.encs.concordia.ca/~abdelw/sba/papers/FIE08-OpenSource.pdf|Learning Software Engineering Principles Using Open Source Software ]]// qui présente cet enseignement au Canada, nous nous proposons d'aborder l'analyse de code. Nous travaillerons cependant sur un exemple plus simple, les classes de graphes issues des [[https://www.enseignement.polytechnique.fr/informatique/INF431/X06-2007-2008/TD/INF431-td_6-1.php|cours en ligne de Polytechnique]] si vos codes ne sont pas en java, sinon directement sur vos codes : {{:2014_2015:s3:concprogobjet:td:src.zip|}}. Ceux qui le veulent peuvent faire le même exercice mais sur les codes de Junit, dans ce cas se reporter à la fin de ce TD pour le téléchargement des codes. Pour faire les tests qui suivent vous devez avoir installé les outils suivants correspondant à des [[https://mbf-iut.i3s.unice.fr/doku.php?id=2014_2015:s3:outils:start#eclipse|plugin eclipse et plus précisement Metrics, Checkstyle et PMD]]. **Question :** - Télécharger les codes sur lesquels nous allons faire de l'analyse de code. ===== Parcourir les codes : premier aperçu ===== Une fois les codes téléchargés et placés dans Eclipse, nous allons utiliser pour l'instant les outils standard pour parcourir ces codes. - Placez vous dans une **perspective** "java": //Window -> open perspective -> Java ...// - Comprenez les hiérarchies des classes en utilisant la vue dédiée {{ :2014_2015:s3:concprogobjet:td:opentypehierarchie.png?direct&300 |}} * Quelles sont les sous-classes de la classe Graphe? - En utilisant la vue //package explorer//, regarder les classes du package ''grapheX''. Est-ce que les noms des classes sont explicites? avez vous une idée de l'intérêt de ces classes? {{ :2014_2015:s3:concprogobjet:td:packageexplorer.png?direct |}} - En utilisant "Outline View", examiner la classe "Arc". Le code est-il autodescriptif? Pouvez-vous expliquer son intérêt sans trop de difficulté? - En utilisant "Outline View", examiner les méthodes non-triviales de la classe Graphe. Le code est-il autodescriptif? Pouvez-vous expliquer son intérêt sans trop de difficulté? - Retrouver les méthodes qui appelent la méthode ''voisins'' de la classe ''Graphe'' {{ :2014_2015:s3:concprogobjet:td:opencallhierarchy.png?direct&300 |}} - Faîtes la même chose à partir de la classe ''Graphe'' pour visualiser tous les appels à son constructeur. ===== Métriques : utilisation du plugin Metrics de Eclipse ===== - Placez vous dans une perspective java - Nous allons ouvrir une autre **vue** (Extrait de http://metrics.sourceforge.net/). * To start using the Metrics View, use Windows -> Show View -> Other and navigate to the Metrics View, as shown in the next image. {{ :2014_2015:s3:concprogobjet:td:capture_d_e_cran_2014-08-12_a_17.31.38.png?direct&200 |}} * Un message vous signale que vous devez calculer les métriques et pour cela "permettre ces calculs". - Clique droit sur le projet, puis Properties -> Metrics -> utiliser les métriques (cf. Figure EnableMetrics) -> Apply {{ :2014_2015:s3:concprogobjet:td:enablemetrics.png?direct&200 |}} - Si l'affichage ne se fait pas, vous devez faire un clean du projet (Projet-> clean/Build). - Vous pouvez double-cliquer sur les métriques pour les voir en détail en particulier pour visualiser les valeurs maximales. Les éléments enfants à chaque niveau sont triés par ordre décroissant métrique (maximum ). - Etudiez les valeurs des métriques obtenues. * Sont-elles dans les limites souhaitées? (voir question 7) * Dans quel cas, ne sont-elles pas dans la limite souhaitée? Qu'en pensez-vous? * Que pensez-vous de la classe //Graphe// : * Nombre de lignes de code des méthodes? Quelle est la méthode qui a le plus de lignes de codes? Qu'en pensez-vous? * Comparer le nombre de lignes à sa complexité //Cyclomatic//. * Que pensez-vous du nombre de méthodes dans cette classe? Est-ce que cela vous gêne? - Les valeurs seuils ne sont pour la plupart pas définies. Pour les définir, aller dans le menu ''Preference'' de **Eclipse** puis sous ''Metric'', configurer les valeurs seuils à votre convenance et regarder à nouveau les codes.{{ :2014_2015:s3:concprogobjet:td:metricparametre.png?direct&200 |}} [[http://metrics.sourceforge.net/|(En savoir plus)]] {{ :2014_2015:s3:concprogobjet:td:metricsresults.png?direct&200 |}} - Regardez vos codes avec cet outil. ===== Conventions de codage et de style : Utilisation du plugin CheckStyle ===== Notre objectif dans cette partie est de comprendre * les notions de normes de codage * comment préciser vos propres règles de nommage. **Questions** - Activer CheckStyle dans le projet {{ :2014_2015:s3:concprogobjet:td:checkstyleactiver.png?direct&300 |}} - Afficher la vue "Checkstyle Violation" et étudier quelques unes des "violations" relevées par exemple les import *, les variables publiques, le nom des variables, ... {{ :2014_2015:s3:concprogobjet:td:checkstyleview.png?direct&300 |}} - Et dans vos codes quelles erreurs de style détectez-vous? - Configurer les règles pour votre projet - Dans Eclipse -> preference -> CheckStyle - Vous visualisez alors les règles par défaut de tous les projets. Prenez le temps de les regarder et d'en comprendre certaines. {{ :2014_2015:s3:concprogobjet:td:checkstyleconfig.png?direct&300 |}} - Nous allons définir nos propres règles, donc nous commençons par définir votre propre configuration : sélection du projet -> properties, puis checkstyle {{ :2014_2015:s3:concprogobjet:td:checkstyleconfigprojet.png?direct&300 |}} - Sélectionner Local Check Configuration -> New {{ :2014_2015:s3:concprogobjet:td:checkstylenewconfig.png?direct&300 |}} - Sélectionner la configuration puis faire configure - Visualisez alors les règles rangées par catégorie. - Choisissez à présent les règles que vous voulez vérifier dans votre projet. * la duplication de code * le nommage des variables * le nommage des packages, mais vous le modifiez pour forcer le nom des packages à se terminer par "pk"par exemple. {{ :2014_2015:s3:concprogobjet:td:checkstyleconfpackage.png?direct&300 |}} - Effacer les violations précédentes (projet -> checkstyle -> clear checkstyle violation. {{ :2014_2015:s3:concprogobjet:td:checkstyleclearviolation.png?direct&300 |}} Si cela ne fonctionne pas, désélectionner "use simple configuration" puis ''Add'' {{ :2014_2015:s3:concprogobjet:td:checkstylecreerconfiguration.png?direct&300 |}} - Visualiser les erreurs sur un graphique - Sélectionner juste à côté de la vue Checkstyle la visualisation graphique (les 4 couleurs) {{ :2014_2015:s3:concprogobjet:td:checkstyleboutongraphique.png?direct&300 |}} {{ :2014_2015:s3:concprogobjet:td:checkstylegraphiquevue.png?direct&300 |}} - Prenez le temps d'étudier vos codes de TD, projet méthodologie ou tutoré. ===== PMD ===== ==== Pourquoi cet outil ? ==== On peut en effet se poser la question car il existe beaucoup d'outils similaires. Le choix fait CETTE année dans le cadre de CE module est motivé par : * Il est reconnu et utilisé par beaucoup de projets Java, et ceci en particulier dans les entreprises qui emploient les étudiants de licence professionnelle; * Il est simple d'utilisation et se présente comme un plugin pour Eclipse, or nous visons dans le cadre de cet enseignement à minimiser les environnements de programmation. * //"Il couvre un large spectre, en termes de contrôle (de la convention de nommage au calcul de complexité cyclomatique) et il fournit, en standard, près de 300 règles « prêtes à l'emploi » "// En savoir plus sur le choix : (cf. [[http://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-105/Verifier-votre-code-Java-avec-PMD]]) ==== Exécuter PMD ==== **Questions :** - Sélectionner le projet -> propriétés -> PMD -> activer PMD - Clique droit sur le projet puis PMD vérifier le projet {{ :2014_2015:s3:concprogobjet:td:pmd-open.png?direct&300 |}} - Pour mieux voir les erreurs, ouvrir une nouvelle vue PMD {{ :2014_2015:s3:concprogobjet:td:pmdvue.png?direct&300 |}} - Etudier les erreurs relevées Pour comprendre les erreurs pensez à cliquer sur l'erreur et visualiser la règle {{ :2014_2015:s3:concprogobjet:td:pmdvoirregle.png?direct&300 |}} - Rechercher les codes dupliqués et étudier les duplications... et sur vos propres codes. {{ :2014_2015:s3:concprogobjet:td:codesdupliques.png?direct&300 |}} - Générer le rapport PMD {{ :2014_2015:s3:concprogobjet:td:pmdgenererrapport.png?direct&300 |}} - Etudier les erreurs relevées dans vos propres codes. ==== Configurer PMD ==== 1- Sélectionner eclipse -> Preferences -> PMD {{ :2014_2015:s3:concprogobjet:td:pmd-configuration.png?direct&300 |}} 2- Visualiser les règles associées au nommage. {{ :2014_2015:s3:concprogobjet:td:pmdregles.png?direct&300 |}} ==== Allons plus loin, comment PMD fonctionne ? ==== * http://pmd.sourceforge.net/pmd-5.1.2/ * http://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-105/Verifier-votre-code-Java-avec-PMD * Quelles règles? http://pmd.sourceforge.net/pmd-5.1.2/rules/index.html#Basic