Aiding Program Comprehension by Static and Dynamic Feature Analysis

1. Aiding Program Comprehension by Static and Dynamic Feature Analysis By Thomas Eisenbarth, Rainer Koschke, and Daniel Simon Presented by Rab Harbart

2. The Who and the Where? • Thomas Eisenbarth some times works for Axivion, a company working to improve software design. He is a contributor to the Bauhaus Research Project, which means Building House • Rainer Koschke is a professor in software engineering at University of Bremen. Current research includes program analysis, feature location and reverse engineering. A co-founder of Bauhaus Research Project,for developing methods and tools for software maintainers • Daniel Simon is in Germany working as a leader for the Group Competence Application Intelligence and has some affiliation with Software Quality Systems

3. Outline • Motivation • Introduction • Terminology • Background • Analysis • Implementation • Case Study • Conclusions • Response • Wrap up

4. Motivation • In general it is very hard for programmers and reengineers to develop an understanding of a system’s implementation without having prior knowledge of that system • The goal is to demonstrate a technique that can build a mapping between what the user perceives as a system’s external visual behavior and relevant parts of code, as done through the use of dynamic and static analysis

5. Introduction • Knowing how a certain feature is implemented is always difficult and a problem when that feature is in need of being altered or expanded • Localization of the implementation is important • Instead of an exhaustive process of reverse engineering analysis, a feature-oriented search on components of interest is more desirable • The implementation to be discussed will use static and dynamic analysis as well as concept analysis to find a correspondence between features and components

6. Terminology • Feature (f)- a realized functional requirement, specifically an observable result that is significant to a user • Scenario (s)- a sequence of user inputs that invoke actions of a system, which will produce observable results. Scenarios may execute multiple features • Component- a computational unit of a system that consists of an interface and implementation to carry out services, example a subprogam or a set of subprograms • Subprogram- a function or procedure that is the lowest kind of component

7. Terminology • Execution Summary- a listing of all subprograms called during a program run • Execution Trace- a listing of the sequence that all performed calls were run • Feature-component Map- describes which components were used to implement a given set of relevant features

8. Background • Chen and Rajlich suggested a method of feature localization where software analysts search a system dependency graph (SDG) • Issues with an SDG- static analysis can show too much or too little- dynamic analysis, done at runtime and only offers results of a specific run • Wilde and Scully offer a set of steps for dynamic analysis- The program is executed twice using sets I (invoking input) and E (excluding input)- Through examination of the execution traces, subprograms implementing features of interest can be found • Issue- works with one feature at a time and can not find feature connectivity

9. Foreground • This paper suggests combining static and dynamic analysis to find components implementing the set of features of interest • Method- Identify set of features - Identify scenarios so all features in F are covered- Execution summary generates all required subprograms- A relation table is created s.t. - Perform concept analysis on - Identify relationships between scenarios and subprograms- Perform static dependency analysis • Feature-component Map is created from dynamic information produced when subprograms activating a feature of interest are run

10. Concept Analysis • Offers insight into binary relations and can be used to evaluate such things as class hierarchies and configuration structures • Here it is used to find a relationship between scenarios and subprograms to determine which subprograms are required for specific features • Concept Analysis- is based on the relationship between objects and attributes- formal context - common attributes- common objects- subprograms are objects and scenarios are attributes- (subprogram s, scenario S) are in the relation if s executes with S- is referred to as a concept

11. Concept Analysis • Attributes of are Objects with are • Here we see that is a subconcept of and that is a superconcept of

12. Lattice and Sparse Representation • The relation table can be viewed as a Lattice where T is the most general element and is the most specific element • A Sparse graph takes the values of the objects and incorporates them into the Lattice, marking the graph nodes with both object and attribute values

13. Dynamic Analysis • Dynamic analysis is responsible for constructing the Feature-component map by correctly using the formal context found in the concept lattice • This process determines which subprograms interact with the set of features in question • Keeping with the relation definition each scenario is designed to exploit one of the desired features. Each scenario is run separately but the results are collected to form a relation table

14. Concept Lattice Interpretations • These are some of the over views on how to interpret lattice relationships- scenarios requiring all subprograms are found at the top element- subprograms required for all scenarios are found at the bottom element- if a subprogram is jointly needed for more than one scenario, then the closest common node from the bottom element is where both are attached- a scenario that is shared by more than one subprogram has the closest common node from the top element to which both are attached

15. Static Dependency Analysis • With a concept lattice a set of subproblems for any set of relevant features are available but it is not possible to determine which can be combined to form a feature-specific components • Static Call Graph is a subset of a dependency graph where the nodes of this graph represent subprograms. This graph offers an intuitive depth-first search approach which does well to explain a subprogram only after all of it its own subprograms have been understood • Strongly connected component analysis - locates cycles in the call graph. All subprograms in cycle are added- dominance analysis locals dominate subprograms, if all paths to a nodecontain the node then is said to be dominate

16. Implementation • These experiments were conducted in a Unix environment- gcc was used to allow a command line switch to profile information- object code viewer and a Perl script was used to identified all functions- a profiler and Perl script gathered the executed functions from the execution summary- concepts was used, it is a concept analysis tool- Graphlet created the lattice- a Perl script to convert file formats from the previous applications • They also used Bauhuas toolkit to create a SDG and a resource flow graph (RFG) from dependencies- SDG uses data and control dependencies on statements and expressions- RFG uses global declarations and their relationships

17. Case Study • Two web browsers were used Mosaic and Chimera- lattice and required subprograms were found they dynamic analysis- relationships were found though concept analysis- table results are brought to you by static dependency analysis • The experiment compared the History (H) and Bookmark (B) functions- notable Chimera has less features then Mosaic • Question could some of Mosaics features be edited and added to Chimera?

18. Tests • History- (H1) browsing - (H2) use of the back button- (H3) use of the back and then forward button • Bookmark- (B1) just open and close bookmark window- (B2) adding a new bookmark- (B3) removing a bookmark- (B4) selecting a bookmark • For (H3) and (B2) conditions were made • HTML and X-windows functions were filtered out

19. Results • (1) all subprograms called(2) count of subprograms called for each specific experiment(3) count of subprograms found in the upper section of the lattice • Here the graph shows that there can be a significant partitioning of the history functions from the rest of the entire program

20. Further Results • This diagram shows there is a significant difference in the design for the history function between the two browsers • Where here there is almost no difference in the design structure for the the bookmarking function

21. Conclusion • Throughout the different usage scenarios this technique, using execution traces, found all components specific to a set of related features • Concept Analysis was used to find the most feature specific subprograms • Static Analysis was then performed on the resulting set to find any other feature-specific subprograms through the use of the dependency graph • The presented technique establishes a partial architecture which can be used for more goal-specific procedures in program comprehension and reverse engineering

22. Response • Do not like it

23. Source • Eisenbarth, T., Koschke, R., and Simon, D., (2001), "Aiding Program Comprehension by Static and Dynamic Feature Analysis", in Proceedings of International Conference on Software Maintenance (ICSM01), Florence, Italy, November 7-9, pp. 602-611

24. Wrap up • Questions or Parting Shots?