Program view generation and change analysis using attributed dependency graphs

Impact analysis (IA) is a critical software maintenance task that identifies the effects of a given set of code changes on a larger software project with the intention of avoiding potential adverse effects. IA is a cognitively challenging task that involves reasoning about the abstract relationships between various code constructs. Given its difficulty, researchers have worked to automate IA with approaches that primarily use coupling metrics as a measure of the “connectedness” of different parts of a software project. Many of these coupling metrics rely on static, dynamic, or evolutionary information and are based on heuristics that tend to be brittle, require expensive execution analysis, or large histories of co-changes to accurately estimate impact sets. In this paper, we introduce a novel IA approach, called Athena , that combines a software system’s dependence graph information with a conceptual coupling approach that uses advances in deep representation learning for code without the need for change histories and execution information. Previous IA benchmarks are small, containing less than ten software projects, and suffer from tangled commits, making it difficult to measure accurate results. Therefore, we constructed a large-scale IA benchmark, from 25 open-source software projects, that utilizes fine-grained commit information from bug fixes. On this new benchmark, our best performing approach configuration achieves an mRR, mAP, and HIT@10 score of 60.32%, 35.19%, and 81.48%, respectively. Through various ablations and qualitative analyses, we show that Athena ’s novel combination of program dependence graphs and conceptual coupling information leads it to outperform a simpler baseline by 10.34%, 9.55%, and 11.68% with statistical significance.

Computer-aided software engineering (CASE) tools have been advocated for improving maintainer productivity and the quality of maintained software. While there is evidence that such benefits can accrue to organizations adopting maintenance-oriented CASE tools, a key problem in achieving the desired benefits from CASE tools is low usage of these tools by programmers. The previously tested Maintenance Tool Utilization Model was a first step in investigating the factors that affect whether maintainers choose to use CASE tools during maintenance projects. We test the addition of experience with software maintenance tools and with the software maintenance task to the Maintenance Tool Utilization Model. The role of experience is important because managers can provide training to increase experience and they can ensure that project teams have some members experienced with the tools or with the task. Data for the test are collected from software maintainers working on their organization’s normal maintenance project backlog. Tool experience is significant as both a main and interaction effect, but task experience adds little to the explanatory power of the Maintenance Tool Utilization Model. These results support the value of improved CASE tool training programs.

Computer-Aided Software Engineering (CASE) tools have been advocated for improving maintainer productivity and the quality of maintained software. While there is evidence that such benefits can accrue to organizations adopting maintenance-oriented CASE tools, a key problem in achieving the desired benefits from CASE tools is low usage of these tools by programmers. The previously tested Maintenance Tool Utilization Model was a first step in investigating the factors that affect whether maintainers choose to use CASE tools during maintenance projects. We test the addition of experience with software maintenance tools and with the software maintenance task to the Maintenance Tool Utilization Model. The role of experience is important because managers can provide training to increase experience and they can ensure that project teams have some members experienced with the tools or with the task. Data for the test are collected from software maintainers working on their organization’s normal maintenance project backlog. Tool experience is significant as both a main and interaction effect, but task experience adds little to the explanatory power of the Maintenance Tool Utilization Model. These results support the value of improved CASE tool training programs.

Software maintainers have long been acutely aware of the challenges involved in managing software change processes. Activities such as software migration, restructuring and reengineering all involve source code modification. They rely heavily on analysis and comprehension of the complex system structures and interactions that characterize both legacy and modern software systems. It is widely accepted that tools that support software analysis and maintenance tasks would go a long way towards addressing the constraints that software developers and maintainers work with on a day-to-day basis. Nevertheless, despite an abundance of tools, not many are used by practitioners and very few are considered essential for a particular development or maintenance task. This workshop examined design issues related to the development and application of tools to support software analysis and maintenance

The internal program representation chosen for a software development environment plays a critical role in the nature of that environment. A form should facilitate implementation and contribute to the responsiveness of the environment to the user. The program dependence graph (PDG) may be a suitable internal form. It allows programs to be sliced in linear time for debugging and for use by language-directed editors. The slices obtained are more accurate than those obtained with existing methods because I/O is accounted for correctly and irrelevant statements on multi-statement lines are not displayed. The PDG may be interpreted in a data driven fashion or may have highly optimized (including vectorized) code produced from it. It is amenable to incremental data flow analysis, improving response time to the user in an interactive environment and facilitating debugging through data flow anomaly detection. It may also offer a good basis for software complexity metrics, adding to the completeness of an environment based on it.

Existing research suggests that a considerable fraction (5-10%) of the source code of large scale computer programs is duplicate code (clones). Detection and removal of such clones promises decreased software maintenance costs of possibly the same magnitude. Previous work was limited to detection of either near misses differing only in single lexems, or near misses only between complete functions. The paper presents simple and practical methods for detecting exact and near miss clones over arbitrary program fragments in program source code by using abstract syntax trees. Previous work also did not suggest practical means for removing detected clones. Since our methods operate in terms of the program structure, clones could be removed by mechanical methods producing in-lined procedures or standard preprocessor macros. A tool using these techniques is applied to a C production software system of some 400 K source lines, and the results confirm detected levels of duplication found by previous work. The tool produces macro bodies needed for clone removal, and macro invocations to replace the clones. The tool uses a variation of the well known compiler method for detecting common sub expressions. This method determines exact tree matches; a number of adjustments are needed to detect equivalent statement sequences, commutative operands, and nearly exact matches. We additionally suggest that clone detection could also be useful in producing more structured code, and in reverse engineering to discover domain concepts and their implementations.

This article examines accusative-instrumental case alternations in Lithuanian, which is limited to four semantic classes of verbs: verbs of throwing, verbs of moving body parts, verbs of making sound and verbs of dressing/wearing clothing. Traditional grammars (e.g. Ambrazas 2006) have claimed that there is no semantic difference between the two cases in these contexts, but I will show that there is such a difference, albeit a subtle one. This allows us to understand why this alternation is possible: there is a difference in event structure, resulting in a different interpretation of the argument. When the argument is affected, or changed, accusative is used, and when it is peripheral to the event, the instrumental is used. This has implications for Case Theory, which aims to explain Case licensing in structural terms. I will argue that if a different morphological case is licensed, there is a difference in structure. By expanding the vP into multiple heads representing the subevents of a single event, we can reduce the accusative/instrumental alternation to a difference in structure.

Software development, testing, and maintenance tools must yield assurance information in a standardized form. Developers can use this information to argue that the software is adequate for its use and secure enough for the risk. NIST's Software Assurance Metrics And Tool Evaluation (SAMATE) project is developing specifications for software assurance tools. These specifications can include optional features for assurance information reports, encouraging tools to provide them. During maintenance, developers can collect this information to make explicit assurance cases

A method to remove variations in source codes

Program slices are useful in debugging, testing, maintenance, and understanding of programs. The conventional notion of a program slice, the static slice , is the set of all statements that might affect the value of a given variable occurrence. In this paper, we investigate the concept of the dynamic slice consisting of all statements that actually affect the value of a variable occurrence for a given program input. The sensitivity of dynamic slicing to particular program inputs makes it more useful in program debugging and testing than static slicing. Several approaches for computing dynamic slices are examined. The notion of a Dynamic Dependence Graph and its use in computing dynamic slices is discussed. The Dynamic Dependence Graph may be unbounded in length; therefore, we introduce the economical concept of a Reduced Dynamic Dependence Graph, which is proportional in size to the number of dynamic slices arising during the program execution.

This paper reports on an empirical strategy of software understanding during corrective maintenance of large-scale software with professional maintenance programmers. Hypotheses are key drivers in program understanding and influence the direction program understanding can take. This paper reports on the types of hypotheses programmers make, how they resolve them, and the strategies and comprehension processes they tend to use

Dependence analysis is a fundamental technique for program understanding and is widely used in software testing and debugging. However, there are a limited number of analysis tools available despite a wide range of research work in this field. In this paper, we present JavaPDG1, a static analyzer for Java bytecode, which is capable of producing various graphical representations such as the system dependence graph, procedure dependence graph, control flow graph and call graph. As a program-dependence-graph based analyzer, JavaPDG performs both intra- and inter-procedural dependence analysis, and enables researchers to apply a wide range of program analysis techniques that rely on dependence analysis. JavaPDG provides a graphical viewer to browse and analyze the various graphs and a convenient JSON based serialization format.

Program slicing is a well known family of techniques used to identify code fragments which depend on or are depended upon specific program entities. They are particularly useful in the areas of reverse engineering, program understanding, testing and software maintenance. Most slicing methods, usually targeting either the imperative or the object oriented paradigms, are based on some sort of graph structure representing program dependencies. Slicing techniques amount, therefore, to (sophisticated) graph transversal algorithms. This paper proposes a completely different approach to the slicing problem for functional programs. Instead of extracting program information to build an underlying dependencies’ structure, we resort to standard program calculation strategies, based on the so-called Bird-Meertens formalism. The slicing criterion is specified either as a projection or a hiding function which, once composed with the original program, leads to the identification of the intended slice. Going through a number of examples, the paper suggests this approach may be an interesting, even if not completely general alternative to slicing functional programs.

Program dependency artifacts such as call graphs help support a number of software engineering tasks such as software mining, program understanding, debugging, feature location, software maintenance and evolution. Java Enterprise Edition (JEE) applications represent a significant part of the recent legacy applications, and we are interested in modernizing them. This modernization involves, among other things, analyzing dependencies between their various components/tiers. JEE applications tend to be multilanguage, rely on JEE container services, and make extensive use of late binding techniques-all of which makes finding such dependencies difficult. In this paper, we describe some of these difficulties and how we addressed them to build a dependency call graph. We developed our tool called DeJEE (Dependencies in JEE) as an Eclipse plug-in. We applied DeJEE on two open-source JEE applications: Java PetStore and JSP Blog. The results show that DeJEE is able to identify different types of JEE dependencies.

Inheritance is one of the main concepts of object-oriented technology. It is claimed that the use of inheritance improves productivity and decreases development time. John Daly et al. reported on two experiments evaluating the effects of inheritance depth on program maintenance. They found that maintenance was performed significantly quicker for software using three levels of inheritance, compared to equivalent `flattened' software without inheritance. A second experiment found that maintenance for software using five levels of inheritance tended to be slightly slower than for equivalent software without inheritance. We report on similar experiments on the same question. Our results contradict those mentioned above. Several crucial changes were made to the setup. In particular longer and more complex programs were used, an inheritance diagram was available to the subjects, and we used more and different kinds of maintenance tasks. Furthermore, our experiment design compares zero level, three level and five level inheritance directly in one experiment. The results suggest that there is a tendency that deeper inheritance may complicate program understanding. But the effect depends rather on other factors such as complexity of the program and type of maintenance task than on inheritance depth. We found a high correlation between maintenance time and the number of methods to trace to gain program understanding. Further work should be done to identify other influence factors.