Reducing Visualization Complexity Using Decomposition ... - CiteSeerX

Reducing Visualization Complexity Using Decomposition Slices Keith Gallagher and Liam O'Brien CSIRO Mathematical and Information Sciences GPO Box 664, Canberra, ACT 2601, Australia.

Abstract Program comprehension is the process in which software engineers gain an understanding of a system. A program comprehension environment provides tools to capture and manipulate information to carry out understanding tasks. We describe an information model and framework for program understanding and show how decomposition slicing (a maintenance method) can be incorporated into this framework. In so doing we discovered a way to signi cantly simplify the presentation of the decomposition slices while not losing information content proportional to the size of the reduction. We report some preliminary data in applying the reduction technique.

1 A Problem in Program Comprehension Program comprehension is the process in which software engineers develop models of a software system's architecture, purpose and behaviour in order to gain an understanding of the system. In order to support comprehension tasks it is necessary to provide a set of tools to carry out various analyses. One way to assist the comprehender is the use of visualisation techniques that will convey the results of these analyses in an abstract, pictorial manner. However, no matter how robust the visualization technique, large systems have the singular capacity to overwhelm both the technique and the user of it. Thus, looking for methods to reduce the visual overhead, while still conveying pertinent information seems to be a reasonable line of attack on the visualization problem.  On sabbatical leave from Loyola College in Maryland, USA.

We have a method for visualizing one aspect of program that was also overwhelmed by large systems. This is a report on our attempt to simplify the presentation, while losing as little information as possible. Organization

This paper is organized into 5 sections. Section 2 provides background and context; section 3 introduces the new idea; section 4 gives some preliminary data and section 5 outlines future work and concludes.

2 A Program Comprehension Environment To support the program comprehension process it is necessary to gain information about the software. There are various sources of information that can be used to support program comprehension. These sources include:     

Source code; Documentation; Reverse engineering and program analysis results; User-generated information; and Maintainer's knowledge.

All of the information from these sources should be made available to a software engineer and it should be possible for the software engineer to examine, manipulate and analyse the information. When carrying out understanding tasks a software engineer may read through source code, examine existing documentation, generate new information through carrying out reverse engineering or review information that may have been generated previously.

A program comprehension environment should provide tools to capture and manipulate this information, so that it can be used to support a software engineer in carrying out understanding tasks. In order to capture this information it is necessary to build an Information Model of the information which can be obtained about a software system. To support the use of the information in understanding it is necessary to provide visualisation of the information that enables exploration and manipulation of the Information Model. Also there is a need to manage the information in the model. We are currently building a framework for program comprehension and the decomposition slicing tool is being incorporated into this environment. The framework consists of a model of the information that can be obtained from software and incorporates various forms of visualisation for visualising, exploring and manipulating this information. Program understanding is supported by building an Information Model of the information captured from software through reverse engineering and user interaction and other forms of analysis. Various views of the Information Model can be presented to software engineers who use the tool when trying to gain an understanding of some piece of software. The users can manipulate various views, change, add more detail, and store them in the repository for reviewing at a later stage. The Information Model also contains functionality to carry out various forms of analysis on the information stored in it.

neer from a program comprehension support environment: 





The Reverse Engineering Component: this component captures information directly from the code and populates the Information Model with that information; The Visualisation and Manipulation Component: is used to visualise information, present it to the comprehender and allows for exploration and manipulation of the information within the Information Model; Various Program Analysis tools: tools such as program slicing and program plan recognition tools are being incorporated into the environment.

An outline of the environment is illustrated in Figure 1. Many reverse engineering and program analysis tools use their own information model to model the information they capture and extract from code. Few tools share information between them. The purpose for building our environment is to enable the sharing of information between the various tools integrated into the environment. In this paper, we focus on one component of this environment, which is a program analysis tool for computing program slices and visualizing a particular kind of slice, a decomposition slice. 2.2 Program Slicing and Unravel

A program slice, SLICE( )(p), of program p on variable v, or set of variables, at statement n yields the portions of the program that contributed to the value of v just before statement n is executed [8]. The pair (v; n) is called a slicing criterion. Slices can be approximated automatically on source programs by analyzing data ow and control ow. Recent surveys of program slicing may be found in [1, 7]. Unravel [6] is used to compute the slices. Unravel generates a Language Independent Form (LIF) upon which a generic slicing algorithm operates. The LIF is an augmented control ow graph. v;n

2.1 Framework Outline

An environment to support a software engineer in carrying out understanding is being developed. This environment contains the following components for capturing information about software: 



An Intermediate Representation. This is used to capture information directly from source code through parsing and loading; An Information Model. This is used to model the information required for understanding and information the software engineer generates through manipulation of the Information Model.

The following components provide many of the capabilities required by a software engi-

2.3 Decomposition Slicing

While a program slice depends on both a variable and a statement in a program, a decomposition slice depends only on a variable,

and 363 edges. The \fan out" at the bottom is caused by the inclusion of stdio.h and the de nition of enumeration types in the program. A tool for Visualizing Compiler Graphs (VCG) [5] is used to display the graphs. Figure 3 is an enlargement of a node in a graph of Figure 2. The nodes show the variable names in the form name-of-function:variable-name, where nameof-function is the function in which variablename is declared; the annotation \size: xx" is the size of the decomposition slice. The second parameter of DS (v; p) is not displayed. 2.4

Figure 1. The Program Comprehension Environment

(or set of variables) and does not regard to the location of the statement. The decomposition slice is the union of a collection of slices, which is still a program slice [8]. A decomposition slice captures all relevant computations involving a given variable and is de ned as follows:

De nition 1 (Decomposition Slice)

Let 1. Out(p; v) be the set of statements in program p that output variable v, 2. last be the last statement of p, 3. N = Out(p,v) [ flastg. Then the decomposition slice on v (of p), DS (v; p), is de ned as SLICE( )(p).

[

2N

v;n

n

We take the decomposition slice for each variable in the program and form a graph,1 using the partial ordering induced by proper subset inclusion. Larger sets will be toward the top; smaller sets will be lower; edges point downward. An edge between A and B means B  A and there is no C; B  C  A. The graph of decomposition slices was originally intended to give software maintainers a method for visual impact analysis [2, 4]. Figure 2 is the decomposition slice graph of a dierencing program. It has 91 nodes 1

The term \lattice" was used in [3].

Decomposition Slices as part of a Program Comprehension Environment

The decomposition slice graph provides information to a software engineer about dependencies that exist between variables in a system. The graph shows what slices for variables are included in the slices for other variables in a system. This information is very useful to a software engineer in trying to gain an understanding of a system as it can be used to track the data- ow for a variable, and it can be used to identify the data that impacts on a particular variable (those variables on which it depends) and the impact of a variable (those variables which depend on it). Providing visual representations of the decomposition slice information providers maintainers with a view of the possible effects of making changes to the computation of a particular variable. One can see from the graphs what variables will be impacted if a change is made to a variable.

3 The Approach We extended the program that produces the graphs to output only one node for each equivalent decomposition slice, as computed by Unravel. Figure 4 shows the result of reducing the graph of Figure 2. The reduced graph of Figure 4 has 34 nodes and 43 edges. We also augmented the node information to show how many other nodes are equivalent with the annotation equiv: x. The border of the node was also widened in proportion to the number of equivalent nodes. Figure 5 is a sample.

Figure 2. The decomposition slice graph of a differencing program.

Figure 3. A node from the graph of decomposition slices.

Figure 4. The reduced decomposition slice graph of Figure 2.

Figure 5. A node from the reduced graph.

4 Preliminary Data In testing the program that computes the reduced graphs, we obtained some interesting data. We used a suite of 39 programs ranging from about 200 to 700 lines, as counted by the Unix utility wc. Here is a sampling: A suite of related programs of about 650 lines, generated graphs with 350 nodes and approximately 2700 edges. We were able to ascertain that these graphs were disconnected. The display took VCG approximately 15 minutes on a Sun Sparc 5(tm). These were reduced to graphs with 77 nodes and edge counts in the low seventies. The largest programs generated 330 nodes and approximately 2300 edges which reduced to about 65 nodes with about 60 edges. The smallest programs generated 19 nodes and 47 edges which reduced to 5 nodes with 5 edges. Thus, substantial amounts of visual clutter can be removed, while still conveying most of the information. The only information that is lost is the actual names of the decomposition slices that were reduced. An early attempt to list all names in the node itself overwhelmed VCG.

5 Future Work and Conclusions Every variable or programmer de ned constant generated a slice. However most of these decomposition slices were \empty"; that is, when unravel is handed a variable to slice on, it rst generates a slice with 3 nodes (from the .LIF): the entry point to the function and the open and close braces. Thus many slices have size 3. Larger programs are currently being analyzed. Building and displaying the reduced graphs generated further ideas for extension: 1. Ignore \empty" slices. 2. Remove enums. 3. Examine \nature" of reduced nodes. 4. List all node names that have been collapsed into a single reduced node. 5. Remove globals included from libraries, while leaving programmer de ned globals. A software engineer is presented with an overwhelming amount of information in attempting to understand a program. Easily computable reductions by equivalent in-

formation is one way to reduce this clutter. By using set equivalence, we can reduce the complexity of graphs of decomposition slices. The signi cant size of the reduction provides a maintainer/comprehender with a much simpler tool for impact analysis.

References [1] D. Binkley and K. Gallagher. A survey of program slicing. In M. Zelkowitz, editor, Advances in Computers. Academic Press, 1996. [2] K. Gallagher. Visual impact analysis. In Proceedings of the Conference on Software Maintenance - 1996, 1996. [3] K. B. Gallagher and J. R. Lyle. Using program slicing in software maintenance. IEEE Transactions on Software Engineering, 17(8):751{761, August 1991. [4] B. Kuhn, D. Smith, and K. Gallagher. The decomposition slice display system. In Proceedings of the 1995 Conference on Software Enginnering and Knowledge Enginnering, SEKE `95, June 1995. [5] I. Lemke and G. Sander. Visualization of Compiler Graphs: Design Report and Documentation. Universitat des Saarlandes, Saarbrucken, Germany, May 1994. vcg. [6] J. Lyle, D. Wallace, J. Graham, K. Gallagher, J. Poole, and D. Binkley. A CASE tool to evaluate functional diversity in high integrity software. U.S. Department of Commerce, Technology Administration, National Institute of Standards and Technology, Computer Systems Laboratory, Gaithersburg, MD, 1995. http://hissa.ncsl.nist.gov/~jimmy/unravel.html

[7] F. Tip. A survey of programming slicing techniques. Journal Of Programming Langages, 13(3):121{189, 1995. [8] M. Weiser. Program slicing. IEEE Transactions on Software Engineering, 10:352{357, July 1984.