Comme on l’a montré dans l’article précédent, Sonar est l’outil indispensable pour évaluer la qualité des projets d’une DSI au fil de l’eau.

Dans cet article nous aimerions présenter l’installation de différents composants de l’analyse Sonar et comment l’intégrer à votre usine de build TFS.

L’installation de Sonar

Sonar est composé de deux éléments : un serveur (base de données + interface web) et un moteur d’analyses, qui va envoyer les résultats en base.

Le serveur de Sonar

La partie serveur de Sonar est très flexible : elle comprend un serveur web minimaliste et une base de données embarquée par défaut, mais peut être branchée sur un moteur de servlet (Tomcat, Jetty) et sur une base de données classique (MySQL, Oracle, SQL Server).

En termes de ressources consommées, il faut compter 500mo de ram et 350ko / 1000 LOC analysées en base de données. A titre d’exemple, la base de la démo de Sonar fait 2Go pour 6 millions de LOC et 2 ans d’historique. Il n’y a donc pas de contre-indication à faire cohabiter Sonar et TFS sur une même machine et une même base.

Le wiki de SonarSource, la société éditrice de Sonar, comporte des instructions détaillées pour mettre en place le serveur.

Les runners de Sonar

Sonar nous propose deux outils pour lancer les analyses de qualité sur nos projets : le « simple java runner » et le plugin sonar pour Maven.

Ces deux runners nécessitent Java 5+ pour fonctionner, sont aussi simples à configurer et s’intègrent facilement dans vos usines de développement. Mais alors que le simple java runner se contente d’effectuer l’analyse Sonar une fois le code compilé, Maven permet aussi d’ordonnancer le build et le déploiement. Ces fonctionnalités supplémentaires ont de l’intérêt lorsque vous utilisez une usine de build multi-langages (Jenkins par exemple).

Que vous choisissiez l’un ou l’autre, la configuration pour Sonar et vos projets C# sera la même, dans un fichier .properties pour l’un et .xml pour l’autre.

Ce fichier de configuration doit se trouver à la racine de votre solution, au même niveau que votre fichier .sln. C’est dans ce fichier que vous renseignerez le nom du programme, la version, les répertoires de sources et de tests et enfin la location du serveur Sonar et de sa base de données s’ils sont sur une machine différente.

Exemple de fichier de configuration basique pour Maven :

	4.0.0

	
	com.octo projetCSharp
	1.0
	Projet C#
sln

		
		ProjectCSharp.sln

		
		*.UnitTests

		cs
	

	


				org.codehaus.sonar-plugins.dotnet
				maven-dotnet-plugin
				true
			

				org.codehaus.mojo
				sonar-maven-plugin
				
					cs
				
			
		
	

Exemple du même fichier de configuration pour Simple Java Runner :

# identifiants du projet
sonar.projectKey=com.octo.projetCSharp
sonar.projectName=Projet CSharp
sonar.projectVersion=1.0

# fichier .sln
sonar.dotnet.visualstudio.solution.file=ProjectCSharp.sln

# répertoires de sources
sources=srcDir1,srcDir2

# répertoires de tests
tests=testDir1,testDir2

# langage
sonar.language=cs

Là aussi, la procédure d’installation du plugin .NET pour sonar est très bien décrite dans le wiki de sonar.

L’intégration à Team Foundation Server 2010

Team Foundation Server (TFS) est l’usine de développement logicielle proposée par Microsoft. Elle est utilisée dans la plupart des grandes DSI adeptes du .NET.

Comme on l’a vu dans l’article précédent, TFS ne permet pas de faire un reporting de qualimétrie aussi poussé que celui de Sonar. Mais par contre, il est relativement aisé d’ajouter l’analyse Sonar au processus de build de TFS à l’aide d’un buildTemplate.

Si on utilise TFS pour builder nos projets, on préférera le Simple Java Runner à Maven. Le runner a besoin des sources compilées, on basera donc notre template sur l’un de ceux disponibles par défault (DefaultTemplate ou UpgradeTemplate) qui s’occupera de compiler le projet.

Enfin, il suffira d’ajouter les activités « Delete/Create/Copy Directory » pour copier les sources dans un répertoire indépendant et « Invoke Process » pour lancer le runner, qui s’occupera d’envoyer les résultats au serveur Sonar.

Les premières versions du plugin Sonar pour .NET prenaient énormément de temps pour faire l’analyse (jusqu’à 1h pour 80kLOC en version 0.2). Mais depuis un gros effort a été fourni par l’équipe responsable de ce plugin et maintenant l’analyse est suffisamment rapide (2-3 minutes) pour être intégrée directement au build Gated Check-In (qui se lance à chaque commit) pour des métriques en temps réel.

Si vous choisissez de faire l’analyse durant un build de nuit, pensez à désactiver le jeu des tests lancés par TFS pour gagner un peu de temps, le simple runner va les jouer lui même.

Pour finir

Les indicateurs de qualité de code fournis par Sonar vous permettront de prendre conscience en temps réel de l’évolution de la dette technique de votre projet.

Attention toutefois, ces indicateurs doivent être compris, notamment les règles de qualité de code, pour pouvoir être paramétrés selon vos besoins. Portez une attention particulière aux règles FXCop et Gendarme : activez les au cas par cas.

Enfin, nous souhaiterions remercier à nouveau l’équipe de développement du plugin .NET pour Sonar, pour la qualité de leur travail.

Suggestion d'articles :

1. Sonar, l’outil qui manquait à l’usine de développement .NET
2. En direct des TechEd : Team System, Tests Unitaires et Software Factory
3. Compte rendu du séminaire SpringSource tc Server du 28 Juillet à OCTO

La reconnaissance faciale est un des problèmes les plus étudiés de l’apprentissage automatique. Grâce à sa popularité ce problème a été bien exploré pendant les 50 dernières années.

Récemment la reconnaissance faciale attire de plus en plus d’attention.

La sécurité reste le domaine d’application principal. Dans ce domaine la reconnaissance de visage est responsable de l’identification et de l’authentification. Un bon exemple de cet usage est l’aéroport du Francfort qui utilise la reconnaissance pour automatiser le contrôle des passagers.

Un autre exemple peut être l’analyse des vidéos capturées par les systèmes de caméras externes gérés par les grandes villes. Les suspects peuvent être identifiés après l’analyse de la vidéo acquise.

La reconnaissance faciale peut aussi être utilisée juste pour accélérer le processus d’identification. On peut imaginer un système qui va identifier un client quand il entre dans l’agence de la banque. Le conseiller peut ensuite le recevoir en ayant préparé son dossier et le saluer par son nom.

Les agences de publicité sont en train de développer des panneaux d’affichage intelligents, qui grâce à la reconnaissance du visage de la personne qui passe adaptent le contenu affiché.

Google et Facebook ont implémenté des algorithmes pour identifier les personnes dans leurs bases de données de photos. D’autres applications, telles que Face.com proposent la recherche dans la base de données de Facebook. On peut facilement chercher toutes les photos où figurent ensemble nos deux meilleurs amies.

La nouveauté dans la reconnaissance faciale arrive grâce au développement des nouvelles caméras de type 3D. Ces caméras obtiennent de meilleurs résultats que les caméras classiques, parce qu’elles acquièrent une image tridimensionnelle de chaque visage. Elles sont ensuite capables de résoudre des problèmes spécifiques à ce domaine (l’illumination et la séparation du visage et du fond). Vous pouvez regarder l’exemple de Kinect, qui reconnaît la bonne personne dès qu’elle passe devant la caméra.

Si vous êtes intéressé, vous pouvez consulter la suite de cet article rédigée en anglais.

Suggestion d'articles :

1. Introduction à la gestion de version distribuée
2. Introduction à la Programmation Orientée Acteurs
3. Introduction au calcul en grille pour l’évaluation de la Value At Risk

Avec l’arrivée massive des processeurs multi-cœur, le parallélisme peut devenir une nécessité pour une application afin exploiter toute la puissance disponible d’une machine proposant ce type d’architecture. En effet, la loi de Moore, vérifiée depuis 1973, se heurte à une autre loi, celle des rendements décroissants.  Le nombre de transistors à ajouter pour obtenir un gain de performance donné devient de plus en plus important, empêchant les fondeurs de continuer à augmenter la fréquence d’horloge des processeurs. Pour contourner ce problème, ils favorisent les architectures multi-cœurs. Le parallélisme peut être très impactant dans le développement d’une application, celle-ci devant être écrite et adaptée pour tirer parti du hardware.

Qu’est-ce que le parallélisme sur une architecture multi-cœur? C’est l’emploi des capacités de calculs en simultané dans un cadre déterministe. Cela consiste à prendre une tâche, la diviser en un ensemble de sous-tâches indépendantes à exécuter simultanément, le travail étant réparti sur plusieurs cœurs (la notion de concurrence, quant à elle traite de l’allocation d’une même ressource CPU pour plusieurs processus, chacun disposant à son tour d’un quantum de temps de calcul).

Dans cet article, je vais examiner comment il peut être relativement facile d’implémenter la programmation parallèle dans une application, en utilisant le Framework  .NET 4.0 et sa librairie TPL (Task Programming Library).

Rappelons que l’idée principale est d’utiliser la puissance des machines multi-cœurs. Le challenge est donc de savoir comment diviser un fragment de programme en multiple unités et ce, de façon simultanée.

Je vous renvoie à un article rédigé par Olivier Roux en 2009, traitant du même sujet mais basé sur les Parallel Exentions. Le but de ce nouvel article est de faire un point sur le développement parallèle, deux ans après. Certains éléments sont rebalayés ici, d’autres clarifiés, de nouveaux sujets sont abordés ainsi que des tests de performance.

La solution existante depuis le Framework .NET 2.0 est l’utilisation d’un pool de threads. Il est composé d’un scheduler et d’une file d’attente de threads. Quand un thread a fini son travail, il est mis dans la file et est de nouveau disponible pour être capté par une opération à exécuter.

Quels sont les avantages et nouveautés de la programmation parallèle dans le Framework .NET 4.0 ? Comme premier élément de réponse, je poserai la question suivante :

• Combien de développeurs sont capables de développer une application multi-threads sans difficultés ?

Il est impossible de prédire le comportement d’un thread après sa création, d’où la complexité de ce type de développement, plutôt réservé aux développeurs chevronnés, spécialisés dans ce domaine. Les difficultés liées à la programmation parallèle sont évoquées dans un article de Sofian Djamaa.

Comment utiliser les tâches ?

Dans les version précédentes de .NET, il était complexe d’obtenir des informations sur ce qui se passait exactement après avoir mis un élément en attente dans le pool, c’était du « fire and forget ».

En .NET 4.0, la librairie TPL est un moyen « simplifié » d’utiliser le pool de threads. Une tâche (Task) représente une opération asynchrone, et à certains égards, ressemble à la création d’un nouveau thread ou à un élément de travail du pool de threads (work item), mais à un niveau supérieur d’abstraction. Les tâches ont deux avantages principaux:

• Une utilisation plus efficace des ressources système:
  Il n’y a pas de relation 1-1 entre une tâche et un thread. Les tâches sont mises en attente dans le thread pool. Celui-ci a été amélioré à l’aide d’algorithmes (comme Hill-climbing) pour déterminer et ajuster le nombre de threads afin de maximiser le trafic. De plus, des algorithmes de type Work-stealing sont utilisés pour répartir la charge en fonction du nombre de processeurs (ou cœurs) disponibles. Le CLR 4.0 s’occupe donc de gérer le niveau de concurrence entre les threads.
• Un meilleur contrôle programmatique qu’avec les threads ou work items:
  La librairie TPL fournit un ensemble de fonctions de contrôle : mise en attente, annulation, gestion des exceptions et plus encore.

Exemple 1 : Création de tâches

	static void Main(string[] args)
	        {
	            //Création et lancement de la première tâche
	            var t1=Task.Factory.StartNew(() => ProcessNumbers(10, 20));
	            //Création et lancement de la deuxième tâche
	            var t2=Task.Factory.StartNew(() => ProcessNumbers(20, 30));
	            //Création et lancement de la troisième tâche
	            var t3=Task.Factory.StartNew(() => ProcessNumbers(30, 40));
	            Console.ReadLine();
	        }  

	        static void ProcessNumbers(int start, int stop)
	        {
	            for (int i = start; i < stop; i++)
	                Console.Write(" " + i);
	        }

Ci-dessus, je créé 3 tâches, exécutées en parallèle. Remarquons que la tâche t3 commence avant que la tâche t2 soit terminée, car l’exécution des tâches est asynchrone.

Exemple 2 : Attendre l’exécution de tâches

	//Création et lancement de la première tâche
	 var t1=Task.Factory.StartNew(() => ProcessNumbers(10, 20));
	 //Création et lancement de la deuxième tâche
	 var t2=Task.Factory.StartNew(() => ProcessNumbers(20, 30));  

	 //Attendons que t1 et t2 soient finies pour commencer t3
	 t1.Wait();
	 t2.Wait();  

	 //Création et lancement de la troisième tâche
	 var t3=Task.Factory.StartNew(() => ProcessNumbers(30, 40));
	 Console.ReadLine(); 

	        }

Le code ci-dessus permet à la tâche t3 de commencer après que les tâches t1 et t2 soient finies. Ces deux tâches sont mises en attente dans le thread pool, l’appel à la fonction Wait() bloque les autres tâches jusqu’à ce que l’exécution de t1 et t2 soit terminée. J’aurais pu utiliser la méthode WaitAll() : Task.WaitAll(t1, t2), cela revient au même.

Exemple 3 : Tâche retournant un résultat

// La method MyMethod() retourne une chaîne de caractères
Task aTask = new Task(MyMethod);
aTask.Start();

Task.WaitAll();

string result = aTask.Result;

Pour que la tâche retourne une valeur, il faut utiliser la version générique Task<T>. Le paramètre T désigne le type de retour. Le type Task a une propriété « Result » qui bloque l’exécution en y accédant, je m’explique :

var task = Task.Factory.StartNew(() =>
{
    Thread.Sleep(3000);
    return "dummy value";
});
Console.WriteLine(task.Result);

La tâche s’exécute dans un thread séparé et prendra 3 secondes. Lorsque j’appelle « Console.WriteLine », une exception n’est pas levée même si le résultat n’est pas encore disponible. L’exécution est bloquée 3 secondes avant de continuer. Cela peut être nécessaire lorsqu’utilisé avec des tâches longues, sachant qu’elles utiliseront cette faculté de bloquer en attendant qu’elles soient terminées.

Remarque : la méthode WaitAny(t1, t2, t3…) permet d’attendre l’exécution de l’une des tâches sans se soucier laquelle.

Il est également possible d’utiliser la méthode ContinueWith(Action<Task>) pour réaliser la même chose, à savoir attendre la fin d’une tâche pour en débuter une autre. La méthode ContinueWhenAll(Task[], Action<Task[]>), quant à elle permet de spécifier quelle(s) tâche(s) attendre avant d’en commencer une autre.
Plus généralement, TaskFactory contient un nombre intéressant de méthodes qui pourront vous aider dans de nombreuses occasions.

Comment paralléliser les boucles ?

L’idée est de traiter chaque itération indépendante de la boucle simultanément.

Exemple 4 : Parallel.For

Considérons une boucle for basique :

for (int i = 0; i < 200; i++)
{
    if (i % 2 == 1)
        Console.WriteLine(i + " ");
}

Remarquons que pour paralléliser cette boucle, la syntaxe change peu:

Parallel.For(0, 200, (i) =>
{
    if (i % 2 == 1)
        Console.WriteLine(i + " ");
});

Exemple 5 : Parallel.ForEach

Voici un exemple plus concret, il provient du projet CreditReview que fournit Microsoft.  L’idée est d’identifier les comptes à risque s’ils ont excédé leur limite de crédit les mois précédents. Le statut de crédit de chaque client ne dépend pas du statut d’un autre.

Boucle séquentielle :

static void UpdatePredictionsSequential(AccountRepository accounts)
        {
            foreach (Account account in accounts.AllAccounts)
            {
                Trend trend = SampleUtilities.Fit(account.Balance);
                double prediction = trend.Predict(
                                 account.Balance.Length + NumberOfMonths);
                account.SeqPrediction = prediction;
                account.SeqWarning = prediction < account.Overdraft;
            }
        }

Boucle parallèle :

static void UpdatePredictionsParallel(AccountRepository accounts)
        {
            Parallel.ForEach(accounts.AllAccounts, account =>
            {
                Trend trend = SampleUtilities.Fit(account.Balance);
                double prediction = trend.Predict(
                                   account.Balance.Length + NumberOfMonths);
                account.ParPrediction = prediction;
                account.ParWarning = prediction < account.Overdraft;
            });
        }

Une telle construction gère de façon dynamique l’augmentation et la réduction du nombre de threads, suivant la charge disponible sur chaque cœur, impliqués dans les opérations de façon à déterminer le nombre de threads optimal pour une charge de travail donnée.

L’avantage par rapport à la gestion classique de threads pour le développeur est de lui épargner de coder des solutions de partitionnement des charges de travail, celui-ci pouvant se concentrer sur la logique métier.

Optimisation des boucles

Dans la pratique, quand plusieurs boucles sont imbriquées, il n’est pas nécessaire de paralléliser boucles externe et boucles internes, la boucle externe suffit. En effet, celle-ci offre de plus grandes unités de travail à paralléliser, diluant la surcharge due au mécanisme de synchronisation des threads.

Une autre optimisation est l’emploi d’une valeur locale. Le problème est le suivant : supposons que nous voulions additionner la racine carré d’un nombre dix millions de fois. Le calcul est parallélisable sans problème, mais additionner les valeurs devient gênant car nous devons verrouiller la mise à jour du total :

Exemple  6 : Lock, optimisation avec une valeur locale

object locker = new object();
double total = 0;
Parallel.For (1, 10000000,
              i => { lock (locker) total += Math.Sqrt (i); });

Dans le code ci-dessus, le gain du à la paralléisation est contrebalancé par le coût de 10 millions de locks, dont nous n’avons pas besoin.

object locker = new object();
double grandTotal = 0;

Parallel.For (1, 10000000,

  () => 0.0,                     // Initialisation de la valeur locale.

  (i, state, localTotal) =>      // Le délégué invoqué pour chaque itération
     localTotal + Math.Sqrt (i),    // Il retourne la nouvelle valeur locale.

  localTotal =>                                // Ajout de la variable locale
    { lock (locker) grandTotal += localTotal; }    // à la valeur globale.

Certes, il y a toujours des locks mais seulement pour la somme grandTotal += localTotal, ce qui est beaucoup plus efficace que la version précédente.

Exemple 7 : Degré de parallélisme

Il s’agit de limiter le nombre de cœurs à utiliser dans une exécution.

var options = new ParallelOptions();
options.MaxDegreeOfParallelism = Math.Max(Environment.ProcessorCount / 2, 1);

Parallel.For(0, pixelData.GetUpperBound(0), options, row =>
{
    for (int col=0; col < pixelData.GetUpperBound(1); ++col)
    {
        pixelData[row, col] = AdjustContrast(pixelData[row, col], minPixel, maxPixel);
    }
});

Bien souvent, la configuration par défaut convient, mais dans certains cas il peut être utile d’utiliser un sous-ensemble des cœurs disponibles. En pratique, cela limite le nombre d’opérations simultanées, qui peut être intéressant si nous exécutons un processus long, nous ne voulons pas multiplier les requêtes sur le serveur en même temps. Le serveur lui-même peut ne pas être en mesure de toutes les traiter et étonnamment se retrouver surchargé (le principe d’une attaque DOS).

PLINQ

L’une des autres avancées du Framework .NET 4.0 en matière de parallélisme est le Parallel LINQ (PLINQ). Son utilisation est identique à LINQ-to-Objects et LINQ-to-XML. Tous les opérateurs de requêtes du C# 3.5 sont disponibles. Les requêtes LINQ-to-SQL et LINQ-to-Entities sont toujours exécutées par les bases de données, donc non parallélisable par PLINQ.

PLINQ s’avère utile pour les requêtes nécessitant une grande quantité de calcul. Il est aussi possible d’interroger simultanément plusieurs sources de données (bases de données, fichier XML…) après avoir été chargées en mémoire.

Exemple 8 : de LINQ à PLINQ

Une requête simple LINQ

IEnumerable data = ...;
var q = data.Where(x => p(x)).Orderby(x => k(x)).Select(x => f(x));
foreach (var e in q) a(e);

En PLINQ

IEnumerable data = ...;
var q = data.AsParallel().Where(x => p(x)).Orderby(x => k(x)).Select(x => f(x));
foreach (var e in q) a(e);

PLINQ exécute les clauses Where, OrderBy et Select de manière transparente sur tous les coeurs disponibles. La technologie Parallel Linq, qui est un sujet à part entière, ne sera pas plus détaillée volontairement.

Comment débugger?

Pour parcourir unitairement en mode pas-à-pas chaque thread, Visual Studio 2010 possède une fenêtre dédiée : Debug -> Windows -> Parallel Tasks. Il est possible de freezer les tâches, de switcher entre-elles. Visual Studio identifiera les deadlocks et vous dira quelles sont les deux threads mis en cause et quel objet elles attendent.

Nous pouvons aussi afficher une représentation graphique des threads exécutés : Debug -> Windows -> Parallel Stacks.

Gestion des exceptions

Il est possible de gérer les exceptions, en effet, celles-ci sont stockées dans une tâche et sont levées lorsque toutes les tâches sont terminées. Les exceptions ne sont jamais perdues et correctement propagées. Pour les propager au thread appelant, elles sont encapsulées dans une instance AggregateException. Elle peut énumérer, examiner toutes les exceptions qui ont été levées individuellement.

Exemple 9 : AggreagateException

var task1 = Task.Factory.StartNew(() =>
            {
                throw new MyCustomException("mon exception");
            });

            try
            {
                task1.Wait();
            }
            catch (AggregateException ae)
            {
                foreach (var e in ae.InnerExceptions)
                {
                    if (e is MyCustomException)
                    {
                        Console.WriteLine(e.Message);
                    }
                    else
                    {
                        throw;
                    }
                }
            }

Et les performances ?

La première démo illustrant le gain de performances de la programmation multi-cœurs en .NET 4.0 est une multiplication de deux matrices de même dimension et le calcul du résultat dans une troisième. Cet exemple est un bon candidat pour le parallélisme car nécessitant beaucoup de calculs.

Je fais cette opération tout d’abord en mode séquentiel, puis en mode parallèle et je compare le temps d’exécution de chacun des deux modes.

Exemple 10 : multiplication de matrices

Ci-dessous le code d’initialisation des matrices :

static double[,] InitializeMatrix(int rows, int cols)
        {
            double[,] matrix = new double[rows, cols];

            Random r = new Random();
            for (int i = 0; i < rows; i++)
            {
                for (int j = 0; j < cols; j++)
                {
                    matrix[i, j] = r.Next(100);
                }
            }
            return matrix;
        }

La boucle séquentielle:

static void MultiplyMatricesSequential(double[,] matA, double[,] matB,
                                                double[,] result)
        {
            int matACols = matA.GetLength(0);
            int matBCols = matB.GetLength(0);
            int matARows = matA.GetLength(0);

            for (int i = 0; i < matARows; i++)
            {
                for (int j = 0; j < matBCols; j++)
                {
                    double temp = 0;
                    for (int k = 0; k < matACols; k++)
                    {
                        temp += matA[i, k] * matB[k, j];
                    }
                    result[i, j] = temp;
                }
            }
        }

Et la boucle parallélisée:

static void MultiplyMatricesParallel(double[,] matA, double[,] matB, double[,] result)
        {
            int matACols = matA.GetLength(1);
            int matBCols = matB.GetLength(1);
            int matARows = matA.GetLength(0);

            // Multiplication des matrices
            // Parallélisation de la boucle externe pour partitionner
            //la matrice source par ligne.
            Parallel.For(0, matARows, i =>
            {
                for (int j = 0; j < matBCols; j++)
                {
                    double temp = 0;
                    for (int k = 0; k < matACols; k++)
                    {
                        temp += matA[i, k] * matB[k, j];
                    }
                    result[i, j] = temp;
                }
            });
        }

La machine sur laquelle les tests sont effectués embarque un processeur Intel Core i7 Quad-Core HT.

Les résultats sont logiquement ceux espérés.

J’ai fait varier la taille des matrices [n,n], n prenant respectivement les valeurs 500, 1000, 1500, 2000, et 2500.

Dans les tests en mode parallèle, le pourcentage d’utilisation du CPU est toujours monté à 100% :

Il est resté bloqué à 12% en mode séquentiel. Cela s’explique par la nature du processeur, Quad-Core en effet, mais 8 threads (avec le support de l’HyperThreading).

En tirant parti de la librairie TPL du Framework .NET 4.0, le temps d’exécution peut même être divisé par un facteur supérieur à 4, en mode parallèle. Ce résultat peut sembler étonnant, nous devrions avoir un gain de performances théoriques inférieures à 4 (car quatre cœurs). En effet, dans l’OS, d’autres applications tournent en arrière-plan. Le mécanisme de synchronisation des threads doit aussi prendre un peu de puissance de calcul. Ceci reflète sans doute l’amélioration des performances due au mode HyperThreading du processeur.

Exemple 11 : BabyNames

La deuxième démo utilise PLINQ cette fois. C’est la démo BabyNames du training kit Visual Studio 2010. Les coordonnées d’individus d’une population sont chargées en mémoire (250 Mo), une requête LINQ ou PLINQ est exécutée suivant le mode désiré. Elle recense le nombre de naissances par année, pour un nom/prénom choisi.

J’obtiens les résultats suivants, en faisant varier le nombre de cœurs :

Les résultats sont à peu près du même ordre que dans l’exemple précédent. Il est intéressant de noter que notre processeur étant HT, le programme détecte 8 cœurs. Nous pouvons donc sélectionner très finement le degré de parallélisme voulu. Nous observons que la requête PLINQ exécuté sur un seul thread d’un unique cœur est presque aussi rapide que la même requête LINQ.

La programmation parallèle est longtemps restée le domaine de développeurs spécialisés. Il semblerait que cela soit en train de changer dans le monde .NET, et c’est plutôt une bonne nouvelle. En effet, le gain de performances que la librairie TPL peut apporter est à prendre en compte dans le développement d’une application ou d’un composant de celle-ci.

Le parallélisme à la sauce Microsoft inclus dans le Framework .NET 4éme mouture est certes une surcouche encapsulant elle-même les mécanismes plus bas niveau du parallélisme, j’entends déjà les puristes de la manipulation du thread crier au scandale. Néanmoins, le développement d’une application multi-threadée est grandement simplifié et peut demander peu d’efforts à condition que les algorithmes soient facilement parallélisable, y compris pour adapter un code déjà existant.

Notons que le C# 5 Async doit apporter un lot de nouveautés, qui, combinées avec la librairie TPL, devraient être intéressantes pour les opérations asynchrones.

Suggestion d'articles :

1. Parallélisation, distribution partie 3 : comment tirer parti des processeurs multi-coeurs à travers l’API de concurrence de Java 7 ?
2. Environnement de développement Maven/Eclipse pour GWT 1.7
3. Devons-nous changer de paradigme pour le développement d’applications informatiques?

Un de nos derniers projet de recherche et développement a été le développement d’une application de banque en ligne, qui nous a permis d’expérimenter les dernières tendances de développement sur la plateforme .NET.

Quand est venu le moment de déployer l’application, nous n’avions pas de machine disponible. Mais attendez, de nos jours, lorsque l’on a besoin de déployer une application, on peux simplement la publier sur le cloud le plus proche !

Evidemment, nous avons choisi la plateforme Azure. La question était juste de savoir si un tel déploiement allait poser problème ? Va t-il falloir adapter notre application ? Combien de temps cela va t-il prendre ?

Finalement le processus de modification a été beaucoup moins lourd que nous l’avions imaginé : en 30 minute, nous avons été capable de préparer les changements nécessaires et publier l’application sur le cloud.

Mais Azure est beaucoup plus qu’une simple plateforme pour les applications web. Il offre aussi plusieurs types de stockage. l’un d’entre eux étant Azure Blob Storage. Après le déploiement, nous avons décidé d’utiliser Azure Blob Storage pour le développement d’une nouvelle fonctionnalité présente dans notre to-do list.

Cet article est un retour d’expérience sur la plateforme Azure. Il est divisé en deux parties.

La première partie décrit comment porter une application .NET sur la plateforme Azure.
La deuxième partie va montrer comment utiliser Azure Blob Storage pour développer un simple coffre fort électronique.

La suite de l’article a été rédigé en anglais, vous pouvez consulter la première partie ici et la deuxième ici.

Suggestion d'articles :

1. Panorama des différentes offres de cloud computing : Microsoft Azure
2. Panorama des différentes offres de cloud computing : comparaison des tarifs
3. Et si nous définissions simplement le Cloud Computing !

Sonar (www.sonarsource.org) est un outil de reporting sur la qualité des projets informatique. Bien qu’à l’origine fait pour le Java, la communauté Open Source a permis l’intégration de Sonar avec d’autre langages : cobol, flex, php, c++ et maintenant .NET.

L’objet de cet article est de vous montrer ce que peut apporter Sonar pour un projet informatique et montrer quelle est sa place dans l’univers .NET.

Sonar : des indicateurs de qualité du code

Sonar centralise les rapports d’outils d’analyse de code pour afficher des informations comme la couverture de test, le respect des normes de développements, la complexité, la duplication…

Il est important de prendre ces indicateurs pour ce qu’ils sont : des indices permettant de déceler de la dette technique. Il serait dangereux d’utiliser ces métriques dans l’absolu pour contractualiser la qualité attendue d’un projet.

Nous allons voir d’un peu plus près les métriques les plus significatives.

Tests unitaires et couverture

La seule façon de prouver qu’un code fonctionne, c’est de le tester.

Sonar permet de connaitre le nombre de tests unitaires joués, le taux de succès et la couverture de ces tests.

La couverture de tests correspond au pourcentage de lignes de code du projet qui est appelé pendant la phase de test. Attention : ce n’est pas parce qu’une ligne est appelée qu’elle est testée.

Une couverture élevée n’est donc pas une fin en soi. Par contre, une couverture basse est l’indice d’une carence dans les tests, ce qui est un risque pour le projet.

Une couverture élevée alors qu’il y a peu de tests implique que les tests ne sont pas unitaires, ce qui veut dire que le code couvert n’est probablement pas totalement testé.

Enfin, un taux de succès des tests qui n’est pas à 100% sous entend que les développeurs ne font pas attention lors du checkin/commit.

Complexité et cohérence

La complexité d’une méthode et la cohérence d’une classe sont des métriques qui permettent de mettre en évidence des problèmes de maintenabilité et de testabilité.

La complexité d’une méthode correspond plus ou moins au nombre de tests qu’il faudra faire pour couvrir tous les cas. Donc plus la méthode est complexe, plus elle sera difficile à maintenir et à tester.

La cohérence d’une classe (ici LCOM4) est un indicateur intéressant qui permet de trouver les classes qui pourraient facilement être découpées. La valeur LCOM4 correspond au nombre de classes qui pourraient résulter de ce découpage.

Règles de qualité du code

Il existe des outils d’analyse statique du code (exemples : Findbugs, Pmd en Java, FxCop, Gendarme en .NET) qui permettent de soulever des bugs potentiels ou des problèmes de maintenabilité.

Dans nos projets nous suivons la procédure suivante :

• Blocker : c’est un bug, on arrête tout et on corrige.
• Critical : il y a de fortes chances que ce soit un bug : on essaye de corriger rapidement.
• Major : ça ne sent pas bon, il vaudrait mieux regarder. On essaye de corriger avant la livraison.
• Minor et info : pensez à regarder si vous êtes curieux. En général, personne n’agit dessus, alors autant les désactiver.

La qualimétrie dans l’univers .NET

Dans l’univers .NET il existe des équivalents des outils permettant d’obtenir les métriques évoquées avant, mais il n’existe pas de solution de reporting  de celles-ci intégrée à l’usine de développement Team Foundation Server.

Team Foundation Server (TFS)

Le reporting TFS repose sur un cube OLAP contenant les données de build, de test et les work items. Il est donc possible de faire des extractions SQL à destination d’Excel, SharePoint ou Crystal Reports.

Néanmoins, ces rapports ne contiennent que des indicateurs de couverture de test, complexité cyclomatique ou de productivité (nombre de ligne produite, de bug résolu …). Les résultats des analyses de règles de qualité de code (FxCop, StyleCop, Gendarme, NDepend) ou de duplication de code (SourceMonitor) ne sont pas injectés dans le cube.

Ainsi, TFS ne permet pas de créer des rapports d’indicateurs qualimétriques provenant d’outils externes sans développement spécifique, d’où l’intérêt de Sonar.

Sonar pour les projet .NET

Le plugin .NET pour Sonar est né dans une DSI où il y avait autant de projets Java que de projets .NET. Il y avait une volonté de centraliser les informations pour avoir une vue globale des niveaux de qualité  des projets de la DSI.

Sonar propose un dashboard global qui répond à ce besoin :

Sonar est conçu pour s’intégrer dans une usine de développement logicielle (Hudson/Jenkins ou bien justement TFS). Cette intégration permet une mise à jour des métriques à chaque build !

Chaque mise à jour est sauvegardée et Sonar propose des graphiques montrant l’évolution des métriques dans le temps :

Pour finir

Sonar est l’outil indispensable pour évaluer la qualité des projets d’une DSI au fil de l’eau.

Dans notre prochain article, nous vous montrerons comment mettre en place Sonar pour un projet .NET et comment l’intégrer à un build TFS 2010.

Nous remercions l’équipe de développement du module .NET pour le travail impressionnant qu’ils ont accompli.

Suggestion d'articles :

1. Intégrer l’outil de supervision Sonar à Team Foundation Server 2010
2. Analyser la qualité de votre code Groovy / Grails
3. Développement parallèle pour des machines multi-coeur en .NET 4.0

A moins de s’être limité à dessiner des ronds et des carrés avec Silverlight, vous avez sans doute déjà tenté d’utiliser un des templates de projets du Silverlight Toolkit permettant de faire des tests unitaires pour vos applications RIA! Plein de bonne volonté, vous vous êtes heurtés aux multiples inconvénients de cette solution :

• Framework de tests spécifique à Silverlight
• Obligation de lancer une application « conteneur » pour lancer vos tests
• Usabilité plus que discutable de cette même application
• Impossibilité d’utiliser une métrique comme la couverture de code
• et j’en passe…

N’abandonnez pas encore ! Je vous proposer ici une solution pour venir à bout de ces limitations… plus d’ excuses, vous pourrez tout tester …

la suite par ici en anglais…

Suggestion d'articles :

1. Flex vs Silverlight
2. Formation Silverlight Tour à Paris les 19,20 et 21 janvier
3. Formation Silverlight Tour à Paris – 28, 29, 30 Avril

Voici plus d’un an maintenant que je réalise régulièrement des scripts PowerShell en tout genre.
Dernièrement j’ai pu remarquer que j’utilisais et améliorais continuellement certaines pratiques qui me facilitaient aussi bien le développement de scripts PowerShell que leur correction ou évolution.

Dans cet article (en anglais), je vous présente ainsi ces « bonnes pratiques » que j’ai pu identifier avec le temps.
La suite ici.

Suggestion d'articles :

1. OCTO partage ses bonnes pratiques dans le livre Partageons ce qui nous départage
2. PowerShell : le couteau suisse des administrateurs Windows ?
3. Beckett, la guitare de Jimi Hendrix et les pratiques agiles

L’approche « Behavior Driven Development », ou l’art d’écrire des tests qui décrivent le comportement attendu du système et que tout le monde comprend.

Dans cet article (en anglais), je présente l’architecture mise en place pour suivre cette démarche, dans un projet de développement d’un client lourd sous .NET/WPF, et comment l’utilisation du design-pattern MVVM nous a aidé à atteindre notre objectif.

La suite ici.

Suggestion d'articles :

1. Le Test Driven Development au secours de Javascript !
2. Architecture d’intégration basée sur un pattern Médiateur
3. TDI ou Test Driven Infrastructure

« Rien de très original » me direz vous. Venant d’Apple ou Google ce serait vrai, mais pour Microsoft c’est un énorme pas en avant. Espérons tout de même que ces choix permettent à Microsoft de prendre assez d’avance pour rester concurrentiel sur un marché où les concurrents sortent de nouveaux téléphones (avec un nouveau hardware) tous les 6 mois.

La couleur:

Quelques lignes plus haut, je faisais allusion à l’interface Metro. Microsoft a appris de ses erreurs et change radicalement le paradigme d’interaction avec l’utilisateur. Fini les scrollbars trop petites et les contrôles inspirés du PC. Le design Metro est épuré et centré sur le contenu plutôt que les effets graphiques (« Content, not Chrome »).  Voir une démonstration video de l’interface Windows Phone 7.

Voici les documents officiels de Microsoft expliquant les concepts d’intéraction et de design des Windows Phone (à noter la mise à disposition de modèles Photoshop permettant de créer ses propres contrôles respectant le look-n-feel de la plateforme).

Késacode Windows Phone ?

Tout cela ne pouvait être possible sans rompre avec l’architecture actuelle des Windows Mobile (<6.5), Microsoft a donc pris la décision de revoir entièrement sa copie. Ainsi « exit » les applications dites natives C++, adieu nos habituelles Windows Forms. Pour développer sur Windows Phone 7, il faudra faire du Silverlight ou du XNA (orienté jeux et 3D).

Cela veut donc dire que Microsoft accepte de faire le deuil de la fameuse rétro-compatibilité qui lui été si chère: aucune application Windows Mobile ne sera fonctionnera sur Windows Phone. C’est un choix ambitieux mais qui pourrait choquer certains développeurs.

Voici un schéma des différentes composants logiciels et API disponibles sur Windows Phone.

Silverlight, XNA et .Net CF

Une version plus technique du schéma d’architecture Windows Phone 7 est disponible ici.

Les compétences C# .Net seront partiellement réutilisables pour les couches métiers mais l’apprentissage restera important au niveau IHM, accès aux données (Isolated Storage) et couches de communication pour les nombreux éditeurs qui n’ont pas encore fait le pas du .Net 3.5 et WPF.

Les développeurs profiteront d’un environnement de développement complet et facile à utiliser (Visual Studio, éditeur Wysiwyg, émulateur, …). Le support de Microsoft  est lui aussi largement suffisant pour prendre en main rapidement les API de la plateforme (documentation assez importante et exhaustive).

Ok, je viens de coder ma boîte à meuh, que me reste-t’il à faire ?

Le cycle de vie (from development to cash) d’une application Windows Phone est le suivant:

Cycle de vie des applications Windows Phone

Une fois que votre application a été développée et testée par vos soins via l’émulateur très complet, il faut maintenant la publier sur le Marketplace.

Vous pensez être prêt pour la commercialisation, et si vous faisiez une version d’essai de votre application pour convertir plus facilement vos prospects !
L’API Windows Phone permet de faire du Try & Buy sans avoir à maintenir 2 applications distinctes. La même application (au niveau binaire) puisse servir à la fois de version d’essai et de version complète (via la vérification d’un booléen LicenseInformation.IsTrial), le MarketPlace s’occupera de vérifier la validité de licence et d’autoriser la version complète suite à l’achat.

La publication d’applications nécessite un compte payant ($100/an) qui vous permettra de publier autant d’applications payantes que vous le souhaitez et 5 applications gratuites. Au-delà de 5 , il faudra dépenser $20 pour chaque nouvelle application gratuite. Cela peut paraître bizarre de devoir payer pour publier une application gratuite, mais l’enjeu est simple: dissuader les éditeurs de publier des applications « spam » qui pollueraient les catalogues d’applications (détecteur de mensonges, boîte à prout, lampe torche…)

Vous pourrez ensuite choisir le prix de vente de l’application (par pays) et alimenter le catalogue Marketplace avec une description, des mot-clefs et des captures d’écran de votre application. Une fois en vente, Microsoft ponctionnera 30% des montants générés par la vente de l’application. Des frais tout à fait raisonnable et ne nécessitant pas une refonte du business plan de l’entrepreneur.

Le processus de validation/publication est assez strict et votre application devra répondre à un certain nombre de critères de qualité, de législation et de performance (tous justifiés et atteignables). Voir les Windows Phone 7 Application Certification Requirements pour plus d’informations.

A noter que pour les applications Windows Mobile 6.5, les équipes de certification Marketplace (dont Intertek Systems Certification) lançaient entre autre un générateur de clics aléatoires (Hopper Test Tool) qui permettait d’effectuer un stress-test de votre application pendant plusieurs heures.

Le Windows Phone 7, c’est aussi pour moi ?

Malgré toutes les promesses de Windows Phone 7, l’un des points noirs de cette plateforme pour les entreprises du secteur de l’industrie est qu’elle ne sortira pas sur du matériel à « coque renforcée » ou « sur mesure » (lecteur de code à barres intégré, RFID, connectique série…).

L’utilisateur type d’un Windows Phone est un consommateur lambda (cela inclut les professionnels) mais les techniciens, les spécialistes et les opérateurs ne font pas forcement partie de la cible.

Microsoft et les différents fabriquants (Motorola/Symbol, DataLogic…) continueront donc maintenir les gammes Windows Mobile 6.5, Windows CE, Windows Embedded. Cela passera par une autre modification/homogénéisation du nom de ces gammes mais les développements resteront les mêmes : .Net, C++…

Voir la Communication officielle de Steve Ballmer sur la road map Windows Phone et Windows Embedded.

Pour conclure

Si je n’avais qu’un conseil à donner aux développeurs Windows Mobile, ce serait de regarder dès maintenant la plateforme Windows Phone qui vient de passer en RTM (Release-to-Manufacturing) et dont les premiers téléphones seront disponibles pour le grand public entre octobre et novembre en Europe.

Les outils de développement Windows Phone Developer Tools (actuellement en Beta) sont disponibles gratuitement sur le portail Windows Phone et Microsoft fait beaucoup d’effort pour aider les développeurs à faire  le pas (certains développeurs ont pu recevoir gratuitement un téléphone de test Windows Phone 7). Les Windows Phone Developer Tools contiennent:

• Visual Studio 2010 Express
• Expression Blend pour Windows Phone
• XNA Game Studio
• Emulateur Windows Phone

L’évènement Microsoft Days (du 30 septembre au 3 novembre suivant les villes) sera le lieu idéal pour Microsoft pour présenter sa plateforme à la communauté française des développeurs.

Si l’on regarde le système et la plateforme applicative dans son intégralité, les motivations principales de son architecture sont (texte extrait du blog de Pierre Cauchois, évangéliste Microsoft Mobilité et Embarqué):

• Pour l’utilisateur: une homogénéité, et une intégration efficace des applications dans les différents usages qu’il a de son téléphone. C’est avant tout l’utilisateur qui est au centre de toutes les attentions, qu’elles soient de la part de Microsoft, des opérateurs, des fabricants de téléphones ou des développeurs d’applications tierces.
• Pour le développeur: simplicité et rapidité de développement. Les API sont intuitives et abstraient volontairement la complexité de certains traitements (comme la géolocalisation par exemple) et garantissent que quel que soit l’état du téléphone il se comportera correctement, c’est-à-dire de façon fiable et prévisible afin de garantir la meilleure expérience pour l’utilisateur.

Windows Phone 7 n’en est pour l’instant qu’à sa première version et rien n’est gravé dans le marbre. Il n’est pas impensable que Microsoft accepte de faire évoluer cette plateforme très prometteuse qu’est Windows Phone afin de répondre aux besoins spécifiques du marché grand public et professionnel.

---

Voici quelques liens complémentaires sur les différents sujets de cet article :

• Article intéressant sur l’Ecosystème de développement des applications mobiles sur les différentes plateformes.
• Vue d’ensemble de la plateforme Windows Phone 7 (en anglais)
• Choisir entre Silverlight et XNA (en anglais)
• Comprendre la plateforme Windows Phone 7
• Le blog de Pierre Cauchois : évangéliste Microsoft Mobilité et Embarqué
• L’interface Metro vue par un développeur
• L’ensemble des sessions du MIX2010 sont disponibles gratuitement | Version iTunes (en anglais)
• Webcast [MIX 2010] Windows Phone 7 UI and Design Language | Version iTunes (en anglais)
• Windows Phone pour les professionnels

Suggestion d'articles :

1. N’oublions pas Windows Mobile
2. Et si Microsoft abandonnait la marque Windows ?
3. PowerShell : le couteau suisse des administrateurs Windows ?

Nous avons déterminé dans la première partie que les nombres à virgule flottante sont à proscrire.

Nos armes seront donc le BigDecimal en Java, le type decimal en .Net. Malheureusement, d’autres pièges pavent notre chemin.

Notes:

• Sous Oracle, le type NUMBER(p,s) peut être soit décimal si p (et optionnellement s) est spécifié et sera à virgule flottante sinon. Conclusion, toujours spécifier p (et s pour avoir des décimales).
• Pour un Web Service, la valeur d’un type xs:decimal sera sous forme texte (ie. « 123.456″) et sera donc précis et mappé sans problème vers un BigDecimal (Java) ou decimal (.Net).

Utilisation des décimaux

Littéraux

J’ai souvent le commentaire suivant: « J’aime pas les BigDecimal, on ne peut pas utiliser les opérateurs du langage avec ». C’est vrai, mais en attendant que Java supporte la surcharge d’opérateur (et c’est pas demain la veille), vous n’avez pas le choix, il faut utiliser les méthodes de la classe BigDecimal.

Le respect de la première règle ci-haut proscrit les choses suivantes:

BigDecimal d = new BigDecimal(1.0); // initialisation par un double
BigDecimal d = BigDecimal.valueOf(1.0); // aussi une initialisation par un double
boolean b = (d.doubleValue() == 0.0); // comparaison avec un double
BigDecimal d = BigDecimal.valueOf(d1.doubleValue() * d2.doubleValue()); // passage par un double pour calcul mathématique

remplacer tout cela par

BigDecimal d = new BigDecimal("1.0"); // crée très précisément un BigDecimal de mantisse 10 et d'échelle 1
BigDecimal d = BigDecimal.valueOf(10, 1); // Même résultat que la ligne précédente
boolean b = (d.signum() == 0); // signum compare avec zéro et retourne -1, 0 ou 1. Pour une valeur différente de zéro, faire un compareTo
BigDecimal d = d1.multiply(d2); // tout le calcul se fait en type décimal

Échelle

L’échelle (scale) indique le nombre de chiffres à droite de la virgule. Il faut bien comprendre que deux chiffres apparemment identiques peuvent être en fait différents de par leur échelle. C’est pour cette raison qu’en Java, dans l’exemple ci-dessous, b sera faux

BigDecimal d1 = new BigDecimal("1.0");
BigDecimal d2 = new BigDecimal("1.00");
boolean b = d1.equals(d2); // false

L’échelle a aussi un impact lors d’opérations mathématiques.

Note: L’affichage d’un BigDecimal (d.toString()) affichera toujours l’échelle en entier et non uniquement les zéros significatifs.

Additions et soustractions

L’échelle du résultat d’une addition ou soustraction sera la plus grosse échelle des deux opérandes.

BigDecimal d1 = new BigDecimal("1.0"); // échelle de 1
BigDecimal d2 = new BigDecimal("2.00"); // échelle de 2
BigDecimal r = d1.add(d2); // résultat d'échelle 2
System.out.println(r); // affiche 3.00

Multiplications

L’échelle du résultat d’une multiplication sera la somme des échelles des opérandes (car mathématiquement, le résultat ne sera jamais sur plus).

BigDecimal d1 = new BigDecimal("1.0"); // échelle de 1
BigDecimal d2 = new BigDecimal("2.00"); // échelle de 2
BigDecimal r = d1.multiply(d2); // résultat d'échelle 3
System.out.println(r); // affiche 2.000

Divisions

Tout se complique pour les divisions. En effet, l’échelle théorique du résultat d’une division est potentiellement infinie (si le résultat de la division est un nombre périodique par exemple). C’est très différent de l’arithmétique en virgules flottantes qui stockera, dans sa taille finie, la valeur la plus proche du résultat réel. Vous aurez donc les résultats suivants:

BigDecimal d1 = new BigDecimal("1.0");
BigDecimal d2 = new BigDecimal("3.0");
System.out.println(d1.divide(d2, RoundingMode.HALF_UP)); // affiche 0.3
System.out.println(d1.divide(d2, 4, RoundingMode.HALF_UP)); // affiche 0.3333
System.out.println(d1.divide(d2)); // ArithmeticException

Si la règle d’arrondi n’est pas spécifié, comme le BigDecimal ne peut décider comment arrondir par lui-même, il retourne une exception *et c’est une bonne chose*. En effet, il ne faut jamais arrondir au hasard. Si vous ne savez pas comment arrondir, demandez à votre MOA. L’arrondi est systématiquement lié à une règle métier (ex.: arrondir à la précision de la monnaie). Je vous recommande d’ailleurs de mettre dans vos tests unitaires des chiffres testant l’arrondi pour prévenir les problèmes.

Comparaison

C’est l’un des comportements laissant le plus perplexes les développeurs. Nous en avons parlé plus haut, le equals
du BigDecimal compare aussi l’échelle. Il ne faut donc jamais l’utiliser si l’on souhaite comparer la valeur du BigDecimal. C’est là où compareTo vient à notre secours. Il se comporte comme nous le voudrions intuitivement.

BigDecimal d1 = new BigDecimal("1.0");
BigDecimal d2 = new BigDecimal("1.00");
int i = d1.compareTo(d2); // 0, ce qui veut dire de même valeur selon le contrat de compareTo

À noter: Comparativement à la comparaison entre nombres à virgule flottante, il n’est pas nécessaire d’ajouter un delta lors des comparaisons. Le décimal étant toujours précis, la comparaison sans delta le sera donc aussi.

Conversion

Il faut prendre quelques précautions lors de la conversion d’une BigDecimal vers une valeur entière. En effet, celui-ci arrondira à l’unité. Il est souvent plus sécuritaire de vérifier s’il y a des décimales lors de la conversion. Les méthodes xxxValueExact() ont donc été mise à disposition pour faire très exactement ceci. Une ArithmeticException sera lancée si une conversion sans arrondi est impossible.

BigDecimal d1 = new BigDecimal("1.1");
System.out.println("i: " + d1.intValue()); // affiche 1
System.out.println(d1.intValueExact()); // lance une ArithmeticException

.NET

L’article s’est pour l’instant beaucoup penché sur Java. L’équivalent .Net du BigDecimal est le decimal. De même qu’en Java, il doit être utilisé en tout temps au lieu du float et double.

Littéraux

Le type decimal étant un type primitif de .Net, C# fournit une syntaxe littérale pour ce dernier (suffixe m). Les zéros non significatifs sont utiles pour déterminer l’échelle.

decimal d = 99.9m; // le m indiquant qu'il s'agit d'un décimal
decimal b = 9.00m; // decimal d'échelle 2

Il est d’ailleurs judicieusement nécessaire de convertir explicitement d’une virgule flottante à un décimal.

decimal a = (decimal) 9.0; // conversion explicite nécessaire et perte de précision potentielle. À ne pas faire!

Calculs mathématiques

Être un type primitif a d’autres avantages, les calculs mathématiques sont plus élégants qu’en Java.

decimal d = 1.0m * 2.0m; // +, -, /, * et % sont utilisables
decimal b = decimal.Multiply(1.0m, 2.0m); // l'équivalent en méthode statique est aussi disponible

La division n’a pas besoin et ne peut avoir de règle d’arrondi. Elle fera au mieux dans les 96 bits d’espace. Il ne faut toutefois pas oublier qu’un arrondi sera éventuellement nécessaire et sera comme toujours guidé par une règle métier.

Comparaison

Comparativement à Java, le compare et le equals donne le même résultat peut importe l’échelle. C’est beaucoup plus intuitif, mais implique qu’il est impossible de comparer en voulant considérer l’échelle.

Console.WriteLine(decimal.Compare(1.00m, 1.0m)); // affiche 0, donc égal
Console.WriteLine(1.0m.CompareTo(1.00m)); // autre façon de comparer, retourne aussi 0
Console.WriteLine(1.0m.Equals(1.00m)); // affiche true

Il est d’ailleurs impossible de connaître l’échelle d’un décimal facilement en .Net. Pour avoir l’échelle, il faut faire ceci:

int scale = (System.Decimal.GetBits(monDecimal)[3] >> 16) & 31; // oui oui, ça s'invente pas

ou passer par un ToString, trouver le séparateur décimal (en fonction de la culture) et compter le nombre de chiffres à sa droite.

Conversion

Au niveau conversion, il existe des méthodes ToXXX permettant la conversion vers un autre type. Le concept de ToXXXExact n’existe pas. Il faut donc s’assurer au préalable qu’il n’y aura pas de perte de précision. Une solution possible est ceci:

decimal toInt = 1.1m;
int i = decimal.ToInt32(toInt);
Console.WriteLine(toInt.Equals(new decimal(i))); // n'est pas égal, car nous avons perdu les décimales

Conclusion

Le but n’est pas de comparer, mais vous l’aurez compris

• La version Java demande de bien comprendre son implémentation, mais sévi en cas de mauvaise utilisation
• La version .Net se veut plus conviviale, mais est donc plus permissive et rend plus compliqués certaines opérations.

Mais peu importe le langage, les choses importantes à retenir se résument à

• Ne pas utiliser de types à virgule flottante pour représenter des décimaux
• Avoir en tête qu’en informatique de gestion tous les nombres ou presque sont des décimaux
• Penser aux arrondis et les faire suivant une règle métier
• Bien avoir en tête les spécificités du langage avant utilisation

Une seule nuance à ces règles. Il est possible que pour des raisons de performance vous deviez utiliser des nombres à virgule flottante. Par exemple, dans le cadre du simulation de Monte-Carlo. Je ne peux dans ce cas que vous recommander de bien vous documenter sur la manipulation des nombres à virgule flottante. Il existe de nombreuses méthodes pour minimiser les problèmes mais le tout reste relativement complexe et sors du cadre de cet article.  Ne les utilisez donc qu’en dernier recours.

En conclusion, appliquez ces règles religieusement et vous devriez être parés pour éviter les soucis de calcul de vos futures applications d’entreprise. Je vous souhaite de précis calculs et vous dis à la prochaine.

Suggestion d'articles :

1. Problèmes courants: Imprécision des calculs mathématiques (1ère partie)
2. Livrer plus vite. Des pistes issues des mathématiques.
3. Refactoring .NET avec UML, 1ère partie