Génération de diagrammes UML à partir d'une analyse dynamique

Repond, Julien ; Dugerdil, Philippe (Dir.)

Mémoire de bachelor : Haute école de gestion de Genève, 2009 ; TDIG 38.

La réingénierie logicielle est devenue un des principaux outils de compréhension des systèmes existants mis en oeuvre lors de la phase de maintenance. Les ingénieurs logiciels requièrent essentiellement à des analyses, dites statiques, qui utilisent le code source du logiciel pour en reconstruire ses modèles et sa documentation. Nous nous focalisons sur l’architecture actuelle, telle... Plus

Ajouter à la liste personnelle

Autres fichiers

    Résumé
    La réingénierie logicielle est devenue un des principaux outils de compréhension des systèmes existants mis en oeuvre lors de la phase de maintenance. Les ingénieurs logiciels requièrent essentiellement à des analyses, dites statiques, qui utilisent le code source du logiciel pour en reconstruire ses modèles et sa documentation. Nous nous focalisons sur l’architecture actuelle, telle qu’elle a été pensée par les concepteurs, sans tenir compte de sa réelle utilisation. Il n’y a par conséquent aucune comparaison avec l’exécution du programme pour évaluer si l’architecture convient au réel emploi. Une autre approche, l’analyse dynamique, tend à s’appuyer sur les informations résultantes de l’exécution des services comme les indicateurs de performances, les interfaces de monitoring fournies par l’environnement d’exécution ou encore les traces d’exécution. A la différence des techniques statiques, nous étudions les processus en cours de réalisation pour reproduire des modèles d’architecture fonctionnels. Dans mon mandat, j’ai été amené à poursuivre les travaux réalisés sur un analyseur de trace d’exécution (Dugerdil, Jossi, 2009). Cet analyseur apporte une approche originale pour restituer les modèles d’un programme : utiliser une analyse statistique de la trace, basée sur la segmentation de celle-ci, pour produire des regroupements fonctionnels de classes triées grâce à leur facteur de corrélation, leur couplage. Premièrement, l’avantage d’utiliser les traces d’exécution pour produire ce résultat, est de se détacher d’un quelconque environnement d’exécution. La matière première de l’analyse, la trace, est indépendante du langage de développement et de tous les outils s’y référant. De plus, ces ensembles de classes corrélées, nommés clusters, fournissent une architecture fonctionnelle élaborée en observant le comportement réel du programme. Dès lors, une évolution naturelle de l’analyseur pour aboutir l’analyse est de fournir un moyen de comparaison graphique de ses clusters avec l’architecture initiale pour pouvoir évaluer la pertinence de cette dernière et entreprendre des modifications, ainsi que de représenter les flux d’information de la trace. Ce que nous entendons par la représentation des flux d’information, c’est produire un graphique montrant le déroulement d’une fonctionnalité de l’application, l’échange de messages entre les objets durant l’exécution. Mon travail a ainsi porté sur la réalisation de ces deux évolutions. Concernant le premier point, l’idée initiale était de représenter les composants fonctionnels résultant de l’analyse, les clusters, dans un format d’échange standard, XML Metadata Interchange (XMI). Le modèle pourrait ainsi être inséré dans un logiciel de modélisation afin de déléguer la représentation graphique à ce dernier. J’ai étudié les langages de modélisation, Unified Modeling Language (UML), et de métamodélisation, Meta-Object Facility (MOF) et Eclipse Modeling Framework (EMF), ainsi que le format d’échange de modèle. Le manque de ressources pour la manipulation du format XMI et les limites de ce dernier dans le domaine de la représentation graphique m’ont incité à interagir immédiatement avec un environnement de modélisation extensible, Rational Software Architect (RSA). Ce choix m’a tout d’abord contraint à migrer l’analyseur original dans la même technologie que l’outil de modélisation, l’environnement de développement Eclipse, pour ensuite implémenter la fonctionnalité de comparaison de l’architecture fonctionnelle avec l’architecture initiale. La suite de mon mandat s’est concentrée sur la représentation graphique des flux d’informations d’une trace d’exécution. Au sein de la méthodologie UML, c’est un des rôles du diagramme de séquence de fournir une représentation de ces flux. La principale problématique a été de donner une vue simplifiée mais pertinente de ces flux, malgré les millions d’appels pouvant constitués une trace. J’ai débuté par une analogie entre les éléments présents dans la trace et leur représentation dans un diagramme de séquence. Ensuite, j’ai étudié divers travaux portant sur les procédés de simplification d’une trace et tenter de voir dans quel mesure je pouvais les appliquer à mon cas de figure. J’ai finalement implémenté la fonctionnalité de génération d’un diagramme de séquence représentant les interactions entre les éléments de la trace. Pour ce faire, j’ai retenu certaines techniques de simplification que j’ai adaptées au contexte. J’ai terminé par une étude de cas pour évaluer l’efficacité des fonctionnalités et leur utilisabilité.