How it Works

Usage

The Visual Execution Analyzer enables you to generate a Sequence Diagram by recording the live execution of an application. As the application runs, the history of each thread is recorded. This history can be used to generate Sequence Diagrams.

A sequence diagram generated from a program that calculates the price of books.

How does the recorder know what to record?

The recorder works off recording markers. These are placed by you in the functions of interest.

Call stacks in Java can stretch further than the eye can see. How can we restrict the recording to just ten frames?

The recorder is controlled by the depth set either on the recorder toolbar or associated with a markers set stored in the model.

Its the real thing.

In recording, the target application is not modified; no instrumentation of any image or module occurs at all. A recording produced using a 'Release' build of a program is as trustworthy a document as any of what a program did.

Where do you start

So we have a very large server application. Where do we start. If you have little or no understanding of the program you wish to record and little or no model to speak off, you might be best starting with the Profiler. Running the Profiler whilst using a program in a specific manner can quickly identify Use Cases from the entry points and call graphs presented. Having that knowledge can enable you to focus in on areas that are uncovered and record those functions.

If you have the source code, all you need to do is place a recording marker in a function that interests you. We recommend against placing multiple recording markers in multiple functions at the same time. In practice this has shown to be less helpful. Where do you place a recording marker? For windows UI programs, and in relation to some business use case, You might start by placing one in the event handlers for a message that seems most pertinent. If you are investigating a utility function just set an method recording marker, at or somewhere near the start.

For services, demons and batch processes you might want to profile the program once for each behavior of interest and use the report to explore those areas uncovered.

Tip

Its a good idea to have a quick glance at the Breakpoints and Markers window before debugging and check the markers listed here are what you are expecting.

Scenarios

• Microsoft Native C and C++, VB

(Windows programs, Window Services, Console programs, COM servers, IIS ISAPI modules, Legacy)

• Microsoft .NET

(ASP.NET, Windows Presentation Foundation (WPF), Windows Forms, Workflow Services, devices, emulators)

• Java

(Apps, Applets, Servlets, Beans)

• Android

(using Android debug bridge for devices and emulators)

• PHP

(Web site scripts)

• GDB

(Windows / Linux interopability)