Cours au département INFO - IUT - UNS

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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]]  que nous avons déjà utilisé, mais qui vous sont données ici dans leur ensemble : {{: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.

**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.

<html>
<!-- 
Répondez aux questions suivantes:
  * Quelle est la structure générale de l'application ? (Rep : Une partie développement et une partie test)
  *<del> How many packages does your application contain?</del> What are their names? (Rep : 72 et il faut regarder directement dans la colonne package)
  * Browse the classes within a package using the Package Explorer. Based on the class names and the documentation in the source code, can you tell what the overall purpose of the package is? (Rep: je dois donner une selection de package à regarder, c'est pas facile)
  * Select any package and one of its classes. Using the Hierarchy View (clique droit -> Open Type Hierarchy), list all the ancestral classes of the class. Likewise, list all classes that are derived from your chosen class (cf. TypeHierarchy).
  * In the Outline View, examine a non-trivial method of a class. Is the code self-describing? Can you explain the purpose of the method without too much difficulty? If not, what factors contributed to un-readability of the
code? Are the provided comments useful and seem adequate?
  * Sélectionner une méthode et identifier les méthodes appelantes (cf. MethodesAppelantes).
--!>
</html>
===== 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.


<html>
<!-- 
(Extrait de http://metrics.sourceforge.net/) Initially the resulting view will show a brief usage message because no metrics have been calculated yet. To start collecting metrics for a project, right click on the project and from the popup menu select "Metrics->Enable" (or alternatively, use the properties page ).This will tell Eclipse to calculate metrics every time a compile happens. Now that you've enabled a project, the easiest way to calculate all its metrics is to do a full rebuild of that project. The metrics view will indicate the progress of the metrics calculations as they are being performed in the background. When it's all done, the metrics view will look something like this: (cf. MetricResults)


       * If the metric is outside
the desired range, suggest what actions (possible refactoring
actions) need to be taken. A sample listing of metrics
computed using the chosen metrics plug-in is shown below:
• McCabe's Cyclomatic Complexity
• Efferent Coupling
• Afferent Coupling
• Lack of Cohesion in Methods
• Total Lines of Code
• Number of Fields
• Number of Levels
• Number of Parameters
• Number of Statements in Method
• Weighted Methods per Class
• Number of Methods
• Number of Static Methods
• Number of Classes
• Number of Children
• Number of Interfaces
• Depth of Inheritance Tree
• Number of Overridden Methods
• Specialization Index
• Instability
• Abstractness


Répondez aux questions suivantes:
  * How many packages does your application contain? (Rep : 72)
  * Visualiser les dépendances pour cela dans la vue métric sélectionner l'icône à gauche carré rouge (cf. Visualisation des Dépendances) mais cela fonctionne mal ou du moins pour ma part je n'arrive pas à avoir accès aux menus.
{{ :2014_2015:s3:concprogobjet:td:visualisationdesdependances.png?direct&200 |}}
  * NE PAS FAIRE, ON MANQUE D EXPLICATIONS LA DESSUS : Visualiser les couches de packages pour le programme principal (attention, il peut etre nécéesaire de faire un "rebuild du projet" et cela peut prendre beaucoup de temps) (cf. PackageLayers).
{{ :2014_2015:s3:concprogobjet:td:packagelayers.png?direct&200 |}}
--!>
</html>
 
===== 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.

<html>
<!--
http://eclipse-cs.sourceforge.net/basic_setup_project.html

{{ :2014_2015:s3:concprogobjet:td:checkstyle.png?direct&200 |}}
--!>
</html>

**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é.

<html>
<!-- 
**Questions sur vos propres codes**
   - Consider the coding conventions for line length in the Sun document. Browse your application source code and determine if this coding convention has been consistently followed.
  * Consider the coding conventions for line wrapping in the Sun document. Browse your application source code and determine if this coding convention has been consistently followed.
  * Consider the coding conventions for various types of
comments – block, single line, trailing, end-of-line, and
documentation – in the Sun document. Browse your
Session application source code and determine if this coding
convention has been consistently followed.
  * Consider the coding conventions for declarations – number per line, placement, and initialization – in the
Sun document. Browse your application source code
and determine if this coding convention has been
consistently followed.
  * Consider the coding conventions for statements – while,
switch, and try-catch – in the Sun document. Browse
your application source code and determine if this
coding convention has been consistently followed.
  * Pour cela vous limitez à la partie source du code (dans la vue Problems-> Configure Contents (cf. Configure Contents), 
{{ :2014_2015:s3:concprogobjet:td:configure_contents.png?direct&200 |}}
  * puis Error/warnings on Selection (cf. ErrorWarningOnSelection)....  
{{ :2014_2015:s3:concprogobjet:td:errorwarningonselection.png?direct&200 |}}
After answering the above questions qualitatively, the
project teams ran Checkstyle plug-in on their source
code base. Next, they carefully interpreted the results
produced by the plug-in with their qualitative
assessment of the source code base by visual
examination.

Attention c'est des recommandations seulement. Par exemple, dans les tests certaines valeurs ne doivent évidemment pas être définies comme des constantes.
!-->
</html>

===== Couverture des codes =====

Si le système local de l'IUT le permet.
Ceux qui ont leur propre machine peuvent avantageusement l'installer.

http://eclemma.org/

  - Installer le plugin http://eclemma.org/installation.html#marketplace
  - Utiliser le plugin pour vérifier la couverture du code.

===== 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. 

<html>
<!--
1- Fabriquons un exemple pour être sûr d'avoir des erreurs à analyser ((Cette partie s'appuie sur le tutoriel suivant http://www.javatips.net/blog/2012/06/pmd-in-eclipse-tutorial)) : 

<code java>
package test.pmd;

//PMD Eclipse Tutorial
public class PMDTest {
  public static void main(String args[]) {
    PMDTest.CALL_METHOD("hello");
    PMDTest.CallHello();
  }

  public static void CALL_METHOD(String INPUT_PARAMETER) {
    System.out.println(INPUT_PARAMETER);
  }

  public static void CallHello() {
    System.out.println("Hello PMD World!");
  }
}
</code>
!-->
</html>
==== 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
<html>
<!--

==== Découverte de l'outil sur le code de JUNIT ====

  * Ouvrir la vue Synthese des alertes PMD
      * Ne visualiser que les erreurs les plus graves (Ne garder que le petit drapeau rouge sélectionné! cf. figure {{ :2014_2015:s3:concprogobjet:td:flagrouge.png?direct&200 |}}
            * Etudier certaines des erreurs uniquement dans la partie main du code et les comprendre : POURQUOI? (chercher les explications dans http://pmd.sourceforge.net/pmd-5.1.2/rules/index.html#Basic (penser à utiliser la recherche dans la page)), par exemple : AvoidThrowingRawExceptionTypes: Avoid throwing certain exception types. Rather than throw a raw RuntimeException, Throwable,Exception, or Error, use a subclassed exception or  et aller plus loin si besoin).
                * src/main/java/junit/framework/JUnit4TestAdapterCache.java:15:	Variables that are final and static should be all capitals, 'fInstance' is not all capitals.
                * Pour s'y retrouver il peut etre utile de générer le rapport d'erreurs.
                * 
      * voir GodClassPMD (pour comprendre lire : http://pmd.sourceforge.net/pmd-5.1.2/rules/index.html#Basic)
      * La classe Theorie.java est notée comme une GOD Class ? Pourquoi ? (trop de méthodes)
{{ :2014_2015:s3:concprogobjet:td:godclasspmd.png?direct&200 |}}




===== Reverse Engineering =====

Creer un nouveau projet.
Limiter l'importation à la partie main du projet


  - Generate a package diagram
      * Vous aurez besoin de la vue (volet) "Aperçu des diagrammes) pour ... y voir quelque chose!
      * La vue n'apporte pas vraiment d'information éttant donné la taille du projet... Décevant. Néanmoins ce type de visualisation peut etre utile, surtout sur des projets que l'on maîtrise. Appliquer le sur un de vos projets, s'il contient des packages et faîtes-vous une première idée.
      * 
  - Generate class diagrams
      * Cette visualisation doit se faire sur une sous-partie. Sélectionner quelques classes qu'il vous semble intéressant de visualiser.
  - Generate sequence or collaboration diagrams





===== Récupération des codes à Analyser =====


Nous allons travailler sur le projet JUNIT comme base pour prendre en main l'environnement et découvrir quelques bases de l'analyse des codes.

<note>
A priori ce TD vient avant le cours. On devrait pouvoir mettre en place une sorte de classe inversée sur cette base dans le module "Methodologie", alors que celui-ci prendrait sa place dans le module outil.
</note>


Etape 1: Charger les codes à partir du répertoire SVN
https://github.com/junit-team/junit

Extrait du tutoriel http://www.ibm.com/developerworks/opensource/library/os-ecl-subversion/

From Eclipse's File menu, choose Import to display the import manager (see Figure X). Choose Checkout Projects from SVN, then click Next.

{{ :2014_2015:s3:concprogobjet:td:svn_checkout.png?direct&200 |}}

{{ :2014_2015:s3:concprogobjet:td:svn_import_dans_eclipse.png?direct&200 |}}
On the Select/Create Location panel (see Figure 8), we need to create a new location (since we don't have any configured yet), so click Next to continue. 

voir figure X

Attention, nous n'avons pas pour objectif dans ce TD de "corriger" les codes de JUnit mais seulement de regarder des codes existants pour apprendre à les analyser.

Selectionner trunk cela est bien suffisant pour nos tests (et déjà très gros!).

Mais on a quand même 14,9Mo...

!-->
</html>