Enterprise Architect is mainly used as a modelling tool to define and maintain a structured set of models based on standard languages or notations such as UML, BPMN, SysML, or ArchiMate.

Enterprise Architect includes several features to fulfill other needs, associated with functional, business, design, or architecture aspects. This article illustrates the use of Enterprise Architect Execution Analyzer to capture and record method calls between instances of implementation classes during code runtime. A method call recording feature can be enabled:

• to visualize and analyze interactions i.e. invoked methods between instanciated implementation classes,
• to document implementation classes,
• to understand a software or application behaviour,
• as an option to identify reasons for bugs when static code analysis hasn't been satisfying.

Note: static code analysis can be carried on the source code from the IDE, whereas dynamic code analysis is carried in a runtime environment.

Context

More and more complex technical architectures are defined for projects, with several heterogeneous software components communicating via their interfaces or services, and design patterns such as Dependency Injection can be applied to load modules or objects at run time, preventing any analysis at compile time.

Investigating bugs in such context on a production environment can be difficult. Source code analysis from the IDE may not be the right place to find solutions. This is exactly a case that one of my clients came across; Enterprise Architect Execution Analyzer feature offered an interesting and innovative approach enabling dynamic code analysis via method call recording. This could potentially lead to identify details surrounding a random software bug. In this specific case, as the issue was not related with the code itself, the Execution Analyzer hasn't identified any clue.

This article illustrates how to configure and use this feature in Sparx Enterprise Architect 12. As an example, I selected an Enterprise Architect add'in project I'm currently working on. The technical environment involves a Visual Studio 2012 C# solution. The Execution Analyzer also works with other technical environments such as Java or C++.

Setting up a suitable workspace

The Execution Analyzer involves the use of several views which can be enabled from the Analyzer menu:

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

Once all the mentioned views have been displayed in your Enterprise Architect workspace, this configuration can be saved from the menu View > Perspectives > Save as New.

Configuring the Execution Analyzer

Importing the source code with reverse engineering

Start with importing the source code in the Enterprise Architect project:

• Create a package and run Code Engineering > Import Source Directory.
• Select C# and the folder that contains the source code.

• Packages and implementation classes resulting from the reverse engineering are visible from the Project Browser.

Create a local path for the IDE

To easily access and run Visual Studio IDE files, the local path %VS2012% has been defined via the menu Tools > Local Directories and Path:

Create an Execution Analyzer Script

Right click on the root package where implementation classes have been imported, and select Execution Analyzer; the dialog box below is displayed. Click on Yes to generate an Execution Analyzer script on this package.

The Execution Analyzer script properties are displayed. Configure the source code compilation from the Build tab:

• The command line need to match the following example:
  • "%VS2012%\devenv.com" /build Debug myapp.sln
• Default directory: source code location
• Parse Output: Microsoft .NET
• Exec Command as: Batch File
• These settings will be used by Enterprise Architect to build the C# solution.

Select the Clean tab and provide the same information as previously (Build), and replace "/build" with "/clean" in the command line:

• "%VS2012%\devenv.com" /clean Debug myapp.sln
• These settings will be used by Enterprise Architect to clean the C# solution.

Open the Debug\Platform tab, and provide the following information:

• Debugger: Microsoft.NET
• Select Run
• Default directory: location for compiled binary files
• Application path: application to launch
• These settings will be used by Enterprise Architect to start the applicatin in debug mode (in the case of an add'in, Sparx Enterprise Architect is launched).

Open the Debug\Workbench tab:

• The following properties can be entered e.g. by selecting a DLL file, so that implementation classes can be instanciated from Enterprise Architect (this feature is not used in the current article).

Define breakpoints

As the source code can be opened in Enterprise Architect, breakpoints can be defined like in Visual Studio or any other IDE. Once a breakpoint is reached during the runtime, the application is suspended, pending any user action in Enterprise Architect, acting like an IDE since it builds and debugs the application.

Enterprise Architect supports a specific type of breakpoints: Recording Markers, described below. 

• Open the source code from a class in the Project Browser (select the class > F12)
• Enterprise Architect internal code editor opens the source code file associated with the class, e.g. src\Main.cs

• A right click on a line in the source code can be used to insert a Breakpoint > Add Start/End Recording Marker

• Add Start Recording Marker indicates that Enterprise Architect must start recording the method calls
• Add End Recording Marker indicates that any active recording must end (optional)
• In the following example, two recording markers have been added: start recording on line 114, and stop on line 118.
• Once a start recording marker is reached, method calls are recorded in the project. This data can be used after exiting the debug mode to generate UML sequence diagram.

Build with the Execution Analyzer

Important: Windows 7 usually requires to starts Enterprise Architect as an Administrator so the Build can be run without any error.

Select and right click on the the Execution Analyzer script (configuration) > Build, or click on Build Current Package :

The System Output view displays results to confirm if the build has been successful (content should be identical to a Build run in Visual Studio).

Debug with the Execution Analyzer

To start the Debug from Enterprise Architect, select and right click on the script > Debug.

A new instance of Enterprise Architect is launched in order to run tests on the add’in (other types of applications will be launched in debug mode).

Use the add’in to reach a start recording marker e.g. by displaying the About window.

On the Start Recording Marker is reached, Enterprise Architect starts recording method calls. Note that the add'in execution can be more or less slowed down due to the recording processing performed by Enterprise Architect. This show down can be relative on the analysed application.

Additional add'in features can be tested to reach the Stop Recording Marker.

Display the Record and Analyze view to show all recorded method calls, listed under a sequence of interactions.

Each interaction has two "Method" columns: the first displays the current class and method whereas the second one displays the invoked class and method, alongside parameters. A double click on one of the interactions opens the invoked method in the source code, e.g. gui.About.About invoked from Mail.EA_MenuClick:

A right click on the whole sequence will generate a UML sequence diagram with the recorded data.

Note: number 15 in the above screenshot defines the depth level to record calls. This can be modified according to analysis requirements.

The following dialog is shown to optionally rename and confirm the sequence diagram to create in the modelling project:

An illustration of the generated diagram is shown below. Colours and comments have been added following the carried analysis.

The above diagram shows a scenario of executing the code according to the deployed version in the runtime environment. This diagram and the implementation class model generated using the reverse engineering can be associated with other modelling elements, such business classes, processes, or requirements.