These functionnalities are also available on some other tools, among them JBoss Operation Network (the drift feature is available since version 3.0), however puppet seems to gather of a larger adoption among the community.

While working at a customer, I met a sponsor so we decided to give it a large try.

Corporate customers often rely on a enterprise Linux distribution, and RHEL 5 is often a common guest in the party. Unfortunately, puppet is not a part of the distribution and you have to rely on the EPEL (Extra Packages for Enterprise Linux) repository to make it available for installation.
To do so, simply add /etc/yum.repos.d/epel.repo with the following content:

[epel]
name=Extra Packages for Enterprise Linux 5 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/5/$basearch
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=0

sudo yum install puppet
sudo /etc/init.d/puppet start

My favorite demo application is Seam Booking application which is a “bogus” Hotel Reservation Web Application developed with Seam (using JSF, Seam and Hibernate). The application is pretty and nice to use. It uses Ajax and just like all JSF applications it rely on javax.faces.viewState’s that are exchanged along pages. Because it uses Seam, there is also a “Conversation ID” that is hold from pages to others.

The perfbench project

I was very happy to see that an existing project is already doing as Seam load test through a performance comparison between presentation frameworks. However, the scripts were pretty old, and I performed a few modification to make them work.

Adapt booking.jmx to Seam 2.2

There are only minor changes, mainly on 2 pages:

• The main.seam page does not refer anymore to a main form, instead it is named “searchCriteria”. First step, was to modify the request’s parameters to match this new name.
  
• On book.seam page , CreditCardNameDecorate:* attributes have been renamed to creditCardNameDecorate (with a lower case c). Second step, is to rename all the form’s attributes related to this decorator.

Missing Ajax call to validate the booking

Caused by: javax.faces.application.ViewExpiredException: viewId:/confirm.seam - View /confirm.seam could not be restored.

An important detail about seam, all the application’s pages submitted via a POST are followed by a redirect to avoid double submit issues. This can be confusing, because every POST leads to an HTTP 302 error: Moved temporarily. In fact, this redirect gives the location of the next page in navigation and provides the updated cid through url.

After investigation, using firebug and Results Tree Listeners in JMeter, I realized that the “POST booking details” step was not performing correctly. Indeed, instead of returning an HTTP 302 code like all the other posts, it was only doing a GET on a the book.seam view. Then, the confirm.seam view was failing because of an incoherent “cid”.

So, I finally ended to look deeper in Seam Booking Code to determine why the redirection does not occur at this time. This is due to the following code in the WEB-INF/pages.xml:

<page view-id="/book.xhtml" conversation-required="true" login-required="true">
  <description>Book hotel: #{hotel.name}</description>
  <navigation from-action="#{hotelBooking.setBookingDetails}">
    <rule if="#{hotelBooking.bookingValid}>
      <redirect view-id="/confirm.xhtml"/>
    </rule>
  </navigation>
</page>

<!--rule if="#{hotelBooking.bookingValid}"-->
  <redirect view-id="/confirm.xhtml"/>
<!--/rule-->

Finally, here is the resulting booking.jmx file to load test Seam Booking.

Interesting links

http://kalgtech.blogspot.com/2009/10/load-testing-seam-application-using.html
http://ptrthomas.wordpress.com/2009/01/14/seam-jsf-vs-wicket-performance-comparison/
http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
http://seamframework.org/Community/JMeterSeamCidProblem
http://blog.milamberspace.net/index.php/jmeter-pages/jmeter-test-de-charges-dun-site-web-mode-demploi/jmeteriser-son-scenario-fonctionnel

Nombre de lignes de code ou LoC

Parmi les métriques de bases de la qualité logicielle, s’il y’en a une bien qui est vraiment LA métrique de base, c’est le nombre de ligne de codes. On ne va pas expliquer ici comment on calcule ce nombre, Wikipedia en anglais contient une page LoC (Lines of Code) sur le sujet.

Le nombre de ligne de codes d’un projet, d’une application, d’une classe ou d’une méthode est une métrique intéressante pour évaluer la complexité de chacun de ces éléments.

Le mot “évaluer” est délibérément choisi, car effectivement ce n’est qu’une évaluation et non pas une vision exacte de cette complexité, néanmoins c’est un indicateur  convenable. Ceci n’est pas du à la précision du calcul, mais au fait que la complexité, comme la simplicité ou l’intelligibilité sont des critères subjectifs et donc difficilement quantifiables.

Un exemple simple pour démontrer cela. Prenons le code Java suivant que l’on va nommer code A:

 int i = 0;
 System.out.println("ligne " + i);
 i++;
 System.out.println("ligne " + i);
 i++;
 System.out.println("ligne " + i);
 i++;

Et ce code ci que l’on nomme code B:

 for( int i = 0; i < 3;i++) {
 System.out.println("ligne " + i);
 }

Bien que ces deux codes fassent la même chose, et que le code B comporte moins de lignes que le code A, d’un point de vue intellectuel, le code B est plus complexe que le code A. Pour vous en convaincre, rappelez-vous que lorsque vous avez appris à programmer, vous avez d’abord appris ce qu’était une instruction, puis une série d’instructions, puis une boucle.

Je ne parle pas ici d’une autre métrique qui est la Complexité Cyclomatique, que l’on développera dans un autre article, mais purement de complexité au sens intellectuel du terme. Cette même complexité qui est proportionnelle à l’effort de réflexion ou de conceptualisation nécessaire à la compréhension d’un raisonnement, d’un algorithme et par extension d’un code.

Évidemment, cet exemple est un cas extrême, et si votre application ne ressemblait qu’à des successions de lignes identiques (du copier coller du code A), il y’aurait probablement un sérieux problème. Dans la majorité des cas, votre application ressemble plutôt à une succession ou à un enchevêtrement du code B avec en plus des tests (instructions if, else, switch/case, etc…), des appels de méthodes, de l’introspection et tout un tas d’autres choses assez complexe à appréhender.

Globalement, le nombre d’instructions et donc de lignes va en croissant avec la complexité de ce qui est développé.

Revenons à notre sujet : La méthode de 1000 lignes

Récemment, j’avais une discussion intéressante avec un chef de projet technique qui a pas mal travaillé sur une application grandissante et vieillissante et qui était confronté à des problématiques de méthodes de plus de 700 lignes, voire 1000 lignes. Il va sans dire que la maintenance était éprouvante.

Les méthodes en question réalisaient les écritures comptables des transactions journalières d’une application d’encaissement et de facturation. Cette application était soumise à de nombreuses évolutions de ses règles de calcul, notamment du fait de l’existence de “promotions” et de “barèmes dérogatoires”. Si bien qu’au bout d’un temps, les méthodes qui réalisaient le calcul étaient criblées de portions de code de ce type:

if( je suis dans ce cas) {
  +20 lignes de code
}

Les méthodes ont rapidement atteint plusieurs centaines de lignes, dépassant parfois le millier.
Ce à quoi j’ai répondu simplement:

- Il suffit de remplacer “+20 lignes de code” par une méthode privée au sein de ta classe.
- Oui, mais au final la classe fera toujours plus de 1000 lignes et sa taille continuera de croître.
- C’est vrai, mais il vaut mieux avoir 100 méthodes de 10 lignes que 10 méthodes de 100 lignes ou pire une méthode de 1000 lignes

A ce niveau là, il y’a deux points de vues:

- Effectivement on aura toujours +1000 lignes donc autant laisser comme ça

et dans ce cas, la lecture de cet article ne devrait plus vous intéresser. Ou alors

- 100 méthodes de 10 lignes, on peut mieux faire et améliorer encore cette classe en la découpant en plusieurs classes

Pour ceux qui sont en accord avec le premier point de vue voici tout de même quelques arguments pour finir de vous convaincre et vous rallier à la cause de la qualité logicielle. Pour les autres, vous pouvez passer à la conclusion.

Les numéros de téléphone ne dépassent pas 10 chiffres

Cette affirmation est vraie pour la quasi totalité des pays et lorsque ce n’est pas le cas, il existe une numérotation locale qui permet de descendre en dessous de ce nombre.

Nous ne sommes pas tous rainman

La raison à cela se trouve entre nos deux oreilles. Généralement, notre mémoire à court terme ne retient qu’un nombre restreint d’éléments (entre 7 et 10). C’est cette mémoire que nous utilisons dans des tâches qui nécessitent de la concentration ou de la conceptualisation. Comme c’est le cas de manière intensive lorsqu’on programme une application informatique.

Au delà, on entre dans un processus de mémorisation à plus long terme basé sur de la matérialisation d’idées plus que sur des faits. Comme c’est le cas lorsqu’on lit un roman: On ne retient pas toutes les pages et toutes les actions, mais on mémorise et construit globalement l’histoire. Ce qui est sujet à l’imagination et non pas à la mémorisation. C’est ce qui fait d’ailleurs qu’un même lecteur  peut lire plusieurs fois un même extrait et le percevoir de manière comme  différente.
La lecture d’une méthode de plusieurs centaines de lignes s’apparente davantage à ce processus ce qui fait que le développeur perds en concentration et en précision.

Mémoriser peu, retenir beaucoup

Dans le cas contraire, la mémorisation de 7 verbes ordonnés ne pose généralement aucun problème à la plupart des individus. C’est encore plus simple si il existe un ordre “logique” entre ces verbes: Par exemple:

se lever
se laver
s'habiller
manger
partir travailler
rentrer chez soi
dormir

Il est ensuite possible d’entrer dans le détail de chacun de ses verbes, je peux par exemple détailler en 7 actions le fait de “se laver” ou tout autre action. Ce qui me permettrait par exemple de définir et de retenir un enchaînement de 49 actions. Tout en ne travaillant que sur des unités de travail facilement mémorisables.

Diviser pour mieux régner

Ces simples constats vont dans le sens d’une simplification des méthodes au sein de la classe: Il suffit de penser à découper les actions d’une méthode au sein d’actions plus petites et des les invoquer dans un ordre logique.
De cette façon, la lecture de la méthode est plus facile puisqu’elle s’apparente une mémorisation d’actions courtes. Les anomalies présentes sont alors plus faciles à détecter. Pour reprendre notre exemple, imaginez la suite suivante:

se lever
dormir
se laver
s'habiller
manger
partir travailler
rentrer chez soi

L’anomalie saute aux yeux, alors que si j’avais donné la séquence des 49 actions, elle serait bien plus difficille à détecter.

La qualité logicielle: un travail de fond

Le nombre de lignes d’une méthode est la métrique de base qui permet de s’attaquer à des problèmes de maintenabilité du code. Il ne faut pas perdre de vue le fait qu’il s’agit de la première métrique, celle qui va aider à poser les jalons de l’amélioration continue de la qualité.

Parmi ces jalons, les plus importants sont:
- La réduction du nombre de lignes de code dans une classe
- La réduction du manque de cohésion d’une classe (trop d’attributs dans une classe et les méthodes de la classe n’accède qu’à peu d’attributs)
- La réduction de la complexité cyclomatique

Dans mon travail, j’entends souvent: Ce n’est pas ma faute, il y’a une anomalie dans le service, il ne retourne pas les bonnes données. Ou encore il y’a un bug dans le framework.
Ou plus rarement, mais c’est arrivé, c’est un bug de la JVM ou de Spring ou de Hibernate.

C’est souvent plus facile d’accuser quelqu’un d’autre, parfois même ça peut rendre service. Mais face à ce genre de situation, dans 99,9999% des cas, le problème provient de ce qui se trouve entre le clavier et l’écran: Le développeur (en l’occurence moi).

Comment s’y prendre

En fait, ce genre de situation me rappelle une anecdote que j’avais entendu quand j’étais encore sur les bancs du cours de Génie Logiciel (en école d’ingénieurs), qui concerne la façon dont a été découvert le bug du Pentium.

Si vous recherchez un peu sur le net, il y’a des articles qui parlent profondeur des tenants et des aboutissants de cette histoire, mais l’idée ici est surtout de décrire la démarche du mathématicien américain Thomas Nicely, de l’université Lynchburg (Virginie).

Ce mathématicien travaillait sur la suite numérique qui additionne les inverses des nombres premiers jumeaux (nombre premiers dont la différence vaut 2, exemple, 5 et 7 , 11 et 13, etc…). Le début du la suite est (1/3 + 1/5) + (1/5 + 1/7) etc… .

Autant dire qu’il s’agit d’un sujet pointu et précis et que notre expert connait bien son domaine, il faut dire que la valeur de cette suite ne change pas. Il possédait alors des tables contenant la valeur de cette suite. Et biensûr, il avait établi des algorithmes et développé des programmes permettant de réaliser ces calculs.

En 1994, il reçoit un nouvel ordinateur équipé d’un processeur révolutionnaire, lui permettant d’approfondir son étude. Il s’empresse de recompiler ses programmes pour ce processeur et les executent avant de s’apercevoir de différences entre les valeurs de ses tables et celle retournées par ses programmes.

Il commence alors par vérifier ses tables, refait les calculs et valide ses résultats. Tout est correct, ses résultats sont bons.
Il reverifie alors ses algorithmes, les écrits dans un autre langage, et obtiens des résultats incorrects sur ce processeur.
Il décortique alors le compilateur afin de rechercher une anomalie dans ce dernier et toujours rien.
Il met alors finalement en cause le processeur et démontre que l’unité de division de calcul flottant contient effectivement un bug.

La morale de l’histoire

Avant de rejeter la faute sur quelqu’un d’autre, je m’assure toujours que l’erreur ne vient pas de moi et de ce que j’ai fait. Aujourd’hui, c’est encore plus simple de s’en assurer avec tous les outils à ma disposition. Voici les quelques pratiques que j’utilise et qui m’aide à faire celà dans mon travail:

• Les tests unitaires automatisés et tous les frameworks de tests unitaires
• Le mode debug (et remote debug, on l’oublie souvent celui-là) de mon IDE
• Les sources des frameworks (ou de la VM) que j’utilise, non pas pour les incriminer mais pour comprendre ce que j’ai fait d’incorrect
• La documentation de reference et les API

Du PHP dans Sonar

Vous l’aurez compris, il s’agit plugin PHP pour Sonar. Depuis Sonar 2.1, il est en effet possible de développer des plugins permettant à Sonar de réaliser l’analyse de la qualité du code d’applications écrites dans autre chose que du Java.

Le développement du plugin a commencé courant 2009 avec pour objectif de permettre aux développeurs PHP de disposer d’un outil de qualimétrie puissant et automatisable.

PHP étant un language ouvert,il existe déjà de nombreux outils d’analyse de qualité de code, de calcul de métriques et de détection de bugs. Dans un premier temps, l’idée consiste à s’appuyer sur ces outils.

Ajouter le support d’un langage

Il y’a plusieurs façon d’ajouter le support d’un nouveau langage à Sonar. La plus “intégrée” consiste à développer ou à utiliser un outil Java qui réalise l’analyse syntaxique du code (en s’appuyant par exemple sur un AST (Abstract Syntaxic Tree)), et à en faire ressortir certains nombres de métriques.

Une autre possibilité consiste à s’appuyer sur des outils existants et à les intégrer dans Sonar. Pour le développement de PHP Plugin, nous avons choisit la deuxième solution, principalement pour 3 raisons:

• Nous n’avions pas trop le temps de développer l’AST pour PHP
• Des outils qui font déjà le boulot existent dans le monde PHP
• Utiliser des outils connus par la communauté peut aider à l’adoption
• 

Le plugin Sonar PHP se contente, et c’est dejà pas mal, de:

• recueillir les informations sur le projet: emplacement des sources, des tests unitaires, identifiants et version du projet
• construire les lignes de commande nécessaires au lancement de des outils
• lancer l’execution de chacun des outils
• recueillir les résultats de l’analyse au format XML
• insérer ces données dans la base Sonar en utilisant l’API Sonar Plugins

Une fois ces données receuillies et réconcilliées avec les fichiers auxquelles elle se réfère, le moteur de Sonar prends la relève et permet de réaliser le drilldown dans le tableau de bord pour aller visualiser l’état du code en détail.

PHPDepend

Parmi ces outils,  l’incontournable PHP Depend est capable de parser un ensemble de code PHP et d’extraire les métriques de bases qui nous permettent de construire un tableau de bord:

• Le nombre de ligne de code
• Le nombre de ligne de commentaires
• La complexité conditionnelle (ccn et eccn)
• La profondeur d’héritage
• Le nombre pondéré de méthode (wcm)
• Le nombre de classes, méthodes, fonctions, …

On obtient en sortie un fichier xml contenant l’ensemble de ces métriques et les artefacts (fichiers, classes, packages) auxquels ils se référent.

<pre><?xml version="1.0" encoding="UTF-8"?>
<metrics ahh="0.19444444444444" andc="0.46268656716418" calls="1406" ccn="1203" ccn2="1237" cloc="11657" clsa="7" clsc="60" eloc="6528" fanout="571" leafs="59" loc="20078" maxDIT="2" ncloc="8421" noc="67" nof="0" noi="21" nom="578" nop="11" roots="5">
  <files>
    <file name="/usr/local/pear/PEAR/PHP/Depend/Parser.php" cloc="324" eloc="534" loc="997" ncloc="673"/>
    <file name="/usr/local/pear/PEAR/PHP/Depend/StorageRegistry.php" cloc="81" eloc="18" loc="103" ncloc="22"/>
  </files>

class=”aligncenter size-medium wp-image-128″z

Le plugin Sonar PHP receuille ensuite les informations contenues dans ce fichier et les insère dans la base de données Sonar. En sortie on obtient un tableau de bord Sonar dont voici quelques copies d’écrans.

PHPUnit

PHPUnit est un framework de tests unitaires automatisés pour PHP. C’est l’équivalent de JUnit (ou Testng) en Java. Il permet de lancer les tests unitaires, fournit une API d’assertion et permet d’extraire des métriques, des rapports d’exécution et de taux de couverture du code testé, là encore au format XML. Sonar PHP fait le même travail de pilotage et d’aggrégation des résultats, mais sur des métriques différentes telles que le nombre de tests, le taux de couverture, les statistiques d’echec et de succès des tests.

PHP CodeSniffer

Code Sniffer est un moteur de détection de violation qui s’appuie sur des clases PHP appellées “Sniff” et qui parcourent des éléments de code afin de détecter des violations. Il s’appuie sur des rulesets qui définissent l’ensemble des règles disponibles. La force de l’outils réside dans le fait qu’il référence plus de 400 contrôles qualité.  L’utilisateur a même la possibilité d’enrichir ces règles avec des nouveaux contrôles. Ou au contraire être le limiter à certaines règles.

L’intégration de CodeSniffer dans Sonar PHP est plus la plus avancée puisqu’il est possible d’intégrer des rulesets personnalisés simplement en les packageant et les copiant dans le repertoire  $SONAR_HOME/extensions/rules. Et une évolution important prévue dans la version 0.4 permettra de ne lancer que les règles choisies par l’utilisateur afin d’améliorer les temps de construction du dashboard.

PHP Mess Detector, PHP Cpd et les autres…

Deux autres outils s’ajoutent aux précédents:

• PHPCpd (Copy Paste Detector) fournit des métriques sur le taux de duplication de code : Le copier/coller
• PHPMD est un autre moteur de détection de bug qui réalise aujourd’hui avec une vingtaine de contrôle sur le design, le nommage ou la taille des classes ou méthodes

A ces outils d’autres peuvent venir s’ajouter. Mais pour le moment, nous nous concentrons davantage sur l’intégration au sein d’outils de build ou d’intégration continue.

Conclusion

L’objectif de cette article était de présenter le fonctionnement et d’avoir un aperçu des fonctionnalités du plugin Sonar PHP. Voici quelques liens où l’ont peut trouver davantage d’informations sur Sonar ou de la domaine de qualité logicielle, et sur le plugin bien évidement.

La documentation du plugin sur codehaus

Le site de la forge sonarsource.org

Des détails sur le fonctionnement et la configuration du plugin

J’ai entendu parlé de Sonar pour la première fois en 2008. Je travaillais alors comme consultant pour un éditeur de logiciel spécialisé dans le domaine de la qualité logicielle et de l’Application Intelligence. A l’époque, Sonar commençait tout juste à être connu mais n’était perçu encore que comme un agrégateur de résultats d’analyse fournis par différents outils.Courant 2008, je réalise une étude comparative pour le client pour qui je travaille, et là, je me rends réellement compte qu’il s’agit d’une solution crédible pour l’audit de code et pour l’inspection continue. La grande différence avec les outils avec lesquels je travaille chaque jour et la réelle automatisation et l’extensibilité.

Comment que ça marche?

Le principe de fonctionnement de Sonar est simple. Les concepteurs ont eu la bonne intuition de s’appuyer maven qui est aujourd’hui un outil largement répandu dans le monde de l’intégration continue Java. En une simple ligne de commande, on réalise les contrôles qualités de son application et on dispose de tableaux de bords qui fournissent des indicateurs quantitatifs et qualitatifs sur le code source analysé.

C’est là qu’entre jeu le deuxième pilier de l’architecture de sonar: Le serveur Sonar qui héberge les différents widget sonar, les profils qualité, la base de données des règles, des mesures et des violations, les plugins additionnels et enfin l’API Sonar qui permet d’enrichir le produit avec des nouvelles fonctionnalités.

Comme le montre le schéma (issue d’une présentation de Sonar), Sonar est au départ prévu pour effectuer de l’analyse de code Java. Il s’appuie sur des outils bien connus du monde Java: PMD, Checkstyle, Findbugs, Surefire, Cobertura, etc… Le projet connait de nombreuses évolutions notamment au niveau des plugins de présentation des différentes violations présentes au sein de l’application analysée: Timeline, Technical Debt, Squid ou Views.

L’API Sonar et le support d’autres langages

L’API Sonar permet d’étendre les fonctionnalités du produit de deux manières différentes. Sous la forme d’extensions batch side et server side.

• Les extensions batch side sont celles qui s’executent au sein du plugin maven de sonar. C’est le cas par exemple des plugins qui d’analyse d’autres langages
• Les extensions server side s’executent côté server Sonar. C’est le cas des extensions web services, ou des widget additionnels

L’équipe Sonar a mis à disposition une forge logicielle hébergée sur codehaus pour les développeurs qui désirent s’impliquer dans le développement de plugin. Le point d’entrée est la page suivante: http://docs.codehaus.org/display/SONAR/Coding+a+plugin

Depuis la version 1.5, le support d’autres langages est possible. Mais ce n’est qu’avec la version 2.0 qu’arrivent réellement des plugins pour le support d’autres langages de programmation: Flex (ActionScript), C, Cobol, PL/SQL, VisualBasic, .Net et PHP. L’API Sonar Plugins évolue au cours de l’année 2010 en version 2.2 et casse la compatibilité avec les versions précédentes mais introduit de nouvelles possibilités.

Le développement de plugin pour la plateforme est grandement simplifié par l’utilisation d’archetype et l’utilisation de maven pour lancer un serveur sonar automatiquement téléchargé et initialisé.

Installer maven

Maven est un outils permettant de compiler, construire, packager et livrer des projets en faisant de l’intégration continue. Il s’appuie sur les notions de

• repository (dépôt) de binaires qui est un répertoire sur la machine locale sur laquelle les binaires (jar, war, zip, etc..) sont téléchargés et copiés pour une utilisation pour la compilation d’application en local
• repository distant qui est un dépôt de binaire central accessible à travers le réseau
• goal qui est un tâche rattachée à une phase et à un plugin qui permet de réaliser des actions nécessaires à la construction d’un binaire (exemple compile, process-resources, etc…)
• plugin qui permet d’étendre les fonctionnalités de maven pour la réalisation d’autres actions ou d’opérations nécessaires ou connexes au build (exemple: générer la documentation, calculer le taux de couverture de test, générer des rapports, etc…)

Avant de commencer, assurez vous que java est installé sur votre système et que la variabe JAVA_HOME est définie.
L’installation de maven commence par son téléchargement depuis le site maven.apache.org. Il faut ensuite simplement extraire les binaires dans un répertoire et faire pointer la variable d’environnement MAVEN_HOME vers ce répertoire. Et ajouter $MAVEN_HOME/bin à votre PATH.

Le répository maven local sera crée par défaut dans le répertoire $HOME/.m2/repository.

Installer Sonar

L’installation de sonar consiste à:

• télécharger la distribution de Sonar
• décompresser l’archive dans un répertoire $SONAR_HOME
• lancer le serveur depuis $SONAR_HOME/bin/ en choisissant le répertoire correspondant à la plateforme sur laquelle sonar est installé

Pour de plus amples détails ou des configurations particulières (utilisation d’un serveur d’application ou d’une base de données externe), il faut se reporter à la documentation de Sonar.

Analyser un projet

Une fois le serveur installé et lancé, l’analyse d’un projet se limite à lancer la commande suivante dans le répertoire du projet.

mvn sonar:sonar

La dernière étape consiste à se rendre à l’adresse http://localhost:9000/ et à visualiser le tableau de bord récapitulant les mesures et violations du projet.

Après ces quelques étapes, vous disposez d’une plateforme d’inspection en continue qui vous permet de suivre l’évolution de nombreux indicateurs concernant le code source de vos projets. Dans les articles suivants nous verrons comment exploiter ces métriques au profit de votre projet ainsi que les explications et l’utilisation d’éléments de qualimétrie courants.

L’objectif de cette article n’est pas de faire peur ou de dire que la qualité logicielle est réservé aux esthètes, aux intégristes de la ligne de code ou aux architectes qui n’en écrivent jamais une.

La qualité logicielle, c’est cool

Oui c’est cool, mais c’est quoi? Il existe plusieurs définitions, celle de wikipédia :

In the context of software engineering, software quality measures how well software is designed (quality of design), and how well the software conforms to that design (quality of conformance), although there are several different definitions. It is often described as the ‘fitness for purpose’ of a piece of software.

Whereas quality of conformance is concerned with implementation, quality of design measures how valid the design and requirements are in creating a worthwhile product.

Comme c’est si justement dit, la plupart des outils et des modèles distinguent plusieurs niveaux de conformité. Globalement, tous se basent sur des métriques (des éléments factuels qui sont mesurables sur l’application). C’est la clé de voute de la qualité logicielle.

La qualité logicielle: à quoi ça sert?

Comme toutes les choses cool, la qualité logicielle ça peut être très utile, parfois ennuyant et parfois même handicapant. La réelle utilité tiens dans une notion simple, celle de l’amélioration continue. Pourquoi mesurer quelque chose si ce n’est pour l’améliorer? En fait, il y’a deux réponses à cette question qui s’opposent à priori.
D’une part, le développement est un métier artisanal dont l’état de l’art évolue et s’adapte aux besoins ou aux évolutions des technologies. Pour pouvoir construire des applications, il y’a certains critères qu’il est nécessaire de respecter pour que l’édifice puisse croitre.
Le deuxième aspect en contradiction avec le premier, c’est la nécessité d’industrialiser, de faire évoluer et de maintenir les opérations de construction de l’application.

Artisanat et industrie logicielle

Les deux objectifs sont opposés mais la finalité est la même: Bien développer. La difficulté réside dans le fait d’exprimer le “bien développer”. Un modèle qualimétrique définit généralement des facteurs de qualité (ou de santé) d’une application. Un des modèle les plus répandu est l’ISO 9126-3.  Mais il en existe d’autres, celui du SEI, ou encore des modèles propres à des éditeurs, des outils ou à des méthodologies de projet ou d’analyse de la qualité. A titre d’exemple, l’evolutivité, la transférabilité, la sécurité, la robustesse et la performance sont des facteurs de santé.

Certains modèles s’appuient (aussi ou uniquement) sur des critères  qualités: Gestion des erreurs et des exceptions, documentation ou complexité sont des critères qualités.

En bout de chaîne, la métrique est l’élément essentiel permettant de réaliser la mesure et intervient ainsi dans le critère qualité ou dans le facteur de santé. La complexité cyclomatique, le taux de documentation, le taux de duplication ou le taux de couverture par les tests unitaires sont des métriques. Elles sont valuées et répétables.

Génèse

Evidement, tout ne s’est pas fait en jour, et la naissance des Services Web et des technologies qui les accompagne remonte à un peu plus loin que cette date. En réalité, l’histoire commence en 1975 lorsque l’informatique souffrait encore de peu de standardisation et que les constructeurs et éditeurs se rendent compte de la nécessité d’uniformiser les échanges de données. Ils firent alors le vœux pieux de “l’interopérabilité” afin de standardiser la communication entre application au travers d’un réseau. c’est la naissance l’EDI (Electronic Data Interchange ou Echange de Données Informatisées), l’ancêtre des Web Services.

De nombreuses technologies ont alors émergé depuis avec toujours cet objectif de connecter des logiques métiers au travers d’un réseau: C’est la naissance de CORBA, DCOM, Unix RPC, Java RMI, mais aucune de ces technologies n’a réellement réussit à s’imposer comme standard universel car souvent rattaché à un système d’exploitation, à un éditeur ou à un langage particulier.

Le web à la rescousse

L’arrivée du web à tout bouleversé. Jusque là toute les tentatives d’accorder les acteurs du marché autour d’un protocole réseau d’interconnexion des applications ont échoués. Le web a rendu cela possible en s’appuyant des modèles académiques (modèle OSI) et en reprenant les clés du succès de protocoles de plus bas niveaux déjà adopté.

L’émergence du Web va passer par la création du protocole HTTP et sa standardisation en 1997 comme protocole de transfert de données hyper texte (du texte avec des liens) et qui s’appuiera sur TCP/IP. A ce moment, IP est un protocole d’interconnexion mature et dont la diffusion était importante dans les universités et les entreprises. Il ne manquait alors qu’un format d’encapsulation et d’échange de message pour finaliser la chaîne de l’interopérabilité.

L’arrivée d’XML et la naissance de XML-RPC

En 1998, année de sa standardisation en version 1.0 par le W3C, XML viendra compléter la chaîne de l’interopérabilité en s’imposant comme format d’échange et de description des données, indépendant de toute plateforme.

La même année, la société UserLand très active dans le domaine de la gestion de contenu (CMS), et pionnière sur XML, entame alors des travaux en collaboration avec Microsoft pour standardiser une technologie d’échange entre applications. C’est la naissance de XML-RPC.

Stop stop stop

L’histoire ne s’est pas arreté là, mais la redaction de cette article oui, car cette article a donné lieu à un document beaucoup plus important d’une soixantaine de pages sur les normes d’architecture et de développement des Web Services.