S3 : Conception et programmation objet avancée
-
- TDs : Description, Livrables, Evaluation
This is an old revision of the document!
Sur la base de l'article 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 cours en ligne de Polytechnique que nous avons déjà utilisé, mais qui vous sont données ici dans leur ensemble : 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 :
Une fois les codes téléchargés et placés dans Eclipse, nous allons juste utilisé pour l'instant les outils standard pour parcourir ces codes.
Graphe
pour visualiser tous les appels à son constructeur.
Preference
de Eclipse puis sous Metric
, configurer les valeurs seuils à votre convenance et regarder à nouveau les codes.
Notre objectif dans cette partie est de comprendre
1- Activer CheckStyle dans le projet
2- Afficher la vue “Checkstyle Violation”
3- Configurer les règles pour votre projet
a- Dans Eclipse → preference → CheckStyle
Vous visualisez alors les règles par défaut de tous les projets.
b- Pour votre projet, il est utile de définir votre propre configuration : sélection du projet → properties, puis checkstyle
c- Sélectionner Local Check Configuration → New
d- sélectionner la configuration puis faire configure
Vous choisissez à présent les règles que vous voulez vérifier dans votre projet.
e- effacer les violations précédentes (projet → checkstyle → clear checkstyle violation
si cela ne fonctionne pas, désélectionner “use simple configuration” puis Add
Vous visualisez les règles rangées par catégorie.
X- Visualiser les erreurs sur un graphique
Sélectionner juste à côté de la vue Checkstyle la visualisation graphique (les 4 couleurs)
Leur donner les conventions Sun
Quand vous travaillez à plusieurs sur des codes vous pouvez être amenés à définir vos propres règles de nommage par exemple, tous les noms de packages se terminent par pk, …
questions:
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.
Sun document. Browse your application source code and determine if this coding convention has been consistently followed.
switch, and try-catch – in the Sun document. Browse your application source code and determine if this coding convention has been consistently followed.
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.
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 :
En savoir plus sur le choix : (cf. http://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-105/Verifier-votre-code-Java-avec-PMD)
1- Fabriquons un exemple pour être sûr d'avoir des erreurs à analyser 1) :
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!"); } }
2- Clique droit sur le projet puis PMD vérifier le projet
3- Pour mieux voir les erreurs, ouvrir une nouvelle vue PMD
5- Etudier les erreurs relevées dans la nouvelle classe, dans les codes existants et dans vos propres codes.
Pour comprendre les erreurs pensez à cliquer sur l'erreur et visualiser la règle
Appliquer PMD sur vos propres codes.
Creer un nouveau projet. Limiter l'importation à la partie main du projet
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.
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.
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…