4 LES TRAVAUX CONNEXES
4.1 Réalisation d'un plugin Eclipse
Durant la réalisation de ce mémoire, j'ai eu
à encadrer le stage en entreprise d'un étudiant en Master 2 en
Informatique, spécialité architecture logicielle de
l'université de Nantes. L'objectif de son stage était la
réalisation d'un plugin Eclipse permettant de suivre l'avancement de
l'intégration des projets de migration. Cet outil de suivi est
centré sur la base de cartographie à laquelle des notions de
suivi ont été greffées, et sur l'analyse des codes sources
en cours d'intégration.
Dans le processus classique de migration, les scripts de
génération des méthodes et des classes ont
été modifiés afin d'intégrer deux types de balises
:
· Une balise identifiant qui ne doit pas être
supprimée.
· Des balises de début et de fin de
méthode.
Elles ont toutes comme information principale l'«
elementKey », leur identifiant en base. Lorsque l'intégrateur
commence à travailler sur une méthode, il supprime la balise de
début.
La méthode est alors reconnue comme étant en
cours d'intégration. Ensuite, lorsque l'intégrateur estime qu'il
a terminé sa méthode, il supprime la balise de fin. La
méthode passe alors en statut terminé. Si on prend pour exemple
une méthode qui contient dix lignes de code et qui a ses balises de
début et de fin, elle comptera pour zéro ligne
intégrée. Avec cette même méthode, si la balise de
début a été supprimée, elle comptera pour cinq
lignes intégrées. Et enfin si cette méthode n'a plus ni
balise de début ni balise de fin, elle comptera pour l'ensemble de ses
lignes de code, donc pour dix lignes intégrées. Ensuite, pour
connaître le niveau d'intégration de la classe, on calcule le
rapport entre le nombre de lignes de code intégrées et le nombre
de lignes de code total. Certes, ce mécanisme assez basique, laissant
des actions manuelles à la charge des intégrateurs n'est pas
parfait. En effet, la plupart des erreurs proviennent justement de ces
interventions humaines. Mais il permet tout de même d'avoir sur
l'ensemble de l'application une idée assez précise de
l'avancement de l'intégration.
CNAM de Nantes - 2010 / 2011 - Mémoire
d'ingénieur
|
|
|
Figure 31 : Copie d'écran de la page Html du taux de
couverture de l'application LV
Figure 32 : Copie d'écran de la page HTML
détaillant le code d'une méthode de l'application LV
CNAM de Nantes - 2010 / 2011 - Mémoire
d'ingénieur
|
|
|
4.2 Instrumentation
J'ai réalisé une suite d'outils permettant
d'injecter du code dans des applications Visual Basic. L'objectif de ces
injections est de produire des traces au format XML qui seront
interprétées puis insérées dans la base de
cartographie.
4.2.1 Taux de couverture
Le taux de couverture des tests de références est
calculé de la manière suivante :
· On ajoute un appel à une méthode de
comptage pour chaque ligne de code. Chaque appel prend en paramètre un
compteur qui devient son identifiant. Dans le même temps, on
insère dans une table de base de données une ligne correspondant
à la ligne de code traitée, avec bien sûr le même
identifiant.
· Ensuite, lors de l'exécution de l'application
instrumentée, après chaque ligne de code, il y aura l'appel
à la fonction de comptage. Cette dernière peut selon un
paramétrage, soit produire une trace XML donnant la liste des lignes
appelées, soit mettre à jour directement la ligne correspondant
à son identifiant en base.
· Au final, on se retrouve avec une table contenant
l'ensemble des lignes de l'application, et pour chacune d'elle, un indicateur
spécifiant si elle a été utilisée lors de
l'exécution ou non. De simples requêtes suffisent ensuite pour
connaître le taux de couverture24.
J'ai aussi développé un outil produisant un
site web statique permettant de mieux visualiser le taux de couverture (cf.
Figure 31). La première version de l'outil de couverture était
d'une certaine manière plus « intelligente » car elle
n'ajoutait pas d'appels à chaque ligne de code, mais uniquement au
début des méthodes et dans chaque branche (conditions, boucles),
en indiquant le nombre de lignes de code de chaque bloc. La Figure 32
démontre la nécessité d'instrumenter toutes les lignes de
l'application.
En effet, ici si l'instruction «
CommonDialog.ShowPrinter » provoque une erreur, le reste des lignes
jusqu'au traitement d'erreur ne sera pas exécuté. Or, avec la
logique précédente, dès l'entrée dans la
méthode, l'ensemble des lignes se trouvant hors d'une condition ou d'une
boucle, aurait été considérées comme
passées, ce qui est faux, puisque la gestion d'erreur force le
débranchement jusqu'à la balise « ErrHandler: », donc
les lignes 1013 à 1018 n'ont pas été
exécutées.
24 100 . nombre de lignes utilisées
nombre de lignes total
).
Taux de couverture : (
CNAM de Nantes - 2010 / 2011 - Mémoire
d'ingénieur
|
|
|
Figure 33 : Diagramme de séquence d'appels à
l'opération « SdfCartography »
de la classe «
SdfMigration ».
CNAM de Nantes - 2010 / 2011 - Mémoire
d'ingénieur
|
|
|
| 
