Enterprise Architect est principalement connu comme outil de modélisation pour établir des modèles structurés en s’appuyant sur des langages ou notations standards tels qu’UML, BPMN, SysML, et ArchiMate.

Ses nombreuses fonctionnalités permettent de répondre à bien d’autres besoins, que ce soit pour des aspects fonctionnels et métier, de conception, ou d’architecture. Cet article présente la fonction Execution Analyzer d’Enterprise Architect qui permet de générer les appels de méthodes en instances de classes d'implémentation lors de l’exécution du code. Une fonction d'enregistrement des appels de méthodes peut être activée :

• afin de visualiser et d’analyser ces interactions,
• pour documenter les classes d’implémentation,
• pour comprendre le fonctionnement d’un logiciel ou d’une application existante,
• comme piste pour identifier l’origine de bugs lorsque l’analyse du code n’est pas suffisante.

Problématique

Les architectures techniques mises en place sont de plus en plus complexes : de nombreuses briques logicielles communiquent via les services qu’elles exposent, des patterns comme l’inversion de contrôle et l’injection de dépendances sont appliqués afin de charger les modules dynamiquement lors de l’exécution du code.

Dans ce contexte, l’analyse de bugs sur une plateforme en production peut rapidement devenir fastidieuse. En effet l’accès au code source ne permet pas toujours d’en identifier l’origine. C’est précisément le cas de figure que l’un de mes clients a rencontré ; la fonction Execution Analyzer d’Enterprise Architect présentait alors l’intérêt d’enregistrer les appels de méthodes entre classes instanciées pendant l’exécution de l'application afin d’identifier l’origine d'erreurs déclenchées aléatoirement. Dans ce cas précis, l'Execution Analyzer n'a pas abouti à l'identification du problème traité par la suite.

Cet article présente la mise en place de cette fonctionnalité avec Enterprise Architect 12. Pour illustrer le fonctionnement de l’Execution Analyzer, j’ai utilisé le code source d’un add’in C# pour Enterprise Architect sur lequel je travaille actuellement. L'environnement technique porte donc sur une solution dot net C# avec Visual Studio 2012. L’Execution Analyzer fonctionne également avec d’autres environnements de développement tels que Java et C++.

Environnement de travail

L’Execution Analyzer comprend plusieurs vues pouvant être affichées via le menu Analyzer :

• Manager Analyzer Scripts
• Debug > Debugger
• Breakpoints and Markers

Une fois l’ensemble des vues affichées et organisées dans l’espace de travail, leur configuration peut être enregistrée via le menu View > Perspectives > Save as New.

Execution Analyzer : configuration

Importer le code source (retro-ingénierie)

La première étape consiste à importer le code source dans le projet Enterprise Architect :

• Créer un paquetage et exécuter la commande Code Engineering > Import Source Directory
• Sélectionner C# et le répertoire qui contient le code source

• Une fois le projet importé, l’ensemble des paquetages et classes d’implémentations sont visibles dans le Project Browser

Créer un chemin local vers l’IDE

Afin de faciliter l’accès aux fichiers de l’IDE Visual Studio, la variable locale %VS2012% a été définie à partir du menu Tools > Local Directories and Path, comme illustré ci-dessous :

Définir un Script Execution Analyzer

Lancer un clic droit sur le paquetage créé et sélectionner Execution Analyzer ; le message suivant est affiché. Cliquer sur Oui afin de générer un script « Execution Analyzer » sur ce paquetage.

La fenêtre de configuration du script est affichée.

Configurer la compilation du code (Générer/Build) dans l’onglet Build :

• La ligne de commande doit correspondre à l’exemple suivant :
  • "%VS2012%\devenv.com" /build Debug myapp.sln
• Default directory = répertoire du code source
• Parse Output = Microsoft .NET
• Exec Command as  = Batch File

Ouvrir l’onglet Clean et renseigner les mêmes informations que dans le Build et remplacer « /build » par « /clean » dans la ligne de commande :

• "%VS2012%\devenv.com" /clean Debug myapp.sln

Ouvrir l’onglet Debug\Platform et renseigner les informations suivantes :

• Debugger : Microsoft.NET
• Sélectionner Run
• Default directory : répertoire où se situent les fichiers binaires
• Application path : l’application à lancer (dans cet exemple, Enterprise Architect est lancé afin d’exécuter l’add’in en mode debug)

Ouvrir l’onglet Debug\Workbench :

• Ces propriétés peuvent être utilisées pour sélectionner un fichier, par exemple une DLL, permettant d’instancier une classe depuis Enterprise Architect (cette fonction n’est pas utilisée dans cet article).

Définir les points d’arrêt (breakpoint)

Tout comme avec une IDE, des points d’arrêt ou « breakpoints » peuvent être ajoutés dans une ou plusieurs lignes du code. Lorsqu’une ligne avec un point d’arrêt s'apprête à être exécutée, le programme passe en pause et l’IDE, Enterprise Architect dans le cas actuel, permet de visualiser par exemple la valeur des variables.

La particularité proposée en complément par Enterprise Architect consiste à définir des points d’arrêts d’enregistrement afin d’enregistrer dans un diagramme de séquence UML les appels de méthodes entre instances de classes d’implémentation. 

• A partir du Project Browser EA, ouvrir le code d’une classe issue de la retro ingénierie (sélection de la classe > F12)
• L’éditeur de code interne à Enterprise Architect ouvre le fichier source associé à la classe (ex : src\Main.cs)

• Le menu contextuel (clic droit) permet d’insérer des points d’arrêts dans le code : clic droit dans une ligne du code > Breakpoint > Add Start/End Recording Marker

• Add Start Recording Marker indique à Enterprise Architect de lancer l’enregistrement des appels de méthodes
• Add End Recording Marker indique à Enterprise Architect d’arrêter un enregistrement en cours (optionnel)
• Dans l’exemple suivant, deux points d’arrêt ont été définis : l’enregistrement commence lorsque la ligne 114 a démarré, et s’arrête lorsque la ligne 118 est atteinte.

Execution Analyzer : build

Important : avec Windows 7, il peut être nécessaire de lancer Enterprise Architect en tant qu’administrateur afin de permettre au Build de s’exécuter sans erreur.

Sélectionner le script défini, clic droit > Build, ou cliquer sur Build Current Package :

La vue System Output permet de vérifier si la génération a été exécutée sans erreur (le contenu est identique à celui obtenu via un Build sous Visual Studio).

Execution Analyzer : debug

Pour lancer le débogueur à partir d’Enterprise Architect ; sélectionner le script, clic droit > Debug.

Une nouvelle instance d’Enterprise Architect se lance afin de réaliser les tests de l’add’in (pour une application autre qu'un add'in EA, celle-ci est lancée en mode debug).

Utiliser l’add’in afin d’atteindre l’un des points d’arrêts/enregistrements, par exemple pour afficher la fenêtre About My add’in.

Dès que le premier point d'enregistrement est atteint, EA enregistre les appels de méthodes. A noter que l’exécution de l’add’in peut être ralentie en raison de l’enregistrement des appels de méthodes par le débogueur sous Enterprise Architect. Ce ralentissement est relatif au projet exécuté.

Une fois l’exécution de la fonction de l’add’in terminée, une seconde fonction peut être testée avant de sortir du mode debug.

Afficher la vue Record and Analyzer ; l’ensemble des appels de méthodes via les fonctions utilisées sont présentées sous une séquence.

Chaque interaction comporte deux colonnes « Method » : la première correspond à la classe et méthode en cours, et la seconde correspond à la classe et méthode appelées avec les paramètres. Un double clic sur une interaction ouvre la méthode appelée dans le code source, par exemple gui.About.About appelé depuis Mail.EA_MenuClick :

Un clic droit sur la séquence complète permet de générer un diagramme de séquence UML à partir de ces enregistrements.

Remarque : le nombre « 15 » affiché dans la fenêtre indique la profondeur maximum d’enregistrement des appels. Celle-ci peut être limitée ou augmentée selon les besoins d’analyse.

La fenêtre suivante propose le nom de l’interaction UML à créer sous l’élément ou le paquetage sélectionné à partir du project browser :

Un extrait du diagramme de séquence obtenu est présenté ci-dessous. Ce diagramme a été mis en forme et annoté via des commentaires issus de l’analyse des échanges enregistrés.

Dans le cas présent, ce diagramme contient un exemple d’exécution du code correspondant à la version déployée et à l’environnement d’exécution utilisé. Ce diagramme peut être annoté afin de documenter l’enchaînement des interactions, ou dans le cas d’une anomalie identifiée, son origine.

Ce diagramme et le modèle de classes d’implémentations issues de la retro-ingénierie peut alors être complétés par d’autres éléments du référentiel de modélisation, en les associant avec des classes métiers correspondantes, des exigences fonctionnelles...