Acknowledgments 2

Transcription

1 Program Slicing: An Application of Object-oriented Program Dependency Graphs Anand Krishnaswamy Dept. of Computer Science Clemson University Clemson, SC Abstract A considerable amount of work has been done in the area of representing programs with single and multiple procedure bodies. A complete study of the latter requires both intra and interprocedural analysis. In the analysis of an object-oriented program, it is all the more important due to the existence of numerous classes and methods within the classes. Object-oriented design is based on the philosophy of data encapsulation and controlled access to the encapsulated data. There are dierent representations available for object-oriented design. These representations do not give a complete picture of the programs thus restricting code analysis and preventing many testing techniques from using them. This paper discusses the issues involved in representing object-oriented programs. A representation based on the Program Dependency Graphs is designed. Dierent concepts of the paradigm are represented, including polymorphism, dynamic binding and the class inheritance hierarchy. Message exchanges between objects are also discussed and a more compact manner of representing parameter ow is presented. A second issue addressed in this paper is that of slicing in object-oriented programs. Determining an object-oriented slice is more complex than determining either an intraprocedural or interprocedural slice. It has been shown that Program Dependency Graphs are well suited for slicing procedural programs. A high level pseudocode algorithm is given, that demonstrates the applicability of the Object-oriented Program Dependency Graph for slicing object-oriented programs. Other applications based on this representation are also introduced. 1

2 Acknowledgments 2

3 Contents 1 Introduction 5 2 Background Object-Oriented Systems : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Program Dependency Graphs : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 6 3 Problem Scope Representing Object-oriented Programs : : : : : : : : : : : : : : : : : : : : : : : : : Calculating an Object-oriented Slice : : : : : : : : : : : : : : : : : : : : : : : : : : : 9 4 OPDG: A Compact Representation Overview of the Representation : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Syntax : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Vertices in the OPDG : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Edges in the OPDG : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Discussion : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Call Edges : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Parameter Handling : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Representing Polymorphism : : : : : : : : : : : : : : : : : : : : : : : : : : : : 18 5 Program Slicing Slicing in Object-oriented Programs : : : : : : : : : : : : : : : : : : : : : : : : : : : Polymorphic Slices : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Tracing the calling context : : : : : : : : : : : : : : : : : : : : : : : : : : : : 21 6 Other Applications of the OPDG 22 7 Related Work 23 8 Conclusions and Future Work 24 A Methodology for Slicing using the OPDG 28 A.1 Background for the pseudocode : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 28 A.2 Pseudocode Algorithm : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 29 B An Example 32 B.1 Complete Representation for the Example System : : : : : : : : : : : : : : : : : : : 32 B.2 A Slicing Example : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 34 3

4 List of Figures 1 A program segment, its CDS (left) and DDS (right) : : : : : : : : : : : : : : : : : : 7 2 Syntactic notations for dierent edges and vertices : : : : : : : : : : : : : : : : : : : 12 3 String class example in C++ with a free standing friend operator<< procedure : : : 13 4 Example representation for Control Flow and Control Dependence Edges : : : : : : 15 5 Representation of Virtual Methods and Polymorphism : : : : : : : : : : : : : : : : : 18 6 Polymorphic Slices at compile time, reduced to a single run-time slice : : : : : : : : 21 7 Class Hierarchy Subgraph (CHS), generated from header le information : : : : : : : 32 8 Complete representation for class A in the example class hierarchy : : : : : : : : : : 33 9 Complete representation for class B in the example class hierarchy : : : : : : : : : : Representation for the main program and the relation with the class hierarchy : : : Subgraph representation for the main program giving slice information : : : : : : : : Subgraph representation for class A giving slice information : : : : : : : : : : : : : : Subgraph representation for class B giving slice information : : : : : : : : : : : : : : C++ code for the example system : : : : : : : : : : : : : : : : : : : : : : : : : : : : 38 4

5 1 Introduction Object-oriented design is based on the philosophy of data encapsulation and controlled access to the encapsulated data. There are a number of object-oriented programming languages, each with a dierent set of constructs and syntax. These have led to a wide variety of software tools that are based on the syntax of a particular language. In order to bring about a generality in the software support and program analysis tools developed, a common representation has to be evolved that portrays the concepts of a design philosophy rather than the language features. A few characteristics of a good common representation are: Easy to understand Able to act as a bridge across languages Able to support a range of program analysis activities Freedom to be updated, when the paradigm grows Freedom to be tailored to a particular language There are dierent representations available for object-oriented design, like the Object Modeling Technique (OMT) [23] and the Interface Denition Language (IDL) [1]. These representations being design based, fail to give a complete picture of the programs they represent. Implementation details are not presented, and this prevents the complete analysis of the code. Many testing tools need important implementation details to carry out their function and hence require a representation that can provide the information. An object-oriented program is quite dierent than a procedural program. Classes and objects are central to the development of an object-oriented system. Data is encapsulated in units called classes, along with the operations on that data. Instances of classes are called objects and these are the run-time entities that depict the state of the system. An object is a directly addressable syntactic unit in a program. Thus, object-oriented program analysis involves lot more issues than that of a procedural program. This paper discusses the development of a representation for object-oriented programs based on the concept of a Program Dependency Graph (PDG). It is a parse-tree based representation, created at the time of compiling an object-oriented system. Thus, all implementation details of the object-oriented program are presented. The representation is built from the program implementation, but the nal picture gives a conceptual view to the various object-oriented concepts. Dierent concepts of the paradigm are handled, including polymorphism, dynamic binding and the inheritance hierarchy between classes. Message exchanges between objects are also discussed and a more compact manner of representing parameter ow is presented. The paper then discusses the application of the representation for slicing object-oriented programs. Various other applications based on this representation are also introduced. The following section gives a background description of the object-oriented philosophy and also talks about PDGs. Section 3 denes the problems addressed in this research, namely the representational issues and slicing as an application. A description of the Object-oriented Program Dependency Graph (OPDG) is provided in section 4. Section 5 discusses the topic of slicing objectoriented programs in the context of the OPDG. Some other applications for this representation are given in section 6. Related work in this eld is acknowledged in section 7 and future work in extending this representation is discussed in the last section. Appendix A gives a pseudocode that demonstrates the applicability of the OPDG in slicing. An example program is used to present the various capabilities of the OPDG in appendix B. 5

6 2 Background 2.1 Object-Oriented Systems The object-oriented paradigm places the emphasis on the relationships between the objects as the fundamental part of the system architecture. A class is a conceptual denition of a collection of data items, and operations on that data. Objects are instances of a class, and are those units that are syntactically addressable in a program [16]. The object-oriented paradigm's design principle is to build the system in an incremental fashion. A hierarchy of classes is developed, and specialized classes are constructed as we move down the hierarchy. Similarly, classes with more generalized features are seen as we move up the hierarchy. In other words, the inheritance relation is used to express specializations and generalizations of the concepts represented by the classes. Inheritance is a relation between classes that allows denition and implementation of a class to be built on another. Inheritance proposes reuse of software units, like pre-designed classes and hence is a major structuring principle in the design of object-oriented systems[22]. Another concept that stands prominently in an object-oriented design is polymorphism and dynamic binding of messages to methods. Polymorphism in an object-oriented sense means that over time, object references can be to more than one class. As such, a polymorphic reference has both a static and a dynamic type associated with it[16]. The static type is the type with which the object is associated at declaration time and the dynamic type is the one that exists at run-time and is susceptible to change. Classes are composed of data members and methods which form the attributes of the class. A method in a class is invoked by sending a message to an instance of that class. Objects interact in an object-oriented system by exchanging messages. Since the data members are encapsulated within the boundaries of the class scope, very few parameters are used along with the message calls leading to a more clear and compact message exchange mechanism. 2.2 Program Dependency Graphs A Program Dependency Graph (PDG) [13] is a graphical representation of a program that encodes both control and data dependencies into a single structure. For given statements X and Y in a program, the two statements can be related to each other either through control or data ow. A statement X is said to be control dependent on another statement Y, if there are at least two paths out of Y, with one path always leading to the execution of X, and the other may result in X not being executed. A statement X is said to be data dependent on Y if there is a path from Y to X, and there exists a variable that is dened at Y and used at X, but not redened anywhere else along the path from Y to X. A PDG is formally dened to have a Control Dependence Subgraph (CDS), a Control Flow Graph (CFG) and a Data Dependence Subgraph (DDS) [21]. Control Dependencies in a program are encoded in the CDS. The CFG describes the ow of control in the program and is similar to a owchart in the normal sense. A DDS is a graph that incorporates all the data dependencies among the statements in a program. Figure 1 depicts a program segment and the corresponding CDS and DDS for this program segment [17]. A CDS contains several types of vertices. Statement vertices, such as S1 and S3, represent statements in the program. Region vertices, such as R1 and R2, summarize control dependencies for statements in the region. Predicate vertices, from which two edges may originate, represent decision or branch conditions in a program. Region vertices in the CDS are used to group statements with the same control dependencies. For example, in Figure 1, statement vertices 6

7 S1 C2 R1 R2 P2 T R3 S1: n = 2; P2,C2: while(n <= 100){ S3: S4: P5,C5: S7: S8: div = 2; flag = 1; while(flag && div <=n/2){ P6,C6: if(n % div == 0) P9,C9: S10: S11: flag = 0; div++; } if(flag) cout << n; n++; } S1 C2 R1 R2 P2 R3 S3 S4 R4 R5 S11 S3 S4 R4 R5 S11 C5 P5 T R6 C6 P6 S8 T R8 C9 R7 S10 T P9 C5 P5 R6 C6 P6 S8 R8 C9 R7 S10 P9 S7 S7 Figure 1: A program segment, its CDS (left) and DDS (right) S8, C6 and the predicate vertex P6, are all control dependent on the predicate P5 being true. Furthermore, vertices S3, S4, R4, R5 and S11 are all in the same region R3 and thus, have the same control dependencies. Control ow information, for a structured program, is incorporated into the PDG, implicitly by ordering the vertices and explicitly by adding backedges for loops [21]. In Figure 1, vertices S3, S4, C5 and P5 are ordered as they appear in the source code, which also indicates the ow of control for these vertices. The back edges from vertex S8 to R4 and S11 to R2, indicate explicit ow of control from the bottom of the while loop to the top of the loop. Another subgraph of the PDG is the DDS that encodes data dependencies among statements. The DDS for our program segment is also illustrated in Figure 1. The DDS is constructed by inserting edges between vertices in the CDS to represent data dependencies. For example, in the DDS of Figure 1, there is an edge from the denition of n in S1 to the use of n in S11. For clarity of presentation, the DDS of the PDG is not discussed in the remainder of this paper. A PDG is dened usually for a single procedure program. In order to make it more realistic, we have to consider a representation that matches the real world programs, that are made up of multiple procedures. A System Dependence Graph [25], is a decorated parse tree of the program. Formally, a SDG is a directed, labeled multigraph that consists of a program dependence graph 7

8 and a collection of procedure dependence graphs. The program dependence graph models the main program and the latter model the procedure bodies in the software system [20]. The SDG also handles interprocedural ow of data and control, and the representation for the transfer of parameters. Dierent techniques are seen in the literature that discuss issues about parameter handling. Some of the techniques are based on work done by Horwitz et al in [25], Harrold et al in [8] and Livadas and Scroll in [19]. Each paper discusses the pros and cons of the dierent approaches. We considered the various techniques and an eort was made to pick up the good points in each technique, to suit our requirement of representing object-oriented programs. 3 Problem Scope Object-oriented software development, like other paradigms, consists of the design, analysis and implementation phases, followed by testing. These phases can be structured to follow one another or the process could be iterative such that the phases are done over a cycle and repeat at the end of it. There are many object-oriented languages in the industry, and each language has its own set of syntax rules, and implementation requirements. These languages have their own boundaries although they follow the same concepts. Compatibility between the languages and inter-language transformations are limited. Software support and program analysis tools are built every other day, but these are bound to a particular language. A common software tool should be like a bridge between the languages and designed to work on a representation that can stress on the concepts of the paradigm the languages represent rather than the specic language features. The scope of the problem handled in this research spans over two issues. The rst is the design of a suitable compact representation for object-oriented programs [17]. An addendum to the problem discussed is that of retrieving a slice for an object-oriented program, given the compact representation. The following sections discuss the two issues in more detail. 3.1 Representing Object-oriented Programs There are a few representations for object-oriented programs that come close to being general, like Rumbaugh's Object Modeling Technique (OMT) [23] and Object Management Group's Interface Denition Language (IDL) [1]. Another representation for object-oriented programs is the extension to the formal specication language Z, namely Object Z [6]. All these representations have their own limitations, that of being at the design level, and hence do not provide a complete picture of the software system. The OMT model represents classes and relations between the classes. This also supports supplementary models to represent the functional and dynamic state of the system. All the information represented is at the design level, and hence does not provide a complete detailed picture of the program. The IDL, although provides opportunities to have a bridge between the tools that use IDL, fails to give a representation with enough details to perform either code analysis or structural or functional testing. IDL is a language by itself, and has all the constraints and domain problems that go in with a \language". These representations, although good, in certain respects lack the details necessary to perform compiler optimizations and prevent most structural and functional testing tools from being operative on them. In order to achieve a clear representation of a program, a language independent representation should be designed. The language features from dierent object-oriented languages should be absorbed and a stable representation that depicts the concepts rather than features of a language, should be evolved. 8

9 From the survey of the many representations for procedural programs, we found that the one most widely used and that has a large variety of applications built on it, is the Program Dependency Graph (PDG). There are dierent versions of the PDG, each with an extension of the formal denition given by Ferrante et al [13]. As an object-oriented system consists of a number of messages between its constituent objects, the representation should be capable of depicting interprocedural dependencies, along with the other concepts of the paradigm namely, polymorphism, dynamic binding, classes and objects, and inheritance. The versions of a PDG that come close to our requirements for representing object-oriented programs are the interprocedural dependency graphs. Some interprocedural versions of a PDG are the System Dependency Graphs (SDG) rst introduced by Horwitz et al [25] and extended by Livadas et al [19], the Unied Interprocedural Graph (UIG) by Harrold et al [8], the Call Graph by Ryder [3], Lakhotia [18] and others, and the Program Summary Graph by Callahan [4]. Although an interprocedural representation can depict an object-oriented program as a set of interlinked procedures, connected through call and return edges, there is a gap when it comes to representing the procedures as methods of a class. Issues like polymorphic references need special attention, since they are not resolved until run-time, and we found no representation that could handle this suitably. Instantiation of objects from classes gives rise to the problem of handling various objects that have dierent \states". A technique to represent the various concepts would not be possible with the existing variations of a PDG. We needed an enhanced version of a PDG to arrive at our goal of a representation with as much detail as possible at the implementation level for an object-oriented program. This research work concentrates on bringing the important conceptual features of an object-oriented program in the form of a clear visible representation form [17]. The representation is an extension to the PDG and is termed, the Object-oriented Program Dependency Graph or the OPDG. 3.2 Calculating an Object-oriented Slice The slice of a program with respect to a program point p and variable x consists of all statements and predicates of the program that might aect the value of x at point p [26]. Horwitz et al give a general denition of a slice [25]. A slice is dened with respect to a program point p and a variable x that is dened or used at p. We consider this denition of a slice in the remainder of this work. It is evident that the value of x is inuenced by the control structure enclosing the statement and the values of other variables at p. Intraprocedural slicing is a matter of determining which of the statements aect a variable at a particular statement in a single procedure body. The problem is more severe when we talk about interprocedural slicing where a program with multiple procedure bodies has to be considered, and the slice spreads across these procedure bodies. The major problem encountered in determining slices across procedure bodies is the handling of parameters and ow of control and data across procedures. Pioneer work in interprocedural slicing has been done by Weiser [26], Horwitz et al [25], Gupta et al [11] and Livadas et al [19] among others. Slicing an object-oriented program requires more information than slicing a procedural program, even with multiple procedure bodies. A PDG provides sucient information for a slicing tool to retrieve the slice for a statement-variable combination [14][19]. Slicing techniques based on the PDG are not sucient to handle object-oriented programs. This is a continuation of the point raised in section 3.1, that PDGs do not provide a complete representation for object-oriented programs. The existence of polymorphic references and hence dynamic binding of methods to messages, makes the situation more complex. An uncertainty exists in the system until all the polymorphic references to the methods in the system are resolved. As such, developing a slice is not straight 9

10 forward and requires a suitable representation to work on. The representation developed by us for object-oriented programs presents the dierent concepts in a clear way, with the focus being on the concepts rather than on the features of a particular language. Slicing is discussed in this work as an application of the representation and a high level pseudocode algorithm is given in Appendix A to demonstrate the same. 4 OPDG: A Compact Representation The problem dened in section 3.1 derives its content from the fact that there is a lack of a suitable representation for object-oriented programs at the implementation level. The representation developed as a part of this work is based on the concept of the Program Dependency Graph. Like object-oriented systems, even the representation is designed for incremental growth. In other words, given a class inheritance hierarchy, the representation is built for the base class, and then for the subclasses down the hierarchy. The representation is in three layers, namely the Class Hierarchy Subgraph (CHS), the Control Dependence Subgraph (CDS) and the Data Dependence Subgraph (DDS). The breaking up of the representation into dierent layers gives the user an opportunity to concentrate on a part of the representation that suits his/her requirements. Thus a minimum amount of information is retained for a particular purpose. The base layer of the representation is the Class Hierarchy Subgraph (CHS). The CHS is a graphical representation of the inheritance relationship between classes and the composition of methods into a class denition. Each CHS includes a Class header vertex for each class and a Method header for each method dened in the class. Edges in the CHS also connect each Class header to corresponding headers of other classes with which it has an inheritance relationship. Methods are represented by their headers connected to the Class header for the class in which they are dened. Subclass representations do not have representations for methods dened in the superclass thereby eliminating repetitive representations for inherited methods. The CHS is not a complete static representation of the program since it does not represent any implementation details of the methods. However, this level of information is enough for certain algorithms such as the Hierarchical Incremental Testing (HIT) [9] procedure, to provide useful information. The CHS at this stage represents the program after basic class design. The second layer is the Control Dependence Subgraph (CDS). The implementation for each method is included in this representation. Since this is a static representation, some information cannot be completely resolved. For example, the recipients of those messages that will be dynamically bound cannot be uniquely determined. The representation identies the set of classes that are polymorphic substitutes for the formally specied recipient. This is a complete static representation that is capable of supporting a number of analyses such as that required for register allocation. The third layer is the Data Dependency Subgraph (DDS). The run-time environment for an object-oriented program is more complex than that for a procedural program. At this level, objects are added to the representation. This allows complete resolution of dynamically bound messages to specic methods in objects. Other traditional types of data dependency information are represented and provide support for a variety of both static and dynamic analyses. This level of representation provides information for dierent applications such as debugging, dynamic slicing and other analyses. The union of the three subgraphs is the Object-oriented Program Dependency Graph (OPDG). The OPDG provides a comprehensive view of an object-oriented program. Dierent object-oriented concepts are represented in a subtle and clear way, for easy understanding and applicability to 10

11 various applications. Some interprocedural PDGs are constructed as and when a procedure call is processed in the program. As such, the representation for the program system consists of only the procedure bodies that were called at any instant of program execution. This method of generating the representation can be termed as a program control driven representation, since the representation can change if the control sequence in the program changes. An advantage of such a method is that procedure bodies not called, are not represented. This is the typical manner in which dynamic processing tools work. Agrawal et al [2] dene the Dynamic Dependence Graphs using this technique of building PDGs. A disadvantage is that the representation has to be constructed from scratch for the called procedure during each execution and an independent per-procedure representation cannot be saved. The OPDG is developed as the classes are compiled and hence complete class representations can be constructed. A major advantage of this method over the one described in the previous paragraph is that the representation has to be generated just once during the life cycle of the class and does not need to be changed as long as the class denition remains unchanged. The representation for a class can be saved in a OPDG library, and can be retrieved similar to the retrieval of class implementation from a class library. The following section gives an overview of the representation, and a detailed description of the various edges and vertices in the representation is given in section Overview of the Representation In order to represent an object-oriented program from a compile time view point, the important features of the paradigm have to be represented. The syntactic units of the OPDG are built upon the notations used in Program Dependency Graphs. Dierent notations are used for dierent kinds of edges and vertices in the representation. The notations are developed so that they relate to concepts as much as possible. An eort was made to extrapolate on syntactic denitions developed by prior work in the area of PDGs. New concepts that relate to the scope of this work are represented with new notations. The complete generation of the representation for an object-oriented program is accomplished in two stages. The rst stage involves the building of the basic representation and this is nothing but the Class Hierarchy Subgraph (CHS). To build the CHS, the header les for the classes and the main program are sucient. These les depict the inheritance hierarchy and describe the classes with regard to their public interface, methods used for their internal implementation purposes and their data attributes. Similar to the inheritance hierarchy in object-oriented programs, the representation is incrementally built starting from the base class and traversing down the hierarchy. The representation for a given class includes the class header with its connections via edges to any superclass(es) and methods, dened and inherited. Class scoping is incorporated into the CHS by representing the class membership of its attributes, namely the methods and the data items. Method calls can be dynamically bound or methods can be dened in a superclass and inherited in the subclass. A key feature of our representation is the ease with which important object-oriented concepts like polymorphism and a message to an inherited method are represented. The representation gives an understandable picture for polymorphism and dynamic binding. Instead of representing the implementation point of view of the concepts, the representation depicts a language independent picture. The following section gives a detailed description of the dierent edges and vertices in the OPDG. Examples are given to illustrate the subtle concepts which led to the design of this representation. 11

12 4.2 Syntax The basic diagrammatic notations for the dierent edges and vertices in the OPDG are illustrated in gure 2. In this paper we have restricted the discussion to the representation of the CHS and the CDS vis-a-vis object-oriented programs. Discussions regarding the DDS form the third layer in our representation and this is a subject of future work. Edges Vertices Control Edges Explicit Flow Headers Class Dependence Call Simple Call Instantiation Polymorphic Call Polymorphic Choice Method/Procedure Virtual Method Statements Primitive Call Membership Edges Inheritance Procedure Return/Exit Others Predicates Class Membership Regions Inherited Method Parameters Figure 2: Syntactic notations for dierent edges and vertices Vertices in the OPDG The dierent vertices (see gure 2) used in our representation of an object-oriented program are: Headers Headers signify the beginning of a collection of representable entities with a syntactic analogy to the actual code. { Class A Class header signies the grouping of all the methods and data attributes in the class. It also takes part in representing the inheritance hierarchy between the classes. The Class header contains a list of methods dened in the class, pointers to all the inherited methods, and links to any superclass(es) or subclass(es). Information regarding the data members of the class are also available in the Class header. { Method/Procedure A Method or a Procedure header is the entry vertex for the corresponding method or 12

13 #include <iostream.h> class String{ public: String(const char *); virtual ~String(); virtual void do_some_oprn_on_str(); friend ostream& operator <<(ostream& os, String& s); private: char *str; }; ostream& operator<<(ostream& os, String& s) { if (s.str==null) return os << <empty> ; return os << s.str; } Enter String Dependency Graph for String Enter operator << Dependency Graph for operator<< Enter ~String Dependency Graph A for ~String Procedure CLASSHDR(String) Free-Standing Virtual methods Enter Dependency Graph for do_some_oprn_on_str do_some_oprn_on_str Figure 3: String class example in C++ with a free standing friend operator<< procedure procedure. Its representation is similar to the entry vertex of a procedure as given in [21] or [25]. The Method header adds additional meaning to the representation by encapsulating information such as the class to which it belongs, data attributes of the class and parameter translation from actual to formal and vice-versa. The Method header also forms one of the end points of the Class Membership edge. Free standing procedures are seen in a few object-oriented languages, and are such that they are not bound to any class (see gure 3). A header for such a Procedure is identical to the Method header but has no attachment to any Class header. The scope of the procedure is the program environment or the le at the least. The scope of the method is dened by its access privileges that indicates whether it is public or private. { Virtual Method Some object-oriented languages allow all the methods in a class to be dynamically bound. In contrast, C++ restricts the choice of methods that can be dynamically bound by having the keyword virtual before the method declaration. We use a similar approach to distinguish between the methods that can and cannot be dynamically bound. This helps understand the representation for polymorphism and dynamic binding easier. A virtual method is a special member of a class, since a reference to this method, if polymorphic, would have to be resolved dynamically. As such, an enhanced representation is provided for the header of a virtual method. The Virtual Method header, along with the Polymorphic Choice edge plays a signicant part in explicitly representing dynamic binding. Except for the additional features added to the representation for a Virtual Method header, all other features like class membership and class scoping resolution, are similar to that of a Method header. Figure 3 gives the representation for an example String class in C++ and an associated friend operator<< procedure. In the representation, the operator<< procedure is not attached to any Class header, as it is a free standing procedure. 13

14 Statements { Primitive A Primitive Statement vertex represents a statement that carries out some part of a computation and does not result in either a call to a method or a procedure, or a return or exit from the procedure. { Call A Call vertex represents a call to the method or procedure at the call site. This is the starting point for the dierent call edges in the OPDG, namely, the Simple Call edge, the Instantiation edge and the Polymorphic Call edge. The dierent types of Call edges listed above are discussed in section { Procedure Return or Exit A Procedure Return or Exit vertex signies the last statement to be executed in that control ow path. Others { Predicates A Predicate vertex represents the predicate part in a conditional statement. { Regions A Region vertex groups statements with the same control dependencies. { Parameters Parameter vertices are used to signify both actual and formal parameters. For every in parameter, actual and formal, we have one Parameter vertex. If the parameter is such that it may-be-modied, then we have a Parameter vertex each for the formal and actual out parameters. More about this is in section Edges in the OPDG Syntactic denitions for the various edges in our representation are as given in gure 2. A brief description for each type of edge is given below. Control Edges { Flow Edges These are uni-directional edges that depict the explicit ow of control in the program. Implicit ow is denoted using the left-to-right notation of [21]. In gure 4, for the example code segment given, implicit ow of control is represented between the statements S20, S21 and S22 using the left-to-right notation. A few instances of explicit control ow are return to the beginning of a while-loop, an exit or a break statement and an exception. The back edge from S22 to the region vertex R1 depicts the explicit ow to the beginning of the while-loop. { Dependence Edges These are uni-directional edges that show control dependence between the vertices in the representation. Consider the example in gure 4. The edge from R2 to S20, signies that execution of the statement represented by S20 during program execution depends on the control entering the region represented by R2. It should also be noted here that Control Dependence Edges always start from the Region, Predicate or Method/Procedure vertex. 14

15 . R1 P19,C19: S20: S21: S22:. while(c==10){ a = 7*num_cycles; b = restart_flag; c = a * b + 15;; } C19 P19 R2 Explicit Flow Edge Control Dependence Edge S20 S21 S22 Figure 4: Example representation for Control Flow and Control Dependence Edges { Call Edges These edges start from the call site but the end point depends on whether the call is to a free standing procedure or to a method. A Call edge to a free standing procedure ends at the Procedure header, whereas for a method, which is a member of a class, the edge terminates at the Class header. A more detailed description of Call edges is given in section Simple Call A Simple Call edge represents a call to a method or a free standing procedure. This edge represents a call that can be resolved statically and represents the ow of control and data between the call site and the method or procedure called. Instantiation Instantiation in object-oriented programs means the creation of an instance of a class. This is done by a call to the constructor of a class which initializes the object state and brings it into the system 1. A special edge is used to represent the importance of an instantiation call. The Instantiation edge connects the instantiation statement to the Class header whose instance is created. Polymorphic Call A call is said to be dynamically bound if it is not possible to resolve the call to a particular method at compile time. The Polymorphic Call edge is used in the representation of polymorphism and dynamic binding and is discussed in more detail in section Briey, the Polymorphic Call edge is an edge between the call site and the Class header of the class to which the variable is statically typed. The class variable can be made to point to, an instance of the class whose static type it is or any of its subclasses. { Polymorphic Choice Edge A Polymorphic Choice edge connects two members in the set of possible implementations to which a polymorphic reference can be resolved at run-time. This edge starts at a Virtual Method header (see section 4.2.1) in a superclass and terminates at the header 1 In C++, a call to the constructor is implicit and is done at the point of instantiation of an object. In Smalltalk, the call is done explicitly. 15

16 for another virtual method with the same specication in the subclass. A polymorphic reference to a superclass virtual method, can be resolved to any virtual method in the hierarchy from that level downward. The Polymorphic Choice edge plays an important role in depicting polymorphism in the OPDG. Whenever a polymorphic reference is encountered, the reference is resolved by searching the list of possibilities for that reference, connected by the Polymorphic Choice edge. Membership Edges The concept of an entity being a member of some other bigger entity is used to group similar parts of the representation. Grouping of such similar entities allows easier understanding of the representation. { Inheritance The inheritance hierarchy is the backbone of object-oriented design philosophy. The Inheritance edge signies membership of classes in an inheritance hierarchy and connects a subclass to it's superclass(es), in the direction of dependency. { Class Membership Every class denition has a xed number of methods associated with it. As such, each method, including the constructors and destructors of a class, belongs to that class and is addressable only through an instance of that class (or the class itself in case of some object-oriented languages). A Class Membership edge connects the Method header and the Class header of the class in which the method is dened. { Inherited Method A method is said to be inherited if it is dened in a superclass and is inherited into a subclass. The inherited method is just like any other method in the subclass, and is also addressable in a similar way. Thus, an inherited method can be considered to have an implied membership in a subclass. The representation highlights this aspect, and the Inherited Method edge connects the subclass header to the header of the inherited method. 4.3 Discussion This section discusses the syntactic denitions given in the previous section. The discussion concentrates on the important edges and vertices dened for an OPDG that makes our representation suitable for object-oriented programs. Major issues handled by this include representation of polymorphism and dynamic binding, the inheritance hierarchy and a modied representation for handling parameters and parameter ow Call Edges The Call edge to a method terminates at the Class header rather than the Method header. We use this approach to represent dynamic binding and to resolve issues of inherited method calls. The header of a class is equipped with information regarding its member functions, inherited methods, its place in the hierarchy, and its data attributes. We include in the OPDG, all static information necessary to resolve run-time issues about dynamic binding of a call to a method. Consider the following declaration statements in C++: C *c1; C c2; // C is a class in a hierarchy // c1 and c2 are instance variables 16

17 Both c1 and c2 have a static type of class C. However, c1 can have a dierent dynamic type [16], if there are subclasses inheriting from C, since c1 can be made to point to an instance of C or any of its subclasses. Whenever a message is sent to an object whose static type is the class C, the Call edge terminates at the Class header for C. Thus, in our representation, a Call edge representing a call to a method, terminates at the header of the class that dictates the static type of the object. Consider the case of c1 above. A message to a method in an object instance pointed to by c1 can be dynamically bound provided dynamic binding to the method is allowed by the method's declaration 2. If the call is dynamically bound, the call is traced down to the actual implementation of a method to execute using the Polymorphic Choice edge and thus the dynamic reference is resolved. If the message is to an inherited method, it can be traced using the Inherited Method edge from the Class header to the header for the inherited method. If the Call edge to an inherited method was to terminate at the Method headers, then tracking the denition site for the method would be a problem. Although the object is an instance of a subclass, the Call edge would be pointing to a method dened in a superclass. By making the Call edge terminate at the Class header, we eliminate the additional clutter due to the connections between call sites and headers for inherited methods. Thus, inherited method calls and polymorphic calls are now processed in a manner similar to a call to a method that is dened in the class. The uniformity with which a message to a method can be traced out makes this representation compact Parameter Handling Object-oriented systems exchange a number of messages between their constituent objects. These messages pass control to the objects, and request operations to be performed on the data attributes within the object. The scoping rules prevent direct public handling of data and hence any operation on the data can be done only through a method in the interface of the object. Messages in object-oriented programs contain parameters to exchange information and hence handling of parameters is another problem we solve in this paper. The traditional technique of handling parameter ow is to have additional edges between the call site and the called procedure, connecting the actual and corresponding formal parameters [25][20][8]. Since a number of messages are exchanged in an object-oriented system, this technique makes the representation cluttered and dicult to manage due to the excessive edges. Each message includes the Call edge, and along with it, at least one edge for each parameter (two for a pass-by-reference parameter). The reason for these additional edges is to depict the ow of information between the actual and formal parameters. We expand the meaning of a Call edge to represent parameter ow in both directions, namely, from the call site to the method or procedure, and vice-versa. This additional meaning to the Call edge eliminates the edges between the actual and formal parameters thereby leading to a clearer representation. The in-parameters are represented by Parameter vertices at the call site and the method or procedure header. Parameters that may-be-modied are each represented by a Parameter vertex at the extreme right of the call site and the Method or Procedure header. A one-to-one mapping is dened between the Parameter vertices at the actual and the formal sites. Thus, edges between 2 In C++, this means that the method is virtual. 3 Recollect that a call to a free standing procedure is also represented by a Call edge, but this edge terminates at the Procedure header, since the procedure is not bound to any class. 17

18 the actual and formal Parameter vertices are obviated, making the representation more straight forward and easier to understand Representing Polymorphism A polymorphic reference in an object-oriented language can, over time, refer to instances of more than one class [16]. Thus a polymorphic reference has both a static and a dynamic type associated with it. Polymorphism is associated with dynamic binding since the binding of a polymorphic message to the code to be executed in response to the call is accomplished dynamically. This means that the code associated with a given procedure call is not known until the moment of the call at run-time. The resolution of the polymorphic reference at execution time is done based on the dynamic type of that reference. The representation reveals a static view to this dynamic feature of the object-oriented paradigm. Polymorphism is explicitly represented using the Polymorphic Call edge, the Virtual Method headers and the Polymorphic Choice edge. A Polymorphic Call edge is a special edge that represents a call to a method (specically, a virtual method in C++). Polymorphic references are so termed because the references may be to more than one class. As such, the call can be bound to an implementation for a method with the same specication in any of the classes down the hierarchy. In our static representation of the potential run-time environment, this feature is represented by attaching a list of virtual methods to the Polymorphic Call edge. Once the polymorphic reference is resolved at run-time, the actual reference is used to access a method in the list and this method gets executed. CLASSHDR(A) C++ Code Example: Enter do_something Enter A Enter ~A class A{ public: A(); virtual ~A(); virtual void do_something(); }; CLASSHDR(B) class B : public A{ public: B(); ~B(); void do_something(); }; Enter do_something Enter B Enter ~B Figure 5: Representation of Virtual Methods and Polymorphism The representation of virtual methods and the concept of polymorphism is illustrated with an example as shown in gure 5. The virtual method void do something() is redened in class B. The destructor of base class A is declared virtual (following safe class design principles). The destructor in class B is also virtual since the destructor of the base class of the hierarchy is virtual. Since 18

19 polymorphic calls in C++ can only be to virtual methods, each virtual method in a class has a Polymorphic Choice edge to a method with the same specication at the next level in the hierarchy (edge between the do something methods in classes A and B). An exception to the signature rule given above is the Polymorphic Choice edge between destructors of classes in the hierarchy, provided a superclass destructor is virtual (edge between the methods A() and B() in the example). Virtual destructors of a base class allow dynamic resolution to the destructor of any of the subclasses in the hierarchy and not otherwise. Tracing the Polymorphic Choice edge from a Virtual Method header down the hierarchy will lead to the set of possible methods that can be dynamically bound to a polymorphic call. Our solution is to maintain information about the incremental growth of the set of possibilities for the polymorphic call. As the representation is built, the Polymorphic Choice edges are created between a virtual method in a class and its namesake method in its subclass. As classes are developed in a progression down the hierarchy, more choices are linked together. 5 Program Slicing The slice of a program with respect to a program point p and variable x consists of all statements and predicates of the program that might aect the value of x at point p [26]. There are dierent applications of slicing, few of them being isolation of individual computation threads within a program, understanding complicated code, debugging, automatic parallelization and code reusability. Horwitz et al give a general denition of a slice [25]. A slice is dened with respect to a program point p and a variable x that is dened or used at p. We follow this denition in the rest of the paper as we are more interested in the slice on a variable used or dened at a program statement than an arbitrary variable. The value of x is inuenced by the control structure enclosing the statement and the values of other variables at p. An interprocedural slice is more complex than an interprocedural slice. Important issues to be considered while determining slices across procedure bodies are ow of data and control across procedures, and parameter handling. The basic requirements for the process of obtaining the slice are the data and control ow information. A Program Dependency Graph (PDG) provides the control ow, control dependence and data ow information. It was shown by Ottenstein and Ottenstein [14] that PDGs are well-suited for program slicing. Once a PDG has been developed for a given program, determining the slice with respect to a program point and a variable, is similar to a vertex reachability problem. 5.1 Slicing in Object-oriented Programs Our research has brought out a representation for an object-oriented program on the lines of a PDG. This is the Object-oriented Program Dependency Graph (OPDG). The OPDG has notations to represent classes, interactions between classes and the main program body, the inheritance hierarchy between the classes, polymorphism and dynamic binding. The slice of an object-oriented program can have two dierent interpretations, namely: The slice is based on a variable x and a statement p in the main program or any other free standing procedure. The slice is based on a variable x and a statement p inside a method in the class. The variable in this case could be a local variable for that method, a global variable or a data member of the class. 19