Calcul des métriques dans Eclipse

Pour être en mesure de montrer des informations visuelles aux utilisateurs, il y a une première étape cruciale qui est celle de traiter les informations brutes pour qu’elles soient représentatives et utiles dans une analyse. De façon classique, les outils de visualisation ou d’analyse automatique utilisent des données générées au préalable. Ce principe est aussi inscrit dans la mouvance de faire les analyses dans une phase à part, souvent après que le produit a été déployé pour évaluer la qualité d’un produit fini. Dans ce cas, il est plus pertinent et beaucoup plus simple de récolter des données sur un produit à un moment fixé dans le temps. De cette façon, chacune des visualisations donnera assuré- ment les mêmes résultats pour un même échantillon de données. Par contre, cette façon de voir les choses n’est pas applicable à une intégration d’un système de visualisation. Nos besoins impliquent que les données pour l’analyse soient traitées pendant que les utilisateurs effectuent leurs changements justement pour leur permettre de voir à quel point les changements sont pertinents.

Pour permettre aux utilisateurs de voir les changements aussitôt qu’ils sont effec- tués, il faut évidemment calculer les nouvelles informations en temps réel. En effet,

71 dans VERSO, à chaque fois que les utilisateurs sauvegardent les modifications qu’ils ap- portent à un logiciel, VERSO recalcule les métriques et les sauvegarde dans un modèle représentant le logiciel selon une série de métriques jugées pertinentes à travers diffé- rents domaines, dont la qualité, les informations sur le contrôle de versions, les bogues, etc. En réalité, ce modèle interne est composé de toutes les entités d’un logiciel, de leur hiérarchie, de leurs relations et d’un vecteur de métriques associé à chaque élément. Ce modèle est générique et peut être utilisé par n’importe quel système automatique ou semi-automatique d’analyse comme une visualisation de logiciel. D’ailleurs, VERSO possède déjà une manière de stocker les métriques dans un fichier texte où elles peuvent être analysées par un humain ou un ordinateur. De plus, de par sa nature, le modèle est facilement extensible, car il s’agit seulement d’ajouter de nouvelles métriques au vecteur. Le calcul nécessaire pour obtenir les métriques est souvent simple, mais, pour cer- taines métriques, le calcul est plus complexe et demande du temps. C’est entre autres le cas de la métrique de couplage CBO [12] (O(N2_{)) qui se doit de parcourir tous les élé-}

ments et tous les liens vers d’autres éléments pour chacune des classes. C’est pourquoi certaines stratégies doivent être adoptées pour réduire toute latence des utilisateurs dans leur démarche d’analyse.

Dans un premier temps, seulement la portion modifiée est traitée. Le calcul des mé- triques est donc incrémental tout comme les modifications du code qui s’ajoutent tou- jours sur une base déjà présente. Une autre stratégie est d’effectuer certains calculs en arrière-plan dans un autre fil d’exécution, entre autres, les calculs relatifs à l’accès des systèmes de contrôle de versions, car l’accès aux bases de données externes à travers internet est souvent trop lent. Ceci permet aux utilisateurs de continuer à travailler sans affecter leurs tâches directement. Souvent, une fois qu’ils sont prêts à regarder les résul- tats, la visualisation est déjà mise à jour. Sinon, elle s’adapte au fur et à mesure que les informations deviennent disponibles. Cette stratégie est aussi très utile quand les utilisa- teurs téléchargent un nouveau logiciel d’une taille appréciable et qu’ils veulent calculer les données tout en commençant à travailler.

Pour arriver à calculer des informations précises et obtenir ces informations dans des temps assez courts pour que les utilisateurs ne soient pas gênés, nous utilisons le

modèle interne d’Eclipse. En effet, Eclipse fait déjà une grande partie du travail pour arriver à gérer ses propres outils de référence à l’intérieur du code et la compilation au- tomatique des programmes. Ainsi, Eclipse permet la complétion automatique, l’accès à une définition, ou encore l’accès aux appels d’une méthode à partir de sa définition. De plus, par différentes librairies, Eclipse donne accès à ces informations et à l’arbre syn- taxique des logiciels. Ceci donne deux avantages marqués pour l’analyse statique dont nous avons besoin pour calculer les métriques. Dans un premier temps, les programmes Java sont déjà lus et interprétés pour nous et l’accès aux sous-sections de l’arbre syn- taxique est facilité par des outils de parcours de graphes intégrés au modèle d’Eclipse. Dans un deuxième temps, une inférence de type statique est déjà effectuée et permet d’avoir accès facilement à tous les éléments dans la hiérarchie. Ceci représente en effet une économie considérable de temps et évite de refaire des outils complexes alors qu’ils ont déjà fait leurs preuves. De plus, les outils fournis par le noyau d’Eclipse permettent de développer une architecture qui est facilement extensible. L’accès au code étant basé sur le patron de conception visiteur [30] sur l’arbre syntaxique, l’ajout d’une nouvelle métrique consiste uniquement à ajouter des visiteurs et à faire le décompte de différents éléments visités. De plus, le mécanisme de sauvegarde d’Eclipse peut être utilisé pour recalculer les nouvelles métriques. En effet, la section sauvegardée peut être « attrapée » par une méthode et il est possible de recalculer les métriques seulement pour la section qui a été modifiée.