The Java System Dependence Graph

Neil Walkinshaw, Marc Roper, Murray Wood

Livingstone Tower, 26 Richmond Street, Glasgow G1 1XH, UK
E-mail: {nw,Marc.Roper,Murray.Wood}@cis.strath.ac.uk

Abstract al. introduced the System Dependence Graph, which rep-

resents every procedure as an individual dependence graph.
The Program Dependence Graph was introduced by Ot- The procedure dependence graphs are linked to a central
tenstein and Ottenstein in 1984. It was suggested to be dependence graph, which represents the main program [2].
a suitable internal program representation for monolithic
There have been several proposed modifications to the
programs, for the purpose of carrying out certain software
system dependence graph, attempting to enable the repre-
engineering operations such as slicing and the computation
sentation of object-oriented programs. Such approaches
of program metrics. Since then, Horwitz et al. have intro-
must be able to cope with properties such as polymorphism,
duced the multi-procedural equivalent System Dependence
dynamic binding and inheritance. Larsen and Harrold pro-
Graph. Several authors have proposed object-oriented de-
posed a graph capable of representing these features for
pendence graph construction approaches. Every approach
C++ programs [3]. This was modified by Kovács et al. and
provides its own benefits, some of which are language spe-
Zhao, to enable the representation of Java-specific features
cific. This paper presents a Java System Dependence Graph
such as interfaces, packages and single inheritance [4, 5].
which draws on the strengths of a range of earlier works
Liang and Harrold also augmented Larsen and Harrold’s
and adapts them, if necessary, to the Java language. It also
graph to distinguish data members in parameter objects,
provides guidance on the construction of the graph, identi-
eliminating superfluous dependencies at callsites and hence
fies potential research topics based on it and shows, in the
increasing the accuracy of graph-based operations [6].
appendix, a completed graph with a slice highlighted for a
small, but realistic example. This paper presents a Java-based graph that encapsulates
the benefits offered by the approaches mentioned above. It
presents the graph construction from a practical perspective
1. Introduction and provides an example which demonstrates that the ap-
proach presented is viable. Although dependence analysis
is an established area, the JSysDG enables static analysis to
Analysing and representing software in terms of its in-
be carried out on a graph which will produce more accurate
ternal dependencies is important for a variety of software
results than other static Java dependence graphs, because it
engineering applications. These include operations such
can represent abstract classes which need not necessarily be
as slicing and the computation of program metrics. The
interfaces and it can distinguish data members in parameter
program dependence graph represents these dependencies,
objects.
where vertices are program elements and edges represent
dependencies between them [1]. There have been sev- The next section introduces the JSysDG by presenting
eral approaches to building graphs for different program- its individual components. Examples of various concepts
ming paradigms and languages. The Java System De- which are included in the graph are taken from a single
pendence Graph (JSysDG) summarises aspects of object- larger program which is given in the appendix. This is use-
oriented programming that previous work has focused on ful because it puts the various individual illustrations into
and presents a practical approach to its construction. context. Section three analyses the graph from a more prac-
Ottenstein and Ottenstein first suggested that depen- tical perspective. It identifies the steps needed for the con-
dence graphs could be used for software engineering op- struction of the graph. Section four considers potential re-
erations in 1984 [1]. They proposed a graph which was ca- search areas that could benefit from the graph and intro-
pable of representing a program consisting of a single block duces some practical problems that could arise if the rep-
of sequentially executed code. To enable the application of resented program contains features such as threads and ex-
these operations to multi-procedural programs, Horwitz et ceptions. Section five provides a conclusion and summary.
2. The JSysDG 2.2. Statements

A statement represents the lowest layer in the JSysDG.

The abbreviation ‘JSysDG’ was chosen in order to avert
It is an atomic construct representing a single expression in
confusion between this dependence graph construction ap-
the source code of the program. A statement representing a
proach and Zhao’s JSDG [5]. Both are concerned with
call to another method (a callsite) requires a special repre-
building Java-based dependence graphs, albeit slightly dif-
sentation and is described in section 2.4.
ferently.
A JSysDG is a multigraph which maps out control and
data dependencies1 between the statements of a Java pro- 2.3. Method Dependence Graph
gram. Statements are categorised according to whether
they contribute to the structure of a program (i.e. they The method dependence graph (MDG) represents a sin-
are headers representing methods, classes, interfaces and gle method or procedure in a program. It is the next layer
packages) or the program’s behaviour (i.e. they belong to up from the statement layer. MDGs are represented simi-
a method body). Each category is represented differently larly in most OO dependence graph approaches [4, 3, 6, 5].
on the graph. When these different graphs are combined, The method entry vertex is connected to any other vertices
they provide a graph-based program representation, which belonging to the method via control dependence edges.
is suitable as a basis for a range of software engineering Parameter passing is modelled by introducing actual and
applications. formal vertices. On the calling side, actual-in and actual-
The dependence graph is a complex construct and is in- out vertices are tagged to copy each variable to and from
tended as an internal program representation, not a visual a temporary variable as required. The called method con-
one. It is difficult to visualise a graph which is composed of tains formal-in and formal-out vertices, which copy pa-
such a large number of different types of nodes and edges. rameter variables from and to these variables respectively.
This can however be partially facilitated by interpreting the Parameter-in edges connect actual-in and formal-in ver-
JSysDG as a layered architecture, where certain vertices on tices, while parameter-out edges connect formal-out and
one layer are visible only to adjacent layers [7]. actual-out vertices [2].
Further formal vertices are connected to the method en-
Depending on the application the dependence graph is
try vertex to account for instance variables which may be
intended for, not all of the nodes and edge types are re-
referenced or modified during the execution of the method.
quired. The complexity of the graph can be reduced de-
All formal vertices are connected to the method entry vertex
pending on the context in which it is applied. For example,
and all actual vertices are connected to the callsite via con-
if we intend to slice the dependence graph, any nodes or
trol dependence edges. The flow of data within a method,
edges concerned with Java interfaces can be omitted.
to its actual-in and formal-out vertices and from its actual-
out and formal-in vertices, is indicated by data dependence
2.1. A Language-specific Representation edges. The call dependence edge indicates the link between
the callsite and the method being called.
Figure 1 illustrates an example of a simple method which
Object-oriented representations proposed by Larsen and
adds two integers. To put this example into context, see the
Harrold [3] and Liang and Harrold [6] generate the depen-
call from node C26 to E29 in appendix C (in the lower left
dence graph from C++. Several of the differences between
region). The method is represented by a method entry ver-
C++ and Java require different edges or nodes in the graph.
tex (private int add(int c, int d)), which is connected to
Its construction relies on the fact that it is possible to per-
statement vertices (int result = c + d and return result)
form some preliminary control, data and call flow analysis
and formal-in and formal-out vertices (c=c_in, d=d_in and
on a given Java program, in order to build a skeletal ver-
result_out=result) via control dependence edges (plain ar-
sion of the graph. Given that this framework is established,
rows). The callsite (int added=add(a,b)) belongs to an-
other nodes relating to the program structure (e.g. method
other method and is connected to its actual-in and actual-
and class vertices) are added. The accuracy of any traver-
out vertices (c_in=a, d_in=b and added=result_out) via
sal algorithm which operates on the JSysDG (e.g. a slicing
control dependence edges. The call dependence edge from
algorithm) depends on the accuracy of the flow analysis per-
the callsite to the method entry vertex is represented by
formed in the preprocessing stage.
a dotted line. The actual-in vertices are connected to the
1A control dependence

 exists, if the execution of a statement
formal-in vertices via parameter-in edges (dashed lines).


 
B relies on the execution of a predicate statement A. A data dependence
exists, if the execution of a statement B references a variable
The formal-out vertex is connected to the actual-out vertex
via a parameter-out edge (dashed line). Data dependencies
which is defined / modified in a statement A. within the method (e.g. from c=c_in to int result = c + d)
are represented by data dependence edges (dashed lines). A slicing to take individual objects into consideration [6]. A
full legend for all of the examples featured in this paper is statement vertex v which references an object is expanded
provided in appendix A. into a tree depending on the context in which v is used.
The examples (figures 3-6) are taken from the calculator
example given in appendices B and C. The following four
int added=add(a,b) sections illustrate these possible expansions:
private int add(int c, int d) added=result_out
1. v is a parameter vertex representing a statically typed2
c_in=a d_in=b

c=c_in d=d_in int result = c + d return result result_out=result object: v is expanded into a tree. Figure 3 illustrates
the callsite for computePower(e) (see node C9 in ap-
pendix), given that it can only accept objects of the
type AdvancedCalc.
Figure 1. Example of a simple method call
computePower(e)

2.4. Class Dependence Graph

AdvancedCalc e

The class dependence graph (ClDG) represents the

classes in a program [3]. It is the next layer up from the a b

MDG layer. For every class, there exists a class entry ver-
tex, which is connected to the method entry vertices of its
methods via class membership edges. These membership
edges can be tagged as either public, protected or package
(default) to indicate their visibility [4]. If one class inherits Figure 3. Example of single-typed parameter
from another, they are linked by a class dependence edge. object
The class entry vertex is connected to its data members via
data member edges.
Figure 2 shows the ClDG of classes SimpleCalc and 2. v is a parameter vertex representing a dynamically
AdvancedCalc (see nodes CE17 and CE46 in appendix typed3 object: v is connected to a child vertex for each
B). Inheritance is indicated by the class dependence edge possible object type and expands each child vertex into
which passes between them. Note that although Advanced- a tree containing data members belonging to that ob-
Calc inherits all of the data members and methods belong- ject. In figure 4, e can either be of types SimpleCalc
ing to SimpleCalc (apart from its constructors), it only or AdvancedCalc (see node C11 in appendix).
needs to be linked to its own specific data members and
methods. Inherited data members and methods can simply getStats(e)

be computed by traversing up the class dependence edge

and along the class membership / data member edges of e

SimpleCalc [4].
SimpleCalc AdvancedCalc
public class SimpleCalc implements Calculator

public int getA() public int getB()

a b
a b a b
public SimpleCalc()
public int average() private int divide(int c) public int multiply(int c, int d)

public SimpleCalc(int aIn, bIn)

private int add(int c, int d)

public class AdvancedCalc extends SimpleCalc

public power() public AdvancedCalc() public AdvancedCalc(int aIn, int bIn) public int multiply()
Figure 4. Example of polymorphic parameter
object

Figure 2. The ClDGs of the SimpleCalc and

AdvancedCalc classes 3. v is a callsite vertex and the method being called is de-
fined in a statically typed object: Because the imple-
mentation of the method can be determined statically,
Object Representation and Polymorphism The 2 The object type can be determined statically, without running the pro-
JSysDG represents different instances of a class individ- gram
ually; this enables dependence graph operations such as 3 The object type can only be determined dynamically
 the callsite can simply be expanded by adding the another object, this must further be expanded to reveal its
actual-in and actual-out vertices. Note that, although type(s) etc. This can become problematic if the object is
the method does not have any parameters, we still need defined recursively. To address this issue, Liang and Har-
to represent the object data members as actual-in ver- rold employ k-limiting (the tree is only expanded to a level
tices, because they represent the instance variables ref- k) [6].
erenced by the method. Figure 5 illustrates a call to
power() contained in the statically typed Advanced- 2.5. Interface Dependence Graph
Calc object (see node C16a in appendix).
e.power() Interface Calculator

AdvancedCalc.power public int average() public int multiply(int c, int d)

int c int d int

a b A1_out

SimpleCalc implements Calculator

public SimpleCalc() int getB() int getA()

public SimpleCalc(int a, int b) private int add(int c, int d) public int multiply(int c, int d)
Figure 5. Example of a call to a method in a
public int average()

single-typed object (A1_out is the actual-out private int divide(int c)

c=c_in d=d_in result_out=result

vertex )

4. v is a callsite vertex and the method being called is de-

fined in a dynamically typed object: v points to a ver- Figure 7. The InDG
tex representing the object containing the method be-
ing called. This is further expanded into a tree where The Java interface has been represented by both Kovács
the branches represent the candidate types. These are et al. and Zhao [4, 5]. Its role is to specify the signatures
further expanded to reveal the actual-in and actual-out of the methods which must be implemented by any object
vertices for the (potentially different) method imple- implementing the interface. Neither approach considers the
mentations and linked to the method entry vertices via representation of abstract classes which are not interfaces.
call edges. In figure 6, the multiply() implementation The JSysDG deviates from previous interface represen-
in AdvancedCalc is different to the one in Simple- tations by treating the interface as a special kind of abstract
Calc (see node S12a in appendix). The Java inter- class. Because abstract classes can contain method imple-
preter can only dynamically determine which imple- mentations, the use of callsites to represent abstract meth-
mentation to execute. ods as proposed by Zhao [5] becomes unsuitable. Abstract
methods are represented in the JSysDG with method entry
e.multiply(6,20)
vertices. Both Kovács et al. and Zhao omit parameter-out
vertices from abstract method declarations [4, 5]. To fully
e
represent a method signature, if a method returns a value
(i.e. is not void), the JSysDG connects the method entry
vertex to a parameter-out vertex.
SimpleCalc.multiply AdvancedCalc.multiply
The interface dependence graph (InDG) consists of an
interface entry vertex which is connected to a set of method
6 20 6 20
entry vertices representing its abstract methods via abstract
member edges. The method entry vertices are connected
to parameter vertices, which represent their input parame-
ters(These vertices do not need to be tagged to assign an
Figure 6. Example of a call to a method in a input value to a temporary location, because the interface
polymorphic object is abstract). Each method entry vertex is connected to the
method entry vertex of the method implementing it by an
implement abstract method edge. If a class implements an
In every case, an object is expanded to reveal its data interface, the class is connected to the interface by an imple-
type(s). These are further expanded to represent their re- ments edge. If a class C1 extends class C2, and C2 imple-
spective data members. If a data member happens to be ments an interface, C1 will automatically implement that
interface as well. C1 does not to need to be connected to 3. Constructing the Graph
the interface by an implements edge, as this is implicit in
the inheritance hierarchy. Figure 7 illustrates the Calcula- Ultimately, a Java System Dependence Graph (JSysDG)
tor InDG, which is connected to the SimpleCalc class (see must satisfy the following properties: It must

node IE43 in appendix). The multiply(int c, int d) vertex

has been expanded to reveal its formal vertices in order to Represent methods, classes, and packages [4, 5]
illustrate how parameters from the interface are connected
to their implementation counterparts.

Represent abstract methods / classes and interfaces

Represent individual objects (it must be able to cor-
Abstract Classes An abstract method contains only the rectly represent polymorphic parameters calls to poly-
method signature and leaves its implementation to a sub- morphic objects) [6]
class. If a class contains an abstract method, it must itself
Represent single inheritance (class hierarchy) [4]
be declared abstract. Abstract classes cannot be instanti-
ated. In C++ the equivalent effect is achieved by includ-
ing a pure virtual method4 in the class. Because interfaces The pre-processing stage is beyond the scope of this doc-
are themselves abstract, abstract classes are represented in a ument, but some important features are discussed briefly.
similar fashion. The interface entry vertex is replaced with The graph construction proceeds as follows:
a class entry vertex. The class entry vertex is connected
to abstract methods via an abstract member edge. Abstract Pre-processing the Java program Building the JSysDG
methods are connected to their implementations via imple- requires prior control and data flow analysis. As discussed
ment abstract method edges, as they would be in an inter- in section 2.1, this stage is instrumental in ensuring that the
face. Non-abstract methods are represented as they would resulting JSysDG and any operations on it are as accurate
be in a normal ClDG. If a class entry vertex has at least one as possible. Chambers et al. propose an approach for accu-
abstract member edge, it is an abstract class. rately analysing data dependencies in Java programs which
can handle exceptions, synchronisation and memory con-
Absence of Virtual Methods In C++, the inheritance sistency [8]. Tonella et al. propose a context and flow-
structure is slightly more complicated than in Java. Meth- insensitive Points-To Analysis (PTA) approach, which can
ods which can be overridden and dynamically bound at run- reduce the size of the initial graph to increase the accuracy
time must be explicitly marked as ‘virtual’. In Java, it is of operations such as slicing [9]. Grove et al. propose an
simply presumed that any derived class which contains a approach to elicit call-graphs for OO programs [10].
method with the same signature as a method in a superclass A practical approach to carry out this prior analysis
overrides all definitions further up the inheritance hierarchy. would be to use the Soot analysis framework, which pro-
Because Liang and Harrold base their dependence graph vides several packages to analyse the Java byte-code. Soot
on C++, they require a more complex inheritance structure operates on the Java byte-code, not the source code. One
[6]. Because Java allows only single inheritance and does line of source code usually constitutes several individual
not feature virtual methods, the JSysDG can adopt a sim- byte-code instructions, which are mapped to their respec-
pler inheritance structure, where derived classes can simply tive source code line numbers in the LineNumberTable at-
reuse base-class method definitions [4] (its simplicity is il- tribute of a class. The upside of analysing a program at a
lustrated in figure 2). byte-code level is that more precise results can be produced,
especially in the case of slicing, where it is usually desirable
2.6. Package Dependence Graph to obtain a slice which is as accurate as possible.

A package defines a collection of classes which are con- 1. Construct MDGs

ceptually similar or are dedicated to a similar purpose. It is
represented by a package dependence graph (PaDG) [4, 5].
1. (a) Processing Callsites In order to determine how
Packages are important in terms of slicing, because they are
the methods communicate with each other, each method
needed to accurately compute data visibility. A package
must be processed individually. Methods to be processed
entry vertex represents the package, which is connected to
are identified by traversing the call graph. Once a callsite
each class and interface entry vertex belonging to the pack-
has been identified it can be expanded (ref. 2.4). Once
age via a package member edge.
this is done, the call dependence edge is followed to de-
4 A pure virtual method is a method that is declared as virtual and does termine the called method, where the appropriate formal-in
not include a method body, but is initialised as ‘0’. and formal-out vertices are connected to its entry vertex. In
keeping with Liang and Harrold’s approach, parameter ver- ter object, if the vertex defines the object6 , the object’s data
tices are added for parameters and global variables in the members are added to the DEF set. Similarly, if the vertex
callee’s GREF and GMOD5 . uses the object, the data members are added to the USE set.
A data dependence exists between vertices A and B if Having computed the DEF and USE sets, it is possible to
A modifies / defines a variable which is referenced / used generate the def-use chains as data dependencies.
by B. To compute the data dependencies introduced by an
object’s data members, Liang and Harrold only associate 2. Construct ClDG It is assumed that the class hierarchy
the use of an object with a callsite if the called method is is calculated as part of the pre-processing stage. For every
not a construction. An object definition is associated with class, a class entry vertex is generated, which is connected
a call vertex if the called method is not a destruction. In to the method entry vertices of methods belonging to that
Java, destructors do not exist. Java’s closest equivalent of class via class membership edges. Kovács et al. use this
the destructor is the finalize() method, hence an object def- connection to determine the visibility of the method within
inition is associated with a call vertex if it is not a finalize() the class [4]. The JSysDG adopts this approach as well, so
method. that every class membership edge is tagged as either public,
private, or protected. If a class A extends a class B, A is
connected to B via a class dependence edge. By connecting
1.(b) Expand Objects In order to expand objects,
the classes in this manner, Java’s single inheritance structure
Liang and Harrold introduce the notion of an object-flow
is emphasised. If a class contains an abstract method (i.e.
subgraph. This is a subgraph in the data dependence graph
the class is abstract), it is still represented by a conventional
of a method, containing only the vertices that reference a
class entry vertex, but is connected to the abstract method
given object. This subgraph is traversed, and each ver-
via an abstract member edge. The abstract method is con-
tex v is expanded as discussed in section 2.4. In the get-
nected to its implementation in a subclass via an implement
Stats(SimpleCalc e) method given in figure 8, the vertices
abstract method edge.
e, e.getA() and e.getB() belong to the object-flow sub-
graph and hence are expanded. [Note that it is necessary to
expand the System.out.println... statement, because it is 3. Construct InDG For every interface, there exists an
composed of two method calls, which must be represented interface entry vertex. This is connected to method en-
separately.] try vertices representing the abstract methods in the inter-
face. These are each connected to their set of formal-in
public void getStats(SimpleCalc e)
vertices. Each method is connected to its respective imple-
mentation’s method entry vertex via an implements abstract
method edge. The formal-in vertices linked to the interface
e
System.out.println("a: "+e.getA()+"b: "+e.getB())
method entry vertices are connected to their implementation
counterparts via parameter-in edges.
e.getA() e.getB()

4. Construct PaDG The PaDG is represented by a pack-

age entry vertex, which is connected to its class entry ver-
tices and interface entry vertices via package edges. It is
Figure 8. Example of an object-flow subgraph possible for a program to consist of package hierarchies.
(vertices belonging to the graph are in bold) In this case, subpackages are connected to superpackages
via package dependence edges. This is an important feature
for multi-package programs, because it enables the accurate
calculation of the visibility of classes.
1.(c) Build Data Dependencies for Data Members
Once object vertices have been expanded, data dependen-
cies must be established for the individual object data mem- 4. Operating on the JSysDG
bers. For a callsite c in a subgraph, the definition set DEF(c)
of data members consists of c’s actual-out vertices. The use Although this paper focuses on the graph itself, it makes
set USE(c) consists of c’s actual-in vertices. If the call state- sense to give the reader an idea of some of its potential
ment carries a parameter object, the object’s data members benefits. The main application is slicing, which has been
must be added to the DEF and USE sets. For a parame- the focus of the majority of dependence graph based papers
[2, 4, 3, 6, 1, 5]. In addition to slicing, Horwitz and Reps
5 GMOD(m) is the set of non-local variables which can be modified

within a method m and GREF(m) is the set of non-local variables which 6 An example of this would be i.compareTo(new Integer(5)); where i

can be referenced [11]. is of type Integer

also propose that dependence graphs can be used to estab- classes or packages to be measured. This could be espe-
lish differences between two programs (program differenc- cially useful as a heuristic to software restructuring. If the
ing) and to integrate changes carried out on one program complexity in a given area of the program exceeds a certain
into another similar program (program integration) [12]. threshold, it could indicate that a refactoring (or other form
The combination of data and control dependencies provides of code restructuring) could be necessary. It would be in-
a useful basis for the calculation of program metrics [1]. It teresting to expand on Weiser’s original investigations into
would also be interesting to investigate the usefulness of the slicing based metrics [13]. Bieman and Ott propose the use
JSysDG with respect to software inspections. of program slices to measure functional cohesion [14]. The
JSysDG provides the basic representation for the computa-
4.1. Slicing tion of these metrics.

If the JSysDG is to be sliced, it needs an additional 4.3. Software Inspections / Program Understanding
edge called the summary edge. These represent the tran-
sitive flow of dependence across a callsite caused by both Dunsmore et al. state that delocalised software arti-
control and data dependencies. Such an edge connects an facts hamper object oriented code inspections [15]. Soft-
actual-in vertex to an actual-out vertex if the value asso- ware artifacts become delocalised because object-oriented
ciated with the actual-in vertex may affect the value as- paradigm features such as inheritance, polymorphism and
sociated with the actual-out vertex. Figure 10 shows the dynamic binding can cause code which is responsible for
same callsite example as figure 1, but adds transitive depen- the execution of a single task to be dispersed throughout
dencies from c_in=a to added=result_out and d_in=b to the program. These dispersed artifacts are all connected
added=result_out. via some form of dependence (or chain of dependencies),
which can be traced on the JSysDG. Slicing could be used to
statically determine possible paths of execution in the pro-
gram, providing the inspector with a reading strategy for the
int added=add(a,b)
inspection.
Harman et al. propose a framework for combining slic-
private int add(int c, int d) c_in=a d_in=b added=result_out
ing and concept assignment [16], to facilitate program un-
c=c_in d=d_in int result = c + d return result result_out=result derstanding. Further research is required if this approach
is to be made practical for object-oriented systems. The
JSysDG provides a useful basis for investigating the feasi-
bility of extracting Executable Concept Slices (ECSs) for
Figure 9. Example of method call with transi- object-oriented programs.
tive edges between actual-in and actual-out
vertices 4.4. Practical Issues

The graph has not been designed to incorporate excep-

The slicing algorithm proposed by Horwitz et al. is split tions and threads. Sinha et al. represent exceptions by
into two phases. The first phase traverses backwards along adding vertices and edges around the try and catch clauses
control, call, parameter in and data dependence edges mark- of an exception [17]. This graph will not accurately repre-
ing every graph vertex it passes. In the second pass, the al- sent concurrent programs. Zhao addresses the dependence
gorithm traverses back from each marked vertex along con- graph-based representation of concurrent programs by in-
trol, parameter out and data dependence edges [2]. Liang troducing thread dependence graphs to represent individ-
and Harrold extended this algorithm to enable the slicing ual threads [18]. The integration of these features with the
of individual objects [6]. An example of a slice according JSysDG should be addressed in future work.
to the Horwitz et al. method is marked out in appendix
C (shaded vertices belong to a slice taken from statement 5. Conclusions
S25).
This dependence graph provides a useful basis for the
4.2. Program Metrics representation of Java programs. It enables several useful
software engineering operations to be carried out as queries
Ottenstein and Ottenstein suggested that the dependence / manipulations on the graph, which offers greater speed and
graph would be a suitable basis for the calculation of pro- precision than conventional methods (Horwitz et al. illus-
gram metrics. The JSysDG allows individual methods, trate the increase in precision when slicing the SDG as op-
posed to Weiser’s conventional algorithm [2]). It provides [10] D. Grove, G. DeFouw, J. Dean, and C. Cham-
a representation for interfaces and abstract classes and en- bers, “Call graph construction in object-oriented lan-
ables objects and object data members to be treated indi- guages,” in OOPSLA ’97 Conference Proceedings,
vidually in any operation (e.g. the program can be sliced 1997.
object by object). Now, it is possible to re-interpret the
dependence graph applications as suggested by Ottenstein [11] J. Banning, “An efficient way to find the side effects of
and Ottenstein and Horwitz et al. in terms of the OO procedure calls and the aliases of variables,” in Con-
paradigm. Several potential research areas concerning the ference Record of the Sixth Annual ACM Symposium
JSysDG have been proposed. The next logical step in mak- on Principles of Programming Languages, pp. 29–41,
ing the JSysDG a practical software engineering tool is to January 1979.
develop a framework which will provide an internal repre- [12] S. Horwitz and T. Reps, “The use of program depen-
sentation of a given Java program. dence graphs in software engineering,” in Proceedings
of the 14th International Conference on Software En-
References gineering, 1992.

[1] K. Ottenstein and L. Ottenstein, “The program depen- [13] M. Weiser, “Program slicing,” in Proc. 5th Int. Confer-
dence graph in a software development environment,” ence on Software Engineering, (New York), pp. 439–
in Proceedings of the ACM SIGSOFT/SIGPLAN Soft- 449, IEEE, 1981.
ware Engineering Symposium on Practical Software [14] J. Bieman and L. Ott, “Measuring functional cohe-
Development Environments, pp. 177–184, 1984. sion,” IEEE Transactions on Software Engineering,
[2] S. Horwitz, T. Reps, and D. Binkley, “Interprocedural vol. 20, pp. 644–658, August 1994.
slicing using dependence graphs,” ACM Transactions
[15] A. Dunsmore, M. Roper, and M. Wood, “Object-
on Programming Languages and Systems, vol. 12,
oriented inspection in the face of delocalisation,” in
pp. 26–60, January 1990.
Proceedings of the 22nd International Conference on
[3] L. Larsen and M. Harrold, “Slicing object oriented Software Engineering, (Limerick), 2000.
software,” in 18th International Conference on Soft-
ware Engineering, pp. 495–505, March 1996. [16] M. Harman, N. Gold, R. Hierons, and D. Binkley,
“Code extraction algorithms which unify slicing and
[4] G. Kovacs, F. Magyar, and T. Gyimothy, “Static slic- concept assignment,” in 9th IEEE Conference on Re-
ing of Java programs,” Tech. Rep. TR-96-108, Re- verse Engineering (WCRE ’02), (Richmond, Virginia,
search Group on Artificial Intelligence, Hungarian USA), 2002.
Academy of Sciences, Joesf Attila University, 1996.
[17] S. Sinha, M. Harrold, and G. Rothermel, “System-
[5] J. Zhao, “Applying program dependence analysis to dependence-graph-based slicing of programs with ar-
Java software,” in Proc. Workshop on Software En- bitrary interprocedural control flow,” in Proceedings
gineering and Database Systems, (Taiwan), pp. 162– of the 21st International Conference on Software En-
169, December 1998. gineering, May 1999.
[6] D. Liang and M. Harrold, “Slicing objects using sys- [18] J. Zhao, “Multithreaded dependence graphs for con-
tem dependence graphs,” International Conference on current Java programs,” in Proceedings of the Seventh
Software Maintenance, pp. 358–367, November 1998. IEEE International Workshop on Program Compre-
[7] M. Shaw, Pattern Languages of Program Design, hension (IWPC ’99), pp. 126–133, May 1999.
ch. 24. Addison Wesley, 1996.
[8] C. Chambers, I. Pechtchanski, V. Sarkar, M. Serrano,
and H. Srinivasan, “Dependence analysis for Java,” in
Workshop on Compilers for Parallel Computing, (La
Jolla, LA), August 1999.
[9] P. Tonella, G. Antoniol, R. Fuitem, and E. Merlo,
“Flow insensitive C++ pointers and polymorphism
analysis and its application to slicing,” 19th Interna-
tional Conference on Software Engineering, pp. 433–
443, May 1997.
Appendix A: Legend
class entry vertex / interface entry vertex

method entry vertex / statement vertex / formal or actual parameter in/out vertex

data member edge

control dependence

class membership edge

implements edge / implement abstract method edge

data dependence edge / parameter−in edge / parameter−out edge

call dependence edge

class dependence edge

abstract member edge

transitive dependence

Appendix B: Example Code

CE1 public class Execute{ CE17 public class SimpleCalc implements Calculator{ IE43 interface Calculator{

E2 public static void main(String args[]){ S18 int a,b; E44 int average();

S3 SimpleCalc e; E19 public SimpleCalc(){ E45 int multiply(int c, int d);

S4 if(args.length > 0){ S20 a = 6; }

C5 int a = Integer.parseInt(args[0]); S21 b = 20;

C6 int b = Integer.parseInt(args[1]); } CE46 public class AdvancedCalc extends SimpleCalc{

C7 e = new SimpleCalc(a, b); E22 public SimpleCalc(int aIn, int bIn){ E47 public AdvancedCalc(){

} S23 a = aIn; S48 a = 6;

else C24 b = multiply(a, bIn); S49 b = 20;

{ } }

C8 e = new AdvancedCalc(); E25 public int average(){ E50 public AdvancedCalc(int aIn, int bIn){

C9 computePower((AdvancedCalc)e); C26 int added = add(a,b); S51 a = aIn;

} C27 int divided = divide(added); C52 b = multiply(a, bIn);

S10 System.out.println(e.average()); S28 return divided; }

C11 getStats(e); } E53 protected int multiply(int c, int d){

S12 System.out.println(e.multiply(6,20)); E29 private int add(int c, int d){ S54 int result = c*d;

} S30 int result = c+d; S55 return result;

E13 public static void getStats(SimpleCalc e){ S31 return result; }

S14 System.out.println(“a: “+ e.getA() + “ b: “ + e.getB()); } E56 public int power(){

} E32 private int divide(int c){ S57 int result=a^b;

E15 public static void computePower(AdvancedCalc e){ S33 int result = c/2; S58 return result;

S16 System.out.println(e.power()); S34 return result; }

} } }

} E35 protected int multiply(int c, int d){

S36 for(int i=0; i<c; i++){

S37 d=d+d;

S38 return d;

E39 public int getA(){

S40 return a;

E41 public int getB(){

S42 return b;

}
Appendix C: Entire JSysDG for Example Code
This page is best viewed in colour (A colour image can be downloaded from:
http://www.cs.strath.ac.uk/~nw/documents.html).
CE1

F1_in E2

S3 S4

C9 S10
C5 C6 C7 C8 S10(a) C11 S12

A2_in A2_out A3_in A3_out A6_in A7_in e e e e A13_out

S12(a)

a b a b a b
SimpleCalc AdvancedCalc e

e SimpleCalc.multiply
a b a b AdvancedCalc.multiply
E15

S16
SimpleCalc AdvancedCalc 6 20 6 20

AdvancedCalc C16(a)

a b a b

a b AdvancedCalc.multiply

a b A14_out

E13

e
IE43 S14

SimpleCalc AdvancedCalc
C14(a) C14(b)
E44 E45

a a b A14_in A14_out A15_in A15_out

b
F8_in F9_in

CE17
S18(a)

S18(b)

E22

E19

F6_in F7_in S23 C24 F4_out F5_out E25

F4_in F5_in F4_in F5_in F4_out F5_out

S28 F13_out
S20 S21
A8_in A9_in A9_out

C26 C27

E39
E29 A10_in A11_in A11_out A12_in A12_out

F14_in S40 F14_out

F10_in F11_in S30 S31 F11_out

E32

F12_in S33 S34 F12_out E41

E35

F15_in S42 F15_out

F8_in F9_in S36

S38 F9_out

S37

CE46

E50 E47 E53 E56

F4_in F5_in F4_out F5_out F8_in F9_in F9_out F16_in F17_in F17_out
F6_in F7_in S51 C52 F4_out F5_out
F4_in F5_in

S48 S49

S54 S55 S57 S58

A8_in A9_in A9_out

Vertices marked by the first phase of the slice are shown in blue (darker shade) and those marked by the second phase are
shown in pink (lighter shade). A backwards-slice is demonstrated, taken from vertex S25 (return divided).