No abstract

This paper presents a model for understanding assembly programs for software maintenance. It is based on the theory that explicit representation of various structural and functional elements of code and multiple relationships among them will aid program Understanding and thus software maintenance. We present a parsing technique to extract all the required elements from assembly code to populate the model. The model is a reverse engineering technique. We use the term reverse engineering in its broad sense to include specification as well as design recovery. Most features of this model have been implemented in a tool named 'RETA' for Reverse Engineering Tool for Assembly programs.The model is useful for software maintenance activities such as program understanding, ripple effecl analysis, and program re-documentation. The ripple effect of a contemplated change is the parts of code that depend on the variable or a piece of code to be changed. Once the change is made, those parts need to be reexamined for possible modification. The model generates a functional menu for a given application. The menu describes the functionality of each routine. It is a hierarchical presentation of major program routines, the subroutines supporting each major routine and so on. A routine at any level of detail consists of one or more paths through the code. Paths are presented as control flow sequences between code blocks. Code blocks, and hence functionalities, use and modify data. The maintainer locates the routine to be modified at the lowest level of detail within the functional menu. This automatically slices out the set of paths, and hence the set of code blocks, that have a role in the functionality to be changed. The code blocks in the slice determine the data that are used and modified within the routine to be changed. Path analysis and associated data-used and datamodified information are used to determine which code blocks are to be changed and which data roles are to be modified. The same set of relations are applied in reverse to identify the ripple effect.KEY WORDS Software maintenance Design recovery Reverse engineering Assembly language Computer aided software engineeringThe high cost of software maintenance and the importance of effective maintenance techniques are widely known (Heninger, 1980;Lehman, 1980;Martin, 1983; Ramamoorthy ef af., 1984;Pressman, 1987; Hazzah, 1989). Even a small percentage improvement in the maintenance process can result in significant savings to organizations using large applications. Major improvements in the maintenance process can have far-reaching effects by reducing the investment required to support software, extending the useful life of existing systems, and expanding the range of problems that can be realistically addressed by large software applications.

No abstract

Research methodology, from cognitive science and artificial intelligence, is applied to theproblem of software representation to support the process of software change. A model of software to support change, suggested by thecurrentresearch, ispresented. Populating that model requires data from tasks related to codebased functional decomposition, data abstraction and functional data flows. A competence model for the task of code-based functional decomposition is proposed. The Problem of Software ChangeSoftware maintenance is the process of incremental change. It includes fixing incorrect software functions (corrective); responding to changing user needs (perfective); and responding to changes in the operating environment (adaptive) [PRE 871.Limits on our ability to effect needed change within large software applications is a serious problem. Not only is the cost of changing software high, but there is significant cost associated with lost opportunity. We often do not carry out needed change because the risk is too great. An improved ability to carry out change can lead to prolonged system life and thus reduce the redevelopment costs currently incurred when barriers to change force the prematureredesign andreimplemention of large software applications [RAM 84, IEEE 881.Current approaches to the problem include new design methodology to create maintainable software [AGR 861, automating current methodology in the form of CASE (computer aided softwareengineering) tools [CHA 861, softwaremodels for maintenance [CHE 89, HEI 891 and using descriptive research methods from cognitive science and artificial intelligence to study the ways in which experts cope with the problems of software change [OLS 871. The success of better design methodology depends onunderstanding what is required to support the process of change. CASE tools basedonexistingmaintenancemethodologyrun the risk of amplifying the current dilemma. The contribution of descriptiveresearch, at least during the discovery phase, depends on observing expert behavior in real situations (large software applications, not toy problems) and on our ability to reduce the observations to effective theory relating to theprocess of software change.Research studies of behavior in field settings can contribute to a better understanding of the change process and can provide a basisforimprovedthmry foruseinfutureCASE tools. However, there are many methodological questions that must be explored and answered before this objective can be achieved. This paper describes our current research related to software representation to support the process of change with emphasis on such methodological issues. The Research QuestionWe seek a computational model of the software change process, including models of each type of task carried out during the change process and how knowledge about the software is used to support that task. Current research is focused on two components of this problem. These are, "What needs to be known about a software application to change it?" and "How to obtain t...

No abstract