Identifying function-level code dependency by simulating runtime binding转让专利
申请号 : US13619897
文献号 : US08793667B1
文献日 : 2014-07-29
发明人 : Andrew Huang , Hong Yan
申请人 : Andrew Huang , Hong Yan
摘要 :
权利要求 :
What is claimed:
说明书 :
This application is a continuation of U.S. patent application Ser. No. 11/681,905, filed Mar. 5, 2007, the content of which is hereby incorporated by reference in its entirety.
1. Field of the Invention
This invention pertains to computer software development tools.
2. Description of the Related Art
Some complex software systems must execute with high availability. This requirement means that any downtime or other disruptions to the systems must be minimized. For example, it is desirable to make major electronic commerce websites highly-available because any downtime results in lost revenues. Nevertheless, developers in charge of websites and other such systems often need to alter the software in order to resolve bugs, introduce new functions, and/or otherwise improve it. Therefore, it is an ongoing challenge to alter complex software systems without significantly impacting the systems' availability.
One technique for updating a website or other software system requiring high-availability is to use multiple servers running different versions of the software. The software on one set of servers can be upgraded while the website is run from another set of servers. However, this technique is often difficult to implement. For example, consider a software system that frequently accesses database tables. Any updates to the database schema often result in downtime of the affected tables. Moreover, the changes to the schema might affect any version of the software, meaning that one cannot simply run a website using an old version of the software while changing the database. Similarly, some software and hardware systems are structured in ways that make it difficult or impossible to run different versions of the software on different servers. As a result, there are high costs associated with modifying high-availability software systems.
Another technique for modifying high-availability software systems is partitioning the functionalities of the software systems into different sets. One set of functions is left running, while the other set is brought down (i.e., disabled) for maintenance. For example, one can partition the software for a website into core and non-core functions. The non-core functions are brought down temporarily while they are modified. The core functions, in contrast, are modified using specialized techniques that support high-availability.
A problem with this latter technique is that complex software systems are often difficult to partition. Typically, it is easy to identify the entry-points functions that provide a particular function. However, it is difficult to identify other functions and/or database tables that are used by those entry-point functions. This problem is particularly acute for object-oriented programming languages that use late binding (runtime binding) techniques. With these languages, the actual function invoked by a call is not known until the system executes. Late binding thus makes it difficult to perform a static analysis (i.e., compile-time analysis) of the system to identify functions and/or database tables used by other functions. Class-level dependency tools can be used to analyze the system but such tools often produce an explosion of dependencies that include almost the entire code base. While it is possible to do a runtime analysis (i.e., code trace) of the software system using test input data, the test data might not cover all code branches and result in an incomplete partition.
Therefore, there is a need in the art for a way to identify a set of code and/or database tables that can possibly be accessed by a given function in order to support partitioning and other types of analyses that does not suffer from the problems described above.
Methods, systems, and computer program products consistent with the principles of the invention address this and other needs by analyzing a software system having runtime binding.
In accordance with an aspect of the invention, a computer program product and computer-implemented system include an entry point identification module for identifying an entry point of the software system, a simulation module for simulating runtime binding in the software system from the entry point, and an analysis module for analyzing results of the simulated runtime binding to identify portions of the software system that are potentially invoked from the entry point.
In accordance with a further aspect of the invention, a method includes identifying an entry point of the software system, and creating two or more nodes, one or more edges connecting the nodes, and one or more entries associated with the nodes in a graph data structure, a node representing a class in the software system that is potentially instantiated if the software system is executed from the entry point, an edge representing a relationship between the classes represented by the connected nodes, and an entry identifying a function within the class represented by the associated node that is potentially invoked if the software system is executed from the entry point. The method further includes examining the graph data structure to identify classes that are potentially instantiated and functions that are potentially invoked when the software system is executed from the entry point.
The figures depict an embodiment of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.
The server 110 includes one or more computers for executing the software system 112. For example, the server 110 can be a standard desktop computer system executing the software system 112, or multiple blade servers working together to execute the software system in a parallel and/or distributed manner. In one embodiment, the database 114 is a relational database having tables with rows and columns that are accessed by the software system 112. As with the server 110, the database 114 includes one or more computers for maintaining and controlling access to it. In one embodiment, the server 110 and database 114 collectively provide a website such as an electronic commerce (ecommerce) site having high-availability requirements.
In one embodiment, the software system 112 includes executable code developing using an object-oriented programming language such as JAVA® or C++ that has objects and functions (also called “methods”). In one embodiment, the software system 112 itself is represented as JAVA® byte code. A JAVA® virtual machine compiles the byte code into native code for the computer system at runtime. In one embodiment, the software system 112 uses runtime (late) binding. In runtime binding, an identifier such as a function (and method) name is not bound to a value (e.g., the actual function) until the code is executed. Thus, the particular function invoked on an object is not necessarily known until the code itself is executed.
Further, in one embodiment the software system 112 uses an object-relational mapping with the database 114. In this type of mapping, each object and/or function in the software system 112 is associated with a particular table or tables in the database 114. Thus, if one knows the particular classes/functions invoked during runtime, one can also determine the database tables that were accessed or potentially accessed during runtime.
In one embodiment, the server 110 executes an analysis tool 120 that a developer uses to analyze the software system 112. The analysis tool 120 simulates runtime binding of the software system 112 in order to identify function-level code dependencies. Thus, the tool 120 is useful for partitioning the functions of the software system 112 into core and non-core functions. The non-core functions can then be disabled and updated, while the core functions are left active in order to provide highly-available services. The tool 120 is also useful in other situations where it is necessary or desired to identify function-level code dependencies.
As mentioned above, the server 110 and database 114 include computer systems in some embodiments. Those of skill in the art will recognize that the computer systems include conventional computing hardware including one or more processors and memories for executing and storing code and data. The code and/or data used by the computer system may be organized into one or more computer program modules. As used herein, the term “module” refers to computer program logic and/or data for providing the specified functionality. A module can be implemented in hardware, firmware, and/or software. In one embodiment, the modules are stored on a storage device such as a hard drive, loaded into a memory, and executed by a processor.
Those of skill in the art will also recognize that
The network 118 represents communication pathways between the server 110 and database 114. The network 118 can utilize dedicated or private communications links, and/or public links that travel over the Internet. In one embodiment, the network 118 uses standard communications technologies, protocols, and/or interprocess communications techniques. Thus, the network 118 can include links using technologies such as Ethernet and 802.11 Similarly, the networking protocols used on the network 118 can include the transmission control protocol/Internet protocol (TCP/IP) and the hypertext transport protocol (HTTP). The data exchanged over the network 118 can be represented using technologies and/or formats including the hypertext markup language (HTML), the extensible markup language (XML), etc. In another embodiment, the network 118 can use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above.
An entry point identification module 210 identifies the one or more entry points in the software system 112 at which to start the runtime binding simulation. In one embodiment, the entry point is identified by a fully-specified path to the function to be invoked. For example, in the web development context, an entry point is identified by a path and name such as “www.sample.com/web/software_system/Main_entry_point.class.” In one embodiment, the entry point identification module 210 receives an entry point specified by the developer and searches for it within the software system 112. The searching is performed, for example, by generating a regular expression corresponding to the specified entry point and searching the JAVA® byte code for a pattern that satisfies the expression.
A simulation module 212 simulates runtime binding by analyzing the software system 112 to identify classes that are loaded and functions that are invoked from the specified entry point or points. In one embodiment, the simulation module 212 uses a graph data structure referred to herein as a “tracker graph” to track the classes and functions. In one embodiment of the tracker graph, each node, called a “tracker node,” represents a loaded class or interface as well as the functions (methods) invoked on the class or interface. If a class or interface represented by a tracker node (node A) is a super class or an interface of a class or interface represented by another tracker node (node B), the tracker graph contains an edge from node A to node B. In one embodiment, the graphing module 212 uses regular expressions to parse byte code in a function body in order to extract functions that are invoked therein. The operation of the simulation module 212 is described in more detail below.
An analysis module 214 analyzes the tracker graph created by the simulation module 212. In one embodiment, the analysis module 214 walks through the tracker graph to identify all of the classes and functions identified therein. These classes and functions are potentially instantiated/invoked if the software system is executed from the specified entry point. In one embodiment, the analysis module 214 generates a report describing the tracker graph. The report can include, for example, an output to a file stored on the computer system executing the analysis tool 120 and/or a presentation on a display associated with the computer system. The developer can review the report to determine which portions of the software system 112 and/or database 114 are used or potentially used by particular entry points. Thus, the developer can use the report to perform tasks such as partitioning the software system 112 and database 114 into core and non-core portions in order to identify portions that can be temporarily disabled for upgrading or other purposes.
In a typical embodiment, the developer specifies an entry point in the software system 112 and the tool 120 locates the entry point in the system's byte code. An embodiment of the tool 120 performs algorithm M for each function invoked from the entry point. The process of identifying the entry point and each function invoked from the entry point are not explicitly shown in these figures for purposes of clarity. Rather, the figures illustrate algorithm M starting at the point where a function invoked at the entry point is identified.
For 310 the function invoked at the entry point, the tool 120 finds the declared function (F) and its declaring class (C) in the byte code. The tool 120 determines whether function F has already been processed using algorithm M. If function F has been processed, the tool 120 exits processing of function F (and proceeds to the next function invocation if one exists).
If 312 class C is not an interface, the tool processes 314 the static initializer of class C by recursively applying algorithm M to any functions invoked by the initializer. If 312 class C is an interface, the tool 120 marks function F as processed. The tool 120 then determines 314 whether the tracker graph includes a node that represents class C. Assume for purposes of this example that the tracker graph is initially empty. Thus, the tool creates a tracker node “A” for class C.
The tool 120 then finds 352 the tracker node (node B) that represents class C's super class. If the tracker graph does not contain a node that represents the super class, the tool 120 creates 352 the node in the graph and recursively creates the nodes of any further super classes. The tool additionally creates 354 a link (i.e., a directed edge in the graph) from node B to node A. The tool 120 copies 356 all invoked functions recorded in node B to node A, if the functions are not already in node A. Further, the tool 120 recursively processes 356 each of the copied functions using algorithm M.
Returning now to
Once all of the classes and functions are processed, the tool 120 walks the tracker graph to collect 322 (i.e., identify) all of the classes and functions recorded in the tracker nodes. Thus, these collected classes and functions represent all of the classes that can be instantiated and functions that can be invoked in the software system 112 from the specified entry point. Further, in an embodiment that uses object-relational mapping to associate classes and functions with tables in a database 114, and/or maintains other mappings between classes, functions, and database tables, the collected classes and functions describe the database tables that are potentially accessed by the software system 112 when executed from the entry point. Accordingly, the developer can use the output reported by the tool 120 to partition the software system 112 and/or database 114 into core and non-core functionalities and/or for other purposes.
For purposes of
class Parent{
- Parent( ){foo( );}
- void foo( ){ }
class Child1 extends Parent{
- Child1( ){ }
- void foo( ){child1 foo}
}
class Child2 extends Parent{
- Child2( ){ }
- void foo( ){child2 foo}
}
Parent a=new Child1( );
Parent b=new Child2( );
In this sample program, a super class “Parent” has a constructor that invokes the abstract function “foo( ).” There are two subclasses of Parent, “Child1” and “Child2.” Each subclass includes a different instance of function “foo( )” that overrides the “foo( )” function declared in Parent. The “Parent a=new Child1( );” and “Parent b=new Child2( );” statements are combined declarations and initializations of instances of Parent objects based on the Child1 and Child2 classes, respectively. During runtime, these statements respectively invoke the Child1 and Child2 versions of the foo( ) function. Those of skill in the art will recognize that this program merely serves to illustrate the operation of the analysis tool 120. In real-world embodiments, the software system 112 and/or other software will be more complex but the tool 120 uses the same techniques described herein to perform its analysis.
In the context of the sample code described above,
The tool 120 adds an entry for the constructor function for Child1 to the Child1 tracker node 412. This constructor is denoted as “<init>” and is shown in
As shown in the sample code above, the function Parent.<init> invokes the foo( ) function, referenced as “Parent.foo.” Accordingly, the tool 120 adds and entry for the foo( ) function to the parent as shown in
Next, the tool 120 processes the statement “Parent b=new Child2( ).” The tool 120 determines that a tracker node does not yet exist for the Child2 class and creates a Child2 node 416 for it. In addition, the tool 120 finds the node 410 for the Parent super class of Child2 and adds a link 418 from the Parent node to the Child2 node 416.
The tool 120 adds an entry for the constructor function “<init>” for Child2 to the Child2 tracker node 416 as shown in
The tool 120 analyzes a software system 112 such that if a class is instantiated, all functions that are invoked on the class itself or on its super classes/interfaces are processed. Further, if a function is invoked on a class, all functions that are defined in the classes' subclasses, which are instantiated, are processed. The tool 120 avoids unnecessarily reprocessing functions that have already been processed, which improves performance and avoids processing cycles where a function invokes itself. In addition, static class initializers are processed because these initializers are explicitly invoked when a class loader loads a class. The tool 120, moreover, handles both interfaces and abstract classes and treats static functions and non-static functions differently since static functions do not have runtime binding. Of course, the tool's analysis is restricted to only the relevant code base.
The above description is included to illustrate the operation of certain embodiments and is not meant to limit the scope of the invention. The scope of the invention is to be limited only by the following claims. From the above discussion, many variations will be apparent to one skilled in the relevant art that would yet be encompassed by the spirit and scope of the invention.