Study of Procedure Signature Evolution Software Engineering Project Preetha Ramachandran

Transcription

1 Study of Procedure Signature Evolution Software Engineering Project Preetha Ramachandran 1.0 Introduction Software evolution is a continuous process. New features are frequently added, bugs fixed and code restructured for maintenance. Software projects often involve sources in C, C++, Java, scripts, makefiles, libraries and other files. In this project we aim to study the evolution of Java source files in a project. Source changes in Java frequently involve extending classes, adding new member variables, methods, introducing new interfaces, changing modifiers. We gather information on how often the signature patterns change. We study the addition of new classes, member methods, signature changes and modifiers changes. Software projects can use this information to study which portions of the sources are frequently changed and what is the change pattern if any. This information can be used to efficiently design better interfaces for extensibility, predict signature changes understand how the software is being changed to accommodate features. To study the evolution we used Kenyon[1,2] which is a convenient data extraction software. Kenyon helps extract the various revisions in the software repository and save this information in a database or file format. We implement a Java fact extractor which parses Java source files and class files and gathers information from each revision which is interesting to us. We then Run our analyzer over this information to gather evolution information and patterns. We used this infrastructure to analyze the evolution of Kenyon itself. SCM Repository Kenyon Local directory Java Fact Extractor Results depicting -Additions -Deletions -Return type -Modifier changes etc Analyzer Xml file for each revision containing nodes for each function Figure 1Project Algorithm Flow

2 2.0 The Algorithm Flow We used Kenyon to analyze the Kenyon repository itself. Kenyon provides interfaces to conveniently extract various revisions from the SCM repositories. Figure.1 illustrates the flow of the algorithm used in the project. Using Kenyon, we obtain the source files of the project we wish to analyze from the project's SCM repository. The Fact Extractor reads the source files, extracts data related to the method signatures and creates a graph containing information about methods, classes and their signatures. This information is then written out in a compact file format to disk. Kenyon also provides an interface to store the revision information in a database. For this project we have not used the database feature, rather directly stored the relevant information on disk. We then analyze the changes in these signatures over various revisions using the algorithm described in the Analyzer section. 2.1 Fact Extractor Projects written in Java usually involve the main development tree which mostly consists of Java sources. Projects also contain support libraries in the form of jar files and native sources written in C and C++. Sunghun Kim et al have analyzed signature change patterns for C projects[3]. We concentrate on studying the evolution of the Java portion of the sources only. We ignore any changes in the native C and C++ portions of the software. The fact extractor has the capability of parsing both the class files and Java source files in order to extract information about class and method signatures. Extracting information from a Java source file involves implementing almost all the functionality of a Java source compiler. It also involves completely understanding the language semantics. For our purpose we use the functionality provided by ANTLR[4]. ANTLR has the ability to parse the source files based on the language grammar files[4] and generate its internal representation which is a syntax tree. We selectively walk this syntax tree and gather relevant information. This scheme works very well to gather course grained information about the class file, its methods modifiers and member variables. However, it is complicated to gather information from the method bodies itself, as such information may reside in complicated expression which we may need to reduce. We found if a Java source file could be compiled using the standard Javac compiler, we can conveniently extract all the information from the Java class file. The Java class file format[5,6] is a compact and clear representation of the Java source file. It contains all the information in an easy to gather format. However, we found that some information like line numbers and variable names may not be reliably contained in the class file. Also, not all projects which made their source files available, did make their class files available. Generating their class files ourselves would require setting up the build environment which may not be easily configurable. The capability of parsing class files gives us more options to explore the caller-callee relationships in future and the ability to gather changes in binary distributions of the project and third party jar files. The Java fact extractor walks through the ANTLR syntax tree and generates a graph structure that contains a node for each class and each method. The class node contains the following attributes - hierarchy key which identifies the node as a class name of the class name of the source file if available package name

3 <graph name="system" formatversion="2"> <date>jan 31, :56:23 PM GMT</date> <id>259</id> <node name="edu.se.evolution.kenyon.configdata"> <Extends>java.lang.Object</Extends> <Implements>Comparable</Implements> <Import> edu.se.evolution.kenyon.scm.scmreposconfigspec edu.se.evolution.kenyon.util.* java.util.* net.sf.hibernate.* </Import> <Modifiers>public</Modifiers> <Package>edu.se.evolution.kenyon</Package> <SourceFile>ConfigData.java</SourceFile> <Variable>33:protected:Long:id</Variable> <hierarchy_level>class</hierarchy_level> <tag>configdata</tag> </node> <node name="edu.se.evolution.kenyon.configdata.configdata(scmreposconfigspec)"> <Modifiers>public</Modifiers> <Parametres>(SCMReposConfigSpec)</Parametres> <hierarchy_level>constructor</hierarchy_level> <tag>configdata</tag> <metrics> <Parameters_count>java.lang.Integer::1</Parameters_count> <lineno>java.lang.integer::40</lineno> </metrics> </node> <node name="edu.se.evolution.kenyon.configdata.addgraph(configgraph)"> <Modifiers>public</Modifiers> <Parametres>(ConfigGraph)</Parametres> <Returns>void</Returns> <hierarchy_level>procedure</hierarchy_level> <tag>addgraph</tag> <metrics> <Parameters_count>java.lang.Integer::1</Parameters_count> <lineno>java.lang.integer::73</lineno> </metrics> </node> <node name="edu.se.evolution.kenyon.configdata.addtorelateddata(string,java.io.serializable)"> <Modifiers>protected</Modifiers> <Parametres>(String,java.io.Serializable)</Parametres> <Returns>void</Returns> <hierarchy_level>procedure</hierarchy_level> <tag>addtorelateddata</tag> <metrics> <Parameters_count>java.lang.Integer::2</Parameters_count> <lineno>java.lang.integer::322</lineno> </metrics> Figure 2 A portion of the XML file generated by the Fact Extractor for revision 259 of the Kenyon project

4 extends information about which class it extends import strings if available modifiers that specifies if the class is public, private or protected implements - information about which interface it implements, if any members other than the methods in the class, represented as string Each node for a method which could also be a constructor contains the following attributes- hierarchy key name of the method of the form packagename.classname.functionname return type if the node does not represent a constructor modifiers parameters which is a ',' separated string of argument types parameter count line numbers exceptions that the method throws, if any After extracting this information, the Fact Extractor writes it to an XML file format, resulting in one XML file corresponding to each revision of the project. It also logs all the revisions written out in a separate file which the analyzer can read to compare revisions conveniently. Figure 2 shows a sample XML file generated from the Fact Extractor. 2.2 Analyzer The Java analyzer takes the graph structures generated by the fact extractor as the input, and sorts them based on the version dates. Two consecutive revisions are taken and compared with each other and changes recorded. The algorithm makes the assumption that the method whose name does not match the name of any of the methods in the previous version, is considered to be new. In other words, methods, variables and classes renamed or moved are also considered as new. The different steps in the comparison algorithm can be described as follows. Step 1 : For each method in the newer revision, search for the method with same name in the older revision. If no such method is found consider this method as new. Step 2: If a match is found we compare all the existing signatures of the method in the two revisions. protected:void <-(SCMReposConfigSpec,String,Date ) protected:void <-(SCMReposConfigSpec,String,Date,String,String ) Table 1 An example of parameter addition (A) in revision 87 of the Kenyon project for the function edu.se.evolution.kenyon.scm.scm.setspecprops() Step 3: If the methods in both revisions contain only one signature, then compare and record return type changes (R), modifier changes (M), parameter additions (A), parameter deletions (D), parameter additions and deletions combined (AD) and order changes(o). Parameter additions include only those cases in which the method in the newer revision has one or more parameters in addition to all the parameters of the method in the previous

5 revision. Table 1 shows an example of parameter addition. Similar logic holds for parameter deletions. AD denotes the case in which the method in the newer version contains only some of the parameters of the same method in the previous revision as well as some new parameters. Table 2 shows an example of AD. Order changes (O) are recorded for those methods which have exactly the same parameters as the method in the previous revision, but in a different order. public:void <-(SCMRepositoryInterface,FactExtractor,SystemAnalysis ) public:void <-(SCMRepositoryInterface,FactExtractor,Project ) Table 2 An example of parameter addition and deletion (AD) in revision 109 of the Kenyon project for the function edu.se.evolution.kenyon.datamanager.datamanager() Step 4: If either of the two methods contain more than one signature (i.e. the method is overloaded in any of the revisions) then create a list for each revision containing all the signatures for that method. For example, if a method foo() contains the signatures (char b) and (boolean c) in the old revision, and contains signatures (char b), (boolean c, int d), (boolean c, char g) in the new revision, then the two lists would contain list 1 (revision 1) : (char b), (boolean c) list 2 (revision 2) : (char b), (int c, int d), (boolean c, char g) For each method in list 2, search for an exact match in the list 1 and if found remove both the methods from their respective lists. At the end, each of the lists will contain methods which are in some ways different from all the methods of the other list. In the previous example, (char b) in list 2 has an exact match in list 1. So (char b) is removed from both the lists. The lists would now contain list 1 : (boolean c) list 2 : (int c, int d), (boolean c, char g) Sort the two lists based on the line number of the methods. For example, if the method with signature (boolean c, char g) exists at a smaller line number than that with signature (int c, int d), then after sorting, the lists would contain list 1 : (boolean c) list 2 : (boolean c, char g), (int c, int d) We assume that the user may have introduced new overloaded methods without disturbing the relative locations of existing methods, so the line number correlation is reasonable. If methods are rearranged, the algorithm can produce skewed results. We will need to apply stronger analysis in the future by taking into account the content of the function body and comparing them[7] instead of line numbers. Compare the n th method of list 1 to the n th method of list 2 using Step 3. Record the differences and delete the methods from their lists. In the above example, (boolean c) is compared to (boolean c, char g) and a parameter addition(a) is recorded for this method. The two lists now become list 1 : list 2 : (int c, int d) If all the methods of list 1 gets exhausted, and the list 2 is non-empty, then the

6 methods left in list 2 are considered to be the newly added overloaded methods (L). On the other hand, if the methods of list 2 get exhausted before those in list 1 then the methods left in list 1 are considered to be deleted. In our example L is recorded for void foo(int c, int d). 3.0 Results We used our project to study the evolution of procedure signatures in Kenyon. At the time of data collection there were 293 revisions containing 2047 methods. Figure 3`shows the results from our FE and Analyzer, depicting the number of methods that underwent each type of signature changes. We observe that the number of parameter additions(a) together with the number of parameter additions-and-deletions account for most of the changes. It is closely followed by the number of parameter deletions (D) and the newly added overloaded methods (L). We also found that there were more than 100 functions that were deleted. The class level changes included 27 Super Class changes, 11 modifier changes and 66 class-variable changes. Some of the longest patterns that we observed were ALDD(AD)DD, AADDL, AAAE and some of the shorter ones were AD, DL, AR, AL, RA and RD. The most commonly occurring changes were DMA, AD and L(AD). Types of Signature Changes as seen for Kenyon Additions Deletions Additions & Deletions Modifier change Return type changes Overloaded functions added Figure 3 Types of Signature Changes In order to analyze the type of changes in different revisions, we collected data in groups of 20 revisions. Figure 4 shows the signature changes graph over 293 revisions and figure 5 depicts the distribution of the different types of changes for each of the revision groups. We made the following observations. The maximum number of signature changes occurred between revision 80 and 100. We noticed all the different types of signature changes, parameter addition, deletion, return type, modifier changes and overloaded

7 functions were introduced during this time. There are a couple of windows, one at the beginning and the other after the spike in signature change activity, where we observe almost no changes. It appears that these were the periods when a lot of new classes and methods were introduced to accommodate the growth in the project and the existing methods remained almost unchanged with respect to their signatures. It is also interesting to see that during some intervals as the one between and , a number of new overloaded functions were added and were the only changes that took place during that time. Although, the overall number of parameter additions and deletions are more than the number of additions in overloaded functions, the latter appears to have a larger span over the revisions Figure 4 Change in the number of signature changes in the Kenyon project from revision 1 to revision

8 50 Number of Changes Overloaded method Modifier Add & Delete ReturnType Delete Add Revision Number Figure 5 Signature Change Types Over Revisions Threats to Validity The project uses a preliminary algorithm for taking into account overloaded functions while studying function evolution. The accuracy of the results obtained are dependent on the assumptions made in this algorithm. Secondly, while comparing two functions, the algorithm does not distinguish between addition/deletion of one parameter and addition/deletion of more than one parameter. For example, version 1 has a function void foo(int a), and in version 2 the function signature changes to void foo(int a, char b, int c), we record an addition as the parameter change. We do not count the total number of parameters added. We do not consider pseudo changes such as parameter name changes as long as the type remains the same. The project attempts to develop a methodology for signature analysis of functions for Java based projects in general. The results are obtained for one such project, Kenyon. The patterns observed in the signature changes are therefore specific to this project. 5.0 Conclusions And Future Work In this project we have established a framework for studying the evolution of Java classes and methods. We have applied this work on the Kenyon repository and identified change patterns. This work needs to be applied on more projects and larger repositories in order to find a general evolution pattern. Overloading in Java also provides a challenge in accurately identifying changes to methods. We may need to study other algorithms and works presented in this area to identify name changes and overloading.

9 6.0 References [1] User Manual: Kenyon, GRASE Lab Dept. of Computer Science, Baskin Engineering University of California, Santa Cruz [2] J.Bevan, Kenyon Project Homepage, 2005 [3] Sunghun Kim, E. James Whitehead, Jr., Analysis of Signature Change Patterns, 2005 [4] Another Tool for Language Recognition (ANTLR). [5] T. Lindholm, F. Yellin, The Java Virtual Machine Specification, 2nd Edition, AddisonWesley, [6] James Gosling, Bill Joy, and Guy Steele. The Java Language Specification. Addison Wesley, [7] Q. Tu, M.W. Godfrey, "An Integrated Approach for Studying Architectural Evolution", IWPC, Paris, 2002.