Software Maintenance Tasks Research Articles

Machine Learning and Software Engineering

Machine learning deals with the issue of how to build programs that improve their performance at some task through experience. Machine learning algorithms have proven to be of great practical value in a variety of application domains. They are particularly useful for (a) poorly understood problem domains where little knowledge exists for the humans to develop effective algorithms; (b) domains where there are large databases containing valuable implicit regularities to be discovered; or (c) domains where programs must adapt to changing conditions. Not surprisingly, the field of software engineering turns out to be a fertile ground where many software development and maintenance tasks could be formulated as learning problems and approached in terms of learning algorithms. This paper deals with the subject of applying machine learning in software engineering. In the paper, we first provide the characteristics and applicability of some frequently utilized machine learning algorithms. We then summarize and analyze the existing work and discuss some general issues in this niche area. Finally we offer some guidelines on applying machine learning methods to software engineering tasks and use some software development and maintenance tasks as examples to show how they can be formulated as learning problems and approached in terms of learning algorithms.

Source transformation in software engineering using the TXL transformation system

Many tasks in software engineering can be characterized as source to source transformations. Design recovery, software restructuring, forward engineering, language translation, platform migration, and code reuse can all be understood as transformations from one source text to another. The tree transformation language, TXL, is a programming language and rapid prototyping system specifically designed to support rule-based source to source transformation. Originally conceived as a tool for exploring programming language dialects, TXL has evolved into a general purpose source transformation system that has proven well suited to a wide range of software maintenance and reengineering tasks, including the design recovery, analysis and automated reprogramming of billions of lines of commercial Cobol, PL/I, and RPG code for the Year 2000. In this paper, we introduce the basic features of modern TXL and its use in a range of software engineering applications, with an emphasis on how each task can be achieved by source transformation.

Interprocedural control dependence

Program-dependence information is useful for a variety of applications, such as software testing and maintenance tasks, and code optimization. Properly defined, control and data dependences can be used to identify semantic dependences. To function effectively on whole programs, tools that utilize dependence information require information about interprocedural dependences: dependences that are identified by analyzing the interactions among procedures. Many techniques for computing interprocedural data dependences exist; however, virtually no attention has been paid to interprocedural control dependence. Analysis techniques that fail to account for interprocedural control dependences can suffer unnecessary imprecision and loss of safety. This article presents a definition of interprocedural control dependence that supports the relationship of control and data dependence to semantic dependence. The article presents two approaches for computing interprocedural control dependences, and empirical results pertaining to teh use of those approaches.

An empirical investigation of the relationship between spectra differences and regression faults

Many software maintenance and testing tasks involve comparing the behaviours of program versions. Program spectra have recently been proposed as a heuristic for use in performing such comparisons. To assess the potential usefulness of spectra in this context an experiment was conducted, examining the relationship between differences in program spectra and the exposure of regression faults (faults existing in a modified version of a program that were not present prior to modifications, or not revealed in previous testing), and empirically comparing several types of spectra. The results reveal that certain types of spectra differences correlate with high frequency—at least in one direction—with the exposure of regression faults. That is, when regression faults are revealed by particular inputs, spectra differences are likely also to be revealed by those inputs, though the reverse is not true. The results also suggest that several types of spectra that appear, analytically, to offer greater precision in predicting the presence of regression faults than other, cheaper, spectra may provide no greater precision in practice. These results have ramifications for future research on, and for the practical uses of, program spectra. Copyright © 2000 John Wiley & Sons, Ltd.

Mental representations of expert procedural and object-oriented programmers in a software maintenance task

This study examines the mental representations formed during program comprehension and maintenance by procedural and object-oriented (OO) experts. The programmer's mental representation reflects comprehension of a program and guides tasks carried out on the program, such as debugging and modifications. The goals of the research were three-fold: (a) to determine if and how the mental representations of procedural and OO experts differ, (2) to investigate the initial mental representation formed while comprehending a moderately large program and (3) to examine the evolution of the mental representations of procedural and OO experts over time as they carried out several modifications of the same program. Fifteen expert procedural programmers and 15 expert object-oriented programmers studied and then performed three program modifications during two sessions which were 7–10 days apart. They answered two question sets designed to elicit the categories of knowledge present in their mental representations at different times. The initial mental representation of the OO participants was dominated by problem domain-based knowledge and contained relatively little detailed program information. The procedural participants' initial representation was more balanced, containing domain-based knowledge and also substantial program detail. After performing the modifications, the procedural participants' representations remained essentially the same, while those of the OO participants became more balanced with respect to the program and domain elements. The results suggest that, regardless of paradigm, expert programmers build a mixed mental representation of a larger program, which includes detailed program knowledge as well as domain-based knowledge.

Supporting software maintenance with software engineering tools: A Computed task–technology fit analysis

Management has turned to software engineering tools designed to support software maintenance as a potential solution to maintenance productivity and quality problems. Once adopted by an organisation, however, these tools are often not used. A research model, based on a task–technology fit (TTF) model, is developed to explain the factors which lead to the use of the software maintenance support tools. Our model, which examines the nature of the fit between software tool functionality and maintenance task demands, consists of a TTF model augmented with a model of the maintenance task and a model of software maintenance tool functionality. Such an augmented model is necessary for moving beyond isolated exploratory studies of maintenance and for building on the existing research in software development and software tool utilization. Using this model, fit between maintenance task and technology characteristics is computed for two dimensions of fit derived from the task and technology models. Tests of hypotheses derived from the model demonstrate that task–technology fit, computed using methods for computing strategic fit, is associated with increased tool utilization. Our findings provide direction for the development of better maintenance support tools. This research extends the application and usefulness of TTF models and maintenance task and technology models so that future software maintenance research can build on tested models.

An empirical investigation of program spectra

A variety of expensive software maintenance and testing tasks require a comparison of the behaviors of program versions. Program spectra have recently been proposed as a heuristic for use in performing such comparisons. To assess the potential usefulness of spectra in this context, we conducted an experiment that examined the relationship between program spectra and program behavior, and empirically compared several types of spectra. This paper reports the results of that experiment.

An Evaluation of Knowledge Engineering Approaches to the Maintenance of Evolutionary Software

Reverse engineering and reengineering are two major research challenges in the software maintenance process. Reverse engineering is the process of rederiving the specification of a program; and reengineering is the process of modifying an already existing software to add additional functionalities or to correct any malfunction. The difficulty in these tasks are that software development commonly involves many software engineers with implicit assumptions about the behavior of each module. These assumptions are not documented and often leads to inconsistencies in the code. During reverse engineering, such assumptions may not be uncovered. These assumptions usually have complex dependencies, and are the cause of a lot of bugs when the software is reengineered. Many approaches and prototype tools have been developed to address these issues. Reverse engineering and automated program understanding tools have been developed to support the reverse engineering tasks; while various theoretical works on structural program analysis and programs for automated ripple effect analysis have attempted to deal with the reengineering process. These works can be classified into two main types of approaches: those using shallow knowledge or knowledge about the structure of the system and those utilizing deep knowledge or knowledge about the semantics and behavior of the software system. In this paper, we attempt to survey works that have been done under these two broad categories of approaches to deal with the software maintenance tasks, evaluate the strengths and drawbacks of each approach, and attempt to draw a conclusion on the advantages and disadvantages of the two main lines of approaches.

Computation of interprocedural control dependence

Program dependence information is useful for a variety of software testing and maintenance tasks. Properly defined, control and data dependencies can be used to identify semantic dependencies. To function effectively on whole programs, tools that utilize dependence information require information about interprocedural dependencies: dependencies that exist because of interactions among procedures. Many techniques for computing data and control dependencies exist; however, in our search of the literature we find only one attempt to define and compute interprocedural control dependencies. Unfortunately, that approach can omit important control dependencies, and incorrectly identifies control dependencies for a large class of programs. This paper presents a definition of interprocedural control dependence that supports the relationship of control and data dependence to semantic dependence, an efficient algorithm for calculating interprocedural control dependencies, and empirical results obtained by our implementation of the algorithm.

An empirical study of software maintenance tasks

AbstractAn empirical study of software maintenance tasks was carried out in a large Norwegian organization in the period 1992–93. More than one hundred randomly selected maintenance tasks were studied through interviews with the maintainers performing the tasks immediately before they started the tasks and immediately after they had completed the tasks. The collected data is used to develop distributions and to test 33 hypotheses about software maintenance. The findings from the study indicate, for example, that Application system documentation plays only a minor role as maintenance information source. The maintenance productivity, measured in LOC/effort, is predicted by the size of the task and type of change in the source code, but seems rather independent of language level, maintainer experience, application age and application size. There is an economy of scale for software maintenance tasks. The type of programming language does not correlate with proportion of unexpected maintenance problems, task complexity or task size. The proportion of corrective maintenance decreases with increasing age of the application.

Experience with the accuracy of software maintenance task effort prediction models

The paper reports experience from the development and use of eleven different software maintenance effort prediction models. The models were developed applying regression analysis, neural networks and pattern recognition and the prediction accuracy was measured and compared for each model type. The most accurate predictions were achieved applying models based on multiple regression and on pattern recognition. We suggest the use of prediction models as instruments to support the expert estimates and to analyse the impact of the maintenance variables on the maintenance process and product. We believe that the pattern recognition based models evaluated, i.e., the prediction models based on the Optimized Set Reduction method, show potential for such use.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

An investigation into software maintenance—Perception and practices

AbstractThis paper presents the results of a survey conducted on the perceptions and practices in software maintenance in five major companies in the United Kingdom. It is clear from the study that software maintenance is undergoing a significant transformation, in particular, in terms of its image, its relationship with users and in the nature of software maintenance tools required.The image of the software maintenance task appears to be changing from one which is dull, passive and isolated to one which is reactive, responsive and vital to the business. Maintenance departments are becoming more accountable to user departments and are developing a market orientation. The study found little use of existing software maintenance tools and identified a need for support technology which will facilitate communication between users, developers and maintenance staff.The paper presents the background to the investigation, the procedures followed and a summary of current practice. An analysis of the material highlights the main problems and trends identified within software maintenance practice and its implications upon organizational structure.

TuringTool: a user interface to aid in the software maintenance task

TuringTool is a source program viewing and editing system specifically designed to support the software maintenance task. TuringTool bases all of its views of the program on a single comprehensive viewing paradigm borrowed from program development environments: source text elision. It is shown how this paradigm can be used to represent several kinds of views appropriate to the maintenance of large source programs, including structural views and nonstructural views appropriate to the maintenance task and how it can be extended to allow dynamic creation of complex programmer-specified views using simple set theoretic operators to combine the effects of several views into one. The system exploits the highly structured nature of the Turing programming language to allow seamless viewing of programs consisting of many separately compiled source modules as one uniform source.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

Measuring the Psychological Complexity of Software Maintenance Tasks with the Halstead and McCabe Metrics

Three software complexity measures (Halstead's E, McCabe's u(G), and the length as measured by number of statements) were compared to programmer performance on two software maintenance tasks. In an experiment on understanding, length and u(G) correlated with the percent of statements correctly recalled. In an experiment on modification, most significant correlations were obtained with metrics computed on modified rather than unmodified code. All three metrics correlated with both the accuracy of the modification and the time to completion. Relationships in both experiments occurred primarily in unstructured rather than structured code, and in code with no comments. The metrics were also most predictive of performance for less experienced programmers. Thus, these metrics appear to assess psychological complexity primarily where programming practices do not provide assistance in understanding the code.