15-03-2011, 10:05 AM
Abstract
Well-designed object-oriented programs typically consistof a few key classes that work tightly together to providethe bulk of the functionality. As such, these key classes areexcellent starting points for the program comprehensionprocess. We propose a technique that uses webminingprinciples on execution traces to discover these importantand tightly interacting classes. Based on two medium-scalecase studies – Apache Ant and Jakarta JMeter – anddetailed architectural information from its developers, weshow that our heuristic does in fact find a sizeable numberof the classes deemed important by the developers.
KeywordsReverse engineering, dynamic analysis, webmining, programcomprehension
Introduction
Reverse engineering is defined as the analysis of a systemin order to identify its current components and their dependenciesand to create abstractions of the systems design[3]. A reverse engineering operation almost always takesplace in service of a specific purpose, such as re-engineeringto add a specific feature, maintenance to improve the efficiencyof a process, reuse of some of its modules in a newsystem, etc.[ In order to perform any of these operationsthe software engineer must comprehend a given programsufficiently well to plan, design and implement modificationsand/or additions. As such, program comprehensioncan be defined as the process the software engineer goesthrough when studying the software artifacts, with as goalthe sufficient understanding of the system to perform therequired operations [18]. Such software artifacts could includethe source code, documentation and/or abstractionsfrom the reverse engineering process.Gaining understanding of a program is a time-consumingtask taking up to 40% of the time-budget of a maintenanceoperation [26, 21, 4]. The manner in which a programmergets understanding of a software system varies greatly anddepends on the individual, the magnitude of the program,the level of understanding needed, the kind of system, ...[17, 28, 8, 22]As such sizeable gains in overall efficiency can be attainedby providing assistance to the software (reverse) engineerfor his/her program understanding process. We proposea heuristic in this paper that can help the engineer withfinding important classes that should be looked at first whenstarting the comprehension process.Studies and experiments reveal that the success of decomposinga program into effective mental models dependson one’s general and program-specific domain knowledge[25]. While a number of different models for the cognitionprocess have been identified, most models fall into oneof three categories: top-down comprehension, bottom-upcomprehension or a hybrid model combining the previoustwo [19]. The top-down model is traditionally employedby programmers with code domain familiarity. By drawingon their existing domain knowledge, programmers are ableto efficiently reconcile application source code with systemgoals. The bottom-up model is often applied by programmersworking on unfamiliar code [5]. To comprehend theapplication, they build mental models by evaluating pro gram code against their general programming knowledge[18].Because of the human cognition process , programunderstanding can never be a fully automated process: theprogrammer should be free to explore the software, with thehelp of specialized tools [9, 6]. These program explorationtools should identify those parts of the program that arelikely to be interesting from a program understanding pointof view [14]. For instance, in the case of object-orientedprograms – which is the main focus of our work – programexploration tools should reveal those classes that form coreparts of the design.Orthogonal to the selection of the cognitive strategy, i.e.which mental model to employ, is the choice between severaltechnical strategies, namely (1) static analysis, i.e., byexamining the source code, (2) dynamic analysis, i.e., byexamining the program’s behavior, or (3) a combination ofboth.In the context of object-oriented systems, due to polymorphism,static analysis is often imprecise with regard tothe actual behavior of the application [27]. Dynamic analysis,however, allows to create an exact image of the program’sintended runtime behavior. Our actual goal is to findfrequently occurring interaction patterns between classes.These interaction patterns can help us build up understandingof the software.In this paper we propose a technique that appliesdatamining techniques to event traces of program runs. Assuch, our technique can be catalogued in the dynamic analysiscontext. The technique we use was originally developedto identify important hubs on the Internet, i.e., pages withmany links to authorative pages, based on only the links betweenweb pages [16]. Hence, the Internet is viewed as alarge graph. We verify that important classes in the programcorrespond to the hubs in the dynamic call-graph of aprogram trace.We apply the proposed technique to two medium-scalecase studies, namely Apache Ant and Jakarta JMeter. Theresults show that the hubiness is indeed a good measure forfinding important classes in the system’s architecture.The organization of the paper is as follows. First, in Section2, we give an overview of the different steps in the processand the different algorithms we use. Section 3 showshow we plan to validate the results of our technique. Section4 explains the datamining algorithm in detail, while inSection 5 the results of applying our technique on the twocase studies are discussed. Section 6 explores related work,while Section 7 points to future research and concludes thepaper.
2 Overview of our proposed technique
The technique we propose can be seen as a 4-step process.In this section we explain each of the 4 steps
.Define execution scenario. Applying dynamic analysisrequires that the program is executed at least once. Theexecution scenario, i.e., which functionality of the programgets executed, is very important as it has a great influenceon the results of the technique. For example, if the softwareengineer is reverse engineering a banking application andmore specifically wants to know the inner workings of howinterest rates are calculated, the execution scenario shouldat least contain one interest rate calculation.On the other hand, by keeping the execution scenario specific,e.g. only calculating the interest rate, and not executingmoney transfers, the final results will be more precise.In terms of UML, this would be the same as limiting thenumber of use cases [13].
Non-selective profiling. Once the execution scenario hasbeen defined, the program must be executed according tothe defined scenario. During the execution all calls to andreturns from methods are logged in the event trace. For thisstep, we relied on a custom-made JVMPI1 profiler.Please note however that even for small and medium-scalesoftware systems and precisely defined execution scenarios,event traces become very large. Table 1 gives an overviewof some metric-data for our two case studies.
Datamining. By examining the event trace we want todiscover the classes in the system that play an active rolein the execution scenario. Classes that have an active roledepend on many other classes to perform functions forthem.In Figure 1 we show an example of a compactedcall graph. The compacted call graph is derived from thedynamic call graph; it shows an edge between two classesA ! B if an instance of class A sends a message to aninstance of class B. The weights on the edges give anindication of the tightness of the collaboration as it is thenumber of distinct messages that are sent between instancesof both classes.
download full report
http://googleurl?sa=t&source=web&cd=4&ve...CSMR05.pdf&ei=4et-TbKyOM7irAfX16XDBw&usg=AFQjCNEpn7trIRNCBU6kk85U3T8Q1uY98Q
Well-designed object-oriented programs typically consistof a few key classes that work tightly together to providethe bulk of the functionality. As such, these key classes areexcellent starting points for the program comprehensionprocess. We propose a technique that uses webminingprinciples on execution traces to discover these importantand tightly interacting classes. Based on two medium-scalecase studies – Apache Ant and Jakarta JMeter – anddetailed architectural information from its developers, weshow that our heuristic does in fact find a sizeable numberof the classes deemed important by the developers.
KeywordsReverse engineering, dynamic analysis, webmining, programcomprehension
Introduction
Reverse engineering is defined as the analysis of a systemin order to identify its current components and their dependenciesand to create abstractions of the systems design[3]. A reverse engineering operation almost always takesplace in service of a specific purpose, such as re-engineeringto add a specific feature, maintenance to improve the efficiencyof a process, reuse of some of its modules in a newsystem, etc.[ In order to perform any of these operationsthe software engineer must comprehend a given programsufficiently well to plan, design and implement modificationsand/or additions. As such, program comprehensioncan be defined as the process the software engineer goesthrough when studying the software artifacts, with as goalthe sufficient understanding of the system to perform therequired operations [18]. Such software artifacts could includethe source code, documentation and/or abstractionsfrom the reverse engineering process.Gaining understanding of a program is a time-consumingtask taking up to 40% of the time-budget of a maintenanceoperation [26, 21, 4]. The manner in which a programmergets understanding of a software system varies greatly anddepends on the individual, the magnitude of the program,the level of understanding needed, the kind of system, ...[17, 28, 8, 22]As such sizeable gains in overall efficiency can be attainedby providing assistance to the software (reverse) engineerfor his/her program understanding process. We proposea heuristic in this paper that can help the engineer withfinding important classes that should be looked at first whenstarting the comprehension process.Studies and experiments reveal that the success of decomposinga program into effective mental models dependson one’s general and program-specific domain knowledge[25]. While a number of different models for the cognitionprocess have been identified, most models fall into oneof three categories: top-down comprehension, bottom-upcomprehension or a hybrid model combining the previoustwo [19]. The top-down model is traditionally employedby programmers with code domain familiarity. By drawingon their existing domain knowledge, programmers are ableto efficiently reconcile application source code with systemgoals. The bottom-up model is often applied by programmersworking on unfamiliar code [5]. To comprehend theapplication, they build mental models by evaluating pro gram code against their general programming knowledge[18].Because of the human cognition process , programunderstanding can never be a fully automated process: theprogrammer should be free to explore the software, with thehelp of specialized tools [9, 6]. These program explorationtools should identify those parts of the program that arelikely to be interesting from a program understanding pointof view [14]. For instance, in the case of object-orientedprograms – which is the main focus of our work – programexploration tools should reveal those classes that form coreparts of the design.Orthogonal to the selection of the cognitive strategy, i.e.which mental model to employ, is the choice between severaltechnical strategies, namely (1) static analysis, i.e., byexamining the source code, (2) dynamic analysis, i.e., byexamining the program’s behavior, or (3) a combination ofboth.In the context of object-oriented systems, due to polymorphism,static analysis is often imprecise with regard tothe actual behavior of the application [27]. Dynamic analysis,however, allows to create an exact image of the program’sintended runtime behavior. Our actual goal is to findfrequently occurring interaction patterns between classes.These interaction patterns can help us build up understandingof the software.In this paper we propose a technique that appliesdatamining techniques to event traces of program runs. Assuch, our technique can be catalogued in the dynamic analysiscontext. The technique we use was originally developedto identify important hubs on the Internet, i.e., pages withmany links to authorative pages, based on only the links betweenweb pages [16]. Hence, the Internet is viewed as alarge graph. We verify that important classes in the programcorrespond to the hubs in the dynamic call-graph of aprogram trace.We apply the proposed technique to two medium-scalecase studies, namely Apache Ant and Jakarta JMeter. Theresults show that the hubiness is indeed a good measure forfinding important classes in the system’s architecture.The organization of the paper is as follows. First, in Section2, we give an overview of the different steps in the processand the different algorithms we use. Section 3 showshow we plan to validate the results of our technique. Section4 explains the datamining algorithm in detail, while inSection 5 the results of applying our technique on the twocase studies are discussed. Section 6 explores related work,while Section 7 points to future research and concludes thepaper.
2 Overview of our proposed technique
The technique we propose can be seen as a 4-step process.In this section we explain each of the 4 steps
.Define execution scenario. Applying dynamic analysisrequires that the program is executed at least once. Theexecution scenario, i.e., which functionality of the programgets executed, is very important as it has a great influenceon the results of the technique. For example, if the softwareengineer is reverse engineering a banking application andmore specifically wants to know the inner workings of howinterest rates are calculated, the execution scenario shouldat least contain one interest rate calculation.On the other hand, by keeping the execution scenario specific,e.g. only calculating the interest rate, and not executingmoney transfers, the final results will be more precise.In terms of UML, this would be the same as limiting thenumber of use cases [13].
Non-selective profiling. Once the execution scenario hasbeen defined, the program must be executed according tothe defined scenario. During the execution all calls to andreturns from methods are logged in the event trace. For thisstep, we relied on a custom-made JVMPI1 profiler.Please note however that even for small and medium-scalesoftware systems and precisely defined execution scenarios,event traces become very large. Table 1 gives an overviewof some metric-data for our two case studies.
Datamining. By examining the event trace we want todiscover the classes in the system that play an active rolein the execution scenario. Classes that have an active roledepend on many other classes to perform functions forthem.In Figure 1 we show an example of a compactedcall graph. The compacted call graph is derived from thedynamic call graph; it shows an edge between two classesA ! B if an instance of class A sends a message to aninstance of class B. The weights on the edges give anindication of the tightness of the collaboration as it is thenumber of distinct messages that are sent between instancesof both classes.
download full report
http://googleurl?sa=t&source=web&cd=4&ve...CSMR05.pdf&ei=4et-TbKyOM7irAfX16XDBw&usg=AFQjCNEpn7trIRNCBU6kk85U3T8Q1uY98Q
