Gagne de la cryptomonnaie GRATUITE en 5 clics et aide institut numérique à propager la connaissance universitaire >> CLIQUEZ ICI <<

4.1 Réalisation d’un plugin Eclipse

Non classé

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.

Figure 31 Stratégie de test au sein du processus d’évolution d’architecture de SodifranceFigure 31 : Copie d’écran de la page Html du taux de couverture de l’application LV

Tableau 2 Stratégie de test au sein du processus d’évolution d’architecture de SodifranceFigure 32 : Copie d’écran de la page HTML détaillant le code d’une méthode de l’application LV

Page suivante : 4.2 Instrumentation

Retour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance