Gadget: A Tool for Extracting the Dynamic Structure of Java Programs Juan Gargiulo and Spiros Mancoridis Department of Mathematics & Computer Science Drexel University Philadelphia, PA, USA e-mail: gjgargiu,smancori ¡ @mcs.drexel.edu Abstract Chava [6], would only reveal part of the complete design. Specifically, it would reveal the relationship between the Source code analysis and inspection does not provide client class and the Factory class but not between the client enough information to describe the structure of an object- and the objects that were created by the Factory at runtime. oriented program completely because there are components This paper describes a tool, called Gadget, to help soft- and relations that only exist during its runtime. ware engineers extract the dynamic structure of Java pro- This paper presents a tool, called Gadget, that helps grams. In the profiling phase the tool gathers runtime data software engineers extract the dynamic structure of object- from the executing program. This data captures class load- oriented programs written in the Java programming lan- ing, object creation, and method invocation events. In the guage. The tool uses program profiling, filtering, and graph analysis phase the tool uses filtering and abstraction tech- clustering techniques. niques to select classes of interest. The instances of these In this work we show how Gadget is used to analyze a classes and their runtime relations are then displayed as a standard graphical user interface library for Java, called graph. Swing. This library has a complex structure, part of which In general, one or more features of the target program is we expose using data gathered by Gadget during the execu- analyzed at a time (e.g., the Save feature of a word process- tion of a simple Java program that uses Swing. ing program). The recording of events that occur during the execution of a feature is called tracing, and the collection of trace data is called a profile. The profile is analyzed by 1. Introduction the tool and the dynamic structure of the objects and rela- tions involved in the trace is shown as a DDG (Dynamic As the size of a software system increases, so does the Dependency Graph). A DDG is a graph where nodes rep- complexity of its structure. The use of object-oriented (OO) resent classes or objects and edges represent relations (i.e., development techniques and languages helps programmers method invocation) between two objects or between a static manage this complexity by supporting data abstraction, en- class and an object. A method invocation can be an ob- capsulation, polymorphism, and reuse. However, the OO ject creation (i.e., call to a constructor method) or a sim- approach makes understanding the structure of these sys- ple method call. Gadget uses a tool from AT&T Research tems more difficult because of features such as dynamic called dotty [4] to display the DDGs. An example of a DDG binding and polymorphism. is shown in Figure 7. Understanding the dynamic structure of a system is help- Additionally, Gadget uses a clustering algorithm to par- ful during software maintenance. The dynamic structure of tition the DDGs, thus presenting the dynamic structures in an OO program shows which objects are created and what a modular fashion that is easier to understand. messages are sent between these objects at runtime. Dy- Figure 1 shows the architecture of Gadget, which con- namic analysis can be used to complement static source- sists of three main components: Control, Repository, and level inspection and analysis, which may not provide all of Profiler. The Control and Profiler components execute on the information software engineers need in order to under- different Java Virtual Machines (JVMs). The Control com- stand an OO system. For example, the Factory OO design ponent contains Gadget’s execution and analysis engines pattern [3] is used to “manufacture” objects and make these (i.e., Gadget Executor and Gadget Analyzer). The execu- objects accessible to client objects through an abstract in- tion engine is in charge of the execution of Gadget and has terface at runtime. Static analysis, using a tool such as some control of the execution of the target program being stantiation patterns during the execution of a program. His Target Application approach requires tracing the execution of the program be- ing analyzed and then visualizing the dynamic data captured Profiler by the trace. This work is concerned with searching for so- lutions to the problem of visualizing large data sets of run- SergProf JVMPI time data. It also focuses on detecting inconsistencies be- JVM2 tween the design and implementation of software systems. De Paw, Helm, Kimelman and Vlissides [12] have cre- Repository Profiling Data ated a library for extracting and animating the behavior (file) of OO systems. They present summary information about the execution of a program using a chart-like visualization. They also present techniques to instrument OO programs so Gadget Control Executor that their executions can be traced. Gadget Analyzer Richner, Duccasse and Wuyts [10] use logic program- JVM1 ming to filter data that is generated by execution traces. Their approach also requires code instrumentation. USER Shilling and Stasko [11], and later Stasko and Mukher- Figure 1. Software Architecture of Gadget. jea [9], worked on animating designs and algorithms, which can be helpful during the design process. Unlike the other analyzed. The analysis engine is in charge of managing work presented in this section, their work does not involve the analysis process logic. This includes the interaction program tracing and does not take a reverse engineering ap- with the repository and the interaction with the user inter- proach. face. Gadget’s repository is an external file that contains What distinguishes our work from the above research data about the execution of the target program. This file is the emphasis on filtering and clustering the trace data is first written by the profiler and then read by the analy- before producing design visualizations. Unlike Jerding’s sis engine. The Profiler component is in charge of running work, which tries to reduce complexity by providing better the target program through the SergProf profiling interface, visualizations, our approach attempts to reduce complexity which is our implementation of Sun Microsystem’s Java by filtering out only the runtime data that is relevant to the Virtual Machine Profiling Interface (JVMPI) [13]. SergProf program feature being analyzed. traces class loading, object allocation, method invocation and stack information at the time an object is allocated. Automatic clustering was identified by Belady and Evan- The structure of the rest of this paper is as follows: Sec- gelisti [1] as a means to produce high-level views of the tion 2 provides an overview of related research. Section 3 structure of software systems. We use the Bunch [8] clus- provides background information about the Pluggable Look tering system to group sets of objects and their interrela- and Feel (PLAF) feature of the Java Swing library. Sec- tions in order to produce a high-level “road map” of the tion 4 uses Gadget to extract the structure of the PLAF fea- dynamic software structure. Another distinguishing char- ture. This section presents the basic features of Gadget and acteristic is that our work does not rely on program in- shows screen captures of the tool, as well as the results of strumentation but rather on capturing trace data directly the PLAF feature’s analysis. Section 5 concludes with a from the Java virtual machine using the JVMPI [13]. Fi- summary of the paper, an outline of the contributions made, nally, we are treating this work as an ongoing project and a list of the limitations of the current version of Gadget. and hope to receive feedback from users. For this rea- son we provide a free copy of Gadget from our web page 2. Background (http://serg.mcs.drexel.edu/gadget) and in- tend to maintain the tool if a significant user community In this section we outline the body of work that is most materializes. closely related to the work presented in this paper. At the end of the section we state the distinguishing characteristics Before we show how Gadget is used to extract the struc- of our work. ture of Swing’s PLAF feature in Section 4, we briefly pro- Jerding’s [5] approach to supporting OO program under- vide some background material on this feature in the next standing is based on visualizing object interactions and in- section. 3. The Pluggable Look and Feel Feature of the The UI delegate is installed by the UIManager class, Swing Library which is a static class that has knowledge of the current LAF. The UIManager class makes use of the UIDe- faults class, which has methods for accessing specific Swing is a Java library to support the development of types of information about look-and-feel. The UIDe- graphical user interfaces for Java programs. One of Swing’s faults class includes, among other things, default values goals is to support multiple platforms while preserving a for presentation-related properties (such as color, font, bor- consistent look and feel. der, and icon) for each UI delegate. The Swing pluggable look-and-feel (PLAF) design is the Figure 3 shows the class diagram for a program that portion of a GUI component’s implementation that deals uses a JButton with a PLAF. This diagram describes with the presentation (the look) and event-handling (the Swing’s structure (for one component) showing the rela- feel). Note that the LAF can be changed at runtime [2]. tions between the different classes. Examples of inheritance Figure 2 shows three different GUI buttons, each with a dif- relations are the large edge relations between Motif- ferent LAF.