A Visual Trace Analysis Tool for Understanding Feature Scattering

Victor Sobreira, Marcelo de Almeida Maia Computer Science Departament

Federal University of Uberlândia, Brazil victor.sobreira@gmail.com, marcmaia@facom.ufu.br

Abstract

This work proposes a tool for understanding feature scattering through the graphical visualization of the intersection between features and source code. The tool collects trace events of multi-threaded programs for selected features and shows matrices that help analyzing where those features are implemented. Our claim is that the tool reduces the effort to identify where features are implemented and which source code is specific to a feature. 1. Introduction

Traceability from requirements to code artifacts is a

major challenge for software developers because a very simple user interaction can trigger the use of hundreds, even thousands, of classes and methods depending on the size of the system. A naïve alternative is debugging and navigating the source code using IDE facilities. However, even for medium-size systems this task is extremely laborious because the number of method calls can become too large to trace. Another solution is analyzing the execution trace derived from that event. Indeed, there were proposed many works that help the developer to analyze execution traces depending on which information one wants to extract from them. The specific work of Greevy [1] proposes a visualization technique based on dynamic analysis to characterize features and computational units of an application. The combination of execution traces marked with feature events of appropriate execution scenarios and the corresponding source code model of those traces can provide useful information to understand the scattering of features over the source code.

We propose a visual tool to analyze the intersection of feature elements and source code elements from different matrix perspectives. The main contribution of the tool is to show how expandable and contractile visualization matrices of features and code elements can provide useful insight for understanding the

scattering of features over the code, and thus reducing the comprehension effort during maintenance activities. 2. Overview of the tool

In order to use the tool to analyze programs, the developer must define which features are interesting for analysis, and define an execution scenario, so that features can be directly extracted from specific trace elements of the execution. We consider a feature as “an observable unit of behavior of the system triggered by the user”[2]. In order to identify where the specified features are located in the execution trace, the developer must inform during the execution of the scenario when a feature starts and when it ends. We have developed an instrumentation tool that asks the developer to inform a label to mark the beginning a new feature, immediately before triggering the scenario activity corresponding to a feature. When the execution of that feature ends, the developer must inform such event. This process has to be repeated until the developer executes all planned scenario. The result is an execution trace file for each thread started within the execution of the whole scenario. Each line of each trace file describes a method call completely qualified and its respective timestamp indicating when the method has started. The complete qualification of the method call is important to understand which class and which package has participated in the execution of each feature. A separate feature configuration file with timestamps informing the beginning and the end of each feature is generated from the feature labels informed by the user. The developer can edit this file to produce a hierarchical structure for features. The visualization tool reads the trace files and the feature configuration file and starts up as shown in Figure 1. The window A shows all packages, classes and methods that appeared at least once in the traces of any thread. The window B shows the features provided by the user when collecting the traces. The features can be

2008 15th Working Conference on Reverse Engineering

1095-1350/08 $25.00 © 2008 IEEE

DOI 10.1109/WCRE.2008.40

337

2008 15th Working Conference on Reverse Engineering

1095-1350/08 $25.00 © 2008 IEEE

DOI 10.1109/WCRE.2008.40

337

2008 15th Working Conference on Reverse Engineering

1095-1350/08 $25.00 © 2008 IEEE

DOI 10.1109/WCRE.2008.40

337

2008 15th Working Conference on Reverse Engineering

1095-1350/08 $25.00 © 2008 IEEE

DOI 10.1109/WCRE.2008.40

337

2008 15th Working Conference on Reverse Engineering

1095-1350/08 $25.00 © 2008 IEEE

DOI 10.1109/WCRE.2008.40

337

organized hierarchically. The window C shows the threads that were started when collecting the trace. Threads are numbered according their relative start during the execution. The window D shows matrices that intersect features and source code elements of a specific thread. In the figure, the selected thread in window C is Thread-10. There are three alternative matrices:

1. Element x Element is a square matrix that shows common features between the code elements. This is the matrix shown in Figure 1.

2. Element x Feature is a matrix that shows the influence that a code element has on the implementation of a feature, and vice-versa.

3. Feature x Feature is a square matrix that shows common code elements between the features.

The matrix in window D expands and contracts depending on how the user opens and collapses code elements and feature nodes of windows A and B, respectively. This is an important functionality because it allows the analysis in a high level of packages and macro features or it allows us to detail a specific method and/or a specific feature. The area E shows the corresponding lines and columns of a selected rectangle in the matrix in window D, once it would be unfeasible to label all rows and columns. The window F shows more details of the metric shown in window E.

3. Conclusions

In this work we have proposed a visualization tool to reduce the effort to comprehend feature scattering based on the notion that scattering can be directly observed in matrices that cross code elements and features showing a scaled relationship between them. An important contribution is that the matrices are expandable and contractile allowing the analysis of large-scale software systems. We could also easily find interesting information in coarse grained or fine grained code elements that have some degree of participation in features.

Our tool can be downloaded from http://www.facom.ufu.br/ ~marcmaia. Acknowlegdment. We acknowledge the Brazilian agencies CAPES and FAPEMIG for partially funding. 4. References [1] O. Greevy and S. Ducasse, “Correlating features and code using a compact two-sided trace analysis approach,” in Proc. of the 9th European Conf. on Soft. Maint. and Reeng. (CSMR'05), 2005, pp. 314–323. [2] T. Eisenbarth, R. Koschke, and D. Simon, “Locating features in source code,” IEEE Trans. on Sof. Eng., vol. 29, no. 3, pp. 210–224, March 2003.

A

C

D

B

F

E

Figure 1: Overview of the visualization tool

338338338338338